SPF, DKIM & DMARC: How Email Authentication Works
Email authentication relies on SPF, DKIM, and DMARC — a set of interlocking systems — but most people misunderstand what they really do, and what they don’t protect.
Email was never designed with trust in mind. It was built in an era when the network was small, cooperative, and academic. The assumption was simple: if a message arrived, it came from the person listed in the header. That assumption no longer holds.
At a technical level, basic email does not force a sender to prove their identity—the visible "From" address is merely a text label. Without domain-level checks, anyone can impersonate a bank, an employer, or an individual.
Email authentication protocols fill this gap. They do not decide whether a message is wanted or scam-free, but they answer a narrower question: Is this message authorized to speak on behalf of this domain, and can that claim be verified?
Authentication Protocols Compared
| Protocol | What It Verifies | How It Works | Primary Vulnerability / Limitation |
|---|---|---|---|
| SPF (Sender Policy Framework) | Server Permission | Checks if the delivering IP address is listed in the sending domain’s DNS record. | Fragile: Easily broken by email forwarding or relays; does not check the visible "From" header. |
| DKIM (DomainKeys Identified Mail) | Message Integrity | Uses cryptographic signatures in headers verified via a public DNS key to prove no tampering occurred. | Identity Neutral: Does not verify if the signing domain matches the visible "From" address. |
| DMARC (Domain-based Message Authentication...) | Domain Alignment & Policy Enforcement | Requires SPF and/or DKIM domains to align with the visible "From" domain, and publishes enforcement policies. | Configuration Dependent: Only protects domains that explicitly set enforcement policies (quarantine or reject). |
SPF: Who Is Allowed to Send Mail
SPF allows domain owners to publish a list of authorized sending IP addresses in DNS. When a receiving server gets a message, it verifies the sender’s IP against that list.
However, SPF checks the envelope sender (the hidden return-path address used during delivery), not the visible "From" address you see in your client. Because SPF is tied to the physical delivery path, auto-forwarding, mailing lists, or intermediate relays break SPF checks even on legitimate emails. It stops low-effort spoofing, but it was never designed to stand alone.
DKIM: Proving the Message Wasn't Altered
DKIM handles integrity by attaching a cryptographic signature to email headers. The receiving system retrieves a public key from DNS to verify that the message content and headers haven't been modified in transit.
Unlike SPF, DKIM attaches directly to the message content rather than the server route, meaning it typically survives email forwarding. Its limitation is that a message can be validly signed by spammer-domain.com while displaying bank.com in the visible "From" field. DKIM proves integrity, but not that the signing entity is who you expect to hear from.
DMARC: Tying Identity to Policy
DMARC resolves the limitations of SPF and DKIM by introducing alignment. It requires that the domain listed in the visible "From" header matches the domain verified by SPF, DKIM, or both. If alignment fails, DMARC instructs receiving mail servers how to handle the message:
p=none(Monitoring): Messages pass through normally while domain owners receive aggregate performance reports.p=quarantine: Unaligned messages are directed to spam or junk folders.p=reject: Unaligned messages are blocked entirely at the server boundary.
DMARC transforms the visible "From" address from a cosmetic label into a verified identifier.
Why Authentication Doesn't Guarantee Inbox Delivery
A common misconception is that configuring SPF, DKIM, and DMARC guarantees inbox placement.
Authentication proves a sender is technically authorized to speak—it does not prove the recipient wants to listen.
Modern spam filters run behavioural models on top of technical checks. Inbox placement depends heavily on contextual signals:
- Sender reputation built over time.
- Sudden volume spikes or irregular sending frequency.
- User engagement metrics (open rates, spam flagging, link clicks).
A fully authenticated domain will still land in the spam folder if its sending behaviours mimic abusive patterns.
What Authentication Does (and Doesn't) Protect Against
- What it solves: Impersonation and exact-domain spoofing. It prevents unauthorised third parties from sending mail that claims to originate directly from your domain.
- What it ignores: Message intent and ethics. A message can pass SPF, DKIM, and DMARC perfectly while containing malicious links, scam content, or unwanted marketing.
- Modern Threat Models: Attackers increasingly use legitimate registered domains with fully configured authentication records rather than spoofing existing ones.
Practical Checklist for Domain Owners
To build a reliable email authentication setup:
- Audit Sending Services: Map every third-party service (CRMs, web hosts, ticketing tools) that sends email on your domain’s behalf before writing DNS records.
- Implement DKIM Broadly: Ensure all sending services sign messages with unique DKIM keys to survive forwarding.
- Align Headers: Verify that your "From" address matches your SPF and DKIM domains.
- Deploy DMARC Gradually: Start with a monitoring policy (
p=none), review daily aggregate reports, resolve failing legitimate streams, and then progress toquarantineorreject. - Protect Inert Domains: Add defensive SPF (
v=spf1 -all) and DMARC (p=reject) records to non-sending domains to block abuse.