8.6 Email Authentication: SPF, DKIM, DMARC

90 minutes · Module 8

Email Authentication: SPF, DKIM, DMARC

By the end of this subsection, you will understand what each email authentication protocol verifies, know why passing authentication does not mean the email is safe, and be able to configure DMARC for your domain.

The three protocols

Protocol	What it verifies	What it does NOT verify
SPF (Sender Policy Framework)	The sending server IP is authorized for the domain in the envelope From address	That the domain is legitimate or trustworthy
DKIM (DomainKeys Identified Mail)	The email was not modified in transit (cryptographic signature on headers and body)	That the signer is trustworthy
DMARC (Domain-based Message Authentication, Reporting, and Conformance)	SPF or DKIM passes AND the domain aligns with the header From address	That the content is safe

Authentication verifies origin, not safety

In Module 13, the AiTM phishing email passed SPF, DKIM, and DMARC — because the attacker owned the sending domain (northgate-voicemail.com) and configured authentication correctly. It takes 5 minutes to set up SPF and DKIM for a new domain. Authentication tells you "this email really came from northgate-voicemail.com." It does not tell you "northgate-voicemail.com is trustworthy." Never dismiss a suspicious email because authentication passed.

Configuring DMARC for your domain

DMARC protects YOUR domain from being spoofed by others. It tells receiving mail servers what to do when someone sends email claiming to be from your domain but fails SPF/DKIM alignment.

DMARC policy levels:

Policy	DNS record	What happens to failing emails	Deploy when
None (monitoring)	`v=DMARC1; p=none; rua=mailto:dmarc@northgateeng.com`	Nothing — reports only	Start here. Collect data for 30 days.
Quarantine	`v=DMARC1; p=quarantine; rua=mailto:dmarc@northgateeng.com`	Failing emails go to Junk	After confirming all legitimate senders pass alignment
Reject	`v=DMARC1; p=reject; rua=mailto:dmarc@northgateeng.com`	Failing emails are rejected (not delivered)	After quarantine runs clean for 30+ days

Do NOT deploy DMARC reject without monitoring first

If you have third-party services sending email on behalf of your domain (marketing platforms, CRM, ticketing systems) and they are not configured in your SPF record, DMARC reject will block their emails. Start with p=none, analyze the DMARC reports, add all legitimate senders to SPF, then move to quarantine, then reject.

Common DMARC deployment mistakes

Mistake	Consequence	How to avoid
Deploying p=reject without monitoring	Legitimate third-party email blocked (marketing, CRM, support)	Always start with p=none for 30 days of data
SPF record exceeds 10 DNS lookups	SPF fails for all email from your domain	Consolidate include statements, use SPF flattening services
No DKIM for third-party senders	DMARC fails on alignment even though SPF passes	Configure DKIM signing with your domain for each third-party service
Not monitoring DMARC reports after deployment	New services added without SPF/DKIM break silently	Review DMARC reports monthly, automate with a DMARC monitoring service
Forgetting subdomain policy	Attackers spoof subdomains (hr.yourdomain.com)	Add `sp=reject` to your DMARC record for subdomain policy

Analyzing authentication results with KQL

1
2
3
4
5
6
7
EmailEvents
| where TimeGenerated > ago(7d)
| where SenderFromDomain != SenderMailFromDomain
| project TimeGenerated, SenderFromAddress, SenderMailFromAddress,
    SenderFromDomain, SenderMailFromDomain,
    AuthenticationDetails, Subject
| take 20

Expected Output

SenderFromAddress	SenderMailFromAddress	Auth (summary)
ceo@northgateeng.com	bounce@marketing-platform.com	SPF: pass (marketing-platform.com), DKIM: pass, DMARC: fail (domain mismatch)
hr@northgateeng.com	noreply@attacker-domain.com	SPF: pass (attacker-domain.com), DKIM: none, DMARC: fail

What to look for: Row 1: your marketing platform sends "from" ceo@northgateeng.com but the envelope sender is the platform. DMARC fails because the domains do not align. This is legitimate — add the platform to SPF and configure DKIM signing with your domain. Row 2: an attacker spoofing hr@northgateeng.com from their own domain. DMARC catches this — with a reject policy, this email would never reach your users.

Practical DMARC deployment timeline

Week	Action	Verification
1	Add DMARC TXT record with p=none and rua reporting	`nslookup -type=txt _dmarc.yourdomain.com` returns your record
2-4	Analyze DMARC reports (use a free service like dmarcanalyzer.com or EasyDMARC)	Identify all legitimate senders
5	Add all legitimate senders to SPF record. Configure DKIM signing for third-party services.	SPF lookup confirms all senders authorized
6-8	Change to p=quarantine	Monitor Junk folder for false positives
9-12	If quarantine is clean, change to p=reject	External spoofing of your domain is now blocked

Try it yourself

Your DMARC report shows that your marketing platform (Mailchimp) is failing DMARC alignment because it sends from its own servers but uses your domain in the From address. How do you fix this without disabling DMARC?

Two fixes (use both for maximum protection):

1. Add Mailchimp to your SPF record: Include include:servers.mcsv.net in your SPF TXT record. This authorizes Mailchimp's servers to send on behalf of your domain.

2. Configure DKIM signing with your domain: In Mailchimp settings, set up DKIM to sign emails with your domain's DKIM key (create a CNAME record for Mailchimp's DKIM selector pointing to your DNS). This makes Mailchimp emails pass DKIM alignment.

With both fixes, Mailchimp emails pass both SPF and DKIM alignment — DMARC succeeds. Without these fixes, moving to p=reject would block all your marketing emails.

Check your understanding

1. A phishing email passes SPF, DKIM, and DMARC. Is it safe?

No. Email authentication verifies that the email came from the claimed domain's authorized infrastructure. The attacker owns the domain and configured authentication correctly. Passing authentication means "this email is really from attacker-domain.com" — it does not mean "attacker-domain.com is trustworthy."

Yes — all three protocols passed

Only if DMARC is set to reject

This is one of the most important misconceptions to correct. Authentication proves origin, not safety. The Module 13 phishing email passed all authentication because the attacker set up their domain properly. Authentication protects your domain from being spoofed by others — it does not protect you from emails sent from attacker-owned domains.

← 8.5 Zero-Hour Auto Purge (ZAP) 8.7 Transport Rules for Security →