Stripe & Paddle receipts: test payment confirmation deliverability

Most SaaS teams spend weeks polishing their onboarding email and then forget the single most important transactional email they send: the payment receipt. Stripe and Paddle both ship default receipt templates, and both can be customised to send from your own domain — but the defaults are not always well-authenticated, the custom setups are frequently misconfigured, and nobody tests them until a customer writes in asking where their invoice went.

Stripe default receipts

By default, when a payment succeeds, Stripe sends a receipt from receipts@stripe.com with your business name in the From display. Authentication is handled by Stripe: SPF, DKIM and DMARC all pass because the stripe.com domain is properly set up. In practice, default receipts from Stripe have excellent deliverability — Gmail Primary, Outlook Focused, Yahoo Inbox almost everywhere.

The trade-off: the email obviously comes from Stripe. For self-serve SaaS, this is fine. For higher-ticket B2B, a receipts@stripe.com From address can look off-brand, and some compliance teams route "third-party" billing email into quarantine.

Stripe custom email domain

Stripe lets you send receipts from your own domain via the Custom email domain feature in Settings → Emails. You add DNS records, verify, and from that point receipts go out as billing@yourbrand.com. Here is what actually gets configured and what to watch for:

1. SPF include — Stripe adds include:_spf.stripe.com to your sender domain. If you already have an SPF record, you must merge — not append a second record. Two SPF records is a hard fail.
2. DKIM CNAMEs — Stripe publishes two CNAME records at stripe1._domainkey and stripe2._domainkey. Propagation is usually < 1 hour. Both must resolve before verification.
3. Return-Path — Stripe uses a subdomain for bounce handling (typically bounces.yourbrand.com). Your DMARC policy must allow relaxed alignment, otherwise you will see DMARC failures at Gmail.
4. DMARC — if your main domain is on p=reject, receipts can still align because DKIM is signed with your domain. But check the actual aggregate reports for the first week.

Paddle: Merchant of Record specifics

Paddle is a Merchant of Record, which changes the receipt contract. Paddle's invoice is the legally required document, not yours. By default receipts come from help@paddle.com. You can customise the display name and reply-to, but the sending domain stays Paddle's because it needs to be tied to their tax compliance.

Deliverability of Paddle receipts is consistently strong — Paddle has been warming up paddle.com for years and maintains clean complaint rates. The risk area is the payment confirmation page redirect email many merchants add on top (e.g. "Welcome, your license key is X"). That oneis yours, sent from your own ESP, and it is the one that gets filtered.

Running a real seed test

The only way to know where receipts actually land is to trigger a real payment and observe. Here is a repeatable protocol that costs about $1 to run end-to-end:

1. Create a seed-test customer in Inbox Check. You receive 20+ real inbox addresses across Gmail, Outlook, Yahoo, Proton, GMX, Yandex, Mail.ru, Zoho and corporate providers.
2. In Stripe (or Paddle), create a $1.00 product. Charge each seed address, one at a time, using a live test card or a real card you will refund.
3. Wait 5 minutes. Pull the test report. You now see which providers inboxed, promoted, or junked the receipt — and you have screenshots for each.
4. Refund the test charges. Stripe and Paddle both support one-click refund; fees on $1 transactions are negligible.

The $1-real-purchase method is the only way to capture the full email pipeline, including any post-payment email your own app sends. Test-mode charges skip some of the Paddle tax workflow and therefore do not exercise the real email path.

Common failures we see

1. SPF flattening broke the include

Teams using a tool like EasyDMARC or dmarcian often flatten SPF for speed. When Stripe updates its sending IP ranges, flattened records go stale and receipts start bouncing at strict receivers (Proton, some enterprise Exchange).

2. DMARC forensic = reject and Gmail aggressive filtering

If your DMARC rua and ruf are both firing, and your policy is p=reject, small alignment issues between Stripe's Return-Path subdomain and your org domain cause Gmail to bounce. Move to p=quarantine for the first month of a custom Stripe domain rollout.

3. Reply-To that does not exist

A receipt with Reply-To noreply@yourbrand.com that bounces when a customer replies is a trust hit. Use a real, monitored inbox — billing@ or support@.

4. No monitoring

Almost every team we talk to does not know their receipts went to Spam until a customer tells them. Run a seed test on every release, especially after any DNS change.