Analyst Field Guide · Email Security & Phishing
Email arrived with no way to prove who sent it. Three DNS records were bolted on to fix that — SPF, DKIM, and DMARC — and they work, within limits worth stating precisely. This guide is how sender authentication actually decides trust, why a message that passes can still be an attack, and the social engineering that skips the machinery entirely.
SMTP was built to move mail, not to prove who sent it. The protocol will happily deliver a message whose From: line says anyone at all. Everything in this guide exists to close that gap — but each control closes a specific part of it, and the residual is where phishing lives. The recurring lesson mirrors the Identity guide's: a check that passes tells you a domain was authorized, not that the message is safe.
A single message carries two different sender addresses, and they need not match. The envelope sender (the SMTP MAIL FROM, also called RFC5321.MailFrom, the return-path, or bounce address) is used during delivery and controls where bounces go — the recipient never sees it. The header From (RFC5322.From) is the human-readable line your mail client displays. Nothing in base SMTP forces a relationship between them, so a sender can put a truthful envelope address and a forged header From on the same message.
Hold this frame for the whole guide: SPF and DKIM answer "is this sending path authorized for some domain?" On their own, neither looks at the From line the user sees. DMARC is the layer that says "the domain that passed must also be the domain in the From" — which is why all three are needed together, and why each is worth understanding on its own terms first.
Sender Policy Framework (SPF, RFC 7208) lets a domain publish, in DNS, the list of IP addresses and hosts allowed to send mail as that domain. A receiver checks the connecting server's IP against that list. It is a path authorization, not a message signature.
Reading it: v=spf1 is the version; the middle terms are mechanisms that match sources — ip4/ip6 (address ranges), a, mx, include (import another domain's SPF, as with an email provider), exists. The final all catches everything else, prefixed by a qualifier:
| Qualifier | On all | Receiver treatment of non-listed senders |
|---|---|---|
- fail | -all | Hard fail — the domain asserts nothing else is authorized. |
~ softfail | ~all | Suspicious but accept — usually tagged, not rejected. |
? neutral | ?all | No assertion — provides essentially no protection. |
+ pass | (default) | Explicit pass; rarely written before all. |
Two limits define what SPF can and cannot do:
SPF validates the envelope MAIL FROM domain, never the header From. A message can pass SPF for its envelope domain while displaying a completely different (forged) From line — so SPF alone does not stop From-address spoofing. Separately, SPF is evaluated on the connecting IP: when mail is forwarded, the forwarder relays from its own IP, which is not in the original domain's SPF, so SPF fails at the final hop even for legitimate mail. (Sender Rewriting Scheme, SRS, is the usual workaround.) These are the two gaps DKIM and DMARC exist to cover.
RFC 7208 caps the DNS lookups an SPF evaluation may trigger (mechanisms like include, a, mx) at 10. Exceed it and evaluation returns permerror — which most receivers treat as not a pass, silently breaking authentication. Deep chains of nested include: (common when several senders are stacked) are the usual cause; flatten them and audit periodically.
DomainKeys Identified Mail (DKIM, RFC 6376) attaches a cryptographic signature to the message. The sending server signs a chosen set of headers (which must include From) plus a hash of the body with a private key; the receiver fetches the matching public key from DNS and verifies. A valid signature proves two things: the message was authorized by the signing domain, and the signed parts were not altered in transit.
Reading the signature: d= is the signing domain, s= the selector (which points to the key's DNS location, <selector>._domainkey.<domain>), h= the list of signed headers, bh= the body hash, b= the signature itself. A domain can publish several selectors and rotate them.
Because the signature travels with the message, DKIM keeps verifying after a plain forward, where SPF fails. The catch: DKIM breaks if any hop modifies a signed header or the body — which is exactly what mailing lists do when they prepend a subject tag or append a footer. So DKIM and SPF fail under different conditions, and DMARC (next) only needs one of them to pass and align — the redundancy is deliberate.
Use at least a 1024-bit key; 2048-bit is the common recommendation, and some receivers reject short (e.g. 512-bit) keys outright. Rotate selectors periodically and retire old keys from DNS. DKIM's cryptography has been tightened over time (SHA-256 signing; RSA and Ed25519 key types) — verify the current algorithm guidance before standing up new keys rather than copying an old example. Strong keys reduce the risk of signature forgery; they do nothing about a validly-signed message from a look-alike domain (see §5).
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is the layer that makes SPF and DKIM protect the visible From. It does three jobs at once: it requires an aligned pass, it tells receivers what to do on failure via a published policy, and it requests reports. DMARC was first published in 2015 as the Informational RFC 7489; in May 2026 it was re-issued on the Standards Track as three documents — RFC 9989 (core protocol), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting) — which obsolete RFC 7489. Existing v=DMARC1 records remain valid.
Alignment is the whole idea. A DMARC pass requires either an SPF pass whose MAIL FROM domain aligns with the header From, or a DKIM pass whose d= domain aligns with the header From — at least one. "Alignment" comes in two modes: relaxed (same organizational domain — the default) or strict (identical), set per-mechanism with aspf and adkim. A pass on some unrelated domain does not count.
p= is only a request: a receiver may honor reject/quarantine or apply its own filtering — DMARC is one input to a larger decision, not a delivery guarantee.The policy p= is a ladder: none (monitor only — take no action, just report), quarantine (treat failures as suspicious, usually junk), reject (refuse failing mail at SMTP). RFC 9989 calls p=none "monitoring mode" and quarantine/reject "enforcement." The reports are what make a safe climb possible:
Aggregate reports (rua, daily XML) show every source sending as your domain and whether it aligned — this is how you discover forgotten legitimate senders and spoofing alike. Failure reports (ruf) are per-message detail. The disciplined path: publish p=none, read aggregate reports until every legitimate sender aligns, then move to quarantine, then reject. Jumping straight to reject blocks your own newsletters and ticketing systems. The threat this addresses is exact-domain spoofing; it does nothing for the look-alikes in §5.
Records built for RFC 7489 keep working, but three tags are deprecated (pct, rf, ri) — receivers ignore rather than reject them; remove them at your next DNS edit. Three are added: np (policy for non-existent subdomains), psd (public-suffix-domain signal), and t (testing mode, filling the role pct once played). Organizational-domain discovery no longer relies on the Public Suffix List — it uses a bounded DNS Tree Walk. These specifics are weeks old at this writing; confirm current syntax at rfc-editor.org before publishing.
A mailing list that rewrites the From or edits the body invalidates the original DKIM signature, and SPF sees the list's IP, not yours — so legitimate list mail can fail DMARC and be rejected under p=reject. ARC (Authenticated Received Chain, RFC 8617 — still Experimental) lets an intermediary record and sign the upstream authentication results so a downstream receiver can choose to trust them, and RFC 9989 expands the mailing-list guidance and cautions against blanket reject where lists are common. Two caveats worth stating plainly: the receiver only benefits if it trusts the sealing intermediary (Gmail and Microsoft 365 maintain trusted-sealer lists), and — per RFC 8617 itself — a valid ARC chain attests the authentication results a handler saw, not that the message is safe. Confirm your forwarders' ARC behavior before enforcing.
SPF, DKIM, and DMARC at enforcement address one threat precisely: forging your exact domain in the From line. That is genuinely valuable — it ends direct-domain spoofing and defeats a large class of bulk phishing. It also leaves a defined residual, and naming it is the difference between "compliant" and "protected."
The triad stops exact-domain From spoofing and raises the cost of bulk spoofed spam. It does not stop: look-alike / cousin domains that authenticate their own name; display-name spoofing, where the friendly name reads "CEO" but the address is a free mailbox that passes its own DMARC; compromised legitimate accounts, where the mail truly is from the domain; and content-only social engineering (a plausible request, no link, no attachment). Those are the province of §7's human layer — and they are precisely where BEC operates.
What was best practice became a delivery requirement. Google and Yahoo announced joint bulk-sender rules in October 2023 and began enforcing on 1 February 2024; Microsoft announced its own in April 2025 and began enforcing for consumer Outlook/Hotmail/Live domains on 5 May 2025. A "bulk sender" is defined as one sending roughly 5,000+ messages per day to that provider's users.
| Provider | Enforcing since | Failure handling |
|---|---|---|
| Gmail + Yahoo | 1 Feb 2024 | Rejection / spam placement; bounces carry an error code. |
| Microsoft (Outlook.com, Hotmail, Live) | 5 May 2025 | Rejected at SMTP: 550 5.7.515 Access denied … does not meet the required authentication level. |
The shared baseline for bulk senders: authenticate with SPF and DKIM; publish DMARC at minimum p=none, aligned to the From; provide one-click unsubscribe (the List-Unsubscribe / List-Unsubscribe-Post headers of RFC 8058) on marketing mail and honor it within two days; and keep the spam-complaint rate below 0.3% (Google recommends staying under 0.1%). Transactional mail (receipts, password resets) is exempt from the unsubscribe requirement but still must authenticate.
These rules are an anti-bulk-spam and deliverability regime: they make it much harder to spoof a domain at scale and push the ecosystem toward authentication. They are not an anti-targeted-phishing control. Note the floor: p=none satisfies the requirement while enforcing nothing — a receiver still delivers failing mail. Treating "we meet the bulk-sender rules" as "we are protected from phishing" is the trap; the mandate closes the spoofing-at-scale gap and leaves the spear-phishing and BEC gaps of §7 wide open.
The analyst's method is to stop reading the rendered message and read the headers — they record the message's actual journey and its authentication results.
Received: line is the earliest hop — the claimed true origin. Compare it against the sending domain's known infrastructure.MAIL FROM, header From:, and Reply-To: should be consistent. A Reply-To that routes replies to a stranger is a BEC tell.Any upstream server can write an Authentication-Results header saying whatever it likes. Only the instance added by a mail host inside your own trust boundary is reliable — identify which hostname stamped it before believing it. This mitigates spoofed-verdict headers; it does not tell you the message is safe even when every result reads "pass" (see §5).
Two very different tickets arrive here. First split them: is this our mail failing to deliver (a deliverability problem) or a suspicious inbound message (a phishing report)? Then walk it down.
| Symptom | Look at |
|---|---|
| "Our mail lands in spam / is rejected" | SPF/DKIM present and aligned to the From? DMARC policy? sending-IP reputation and blocklists? For bulk mail, the §6 requirements. |
| "DMARC reports show failures from our own IPs" | A legitimate sender (ticketing, marketing, a subsidiary) that isn't authorized or aligned — add it to SPF/DKIM before tightening policy, not after. |
| "Forwarded mail fails authentication" | Expected: SPF breaks on forwarding (forwarder's IP); DKIM survives unless the message was modified. Consider ARC / SRS; don't reject blindly. |
| "External-sender banner on internal-looking mail" | Routing/relay identity and where the message actually entered — often a legitimate external service sending as your brand, or a spoof. |
| "User reports a phishing email" | Preserve with full headers and report; assess per §8. Treat a confirmed phish as a possible incident, not a delete. |
Two themes recur: alignment, not just a pass, is what DMARC needs — most "our mail fails DMARC" tickets are a real sender that authenticates for the wrong domain; and forwarding failures are usually expected behavior, so reach for ARC/SRS rather than loosening policy.
| Belief | Reality |
|---|---|
| "We have SPF, so we're protected from spoofing" | SPF checks the envelope, not the visible From, and breaks on forwarding. Alone it doesn't stop From-spoofing — that needs DMARC alignment. |
| "A DMARC pass means the email is safe" | It authorizes the domain's use only. RFC 9989 explicitly says a pass is not a guarantee the message is safe or wanted. |
| "We publish DMARC, so we're covered" | p=none is monitor-only and enforces nothing. Protection against exact-domain spoofing starts at quarantine/reject. |
| "DMARC stops phishing" | It stops exact-domain spoofing. Look-alike domains, display-name spoofing, compromised accounts, and content-only social engineering all pass. |
| "DKIM proves who sent it" | It proves the signing domain and that signed content wasn't altered. A look-alike domain validly signs its own mail. |
| "Meeting the bulk-sender rules = secure" | Those are deliverability / anti-spam mandates; p=none satisfies them without enforcing anything or touching targeted phishing. |
Two "From" addresses: envelope MAIL FROM (RFC5321, unseen) and header From: (RFC5322, what the reader trusts). Base SMTP forces no link between them.
SPF (RFC 7208) authorizes sending IPs — checks the envelope, breaks on forwarding, 10-lookup cap. DKIM (RFC 6376) signs headers + body — survives forwarding, breaks if modified. DMARC (RFC 9989, 2026) needs an aligned SPF or DKIM pass and sets policy.
Pass = (SPF pass + aligned) OR (DKIM pass + aligned). Policy ladder none → quarantine → reject. Climb using rua reports; jump straight to reject and you block your own mail.
Authentication proves a domain. It does not stop look-alike domains, display-name spoofing, compromised real accounts, or plain social engineering. RFC 9989: a pass is not a safety verdict.
Phishing = ATT&CK T1566; BEC is text-only and defeats URL/attachment scanning (IC3 2024: ~$2.77B). Levers: authority, urgency, scarcity, trust. The control is out-of-band verification + dual authorization — not a filter.
Standards and threat facts current as of mid-2026, and flagged to verify against the primary source before formal use. SPF is RFC 7208; DKIM is RFC 6376. DMARC was re-published on the Standards Track in May 2026 as RFC 9989 (core), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting), obsoleting the 2015 Informational RFC 7489 — these are recent; confirm the record syntax (deprecated pct/rf/ri; added np/psd/t; DNS Tree Walk) at rfc-editor.org. One-click unsubscribe is RFC 8058. Phishing maps to MITRE ATT&CK T1566 with sub-techniques .001 (attachment), .002 (link), .003 (via service), .004 (voice); verify the current ATT&CK version (the collection tracks v19). BEC/phishing figures are from the FBI IC3 2024 Internet Crime Report and are annual — check the latest report. Transport-layer protections (MTA-STS, DANE for SMTP, TLS-RPT) and brand indicators (BIMI, which requires DMARC at enforcement and is still standardizing) are adjacent and out of scope here — verify their status separately. No configuration is "secure" in the abstract: the SPF/DKIM/DMARC triad addresses exact-domain From-spoofing and bulk spoofed spam, and leaves look-alike domains, display-name spoofing, compromised accounts, and social engineering as residual risks that need the human and procedural controls in §7–§8. Companion to Identity & Authentication (AiTM, phishing-resistant MFA), Attack Taxonomy (T1566 as Initial Access), Incident Response (a confirmed phish is an incident), Zero Trust (assume the credential can be phished), and Networking (DNS, the record store for all three).
Social Engineering & the Phishing Map
When the cryptography holds, attackers route around it — through the person. Phishing is the delivery of a deceptive message to make someone disclose a secret or take a harmful action; in MITRE ATT&CK it is T1566 (Phishing), under the Initial Access tactic. It works because it targets judgment, which no record can sign.
Per the FBI IC3 2024 Internet Crime Report (the most recent annual report at this writing), business email compromise accounted for about $2.77 billion in reported losses across roughly 21,442 complaints — the second-costliest category — while phishing was the most-reported crime (about 193,407 complaints). Because BEC frequently has no link and no attachment, URL and attachment scanning have nothing to inspect. The control that addresses it is procedural: verify any payment or credential request out-of-band on a known-good channel, and require dual authorization for fund transfers. (Treat these figures as annual — check the current IC3 report.)
Adversary-in-the-middle phishing kits relay a login and steal the session cookie, defeating SMS/TOTP/push MFA — only origin-bound, phishing-resistant MFA (FIDO2/passkeys) resists it (see the Identity & Authentication guide). And a user who reports a suspicious message is a detection sensor: a working report button and a no-blame reporting culture surface campaigns faster than any filter. A confirmed phish is an incident — hand it to the Incident Response process.