SPF, DKIM & DMARC Authentication

The Problem All Three Protocols Solve

SMTP — the protocol that delivers email — was designed in 1982. It has no built-in sender verification. Any server on the internet can connect to your mail server and claim to be ceo@yourcompany.com. SMTP will accept it without question. This is not a bug — it is the original design. Email was built for a trusted academic network, not for a global system full of adversaries.

SPF, DKIM, and DMARC are three protocols layered on top of SMTP to retroactively add sender verification. Each solves a different piece of the authentication puzzle:

Click to enlarge

SPF: Sender Policy Framework

SPF lets a domain owner publish a list of IP addresses and servers authorized to send email on behalf of that domain. When a receiving server gets an email claiming to be from example.com, it performs a DNS TXT lookup on example.com and checks whether the sending server's IP is on the authorized list.

SPF Record Syntax

SPF records are published as DNS TXT records on the domain:

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:sendgrid.net -all

SPF Qualifiers

The qualifier before all determines what happens to unauthorized senders:

How to Check SPF

You can query any domain's SPF record from the command line:

dig TXT example.com +short | grep spf
nslookup -type=TXT example.com

In email headers, SPF results appear in the Authentication-Results header:

Authentication-Results: mx.company.com;
    spf=pass (sender IP is 209.85.220.41) smtp.mailfrom=user@example.com

Authentication-Results: mx.company.com;
    spf=softfail (sender IP is 45.33.18.201) smtp.mailfrom=x92@mass-mailer.info

SPF Limitations

DKIM: DomainKeys Identified Mail

DKIM adds a cryptographic signature to outgoing emails. The sending server signs specific headers and the body using a private key. The corresponding public key is published in DNS. Receiving servers retrieve the public key and verify the signature — confirming that the email was not modified after signing and that the signing domain authorized the message.

How DKIM Works

1. Sending server generates a hash of specified headers + body
2. Signs the hash with the domain's private key
3. Adds DKIM-Signature header to the email
4. Receiving server extracts the d= (domain) and s= (selector) from the DKIM-Signature header
5. Queries DNS for selector._domainkey.domain.com to retrieve the public key
6. Verifies the signature against the hash of the received message

DKIM-Signature Header

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

Verifying DKIM via DNS

dig TXT selector1._domainkey.example.com +short

Returns something like:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE..."

In headers, DKIM results appear as:

Authentication-Results: mx.company.com;
    dkim=pass header.d=example.com header.s=selector1

DKIM Limitations

DMARC: Domain-based Message Authentication, Reporting & Conformance

DMARC builds on SPF and DKIM by adding two critical features: alignment and policy enforcement.

The Alignment Problem

SPF validates the envelope sender (MAIL FROM). DKIM validates the signing domain (d= tag). But neither one directly validates the From header that the user actually sees. An attacker can:

• Set MAIL FROM to attacker@evil.com (SPF passes for evil.com)
• Sign the email with DKIM for evil.com (DKIM passes for evil.com)
• Set From: ceo@yourcompany.com (what the user sees)

SPF passes. DKIM passes. The user sees a spoofed From address. DMARC closes this gap.

How DMARC Works

DMARC requires that either SPF or DKIM not only passes, but also aligns with the domain in the From header:

• SPF alignment: The domain in MAIL FROM must match (or be a subdomain of) the From header domain
• DKIM alignment: The d= domain in the DKIM signature must match (or be a subdomain of) the From header domain

If neither SPF nor DKIM is both passing AND aligned with the From domain, DMARC fails.

DMARC Record Syntax

Published as a DNS TXT record at _dmarc.domain.com:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100; adkim=s; aspf=s

Click to enlarge

Checking DMARC via DNS

dig TXT _dmarc.example.com +short

DMARC in Authentication-Results Headers

Authentication-Results: mx.company.com;
    spf=pass (sender IP is 209.85.220.41) smtp.mailfrom=user@example.com;
    dkim=pass header.d=example.com header.s=selector1;
    dmarc=pass (p=REJECT) header.from=example.com

Authentication-Results: mx.company.com;
    spf=softfail smtp.mailfrom=bulk-mailer.info;
    dkim=none;
    dmarc=fail (p=NONE) header.from=microsoft.com

The second example shows a phishing email: SPF softfails (sent from unauthorized server), no DKIM signature, and DMARC fails — but the policy is p=NONE, so the email was delivered anyway.

Reading Authentication-Results: The SOC Analyst's Shortcut

The Authentication-Results header is the single most important header for phishing triage after your initial Return-Path/Received chain analysis. It gives you the combined verdict of all three protocols in one place.

Quick Reference

How Attackers Bypass Each Protocol

Understanding the bypass techniques helps you recognize sophisticated phishing that passes basic authentication checks.

SPF Bypasses

DKIM Bypasses

DMARC Bypasses

Why All Three Are Needed

Even with all three, remember: authentication confirms the email came from the claimed domain's authorized infrastructure. It does not confirm the email is safe. A compromised legitimate account sends fully authenticated phishing. Content analysis remains essential.

Key Takeaways

• SPF validates the sending server's IP against a domain's published authorized sender list — but checks the envelope sender, not the visible From header
• DKIM cryptographically signs email headers and body, ensuring integrity — but does not verify the sender IP and is vulnerable to replay attacks
• DMARC enforces alignment between SPF/DKIM results and the From domain — closing the gap that lets attackers pass SPF/DKIM while spoofing the From header
• The Authentication-Results header is your one-stop shop for SPF, DKIM, and DMARC verdicts during triage
• Most domains use p=none for DMARC — meaning failed emails are still delivered, and you must investigate them manually
• All three protocols together provide strong authentication, but look-alike domains and compromised accounts can still pass all checks
• Authentication tells you where the email came from — content analysis tells you whether it is malicious

What's Next

You now understand the infrastructure that proves (or disproves) an email's claimed origin. In the next lesson, we shift from the technical envelope to the human target. You will learn to classify phishing by type — credential harvesters, malware delivery, BEC, spear phishing — and analyze the URL and social engineering tactics attackers use to manipulate recipients into clicking, downloading, or transferring funds. These classification skills are what you will apply in Lab 4.3 when you triage a mix of real-world phishing samples.