Developers who work on billing recovery will debug everything: retry intervals, decline-code mapping, webhook idempotency, the card-update page's mobile layout. Then the recovery email — the artifact the whole system exists to deliver — goes out from a subdomain nobody warmed, with a subject line that reads like a phishing attempt, and lands in spam. The retry logic was perfect. The customer never saw it.
Dunning email has a deliverability problem that ordinary product email does not. It talks about money, failed payments, and updating card details, which is precisely the vocabulary spam filters and cautious humans are trained to distrust. It is also sent disproportionately to your least-engaged customers — the ones who have not opened anything in months — which is exactly the sending pattern that drags a domain's reputation down. Every unopened dunning email makes the next one more likely to be filtered. The failure compounds in the worst direction.
The fixes are mostly unglamorous infrastructure, and they are checkable. Send billing mail from a dedicated subdomain so its reputation is not hostage to your marketing sends, and authenticate it properly: SPF, DKIM, and a DMARC policy that is actually enforced rather than parked at monitor-only. Keep the from-name and from-address boringly consistent with what the customer saw at signup; a payment email from a name they do not recognize is a delete, or worse, a spam report. Put the card-update link on your real domain, never a shortener. And write subject lines that a bank would write — "Your payment didn't go through" survives filters and humans; "URGENT: action required on your account!!" survives neither.
Then instrument it like the revenue surface it is. Track delivery, bounces, and spam complaints per send, not per month. A hard bounce on a dunning email is diagnostic gold: it often means the account's contact email is dead, which means the subscription behind it is unrecoverable by email and should route to another channel immediately instead of burning four more sends. A complaint spike after a copy change is a rollback signal, not a rounding error.
For the full working list — authentication setup, subdomain strategy, copy patterns that stay out of the filter, and the per-send metrics worth alerting on — a deliverability checklist for dunning email that lands in the inbox lays it out in implementation order, written for the person who owns the sending pipeline rather than the person who owns the brand book.
Bounce policy deserves its own paragraph because billing teams routinely get it backwards. A hard bounce — the address does not exist — should end email attempts to that address immediately and reroute the account to whatever second channel exists, even if that channel is only a banner the customer sees at next login. Soft bounces, the full mailbox and the temporary server refusal, earn a short, bounded retry of the message itself, and then the same rerouting. What neither should trigger is the marketing team's usual reflex, suppressing the contact entirely: a suppressed billing contact is an account you have decided to let die silently. Keep the billing suppression list separate from the marketing one, review it like a failure queue in its own right, and treat every address on it as a small mystery worth one human look — a mistyped domain at signup accounts for more of them than anyone expects, and it is fixable in a single apologetic email to the corrected address.
Recovery systems are usually judged on retry intelligence. Fair enough. But a retry the customer never learns about is only half a recovery, and the other half lives or dies in the inbox. That is why Swipe Again's recovery work treats the email itself — its authentication, its timing, its plain-spoken copy — as part of the retry, not as the notification stapled to it.
Top comments (0)