Deliverability
SPF, DKIM and DMARC
There is one question SMTP does not ask: is this sender allowed to write in this name at all? Three bolted-on procedures answer it — each incomplete on its own, load-bearing only together.
The gap in question
When SMTP was designed, everyone involved knew each other. The protocol therefore does not ask who is speaking: a sending server states a sender address, and the receiving server believes it. That is still the case. You can submit a message in the name of any domain you like, and technically there is nothing wrong with it.
Making matters worse, there are two senders. One is in the envelope and is stated at submission, the other on the letterhead and is displayed to the recipient. They need not match, and for legitimate purposes — bounces, mailing lists — they are not always allowed to.
C: MAIL FROM:<bounces-4711@sender.example> ← envelope: bounces go here
C: RCPT TO:<bert@example.com>
C: DATA
From: Your Bank <service@bank.example> ← letterhead: this is what the recipient sees
Both lines are in the same message and may name different domains. Without keeping the two apart, none of the three checks that follow makes sense.
SPF — who may submit
A domain publishes a list of servers in the DNS that are allowed to submit in its name. The receiving server compares the IP address of the other end against that list.
What matters is what this refers to: the envelope, not the letterhead. SPF says nothing about what the recipient is shown as the sender. A message can pass SPF and still appear in somebody else's name.
The second weakness is fundamental: SPF checks the IP of the submitting party. If a message is forwarded, the original server is no longer the one submitting — the forwarding one is, and it appears in no list. SPF then fails although nothing has been tampered with. That is not a flaw in the procedure but the direct consequence of what it anchors itself to.
DKIM — what was altered along the way
The sending server signs the message cryptographically: selected header lines and the content. The public key sits in the domain's DNS, the signature itself in an additional header line inside the message.
Because the signature travels with the message, it survives a forward — exactly where SPF fails. It only breaks when somebody alters something in the signed part; some mailing lists do that, by appending a footer or amending the subject.
What DKIM does not say: that the message is harmless. A valid signature establishes that the message comes from this domain and was not altered in transit. Spam can be cleanly signed — and often is.
DMARC — the bracket
The two procedures each have a gap: SPF checks the wrong sender, DKIM says nothing about the letterhead. DMARC closes both by imposing a third condition — alignment. The domain that passed SPF or DKIM has to match the domain the recipient sees on the letterhead.
Only this turns "something about this message was correct" into the statement "this message really does come from the sender being displayed". One of the two procedures has to pass and be aligned — not both. Which is why a correctly configured domain survives forwarding: SPF falls, DKIM carries.
DMARC additionally publishes an instruction to the recipient about what should happen to messages that fail — nothing, quarantine, or reject — and an address for reports.
What this means in practice
Anyone sending email themselves today sets up not one procedure but three — and in this order, because the wrong order costs mail: first extend the sender list in the DNS, then sign, and only then tighten the instruction. Set the policy to "quarantine" first and rebuild the sending path afterwards, and you will notice nothing when it breaks, because the recipient no longer rejects but quietly files away.
And even with all three in place, all you have bought is the ticket. They answer the question of whether the sender is genuine. Whether a message lands in the inbox is then decided by reputation — an independent judgement by the recipient about whether mail from this origin is welcome.