Why Your Dunning Emails Go to Spam: SPF, DKIM & DMARC Explained (2026)

Dunning email deliverability fails most often for a reason that has nothing to do with the email itself: the sending domain never passed the three checks a mailbox provider runs before it reads a single word of the message — an SPF record, a DKIM signature, and a DMARC policy. Get the copy and the timing exactly right, as our other dunning guides cover in depth, and it still will not matter if Gmail, Outlook, or Yahoo route the message straight to spam or drop it before delivery. This guide covers the part almost nobody writes about: what these three DNS records actually check, how sender reputation decides the rest once authentication passes, the setup mistakes that quietly cap recovery, and an honest answer to how much of this a tool like Revova can — and cannot — do for you.

We build the software that sends these emails for other people’s Stripe, Paddle, Braintree, Chargebee, and Recurly accounts, and the single most common support conversation we have is not about subject lines or send times — it is a founder asking why their open rate suddenly cratered, and the answer is almost always sitting in a DNS record they never touched. This is the guide we point people to before we point them anywhere else, because no amount of tuning a recovery sequence’s wording matters until the underlying delivery pipe is proven trustworthy to Gmail, Outlook, and Yahoo.

None of this is exotic. SPF, DKIM, and DMARC are decades-old, well-documented internet standards that every legitimate transactional sender — receipts, password resets, shipping notifications — already relies on. Dunning email is unusual only in how much revenue rides on a handful of messages reaching an inbox at exactly the right moment in a billing cycle, which makes a silent deliverability failure on this specific email category more expensive than almost any other kind of email a subscription business sends.

Why dunning emails land in spam even when the copy is perfect

A dunning email lands in spam when a mailbox provider’s automated systems decide, before a human ever sees it, that the sending domain either cannot be verified or does not have enough earned trust to reach the inbox — and neither of those decisions has anything to do with whether the subject line is good or the send time is right. Gmail, Microsoft (Outlook/Hotmail), and Yahoo each run their own spam-filtering pipelines, but all three lean heavily on the same foundation: can this message be authenticated back to a real, consistent sending identity, and does that identity have a track record of sending mail people actually want.

This is the gap almost every other dunning resource skips. Our own guides on dunning email examples and templates and setting up a dunning email sequence cover what to say and when to say it — the content and timing layer. Neither one can help if the message never reaches an inbox at all. A technically perfect, decline-reason-personalized, timezone-aware email sent from an unauthenticated domain routinely loses to a mediocre generic template sent from a domain with clean SPF, DKIM, and DMARC and a healthy sending history. If you have not read what is dunning yet and want the foundation first, that is a good starting point before this one — this guide assumes you already know why dunning matters and want to know why it is not working.

The three DNS records mailbox providers check before anything else

SPF, DKIM, and DMARC are three separate DNS TXT records that together let a receiving mail server verify that a message genuinely came from your domain and was not altered along the way. They are complementary, not redundant — each one closes a different gap, and DMARC specifically depends on the other two being set up correctly to do its job.

SPF record — which servers are allowed to send as you

An SPF (Sender Policy Framework) record is a DNS TXT record on your sending domain that lists the mail servers authorized to send email on your behalf. When a receiving server gets a message claiming to be from yourdomain.com, it looks up that domain’s SPF record and checks whether the connecting server’s IP address is on the approved list. A record commonly looks something like v=spf1 include:_spf.yourprovider.com ~all — the includemechanism adds a provider’s servers to your allowed list, and the trailing qualifier tells receiving servers how strictly to treat a mismatch. The most common DIY mistake is not writing the record wrong, but forgetting to add every service that sends on the domain’s behalf — your dunning tool, your marketing ESP, your transactional receipts — to the same record, since a domain can only have one SPF record and each sender needs its own include line inside it.

DKIM signature — proof the message was not altered

DKIM (DomainKeys Identified Mail) works differently: instead of checking which server sent the message, it attaches a cryptographic signature to the message headers, generated with a private key your sending service holds. The receiving server pulls a matching public key from a DNS TXT record — typically at a path like selector._domainkey.yourdomain.com, where selector is a short string your provider assigns — and verifies the signature against it. If anything in the signed portion of the message changed in transit, or if the signature does not match the public key on file, DKIM fails. SPF and DKIM catch different failure modes: SPF stops an unauthorized server from claiming your domain; DKIM stops a message from being tampered with, or a spoofed message from lacking a valid signature at all.

DMARC policy — what happens when SPF or DKIM disagree with the From address

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer sitting on top of both. It is a DNS TXT record published at _dmarc.yourdomain.com that does two things: it requires SPF and DKIM results to be in alignment with the domain shown in the visible From: address, not just technically passing somewhere, and it tells receiving providers what to do when that alignment fails. The policy is set with a p= tag with three possible values — p=none (monitor only, deliver anyway, but generate aggregate reports), p=quarantine (route failing mail to spam), or p=reject (refuse it outright). DMARC also supports a rua tag pointing to an email address where you receive daily aggregate reports summarizing pass/fail rates across every source claiming to send as your domain — genuinely useful for catching a misconfigured tool before it becomes a spam problem.

Get all three passing and aligned, and a mailbox provider has confirmed your identity as far as DNS can prove it. That is necessary, but it is only half the picture — the other half, covered below, is whether recipients have actually been treating your mail as wanted.

How to actually set up SPF, DKIM, and DMARC for dunning email

Setting up all three is genuinely a DNS task, not a code task — you are adding TXT records through your domain registrar or DNS host (Cloudflare, Route 53, GoDaddy, Namecheap, and similar), and the records themselves are supplied by whichever service actually sends the mail. The order below is the one that avoids the two most common self-inflicted outages.

1. Decide on a sending domain or subdomain. Many teams send dunning email from a dedicated subdomain — something like mail.yourdomain.com or notify.yourdomain.com — rather than the root domain. This isolates the sending reputation of transactional and recovery email from your primary domain, so a reputation problem on one does not drag down the other.
2. Add the SPF record. Publish a single TXT record on the sending domain listing every service authorized to send on your behalf, combined into one record with the correct include mechanisms — a domain with two competing SPF records is invalid and will fail checks entirely.
3. Add the DKIM record. Your sending provider generates a public/private key pair and gives you the exact TXT record and selector to publish; paste it in verbatim, since a single truncated or malformed DKIM key will fail silently rather than throwing an obvious error.
4. Set a return-path domain that matches. The return-path domain (sometimes called the bounce domain, used for the technical Return-Path: header) should also live under your sending domain and be covered by the same SPF record — a return-path domain that points somewhere unrelated is a common reason SPF alignment quietly fails even when the record itself looks correct.
5. Publish DMARC at p=none first. Start in monitor-only mode and point the rua aggregate-report address somewhere you will actually check. Watch reports for one to two weeks, confirm every legitimate sender is passing, then move to p=quarantine, and only move to p=reject once you have confirmed nothing legitimate is still failing.
6. Warm the subdomain before sending at full volume. A brand-new sending domain or subdomain has no history with any mailbox provider, so a sudden burst of volume on day one can land in spam even with perfect DNS records, simply because the provider has nothing to trust it against yet. Ramp volume gradually over one to two weeks — a small, engaged batch first, larger batches as engagement signals accumulate.

Sender reputation: the layer no DNS record fixes

Sender reputation is a mailbox provider’s ongoing, mostly invisible score of how trustworthy your sending domain and IP address are, and it keeps being recalculated long after your SPF, DKIM, and DMARC records are already correct. A domain can pass every authentication check and still lose inbox placement over time if its bounce rate climbs, its spam complaint rate rises, or its engagement signals — opens, clicks, replies, and how often recipients mark mail as wanted — trend downward. Authentication proves identity once, at send time; reputation is a rolling judgment built from weeks of behavior.

Three signals matter most, and dunning email has a structural advantage on at least one of them:

• Bounce rate. A hard bounce (invalid or nonexistent address) that keeps getting resent damages reputation fast — this is exactly why list hygiene and address suppression matter for a recovery sequence, not just for marketing email.
• Spam complaint rate.Every time a recipient clicks “report spam” instead of unsubscribing, it counts against the sending domain’s reputation with that provider specifically. Gmail and Yahoo both publish bulk-sender guidance asking senders to keep this rate low and to make unsubscribing genuinely one click, precisely because a rising complaint rate is one of the strongest negative signals a mailbox provider tracks.
• Engagement signals. Opens, clicks, and replies tell a provider real humans want this mail. This is where dunning email has a structural edge over marketing email: because the recipient has direct, self-interested reason to open it — their subscription is at risk — dunning emails commonly see notably higher engagement than typical marketing sends, which is also exactly why a deliverability failure on this category of email is such an expensive mistake to make.

Put engagement in context against the same open- and click-rate benchmarks we cite across our dunning guides — this is the ceiling reputation is trying to protect, not add to:

Google’s bulk sender guidelines (which apply once a domain sends meaningful volume to Gmail addresses) are the clearest public statement of how seriously mailbox providers take this: authenticated SPF and DKIM, a published DMARC policy, a low spam complaint rate, and a functioning one-click unsubscribe are treated as baseline requirements, not best practices. A domain that ignores any one of them risks having mail throttled or blocked at the provider level, independent of anything about the message content.

Beyond DNS: how spam filters weigh everything else

Passing SPF, DKIM, and DMARC gets a dunning email past the front door — it does not guarantee a seat at the table. Once a message is authenticated, mailbox providers layer additional, largely proprietary signals on top before deciding final placement, and understanding what those signals broadly reward is useful even though none of the providers publish exact weightings.

• Recipient-level history. Gmail in particular personalizes inbox placement per recipient — a customer who has opened and clicked several of your previous dunning emails is far more likely to see the next one land in their primary inbox than a recipient who has never engaged with your domain before, independent of your domain-wide reputation.
• Link and domain reputation inside the message.Every link in a dunning email — the “update your payment method” button, in particular — points to a domain that has its own reputation, separate from your sending domain. Linking to a URL shortener, an unfamiliar third-party checkout host, or a domain with a poor reputation of its own can drag down an otherwise well-authenticated message.
• Feedback loops. Several large mailbox providers offer feedback loops that report spam complaints back to the originating sending service in near real time. A dunning platform that ignores these signals keeps sending to addresses actively marking mail as spam, which compounds the reputation damage instead of containing it.
• Consistency over time. A sending pattern that looks stable and predictable — similar volume, similar structure, similar send windows — reads as more trustworthy than one that spikes unpredictably, which is part of why a slow, monitored ramp beats an abrupt full-volume launch even after authentication is already correct.

None of these four signals are things a DNS record can fix, and none of them are things a subject line rewrite fixes either — they are earned gradually, through consistent sending behavior and a list that genuinely wants the mail it receives. This is the layer that keeps deliverability a maintained discipline rather than a one-time technical project.

Deliverability mistakes that quietly cap dunning recovery

Most underperforming dunning sequences are not obviously broken — they send without error, and the sender has no idea a meaningful share never reached an inbox. These are the mistakes we see most often, roughly in order of how much damage they do:

• No SPF or DKIM at all. Still common on domains that migrated ESPs or added a new sending tool without updating DNS — the single fastest way to have every dunning email treated with suspicion by default.
• Publishing DMARC at p=reject on day one. Well-intentioned but backwards; it turns any small SPF or DKIM misconfiguration into silently blocked mail instead of a visible warning.
• Sending dunning email from the same domain and IP pool as bulk marketing email. A marketing campaign with a rough send — high complaint rate, aggressive frequency — drags down the shared reputation that your dunning sequence depends on, even though the two email types have nothing to do with each other.
• No subdomain warming before a volume launch. Turning on a dunning sequence for an entire existing customer base at once, from a brand-new sending domain, looks statistically identical to a spam burst to a mailbox provider that has never seen that domain before.
• No suppression list. Continuing to send to addresses that already bounced or filed a spam complaint damages sender reputation for every subsequent email from that domain, not just the ones sent to that address.
• A broken or hidden unsubscribe link.If unsubscribing is not genuinely one click, a meaningful share of recipients who want out will click “report spam” instead, which is far more damaging to reputation than a clean unsubscribe would have been.
• Never checking Google Postmaster Tools or equivalent reporting. Most teams find out about a deliverability problem when open rates visibly crater — weeks after the underlying cause started, and after a meaningful amount of recoverable revenue already went unseen.

Should you manage deliverability yourself, or let a tool help?

Plenty of technical teams run this entirely in-house, and for a team with existing DevOps or email-infrastructure experience, that is a reasonable choice. The honest trade-off is less about whether it is possible and more about whether it is the best use of a non-technical founder’s limited time, especially given that this work never really finishes.

The clearest way to think about it: SPF, DKIM, and DMARC are a setup cost, paid mostly once per domain. Sender reputation is a running cost, paid continuously in attention — watching Postmaster Tools, reviewing DMARC aggregate reports, keeping list hygiene clean, and reacting quickly when a number starts trending the wrong way. A founder weighing this against everything else on their plate is really deciding who carries that running cost, not just who configures the DNS records on day one.

Revova sends dunning, pre-dunning, and win-back email through infrastructure that is already warmed, monitored, and configured with correct authentication, and it automatically suppresses addresses that bounce or file a spam complaint so a reputation problem on one recipient does not spread to the rest of your list. It does not, and honestly cannot, add the DNS records to your domain for you — that step belongs to whoever owns the domain’s registrar account, and no SaaS tool can bypass that without asking for access you almost certainly should not grant. What a dedicated tool mainly buys back is everything downstream of that one setup step: ongoing reputation monitoring, suppression-list maintenance, and not having to become the person on your team who understands DMARC aggregate reports. Full plan and pricing details are on the Revova pricing page.

How to verify your dunning emails are actually landing

The only reliable way to know whether deliverability is a problem is to check authentication and reputation data directly, rather than inferring it from a falling open rate days or weeks after the fact. A short verification routine, run monthly at minimum and immediately after any change to your sending setup, catches most problems before they cost meaningful recovered revenue.

It helps to treat this the same way you would treat monitoring for a payment webhook or an API integration — something with an owner, a cadence, and a defined response when a number moves the wrong way, rather than something checked only when a customer happens to mention their card update email never arrived. A calendar reminder tied to whoever owns billing operations is usually enough; this does not need to be a full-time responsibility, it needs to be nobody’s forgotten one.

• Verify domain ownership in Google Postmaster Tools and check your spam complaint rate, IP reputation, and domain reputation panels — this is the closest thing to ground truth for Gmail-bound mail specifically.
• Check your DMARC aggregate reports (sent to whatever address your rua tag points to) for any source claiming to send as your domain that is failing alignment — this catches a misconfigured tool before it becomes a delivery problem.
• Confirm SPF and DKIM are both still passing after any change to your ESP, dunning tool, or DNS host — a routine migration is the single most common way a previously correct setup silently breaks.
• Compare your actual dunning open rate against the 30–40% benchmark. A domain-wide drop, especially one that lines up with a change you made, is a stronger deliverability signal than any individual customer complaint.
• Review your bounce rate and unsubscribe rate for a rising trend, which usually points to list hygiene rather than a copy or timing problem.

What to do if your dunning emails are already in spam

If you already suspect a deliverability problem, the fix is authentication first, reputation second — do not start by rewriting the emails, because copy changes cannot repair a failed SPF check or a damaged sender reputation.

1. Confirm SPF, DKIM, and DMARC are all correctly published and passing, using your DNS host’s TXT record lookup and your DMARC aggregate reports as the source of truth.
2. Check whether your DMARC policy is still sitting at p=none long after you meant to tighten it — or, less commonly, whether it jumped to p=reject before every legitimate sender was confirmed passing.
3. Review your suppression list and remove or stop sending to any address that has bounced or complained recently — continuing to email them actively damages the reputation of every other send.
4. If reputation has genuinely degraded, consider sending dunning email from a fresh, dedicated subdomain and warming it gradually rather than trying to repair the existing one’s history — a clean start is often faster than a slow rehabilitation.
5. Once authentication and list hygiene are both clean, give it several weeks of consistent, low-complaint sending before expecting reputation to fully recover — mailbox providers weigh recent history more heavily than a single clean week.

Once the underlying delivery problem is actually fixed, the content and timing work in our other guides starts paying off again — see dunning email examples and templates for copy that converts once it lands, and how to set up a dunning email sequencefor the cadence and decline-reason routing on top of it. If you are also running Stripe’s built-in retries alongside your dunning sequence, how Stripe Smart Retries works is worth reading too — retries and deliverable dunning email solve different halves of the same recovery problem.

For Google’s own published requirements for bulk senders, see Google’s bulk sender guidelines, and for the technical specification behind DMARC alignment and policy reporting, see the DMARC.org overview.

Frequently asked questions