Email Deliverability: Why SPF, DKIM and DMARC Decide Whether Your Mail Arrives

Somewhere in your sending logs there is a line that says delivered. Then a customer writes in to ask why the password reset never arrived. Both things are true at the same time, and the gap between them is where most email problems live.

Your provider accepted the message and handed it off. After that, a receiving server you do not control decided what to do with it: inbox, spam folder, or a rejection your application never saw. That decision rests largely on three DNS records and the policy connecting them. None of them are hard to publish. All of them are easy to publish wrongly, and the ways they break are quiet.

What "delivered" actually means at the other end

When your provider reports a successful send, it usually means the receiving server accepted responsibility for the message. It does not mean a person saw it, and it does not mean the message will not be filtered afterwards.

The receiving server makes its decision using authentication results attached to the message. Those results travel in headers you can read if you look at a real copy of the message in a mailbox rather than a test preview. Three mechanisms do the work: SPF checks where the message came from, DKIM proves the message was not altered, and DMARC tells the receiver what to do when either check fails to line up with the address your customer actually sees.

SPF covers the envelope, not the message

SPF is a DNS text record listing the servers allowed to send mail using your domain in the envelope — the hidden return address, not the visible From line. A record looks roughly like a list of included providers ending in either a hard fail or a soft fail.

Two constraints cause most real breakage. First, evaluating a record is limited to ten DNS lookups. Every service you add with an include statement spends lookups, and those services often include further services. Long chains quietly stop working, and the failure arrives as a permanent error rather than a warning, so mail from a vendor that worked last year simply starts failing. Second, a domain must publish exactly one SPF record. When marketing adds one and engineering adds another, the result is not a merge — it is a permanent error on every message.

The other thing to understand is that SPF does not survive forwarding well. When a mailbox forwards mail, the forwarding server becomes the sender, and the original IP no longer matches your record. That is not a bug you can configure away; it is why the second mechanism exists.

DKIM signs the message itself

DKIM attaches a cryptographic signature to each message. The signature names a signing domain and a selector, and the matching public key sits in DNS under that selector. A receiver can therefore verify that the message really came from the domain that signed it and that the signed parts were not modified in transit.

Two practical notes matter more than the theory. First, key length: 1024-bit keys still verify, but 2048-bit is the sensible default for anything you are building now. Second, use more than one selector when more than one system sends mail for you. Separate selectors for transactional and marketing traffic mean you can rotate a key or retire a platform without touching the other stream, and it keeps reputation data from different sending patterns from being blended into one bucket.

DKIM also gives you something SPF cannot: a signature that still validates after a message has been forwarded, as long as the signed content is unchanged.

DMARC is a policy, and alignment is the point

A DMARC record at your domain publishes a policy for messages that fail authentication, plus an address where receivers can send reports. It is published on the domain your customer sees in the From line, and it only counts as passing when an authenticated identifier aligns with that domain.

Alignment is the part teams skip, and it is the cause of the most confusing failures. SPF can pass on the envelope domain while the visible From domain belongs to someone else. DKIM can pass on a signature from your email provider's own domain while the From line shows yours. Both checks succeed, both are useless to DMARC, and the message fails. The fix is configuration, not code: authenticate the third-party sender for your own domain so its signature and return path both belong to you.

Policies move in three steps. Monitoring publishes no enforcement and collects reports. Quarantine sends failures to spam. Reject refuses them outright. Monitoring is a temporary position for reading reports, not a destination. A domain sitting in monitoring for a year is a domain that anyone can spoof.

Aggregate reports are the other half of the point. They are unglamorous XML arriving daily, and they are the only reliable way to learn which services are sending as you before you tighten anything.

The mailbox providers turned this into an operational requirement

Authentication stopped being advisory in 2024. Gmail began requiring it in February 2024 for senders hitting 5,000 or more messages a day to personal Gmail accounts, and it counts volume across your primary domain — subdomains count toward the same total, so splitting traffic across them does not move you under the line. Once a domain crosses the threshold and is classified as a bulk sender, that classification does not expire.

The requirements are specific. Authenticate with both SPF and DKIM, publish a DMARC record with at least a monitoring policy, and make sure the visible From domain aligns. Keep user-reported spam below 0.1%, and never let it reach 0.3%, because above that threshold Gmail removes access to delivery escalation entirely until a clean week passes. Marketing and promotional mail must support one-click unsubscribe through list headers; an unsubscribe link in the body of the message does not satisfy that requirement, and transactional mail such as password resets is excluded.

From November 2025 Gmail began ramping up enforcement on non-compliant traffic, with both temporary and permanent rejections, and added a compliance dashboard to Postmaster Tools. Yahoo applied comparable rules from February 2024. Microsoft held out and then moved faster: since 5 May 2025, mail from high-volume domains to its consumer mailboxes that fails SPF, DKIM or DMARC is rejected outright rather than filtered, with a permanent 550 5.7.515 error.

The rejection codes are worth knowing because they tell you exactly what to fix. SPF failures surface as 4.7.27, DKIM failures as 4.7.30, a missing DMARC record or a record without a policy as 4.7.31, and From-header misalignment as 4.7.32. Missing reverse DNS shows up separately as 4.7.23 or 5.7.25. If you see 4.7.31 on a domain you were sure was configured, check that the record actually contains a policy tag and not just a version string.

The standard itself changed in 2026

The original DMARC document was informational — a description of what the industry had already agreed to do. In May 2026 it was replaced by a Standards Track specification, RFC 9989, which obsoletes RFC 7489 and the earlier extension for public suffix domains. Aggregate and failure reporting were split into their own documents, RFC 9990 and RFC 9991.

Four changes affect how receivers read your record. Discovery of the organizational domain now uses an algorithmic walk up the DNS tree instead of a downloaded public suffix list, and a new tag lets a name declare its own role in that hierarchy. A new policy tag specifically covers subdomains that do not exist — the ones attackers love to forge, like a billing subdomain you never provisioned — and rejecting mail from those closes a gap that previously required guesswork. The percentage tag is gone, replaced by a simple testing flag that either applies your policy fully or treats the domain as monitoring only. And the report interval and report format tags were removed: reports are XML and arrive on the receiver's schedule.

For most senders the practical work is small. Existing records keep working. If you carry a percentage tag, drop it and phase enforcement through monitoring, quarantine and reject instead. If you have the appetite, add the non-existent-subdomain policy set to reject.

A rollout that does not break your mail

Start with an inventory, not a DNS change. List every system that sends mail as your domain: the transactional provider, the CRM, the support desk, the invoicing tool, the application's own SMTP relay, and anything a marketing team bought without telling you. The inventory is the whole job; the records are the easy part.

Publish a monitoring record with a reporting address someone actually reads, and leave it alone for a few weeks. Then fix alignment source by source, starting with whichever source appears most often in the reports. When the reports are clean — no unknown sending sources, no alignment failures — move to quarantine, watch for a week, then move to reject.

Separate your streams while you are at it. Marketing and transactional mail have different complaint profiles, and a bad campaign should not degrade password resets. Subdomains give you that separation without changing your public identity.

The checks that pay off every week

Look at the authentication results on a real message that landed in a real inbox, not a preview. Configure Postmaster Tools or an equivalent so you see spam rate and compliance status rather than guessing. Count your SPF lookups periodically and write the number down, so the day a vendor adds an include chain you notice the figure moving.

Handle bounces and complaints as product behaviour, not as noise. Hard bounces should remove an address quickly; complaints should suppress it. Treat open rates as a rough signal only, because image proxies and prefetching make them unreliable as a delivery measure.

And test with seed mailboxes at each major provider after any DNS change. The five minutes that takes is the difference between finding a broken record during a deploy and finding it on a Friday evening when a customer cannot reset a password.

Boring and verifiable beats clever

There is no trick to this work. Three DNS records, correctly aligned, published once and monitored on a schedule, will do more for your delivery rate than any copy change to the email itself. The failures that hurt are almost never exotic: two SPF records, a vendor that was never authenticated for your domain, a monitoring policy nobody ever tightened, a forwarding path that quietly broke alignment.

Fix those, keep reading the reports, and the line in your logs that says delivered starts meaning what your customers experience.