Dunning Email Deliverability: The Involuntary Churn Fix Hiding in Your DNS Records

Every guide to fighting involuntary churn — ours included — talks about the same three levers: extend the retry window, write better dunning copy, add an in-app banner as backup. All of that assumes the email gets to the inbox in the first place. For a meaningful share of SaaS accounts, it doesn't, and the failure is invisible on both ends. The customer never sees a payment-failed notice sitting in spam because they never check spam. You never see it either, because your dashboard shows the email as "sent," and sent isn't the same thing as delivered.

That number isn't about spam campaigns or marketing newsletters. It's about the baseline authentication posture of the domains sending all mail, transactional included — the same category your dunning emails, renewal reminders, and receipts fall into. If your domain is one of the majority sitting below full enforcement, you're not necessarily being blocked outright. You're just starting every send with less trust than a domain that is, and in 2026, that gap is the difference between a payment-failed email landing in the inbox and it landing nowhere a customer will ever look.

The rule change dunning guides don't mention

In February 2024, Gmail and Yahoo stopped treating email authentication as a best practice and started treating it as a requirement. Any sender pushing more than 5,000 messages a day to Gmail or Yahoo addresses — which covers most SaaS businesses with more than a few thousand subscribers — now has to meet a fixed bar just to be considered for the inbox at all, not the promotions tab, not spam, the inbox.

Source: Google and Yahoo bulk sender guidelines, effective February 2024.

None of this is exotic infrastructure. SPF and DKIM have existed since the 2000s. What changed is enforcement — miss any of these and the failure mode isn't a warning, it's your mail getting quietly deprioritized or dropped, with no bounce message telling you it happened. A dunning sequence built around a 21–28 day retry window with three carefully written touchpoints does nothing if none of those three emails clear this bar.

Where Stripe's default setup actually leaves you

By default, every Stripe account sends receipts, invoices, and failed-payment notices from the stripe.com domain. That's not a weakness on its own — stripe.com is enormous, well-authenticated, and has years of clean sending history behind it, which is exactly the kind of reputation a two-year-old SaaS domain doesn't have yet. A dunning email arriving "via stripe.com" often clears inbox filters more reliably than the same email would from a brand-new sending domain with no history.

The tradeoff is trust of a different kind: a customer who doesn't recognize "stripe.com" in their inbox is more likely to ignore it, or worse, assume it's a phishing attempt impersonating a payment processor — a genuinely common scam pattern that's trained people to be suspicious of exactly this kind of email. That's the reason Stripe offers a custom email domain option in the first place: swap in billing.yourcompany.com and the dunning email now looks like it came from a brand the customer actually signed up with.

Here's the part that doesn't get mentioned in most setup guides: turning on a custom domain moves the deliverability responsibility from Stripe's reputation onto yours, immediately, and Stripe's own documentation is direct about the consequence of getting it wrong — if your domain's SPF and DKIM records aren't correctly verified, receiving providers will route the mail to spam, or Stripe will refuse to send it at all, specifically to avoid damaging your domain's reputation further. That second outcome is the one worth sitting with. It's not a spam-folder problem you could eventually go find. It's a failed-payment email that never left Stripe's servers, for a customer who now has no idea their card was declined.

Look at the middle bar. Domains that "have" DMARC but left it at p=none get exactly zero protection from it — the policy exists on paper and does nothing when a check fails, because p=none means "tell me about failures, don't act on them." That's a reasonable starting point while you monitor for false positives, but a huge share of domains never move past it. If your custom email domain is one of them, you've done the visible part of the setup — the record exists — without doing the part that actually changes how Gmail and Yahoo treat your mail.

Why this is worse for dunning specifically than for marketing email

A dropped marketing email costs you an impression. A dropped dunning email costs you the entire subscription, and the customer doesn't even get the chance to notice something's wrong. Failed-payment emails that do arrive get opened at high rates — payment-related transactional mail typically sees open rates in the 55–70% range, well above marketing email, because a customer who sees "payment failed" in a subject line reads it. That number is meaningless for the slice of your dunning sequence that never reaches an inbox at all. It's not a low-performing email; it's an email that doesn't exist as far as the recipient is concerned.

This also breaks the usual diagnosis process. A SaaS team watching involuntary churn tick up will typically check the things covered in our Stripe dunning guide — is the retry window long enough, is Smart Retries on, is the copy generic. All of that can be perfectly tuned and still underperform if a chunk of the emails those settings generate never clear a spam filter. It looks like a copy problem or a timing problem. It's actually a DNS problem, and DNS problems don't show up in A/B test results on subject lines.

What to actually check

1. Confirm your custom domain's status in Stripe. Dashboard → Settings → Business → Custom email domain. A domain sitting in "pending" or showing a verification error isn't degraded, it's likely not sending some emails at all.
2. Look up your own DMARC record. Check whether it exists and what policy it's set to. If it's missing entirely or sitting at p=none with no plan to move past it, you're in the 58% Valimail found with no real enforcement.
3. Set up Google Postmaster Tools for your sending domain if you're on a custom one. It's free, and it shows your actual spam complaint rate — the same number Gmail uses to decide whether to keep trusting your mail — well before it becomes a visible problem.
4. Decide deliberately, not by default, whether stripe.com or your own domain is the right call. If you don't have the engineering time to monitor and maintain your own domain's authentication, stripe.com's inherited trust may recover more failed payments than a half-configured custom domain, even though it looks less "on brand."

None of this replaces the work covered in our guides to renewal reminders or the card account updater that fixes a failing card before it fails at all — those are the right playbook for the failures dunning is supposed to catch. This is the layer underneath all of it: the assumption that the email you sent is the email the customer received. For a meaningful share of accounts on Stripe, especially ones that switched to a custom domain without finishing the DNS side of the setup, that assumption is quietly wrong, and it shows up as involuntary churn that looks unfixable because nobody thought to check whether the fix was ever delivered.

If your involuntary churn number has been stubborn despite a well-tuned retry schedule, run it through our churn calculator before assuming the ceiling is real — a domain stuck at DMARC's monitor-only setting, or a custom domain with one wrong CNAME record, can be worth more recovered revenue than another round of copy testing. And once a customer does make it to the cancel page because a payment quietly failed and they never knew, CancelFlow is the layer that catches it there — surfacing exactly why they're leaving instead of losing that signal to a bucket labeled "other."

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.