Email Security — SPF/DKIM/DMARC

Why Email Authentication Matters

Email was designed in the 1970s and 1980s with no built-in authentication. The SMTP protocol — the foundation of all email delivery — trusts the sender to identify themselves honestly. It is trivially easy to send an email that appears to come from any address. This is called email spoofing, and it is the foundation of most phishing attacks.

As IT support staff, you need to understand how modern email authentication protocols — SPF, DKIM, and DMARC — work together to verify that an email actually came from who it claims to come from. When users report suspicious emails, your ability to read authentication headers and understand these protocols can be the difference between identifying a phishing attack and dismissing it as a false alarm.

The Three Pillars of Email Authentication

Email authentication is built on three complementary protocols. Each addresses a different aspect of the problem:

All three work together. SPF alone does not prevent spoofing. DKIM alone does not prevent spoofing. Even SPF plus DKIM without DMARC leaves gaps. You need all three.

SPF: Sender Policy Framework

SPF allows a domain owner to publish a DNS TXT record listing the mail servers that are authorized to send email on behalf of that domain.

How SPF Works

1. Your organization publishes an SPF record in DNS: v=spf1 include:spf.protection.outlook.com -all
2. Someone sends an email claiming to be from @yourcompany.com
3. The receiving mail server checks the SPF record for yourcompany.com
4. If the sending server's IP address matches the SPF record, SPF passes. If not, SPF fails.

Reading an SPF Record

v=spf1 include:spf.protection.outlook.com include:_spf.google.com ip4:203.0.113.25 -all

SPF Qualifiers

SPF Limitations

• SPF checks the envelope sender (the Return-Path header), not the From: address that users see. An attacker can pass SPF while still spoofing the visible sender address.
• SPF breaks when email is forwarded because the forwarding server's IP isn't in the original domain's SPF record.
• SPF records have a 10-DNS-lookup limit. Complex organizations with many email services can exceed this.

DKIM: DomainKeys Identified Mail

DKIM adds a cryptographic signature to outgoing emails. The receiving server verifies this signature using a public key published in the sender's DNS records.

How DKIM Works

1. Your mail server generates a key pair (private key kept secret, public key published in DNS)
2. When sending an email, the server signs specific headers and the body with the private key
3. The signature is added as a DKIM-Signature header in the email
4. The receiving server retrieves the public key from DNS and verifies the signature
5. If the signature validates, the email has not been altered since it was signed

What DKIM Proves

• The email was sent by a server that possesses the private key for that domain
• The email content has not been modified in transit (integrity)
• The domain in the DKIM signature is associated with the sender

What DKIM Does Not Prove

• DKIM does not prevent a different domain from sending email — it only proves which domain signed the message
• Without DMARC, a failing DKIM check may not result in any action

DMARC: Domain-Based Message Authentication, Reporting & Conformance

DMARC ties SPF and DKIM together and adds a critical missing piece: a policy that tells receiving servers what to do when authentication fails, and a reporting mechanism that lets domain owners see who is sending email as their domain.

How DMARC Works

1. Domain owner publishes a DMARC record in DNS: v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com
2. Receiving server checks if the email passes SPF or DKIM with alignment (the authenticated domain matches the From: domain)
3. If both SPF and DKIM fail alignment, the receiving server follows the DMARC policy
4. The receiving server sends aggregate reports to the address specified in rua

DMARC Policies

DMARC Alignment

This is the concept that catches most people: DMARC requires alignment between the domain in the authentication check and the domain in the From: header.

• SPF alignment — The domain in the Return-Path must match the domain in the From: header
• DKIM alignment — The domain in the DKIM signature (d=) must match the domain in the From: header

An email can pass SPF and DKIM individually but still fail DMARC if the authenticated domains don't match the From: domain. This is how DMARC closes the spoofing gap that SPF and DKIM leave open.

Reading a DMARC Record

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-agg@yourcompany.com; ruf=mailto:dmarc-forensic@yourcompany.com; pct=100

Analyzing Email Headers

When a user reports a suspicious email, checking the authentication headers tells you whether SPF, DKIM, and DMARC passed.

Key Headers to Check

Authentication-Results: mx.google.com;
       dkim=pass header.d=example.com;
       spf=pass (google.com: domain of info@example.com designates 209.85.220.41 as permitted sender);
       dmarc=pass (p=REJECT) header.from=example.com

This email passed all three checks — it is likely legitimate.

Authentication-Results: mx.google.com;
       dkim=fail (signature did not verify);
       spf=fail (google.com: domain of admin@yourbank.com does not designate 185.234.72.90 as permitted sender);
       dmarc=fail (p=NONE)

This email failed all three checks — it is almost certainly spoofed. Note that p=NONE means the sending domain's DMARC policy is monitor-only, so the email was still delivered despite failing.

DMARC Deployment Roadmap

Rolling out DMARC is a phased process. Going straight to p=reject without preparation will likely block legitimate email from third-party services that send on your behalf (marketing platforms, CRM systems, ticketing tools).

Phase 1: Inventory and SPF/DKIM Setup

• Identify all services that send email as your domain
• Ensure SPF records include all legitimate sending sources
• Configure DKIM signing for all email platforms

Phase 2: DMARC Monitor Mode (p=none)

• Publish v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com
• Collect and analyze aggregate reports for 2-4 weeks
• Identify legitimate senders that are failing authentication
• Fix their SPF/DKIM configuration

Phase 3: Quarantine (p=quarantine)

• Update to p=quarantine; pct=10 (start with 10% to limit impact)
• Gradually increase the percentage as you confirm legitimate mail is unaffected
• Monitor reports for false positives

Phase 4: Reject (p=reject)

• Update to p=reject; pct=100
• All unauthenticated email claiming to be from your domain is now blocked
• Continue monitoring reports for new legitimate senders that need configuration

Key Takeaways

• SPF, DKIM, and DMARC work together — All three are required for effective email authentication
• SPF alone doesn't prevent spoofing — It only checks the envelope sender, not the visible From: address
• DKIM proves integrity and origin — But without DMARC, failures may not be acted upon
• DMARC alignment is the key concept — The authenticated domain must match the From: domain
• Deploy DMARC in phases — Start with monitoring, then quarantine, then reject
• Learn to read authentication headers — When users report suspicious emails, the headers tell you the truth
• p=reject is the goal — Anything less than reject still allows spoofed email through