SPF, DKIM & DMARC Explained: Email Authentication for Humans

Email was invented in an era of trust. The original SMTP protocol, designed in the early 1980s, had no built-in way to verify that the sender of an email was who they claimed to be. Anyone could send an email pretending to be anyone else — your bank, your boss, a government agency. The protocol simply did not care.

Four decades later, that fundamental design flaw is still being exploited. Phishing emails, spoofed sender addresses, and business email compromise (BEC) scams cost organizations billions of dollars every year. The FBI's Internet Crime Complaint Center reported that BEC scams alone caused over $2.9 billion in losses in 2023.

Three technologies — SPF, DKIM, and DMARC — were developed to address this problem. Together, they form the backbone of modern email authentication. This guide explains how each one works in plain English, how they fit together, and what it means when they fail — whether you are a developer configuring email for your application, or a user wondering why certain emails never seem to arrive.

The Problem: Email Spoofing

To understand why SPF, DKIM, and DMARC exist, you first need to understand how easy it is to fake an email.

When your email client shows you a message "from" [email protected], that address comes from the From: header in the email. But the From: header is just text — the sender sets it, and SMTP does not validate it. It is like writing any return address you want on a physical envelope. The postal service delivers it regardless.

This means an attacker can send an email with From: [email protected] from any server in the world, and without email authentication, the recipient's mail server has no way to know it is fake.

Email authentication solves this by giving receiving mail servers a way to answer three questions:

1. Is this server allowed to send email for this domain? (SPF)
2. Has this email been tampered with since it was sent? (DKIM)
3. What should I do if authentication fails? (DMARC)

SPF: Sender Policy Framework

What SPF Does

SPF (defined in RFC 7208) lets a domain owner publish a list of servers that are authorized to send email on behalf of that domain. When a receiving mail server gets an email claiming to be from example.com, it can check the SPF record to see if the sending server is on the authorized list.

How SPF Works

SPF uses DNS TXT records. The domain owner adds a TXT record to their domain's DNS that specifies which IP addresses and servers are permitted to send email for that domain.

Here is what a typical SPF record looks like:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.50 -all

Breaking this down:

• v=spf1 — Identifies this as an SPF record (version 1)
• include:_spf.google.com — Authorizes Google's mail servers (if you use Google Workspace)
• include:sendgrid.net — Authorizes SendGrid's servers (if you use SendGrid for transactional email)
• ip4:203.0.113.50 — Authorizes a specific IP address (perhaps your own mail server)
• -all — The policy for everyone else: reject (the - means "hard fail")

The SPF Check Process

When a mail server receives an email:

1. It looks at the domain in the Return-Path (envelope sender) header — not the From: header
2. It queries DNS for the SPF record of that domain
3. It checks whether the IP address of the sending server matches any of the authorized sources
4. It records the result: pass, fail, softfail, neutral, or temperror

SPF Limitations

SPF has important limitations:

• It checks the envelope sender, not the From header. The envelope sender (Return-Path) and the visible From address can be different. SPF validates the Return-Path, but users see the From address. An attacker can pass SPF by using their own domain as the Return-Path while spoofing the From header.
• It breaks with forwarding. When an email is forwarded, the sending server changes but the Return-Path may stay the same, causing SPF to fail at the next hop.
• There is a 10-DNS-lookup limit. SPF evaluation is capped at 10 DNS lookups to prevent abuse. Complex SPF records that chain many include: directives can exceed this limit and fail.

DKIM: DomainKeys Identified Mail

What DKIM Does

DKIM (defined in RFC 6376) adds a cryptographic signature to outgoing emails. The receiving server can verify this signature to confirm that (a) the email was authorized by the domain owner, and (b) the email was not modified in transit.

How DKIM Works

DKIM uses public-key cryptography:

1. The sending server signs the email. When an email is sent, the sending server creates a hash of certain email headers and the body, then encrypts that hash with a private key. The encrypted hash (the signature) is added to the email as a DKIM-Signature header.

2. The public key is published in DNS. The domain owner publishes the corresponding public key as a DNS TXT record under a specific selector (e.g., selector1._domainkey.example.com).

3. The receiving server verifies the signature. The receiving server extracts the signature from the DKIM-Signature header, looks up the public key in DNS, and uses it to verify that the hash matches the email content.

What a DKIM Signature Header Looks Like

A DKIM-Signature header contains several key fields:

• d= — The signing domain (e.g., example.com)
• s= — The selector, used to locate the public key in DNS (e.g., selector1)
• h= — The list of headers that were signed (e.g., from:to:subject:date)
• bh= — The hash of the email body
• b= — The actual signature (a base64-encoded encrypted hash)

DKIM Advantages Over SPF

• Survives forwarding. Because DKIM validates the email content (not the sending IP), a forwarded email still passes DKIM as long as the content was not modified.
• Detects tampering. If anyone modifies the email body or signed headers in transit, the DKIM signature verification fails.
• Validates the From domain. DKIM signs the From header, so it can verify the visible sender identity, not just the envelope sender.

DKIM Limitations

• Does not prevent sending from unauthorized servers. DKIM proves an email was signed with the domain's key, but it does not say anything about which servers are allowed to send. If someone steals the private key, they can sign emails from any server.
• Mailing lists can break DKIM. Mailing list software often modifies the subject line (adding [ListName]) or the body (appending a footer), which invalidates the DKIM signature.
• Only as strong as key management. If the private key is compromised, an attacker can forge valid DKIM signatures until the key is rotated.

DMARC: Domain-Based Message Authentication, Reporting, and Conformance

What DMARC Does

DMARC (defined in RFC 7489) is the policy layer that ties SPF and DKIM together. It does two things:

1. Tells receiving servers what to do when authentication fails — reject the email, quarantine it (send to spam), or do nothing
2. Provides a reporting mechanism — receiving servers send reports back to the domain owner about authentication results

How DMARC Works

DMARC is published as a DNS TXT record at _dmarc.example.com. A typical DMARC record looks like:

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100

Breaking this down:

• v=DMARC1 — Identifies this as a DMARC record
• p=reject — The policy: reject emails that fail DMARC evaluation
• rua=mailto:[email protected] — Where to send aggregate reports
• pct=100 — Apply the policy to 100% of failing emails

DMARC Evaluation Logic

For an email to pass DMARC, it must pass either SPF or DKIM and the passing result must be aligned with the From domain:

• SPF alignment: The domain in the Return-Path must match (or be a subdomain of) the domain in the From header
• DKIM alignment: The domain in the DKIM d= tag must match (or be a subdomain of) the domain in the From header

This alignment requirement is what closes the gap in SPF. Remember that SPF checks the Return-Path, not the From header. Without DMARC alignment, an attacker could use their own domain as the Return-Path (passing SPF) while spoofing the From header. DMARC prevents this by requiring that whatever passes (SPF or DKIM) must be aligned with the visible From address.

DMARC Policies

DMARC Reporting

DMARC reports are one of its most valuable features. Receiving servers that support DMARC send two types of reports:

• Aggregate reports (rua) — Daily XML summaries showing how many emails from your domain passed or failed authentication, and from which IPs. These help you identify unauthorized senders and misconfigurations.
• Forensic reports (ruf) — Individual failure reports with email details. Many providers limit or do not send these due to privacy concerns.

How SPF, DKIM, and DMARC Work Together

Individually, each protocol has gaps. Together, they provide comprehensive email authentication:

The recommended setup is:

1. Publish an SPF record listing all servers that send email for your domain
2. Enable DKIM signing on all outgoing email
3. Publish a DMARC record starting with p=none to collect data, then gradually move to p=quarantine and finally p=reject

What Happens When Authentication Fails

When an email fails SPF, DKIM, or DMARC, the consequences depend on the receiving server and the domain's DMARC policy:

With No DMARC Policy (p=none)

The receiving server makes its own decision. Most servers treat authentication failures as one of many spam signals — the email might land in spam, or it might be delivered normally if other signals are positive.

With p=quarantine

The receiving server sends failing emails to the spam or junk folder. The email is still delivered, but the user is unlikely to see it unless they check their spam folder.

With p=reject

The receiving server rejects the email entirely. It never reaches the recipient — not even in spam. The sending server typically receives a bounce notification.

Real-World Failure Scenarios

Scenario 1: New email provider not added to SPF. Your company switches from SendGrid to Postmark for transactional email but forgets to update the SPF record. Emails sent through Postmark fail SPF because Postmark's servers are not in the authorized list. If DKIM is properly configured on Postmark, the emails still pass DMARC (because only one of SPF or DKIM needs to pass with alignment). If DKIM is also not configured — common during a rushed migration — all emails fail DMARC.

Scenario 2: Email forwarding breaks SPF. A user has their corporate email forwarded to a personal Gmail account. The forwarding server is not in the original sender's SPF record, so SPF fails. If the forwarding server does not modify the email, DKIM still passes, and DMARC passes via DKIM alignment. But if the forwarding server adds a footer or modifies the subject, DKIM breaks too, and the email fails DMARC entirely.

Scenario 3: Mailing list modifies the email. You send an email to a mailing list. The list software adds [ListName] to the subject and appends an unsubscribe footer. This breaks DKIM (because the signed headers and body changed) and SPF fails (because the list server is not in your SPF record). The email fails DMARC. Some mailing lists handle this by rewriting the From address — but that introduces its own problems.

What This Means for Temporary Email Users

If you use a disposable email service like ExpressMail, email authentication directly affects which messages you receive.

Why Some Emails Do Not Arrive

When a sender has a strict DMARC policy (p=reject), their emails must pass authentication to be delivered. If the disposable email service's infrastructure does not properly handle authentication checks — for example, if it forwards emails in a way that breaks DKIM — those emails will be rejected by the original sender's DMARC policy before they reach your temporary inbox.

What You Can Do

• If an expected email does not arrive, it may have been rejected due to the sender's DMARC policy. This is not a bug in the disposable email service — it is the email authentication system working as designed.
• Some senders explicitly block disposable email domains. This is a separate issue from authentication — some services maintain lists of known temporary email domains and reject signups from those domains entirely.
• Emails from major platforms (Google, Microsoft, Amazon) typically have strict DMARC policies. Transactional emails from these platforms are among the most reliably authenticated — if they do not arrive, the issue is more likely domain blocking than authentication failure.

What This Means for Developers and Senders

If you are building an application that sends email, proper authentication configuration is not optional — it directly affects whether your users receive your emails.

Configuration Checklist for Developers

Common Developer Mistakes

• Forgetting to update SPF when adding a new email service. Every new service that sends email on behalf of your domain needs to be added to SPF.
• Using the email provider's default DKIM domain instead of your own. If your provider signs with d=sendgrid.net instead of d=yourdomain.com, DKIM passes but DMARC alignment fails.
• Setting p=reject too early. If you have not confirmed that all legitimate email sources pass authentication, a reject policy will block your own emails.
• Exceeding the SPF 10-lookup limit. Each include: directive counts as at least one lookup. If you use many third-party email services, you can hit the limit. Use SPF flattening tools if needed.
• Not monitoring DMARC reports. DMARC reports tell you about authentication failures you do not know about — third-party services sending on your behalf, forwarding issues, or actual spoofing attacks.

The Future of Email Authentication

Email authentication continues to evolve. Recent developments include:

• BIMI (Brand Indicators for Message Identification) — Allows brands to display their logo next to authenticated emails in supporting clients (Gmail, Apple Mail). Requires a valid DMARC policy at p=quarantine or p=reject.
• MTA-STS (Mail Transfer Agent Strict Transport Security) — Ensures emails are transmitted over encrypted (TLS) connections, preventing downgrade attacks.
• ARC (Authenticated Received Chain) — Preserves authentication results across forwarding hops, solving the email forwarding problem that breaks SPF and sometimes DKIM.

Major email providers are increasingly requiring authentication. Google and Yahoo both announced in 2024 that bulk senders must have valid SPF, DKIM, and DMARC configurations to deliver email to their users. This trend will only continue.

Summary

Email authentication is not glamorous, but it is essential. Here is the one-paragraph version:

SPF declares which servers can send email for your domain. DKIM cryptographically signs emails so recipients can verify they have not been tampered with. DMARC ties them together with a policy that tells receiving servers what to do when authentication fails, and sends you reports so you know what is happening. Together, they prevent spoofing, improve deliverability, and give domain owners visibility into how their email domain is being used — or abused.

Whether you are a developer configuring email for an application, an IT administrator protecting your organization from phishing, or a user trying to understand why an email did not arrive, understanding these three protocols gives you the foundation to diagnose and solve most email delivery problems.