The Complete Guide to Email Authentication: SPF, DKIM, DMARC, and Beyond

Email authentication is the set of standards that prove an email actually comes from who it claims to come from. Without it, anyone can send an email pretending to be your bank, your boss, or your government. With it, receiving servers can verify the sender and reject forgeries.

This guide covers the three core standards — SPF, DKIM, and DMARC — plus the newer additions that are shaping email authentication in 2026. Whether you are setting up authentication for the first time or debugging why your emails land in spam, this is the reference you need.

Why email authentication matters

Email was designed in the 1970s with no built-in sender verification. The "From" header is just text — anyone can write anything there. This design flaw is exploited by:

• Phishing — Fake emails impersonating banks, services, and colleagues
• Spoofing — Sending email that appears to come from your domain without your permission
• Business email compromise — Impersonating executives to trick employees into transferring money

Authentication does not fix these problems entirely, but it gives receiving servers the tools to detect and reject most forgeries. It is the foundation of email security.

Part 1: SPF (Sender Policy Framework)

What it does

SPF answers one question: "Is this server allowed to send email for this domain?"

You publish a list of authorized sending servers in your DNS. When a receiving server gets an email from your domain, it checks the sending server IP against your SPF record. Match = pass. No match = fail.

How it works technically

1. Sender sends email from alice@yourdomain.com via server 203.0.113.10
2. Receiving server extracts the domain from the envelope-from (MAIL FROM)
3. Receiving server performs a DNS TXT lookup on yourdomain.com
4. Finds: v=spf1 ip4:203.0.113.0/24 include:_spf.google.com -all
5. Checks if 203.0.113.10 is in the authorized range
6. If yes: SPF pass. If no: SPF fail.

SPF syntax reference

Mechanism	Meaning	Example
ip4:	Authorize an IPv4 address or range	ip4:203.0.113.0/24
ip6:	Authorize an IPv6 address or range	ip6:2001:db8::/32
include:	Include another domain SPF record	include:_spf.google.com
a	Authorize the domain A record IP	a
mx	Authorize the domain MX servers	mx
~all	Soft fail: unauthorized but do not reject	End of record
-all	Hard fail: reject unauthorized	End of record

Common SPF mistakes

Multiple SPF records

A domain can only have one SPF TXT record. If you create two, both are invalid. Merge them:

# Wrong:
v=spf1 include:_spf.google.com ~all
v=spf1 include:_spf.cleanbox.to ~all

# Correct:
v=spf1 include:_spf.google.com include:_spf.cleanbox.to ~all

Too many DNS lookups

SPF is limited to 10 DNS lookups. Each include:, a, mx, and redirect counts as one lookup. If you exceed 10, SPF permanently fails for all emails. Monitor your lookup count as you add services.

Using ~all instead of -all

~all (soft fail) means "unauthorized servers are suspicious but not rejected." -all (hard fail) means "reject everything not in my list." Start with ~all while testing, switch to -all once confident.

SPF limitations

• SPF checks the envelope-from (MAIL FROM), not the header-from (what you see in your email client). An attacker can spoof the header-from while passing SPF.
• SPF breaks when email is forwarded. The forwarding server IP is not in the original domain SPF. This is why SRS (Sender Rewriting Scheme) exists.

Part 2: DKIM (DomainKeys Identified Mail)

What it does

DKIM answers: "Was this email tampered with in transit?"

The sending server signs the email with a private key. The receiving server retrieves the matching public key from DNS and verifies the signature. If valid, the email is authentic and unmodified.

How it works technically

1. Sending server selects specific headers (From, To, Subject, Date, etc.) and the body
2. Generates a hash of the selected content
3. Signs the hash with the domain private key
4. Adds a DKIM-Signature header containing the signature, selector, and algorithm
5. Receiving server extracts the selector from the signature header
6. Looks up the public key at selector._domainkey.yourdomain.com in DNS
7. Verifies the signature against the email content
8. If valid: DKIM pass. If invalid: DKIM fail.

A real DKIM-Signature header

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=yourdomain.com; s=selector1;
  h=from:to:subject:date:message-id;
  bh=base64encodedBodyHash;
  b=base64encodedSignature

Key components

Tag	Meaning
d=	Signing domain
s=	Selector (identifies which key pair)
h=	Headers included in the signature
bh=	Body hash
b=	The signature itself
a=	Algorithm (rsa-sha256 or ed25519-sha256)

DKIM advantages over SPF

• Survives forwarding — The signature is in the email itself, not tied to the sending IP
• Proves integrity — SPF only checks the server; DKIM proves the content was not modified
• Multiple signatures — An email can have DKIM signatures from multiple domains (original sender + forwarding service)

DKIM limitations

• DKIM does not specify what to do on failure (that is DMARC job)
• Mailing lists that modify the body or subject break DKIM signatures
• Key management requires attention — rotate keys periodically, use 2048-bit RSA minimum

Part 3: DMARC (Domain-based Message Authentication, Reporting and Conformance)

What it does

DMARC answers: "What should happen when SPF and DKIM fail, and does the From header match?"

DMARC is the policy layer. It ties SPF and DKIM together and adds two critical features: alignment (the From header must match the authenticated domain) and reporting (you receive aggregate data about authentication failures).

How it works technically

1. Receiving server checks SPF and DKIM as described above
2. Performs alignment check: does the domain in the From header match the domain that passed SPF or DKIM?
3. Looks up DMARC policy at _dmarc.yourdomain.com
4. If alignment fails, applies the policy: none, quarantine, or reject
5. Sends aggregate reports to the address specified in rua=

DMARC record syntax

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; pct=100; adkim=s; aspf=s

Tag	Meaning	Values
p=	Policy for the domain	none / quarantine / reject
sp=	Policy for subdomains	none / quarantine / reject
rua=	Where to send aggregate reports	mailto:address
ruf=	Where to send forensic reports	mailto:address
pct=	Percentage of messages to apply policy	0-100
adkim=	DKIM alignment mode	r (relaxed) / s (strict)
aspf=	SPF alignment mode	r (relaxed) / s (strict)

The DMARC rollout path

Do not jump straight to p=reject. Follow this path:

1. Monitor: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
   Collect reports for 2-4 weeks. See who sends email on your behalf.
2. Quarantine: v=DMARC1; p=quarantine; pct=10; rua=...
   Apply quarantine to 10% of failing messages. Increase gradually.
3. Reject: v=DMARC1; p=reject; rua=...
   Full enforcement. Unauthorized email is rejected outright.

Understanding alignment

This is the concept most people miss. SPF and DKIM can both pass, and DMARC can still fail. Why? Alignment.

• SPF alignment: The domain in the envelope-from (MAIL FROM) must match the domain in the From header
• DKIM alignment: The d= domain in the DKIM signature must match the domain in the From header

At least one must align for DMARC to pass. This prevents an attacker from passing SPF on their own domain while spoofing your domain in the From header.

Part 4: How they work together

Email arrives at receiving server
    |
    +-- SPF check
    |     +-- Is the sending IP authorized? (DNS lookup)
    |     +-- Does the MAIL FROM domain align with the From header?
    |
    +-- DKIM check
    |     +-- Is the signature valid? (public key verification)
    |     +-- Does the signing domain align with the From header?
    |
    +-- DMARC check
    |     +-- Did SPF or DKIM pass WITH alignment?
    |     +-- If both fail alignment: apply DMARC policy
    |
    +-- Result feeds into spam score
          +-- Pass: score reduced (trustworthy)
          +-- Fail: score increased (suspicious)

Authentication results are not binary accept/reject decisions. They feed into the overall spam score. A legitimate email with a minor SPF misconfiguration might still be delivered if everything else looks clean. A phishing email with forged DKIM will have its score increased significantly.

Part 5: Beyond the big three

ARC (Authenticated Received Chain)

ARC preserves authentication results across forwarding hops. When a mailing list modifies an email (breaking DKIM) and forwards it, ARC lets the final receiving server see the original authentication results from the first hop. Adoption is growing but not yet universal.

BIMI (Brand Indicators for Message Identification)

BIMI displays your brand logo next to your emails in supporting email clients (Gmail, Apple Mail). It requires p=quarantine or p=reject DMARC policy and a Verified Mark Certificate (VMC). Primarily a branding feature, but it incentivizes strong authentication.

MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS ensures that email in transit between servers is always encrypted via TLS. Without it, a man-in-the-middle can downgrade the connection to plain text. Published as a policy file on a well-known HTTPS URL and a DNS TXT record.

DANE (DNS-Based Authentication of Named Entities)

DANE uses DNSSEC to publish TLS certificate information in DNS, preventing certificate forgery attacks on SMTP connections. Requires DNSSEC on your domain, which limits adoption.

Part 6: Practical setup checklist

For a new domain

1. Set up SPF: v=spf1 include:your-provider ~all
2. Generate DKIM keys via your email provider and publish the public key in DNS
3. Start DMARC in monitoring mode: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
4. Wait 2-4 weeks, review reports
5. Fix any legitimate senders that fail authentication
6. Move to p=quarantine, then p=reject

For an existing domain

1. Audit current SPF record — is it complete? Under 10 lookups?
2. Check DKIM — is it enabled? Are keys at least 2048-bit?
3. Deploy DMARC in p=none mode and collect reports
4. Identify all legitimate senders from the reports
5. Fix authentication for each sender
6. Gradually enforce DMARC policy

Part 7: Authentication in Cleanbox

Cleanbox checks SPF, DKIM, and DMARC on every incoming email as part of the spam scoring process. Results are visible in the spam report for each message.

For custom domains, Cleanbox provides the exact DNS records you need to set up, including the SPF include for _spf.cleanbox.to.

For relay addresses, Cleanbox adds an Authentication-Results header to every forwarded message, preserving the original authentication results for your mail server. The envelope-from is rewritten using SRS to ensure SPF passes at the destination.

Failed authentication adds points to the spam score. The exact impact depends on which checks failed and whether other positive signals (trusted sender, clean content) compensate.