Nobody emails you to say your email is not arriving. That is the whole problem. An invoice goes out and is never paid. A password reset never lands. A reply to a customer sits in a junk folder for three days, and the first hint you get is a phone call: "I never received anything from you."
By then the damage is done, because mailbox providers rarely bounce suspicious mail — they file it. A rejection at least leaves a trace in your logs. Silent filing leaves nothing at all.
This guide follows a single message from your server to somebody's inbox. It shows where the three authentication protocols are consulted, what each one actually proves, and why having two of the three is frequently the same as having none.
What a receiving server actually sees
When your mail server connects to a recipient's mail server, the conversation has three separate layers. Each carries a different idea of "who sent this", and they do not have to agree.
1. The connection
The receiver sees an IP address. Before a single byte of your message arrives it can check the reverse DNS of that address, look it up on blacklists, and see whether the connection offers TLS. This layer is pure reputation — no cryptography, no domain name you control.
2. The envelope
Your server then announces the sender with MAIL FROM:. This is the envelope sender, also called the Return-Path or bounce address. Recipients never see it in their mail client. SPF checks this address, and only this address.
3. The message
Finally come the headers and body. The From: header is what the human reads — Accounts <billing@example.com>. It is written by the sending software and SMTP never verifies it. DKIM signs the message; DMARC is what ties everything back to this visible address.
What each protocol proves
SPF proves which servers may send
SPF (RFC 7208) is a TXT record at your domain listing the servers allowed to send mail for it:
example.com TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"
The receiver takes the envelope sender domain, fetches that record, and asks a single question: is the connecting IP in this list? The answer is pass, fail, softfail, neutral, or an error.
Two things make SPF fragile. It breaks on forwarding, because the forwarding server is not in your list. And it has a hard limit of ten DNS lookups, which is easy to exceed and fails silently — see the SPF 10-lookup limit.
DKIM proves the message was not tampered with
DKIM (RFC 6376) adds a cryptographic signature over selected headers and the body. Your sending platform signs with a private key; the receiver fetches the matching public key from DNS:
selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."
The signature names the signing domain in its d= tag. Because the signature travels inside the message, DKIM survives ordinary forwarding — which is exactly why it matters more than SPF for real-world delivery.
DMARC connects both to the visible From address
DMARC (RFC 7489) is published at a fixed subdomain:
_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
It does two things. It tells receivers what to do when a message claiming to be from your domain fails authentication, and it asks them to send you daily aggregate reports about everything sent in your name.
Alignment: the part most people miss
A message passes DMARC when at least one of SPF or DKIM passes and is aligned with the From: header domain. Alignment is a domain comparison, and it is where most surprises live.
- SPF alignment compares the envelope sender domain with the
From:domain. - DKIM alignment compares the signature's
d=domain with theFrom:domain. - Relaxed mode (the default) accepts a shared organisational domain, so
mail.example.comaligns withexample.com. Strict mode requires an exact match.
This is why a marketing platform can report "SPF passed" in its own dashboard while your mail still fails DMARC. The platform passes SPF for its bounce domain, not yours. Nothing is broken from its point of view — but the two domains do not align, so DMARC does not count it.
| Situation | SPF | DKIM | DMARC result |
|---|---|---|---|
| Mail from your own server | pass, aligned | pass, aligned | pass |
| Vendor signs with your domain | pass, not aligned | pass, aligned | pass |
| Vendor uses its own domain everywhere | pass, not aligned | pass, not aligned | fail |
| Message forwarded to another mailbox | fail | pass, aligned | pass |
| Spoofed message from an attacker | fail | none | fail |
What breaks without it
The failure modes are rarely dramatic, which is why they persist for months.
- No SPF or DKIM at all. Major providers treat unauthenticated bulk mail as suspicious by default. Transactional mail — receipts, resets, alerts — is the first to be filed as spam, and those are the messages users most expect to arrive instantly.
- SPF only, no DKIM. Everything works until a message is forwarded. Then SPF fails, there is no DKIM signature to fall back on, and the message fails DMARC at the second hop.
- A new vendor nobody told you about. Marketing signs up for a platform, sends a campaign from your domain, and that mail fails alignment. If your policy is enforcing, the campaign quietly disappears.
- Anyone can be you. Without an enforcing DMARC policy, an attacker can put
billing@example.comin the From header and the receiving server has no instruction to reject it.
p=reject before checking which systems send on your behalf. Your CRM, invoicing tool and helpdesk are not aligned, and their mail stops reaching anyone — instantly, silently, everywhere. Always stage the rollout, as described in going from p=none to p=reject.How to check it in 30 seconds
Run an Email Health report for your domain. It queries your authoritative name servers directly, so you see what receivers see right now, not a cached copy. It checks MX records, SPF (including the lookup count), DKIM for common selectors, DMARC policy and alignment, plus reverse DNS and blacklist status for each mail server.
If you only want one piece, the individual tools are faster: SPF Lookup, DKIM Lookup and DMARC Lookup. To find out why one specific message went astray, paste its headers into the Email Header Analyzer — it shows the authentication results the receiver recorded at the time.
Fix it
- List every system that sends mail as your domain: mail platform, CRM, invoicing, helpdesk, monitoring, website contact forms, payroll.
- Publish one SPF record covering all of them, ending in
-allor~all. One record only — two SPF records is a permanent error. - Enable DKIM signing at every platform, with the signing domain set to your domain rather than the vendor's.
- Publish
v=DMARC1; p=none; rua=mailto:dmarc@example.comand read the reports for a few weeks. - Fix each sender that shows up unaligned, then move the policy to
quarantineand finallyreject. - Check that every mail server IP has a valid reverse DNS record that resolves back to itself.
Then keep it that way
Authentication is not a project you finish. Records get edited during a migration, a DKIM key is rotated and only half-published, a vendor changes its sending infrastructure, or someone adds an include: that pushes you over the SPF lookup limit. None of those events announce themselves.
StatusDNS re-checks SPF, DKIM and DMARC on a schedule, together with your MX records and their blacklist status, and alerts you by email, Slack or webhook when a record changes or a check that was passing starts failing. That turns a silent regression into a message you receive the same day.