Learning Objectives

By the end of this module, you will be able to:

1. Explain SPF evaluation mechanics — mechanisms, qualifiers, includes, redirects, the 10-lookup limit — and explain what "SPF alignment" means as something separate from a plain SPF pass or fail.
2. Explain DKIM signing and verification mechanics, including selectors, canonicalization, and why an intermediary can break a valid signature without the message ever being altered maliciously.
3. Explain DMARC as a policy layer built on top of SPF and DKIM alignment, including percentage rollout (pct=) and report types.
4. Correctly identify and distinguish Header From, envelope From (Return-Path), Sender, Reply-To, and Received headers inside a real message.
5. Explain why forwarding and mailing lists routinely break SPF and/or DKIM through no fault of the original sender, and what ARC and SRS each do about it.
6. Recognize display-name spoofing, lookalike-domain spoofing, and true domain spoofing as three distinct techniques that produce three distinct authentication signatures.
7. Given a message's authentication results, determine and articulate why it passed or failed — not just report that it did.

Key Terminology

SPF

Sender Policy Framework — a DNS-published list of IP addresses/hosts authorized to send as a domain, checked against the envelope sender (MAIL FROM), never the visible From address directly.

DKIM

DomainKeys Identified Mail — a cryptographic signature added by the sending system, verifiable against a public key published in DNS, proving the signed content wasn't altered since signing and originated from a holder of the private key.

DMARC

A policy layer requiring SPF or DKIM to both pass and align with the visible Header From domain, and telling receivers what to do (none/quarantine/reject) when that fails.

Alignment

Whether the domain validated by SPF or DKIM matches the visible Header From domain — exactly, under strict alignment, or as the same organizational domain, under relaxed alignment. Distinct from, and in addition to, a plain SPF/DKIM pass.

Return-Path

A header added by the receiving system recording the envelope sender (MAIL FROM). This is what SPF actually validates.

Sender header

An optional header indicating a message was sent on behalf of the Header From address by a different authenticated party — common with delegate-send scenarios and some mailing lists.

SRS (Sender Rewriting Scheme)

A forwarder-side technique that rewrites the envelope sender to the forwarder's own domain, preserving SPF validity for the forwarding hop even though the original sender's SPF record wouldn't authorize the forwarder's IP.

ARC (Authenticated Received Chain)

Lets an intermediary cryptographically attest to the authentication results it personally observed before forwarding, so a downstream receiver can consider those original results even when its own direct check would fail.

Alignment mode (adkim/aspf)

DMARC's s (strict — exact domain match required) or r (relaxed — same organizational domain suffices) settings, controlling how strictly alignment is judged.

Lesson

By now you can trace a message through the delivery chain (Module 1) and read the DNS records that route mail and describe a domain (Module 3). This module answers the question nearly every one of those messages eventually raises, directly or indirectly: is this message actually from who it claims to be — and when a security product tells you it is, or isn't, what exactly did it check?

Authentication is not one check. It is three layered checks — SPF, DKIM, and DMARC — and each one answers a narrower question than most customers, and more than a few new engineers, assume it does. Each layer can produce a result that looks contradictory until you know precisely what it validated and what it didn't. Get comfortable with that three-layer structure before anything else in this module, because the module's central point — the three distinct spoofing techniques in 4.6 — depends entirely on knowing exactly what each layer proves and, just as important, what it does not prove.

4.1 SPF Mechanics in Depth

SPF answers exactly one question: is this envelope-sender IP authorized to send for this envelope-sender domain? It checks the MAIL FROM domain — or the EHLO domain as a fallback, when MAIL FROM is empty, which happens for bounce messages — and it checks only that domain. It never looks at the visible Header From by itself. Hold onto that fact; it is the reason SPF passing tells you nothing, on its own, about whether the visible From address a recipient sees is legitimate. Tying an authentication result to the visible From address is DMARC's job, covered in 4.3, not SPF's.

The mechanisms available, and the order in which a record lists them, are:

• ip4: / ip6: — a literal IP address or CIDR range.
• a — matches if the sending IP resolves to the domain's own A/AAAA record.
• mx — matches if the sending IP is one of the domain's own MX hosts.
• include: — pulls in another domain's SPF record and evaluates its result as a subroutine. Critically, this does not stop evaluation of the outer record if it doesn't match — it's a subroutine call, not a full handoff.
• redirect= — fully hands off evaluation to another domain's record. Unlike include:, this replaces the rest of the current record rather than supplementing it.
• exists: — a macro-based existence check, rare in practice.

Each mechanism can carry a qualifier prefix that determines what happens on a match:

The all mechanism always appears last in a well-formed record and sets the default outcome for anything not matched by an earlier mechanism: -all (recommended once a domain's sending sources are fully inventoried), ~all (common during rollout or testing, while the domain owner is still discovering all of its legitimate senders), or +all (passes everything — this effectively disables SPF as a control, and is almost never the correct configuration for a production domain).

Worked Example: Evaluating an SPF Record by Hand

Suppose vendor.example.com publishes this SPF record:

v=spf1 ip4:203.0.113.10 include:spf.mailprovider.example -all

Now walk two different sending IPs through evaluation exactly as a receiving system would, left to right, stopping at the first match:

• Sending IP 203.0.113.10. The first mechanism, ip4:203.0.113.10, matches immediately. There is no explicit qualifier on it, which means the implicit qualifier + applies. Result: Pass. Evaluation stops here — the include: and -all are never even consulted for this IP.
• Sending IP 198.51.100.44, which happens to be one of spf.mailprovider.example's authorized hosts. The first mechanism doesn't match (it's not 203.0.113.10). The second mechanism, include:spf.mailprovider.example, triggers a DNS lookup (mechanism-lookup count: 1) to fetch that domain's own SPF record, and evaluates that record's mechanisms against the IP. It matches inside the included record. Result: Pass — but note the result was determined by a completely different domain's record than the one you started with, which is exactly the kind of detail worth stating explicitly when you explain a result to a customer.
• Sending IP 192.0.2.99, which is on neither list. Neither the ip4: mechanism nor the include: mechanism matches, so evaluation falls through to the final mechanism, -all. Result: Fail (hard fail) — the domain's own publisher explicitly stated that any IP not covered above is not authorized to send as this domain.

Notice what this exercise does not tell you: it says nothing about whether the visible Header From matches vendor.example.com at all. That question belongs to alignment, not to SPF evaluation itself — keep reading.

4.2 DKIM Mechanics in Depth

DKIM answers a fundamentally different question than SPF: was this specific content signed by a party holding the private key for the domain named in the signature, and has that signed content been altered since signing? Unlike SPF, DKIM has nothing at all to do with the sending IP address — a message can be DKIM-signed and relayed through any number of intermediate systems, and the signature remains checkable regardless of which IP finally delivers it, provided the signed content survives intact.

Every DKIM-signed message carries a DKIM-Signature: header, and being able to read its parameters at sight is a core skill for this module:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
  s=selector1; h=from:to:subject:date; bh=<body-hash>; b=<signature>

• d= — the signing domain. This is the domain DMARC alignment checks the signature against, so it matters just as much as the domain SPF validates.
• s= — the selector, used to locate the public key in DNS at selector._domainkey.domain (Module 3.6 covers reading this record).
• h= — the list of headers that were actually included in the signature computation.
• c= — the canonicalization mode for headers/body, either simple or relaxed. relaxed tolerates minor whitespace and formatting changes without breaking the signature; simple does not, and is far more brittle in the face of ordinary mail-system handling.
• bh= — the body hash, computed at signing time.

Why an intermediary can break DKIM without any malicious intent whatsoever: any system that modifies the message body, or a header listed in h=, after the original signature was applied — a mailing list appending a footer, a legacy gateway inserting a disclaimer, in some implementations even URL/link rewriting if it changes body content after the original DKIM signature was applied — invalidates that specific signature. This is expected, ordinary behavior, not a defect and not evidence of tampering by a hostile party. It is, in fact, the single most common cause of "legitimate DKIM failure" tickets you'll encounter, and you should treat it as expected, benign behavior by default rather than as a red flag — while still following the process in Module 12 to confirm which hop actually caused it. It's also precisely the gap that ARC (4.5) exists to address.

Worked Example: Watching a Signature Break

Picture a clean, properly DKIM-signed message leaving its origin server. At signing time, the signer computes bh= as a hash of the exact body content — call it, for illustration, a value like bh=X7f.... That hash is baked into the DKIM-Signature: header and travels with the message.

Now suppose an intermediate system — a mailing list expander, say — appends a single line to the bottom of the body: "You are receiving this because you subscribed to...". Nothing else about the message changes. No malicious intent is involved anywhere in this chain.

When the final receiver verifies the signature, it recomputes the body hash from the message as it actually arrived — footer included — and gets a different value, say bh=Q2k.... That no longer matches the bh= value baked into the signature at origin. The comparison fails. DKIM reports fail, full stop, with no distinction in the protocol between "an attacker tampered with this" and "a mailing list added one disclosure line." That distinction is something only you, as the investigating engineer, can supply — by identifying the intermediary hop and confirming what it changed (Module 5 covers exactly how to do that from headers). The lesson to take away: a DKIM fail by itself never tells you whether the change was hostile. It only tells you that something changed after signing.

4.3 DMARC — the Alignment Layer

DMARC does not perform any cryptographic checking or IP-based checking of its own. It is a policy wrapper sitting on top of SPF and DKIM, and it requires:

(SPF passes AND is aligned to Header From) OR (DKIM passes AND is aligned to Header From)

"Aligned" means the domain validated by SPF (the envelope/Return-Path domain) or by DKIM (the d= domain) matches the visible Header From domain — exactly, under strict alignment (s), or as the same organizational/registrable domain, under relaxed alignment (r, DMARC's default when unspecified).

This is the reason SPF or DKIM can each individually "pass" while DMARC still fails — the passing mechanism validated a domain that is real and legitimate, but simply different from the one the recipient sees in their inbox. This gap is precisely what malicious spoofing tries to exploit: an attacker's own domain passes their own SPF/DKIM completely legitimately, while their visible Header From impersonates a victim brand the attacker doesn't control at all. You'll see this pattern formally as Example B in 4.7, and it is worth previewing now: authentication passing is not the same claim as "this message is safe," and the gap between those two claims is alignment.

Worked mini-example — why DMARC can fail even when SPF passes: a mailing list forwards a message. The list rewrites the envelope sender to its own domain (standard practice, for bounce handling) and that new envelope sender legitimately passes SPF — for the list's domain. But the visible Header From still shows the original sender's domain. SPF "passed," but for a domain other than the one the recipient sees, so SPF alignment fails. If DKIM also broke in transit (as in the worked example in 4.2), DMARC fails entirely — even though nothing about this chain was malicious.

4.4 Full Header Field Reference

A single message carries several fields that all sound like "who sent this," and customers — and more than a few new engineers — use them interchangeably. They are not interchangeable. Each one is set by a different party, represents a different fact, and is authenticated (or not) by a different mechanism. Treat this table as a reference you come back to, not something to memorize in one pass:

The field that deserves the most suspicion when a customer reports "this looks like phishing but our filter passed it" is almost always Reply-To:. It is entirely unauthenticated, entirely attacker-controlled, and it is exactly where a reply from a fooled recipient will actually go — regardless of what the Header From shows, and regardless of what SPF, DKIM, or DMARC concluded. Get in the habit of checking it independently on every impersonation-flavored ticket.

4.5 Forwarding, Mailing Lists, SRS, and ARC

Forwarding — whether it's a user's own mailbox auto-forwarding, or a customer's downstream relay — resends a message from a new envelope sender (commonly the forwarding system's own address, or sometimes the original one, depending on implementation) while typically preserving the original Header From untouched. This routinely breaks SPF alignment, because the forwarding server's IP simply isn't listed in the original domain's SPF record — even though DKIM, if it survives unmodified in transit, can still pass and align. That's precisely why DMARC's "SPF-or-DKIM" design exists in the first place: forwarding is one of its primary, intended, real-world accommodations, not an edge case it forgot to handle.

This is worth connecting directly back to Module 2's deployment-architecture content: hybrid environments and forwarding-heavy environments will generate a disproportionate share of "legitimate DMARC failure" tickets. Expect that pattern going in, rather than defaulting to treating every DMARC failure as suspicious the moment you see it. Forwarding should be your default first hypothesis for an unexplained DMARC failure, checked and ruled in or out before you escalate it as a security concern.

SRS (Sender Rewriting Scheme) is a forwarder-side fix: the forwarder rewrites the envelope sender to an address at its own domain, encoding the original address inside it for correct bounce routing, so that its own SPF record — not the original sender's — governs the forwarding hop. This restores SPF-passing at the forwarding hop, but it does nothing at all for alignment to the original Header From domain. In an SRS scenario, DKIM remains the mechanism DMARC actually has to rely on for a pass, since SPF's alignment is unrecoverable through SRS alone.

ARC (Authenticated Received Chain, RFC 8617) solves a genuinely different problem. It lets a trusted intermediary — a mailing list, a corporate relay — cryptographically attest, in effect, "here is exactly what I personally observed for SPF, DKIM, and DMARC when I received this message." A downstream receiver can choose to trust that attestation even though its own direct SPF/DKIM check on the final hop would fail, because it understands that the intermediary's own forwarding legitimately broke those signals in a way that has nothing to do with the message's authenticity. ARC does not replace DMARC evaluation on its own — it supplements it, as an additional trust signal a receiving system may use in its own policy decision. When you describe ARC to a customer, present it as something that may help sophisticated receivers correctly handle known-legitimate forwarding — not as a guarantee that a receiving system will honor it, since ARC support and trust policy both vary by receiver.

4.6 Display-Name Spoofing, Lookalike Domains, and True Domain Spoofing

Customers routinely lump all three of these together as "spoofing." You cannot afford to — they are three distinct techniques that produce three distinct authentication signatures, and conflating them is exactly how an engineer ends up giving a customer a dangerously wrong explanation.

4.7 Worked Pass/Fail Examples

Before you read the three examples below, try predicting them yourself. Given only "a mailing list forwarded a legitimate message and appended a footer" — what would you expect SPF, DKIM, and DMARC to each report, and would you call this message safe or suspicious? Hold that prediction in mind, then check it against Example A.

Laid side by side, the three examples make the point of this whole module concrete — the same three-letter verdicts (Pass/Fail) mean entirely different things depending on which domain was validated and whether it aligns with what the recipient actually sees:

Notice that Example B is the one with the cleanest, most reassuring-looking authentication result of all three — full pass, straight down the line — and it is also the only genuinely malicious message on this table. That is not a coincidence; it's the whole reason this module spends as much time on alignment and spoofing technique as it does on evaluation mechanics.

Hands-On Lab

Scenario-Based Exercise

Knowledge Check

Answer each question yourself before expanding it.