Email deliverability: SPF, DKIM and DMARC, and what they actually prove
Three DNS records, three different questions. What each one proves, why forwarding is where deliverability goes to die, and what a platform publishes for you — and what no record can promise.
Email deliverability: SPF, DKIM and DMARC
Every email that arrives claims to come from a domain, and the server receiving it has exactly one way to check that claim: ask the domain's DNS. Three records carry the answer, and each one answers a different question. This page is about what each record actually proves, what breaks when one of them is missing, why forwarding is where deliverability goes to die, and what gets published for you when your domain's mail is set up here.
Three records, three questions
SPF answers: which mail servers may send mail for this domain? It is a TXT record holding a list of sending servers. When mail arrives, the receiver looks up the list and checks the address of the server that connected to it. SPF speaks for the envelope — the path the message travelled — not for anything inside the message.
DKIM answers: did the domain's own server sign this message, and did anything change it on the way? The sending server signs selected headers and the body with a private key; the domain publishes the matching public key in DNS. The signature travels inside the message, so it survives relaying — as long as nothing along the way rewrites what was signed.
DMARC answers: what should a receiver do when the first two fail, and where should it report what it found? DMARC is a policy record. It ties the other two to the domain your reader actually sees in the From: header, says whether failures should be delivered, quarantined or rejected, and asks receivers to send you aggregate reports either way.
| Record | What it proves | What breaks without it |
|---|---|---|
| SPF | The server that handed the mail over was authorized by the domain | Receivers judge you on reputation alone, and any server can put your domain in an envelope |
| DKIM | The message is what the sending server signed, unaltered | Nothing survives forwarding with proof attached |
| DMARC | Failures have a stated policy, and the checks apply to the domain readers see | Receivers invent their own handling of failure, and you learn nothing from it |
What breaks when one is missing
Without SPF, a receiver has no list to check against, so it falls back on reputation and content heuristics. Mail may still arrive, but nothing about it is verifiable, and an impersonator has an easier job.
Without DKIM, no proof travels with the message. A receiver that wants to know whether the body was altered in transit has no way to tell — and, as the next section explains, relays rewrite things more often than senders expect.
Without DMARC, the failures have no policy. A receiver that sees SPF pass but DKIM fail has to guess, and different receivers guess differently. DMARC is also the only one of the three that produces feedback: its aggregate reports tell you who is sending mail as your domain, authorized or not. Large receivers now expect DMARC on mail sent at volume, and treat its absence as a signal in itself.
The three records are complementary by design. SPF authorizes a path, DKIM signs the content, and DMARC tells receivers how strictly to judge the pair. One alone proves very little.
Forwarding, where deliverability goes to die
Forwarding breaks SPF by construction. A forwarder receives your mail and re-sends it from its own servers, so the server the final receiver sees is no longer on your SPF list — even though nothing about the message is wrong. SPF checks the last hop of the journey, and forwarding adds a hop you do not control.
DKIM is the reason some forwarded mail still arrives. The signature travels inside the message, so it survives a clean relay untouched. But not every relay is clean: mailing lists add headers and footers, some auto-forwarders rewrite links, and anything they touch that the signature covered breaks it.
DMARC judges the pair against the From: domain, which is where alignment comes in. Forwarded mail usually fails SPF alignment but can pass on DKIM — so a message that would be rejected on SPF alone survives because its signature held. When a mailing list mangles both, DMARC has no leg to stand on, and the receiver's policy decides. This is the mechanism behind "mail I send to one person arrives, and the same mail through a list does not": the records did not change, the path did.
How mail records are provisioned here
When a domain is registered with Zeso, the provisioning pipeline configures its mail records alongside everything else the domain needs — the same pipeline that creates the DNS zone, sets nameservers and issues the TLS certificate. SPF, MX and DMARC are published automatically, so mail authenticates from the first message without you editing a zone file.
Two properties of that mechanism are worth knowing. The platform maintains the records, so changes to its sending infrastructure are updates to your zone that you never have to make. And because the records are platform-maintained, a hand-edited duplicate is not a tweak but a conflict: two SPF or two DMARC records at the same name are ambiguous to receivers and to us. If you need a record the platform did not publish, add it beside the existing ones rather than over them — and see also: the DNS explained article, for how the zone itself resolves.
What these records do not promise
None of these records promises that mail is delivered, and no provider can promise inbox placement — anyone who does is selling a number they do not control. What the records prove is authorization: that the sending server was permitted, that the content is unaltered, and that failures have a policy. Receivers weigh that alongside reputation, engagement history and content, most of which is earned message by message.
That is the honest framing: these records are table stakes, not magic. Missing them reliably hurts. Having them reliably earns you the right to be judged on the mail itself.