Topic 9 · Deep Dive

9.1 Email Anatomy: Headers, Links, Attachments

Two Senders: Envelope and Message

SMTP carries two identities. The envelope sender is the MAIL FROM address in the SMTP conversation, reported later in Return-Path; the message sender is the From: line you read. Relays prepend Received: lines bottom-up, so the chain traces the real transport path. Crucially, From: is unauthenticated free text -- nothing in SMTP binds it to the connection, and SPF, DKIM, and DMARC exist to close that gap.

SPF: Who May Send for the Domain

SPF is one TXT record at the domain apex, evaluated by the receiver during the SMTP session against the envelope address. A real record: example.com. TXT "v=spf1 ip4:198.51.100.0/24 include:_spf.example.net -all". Mechanisms (ip4, a, mx, include) authorize hosts; the qualifier sets the verdict: -all hard fail may be rejected outright, ~all soft fail accepts but marks, keeping misconfigured mailing lists alive -- and redirect= delegates the whole decision to another domain's policy. Read Authentication-Results for the verdict, and remember SPF says nothing about the visible From:.

DKIM: A Seal Over Headers and Body

DKIM signs the message so tampering breaks the seal. The signer hashes the body, canonicalizes chosen headers, and publishes a public key at selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANB...". The signature travels in the message: DKIM-Signature: v=1; a=ed25519-sha256; d=example.com; s=selector1; h=From:To:Subject:Date; bh=3V9k...=; b=Kq2f...= -- d= the signing domain, s= the selector choosing the DNS record, bh= the body hash, and b= the RSA or Ed25519 signature over the canonicalized header block plus body hash. Canonicalization decides tolerance: simple accepts no rewriting, relaxed folds whitespace so a relay or list manager does not void the signature, and h= lists which headers are covered.

DMARC: Alignment Turns Checks Into Policy

SPF passing on a bulk-sender envelope and DKIM signing by a third-party platform prove nothing about the brand in From:. DMARC supplies the rule: publish _dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com; adkim=r; aspf=r", and the receiver requires either SPF to pass with its envelope domain aligned, or DKIM to pass with its d= aligned -- same organizational domain (public suffix plus one label), strict or relaxed per aspf/adkim. p=none collects telemetry, quarantine asks for spam treatment, reject refuses delivery, pct= ramps the fraction, and rua= requests aggregate XML reports so every signer is enumerable before tightening.

Reading Headers, Handling Payloads

Inspect like a receiver: confirm Authentication-Results shows spf=pass dkim=pass dmarc=pass for a domain aligned with the visible sender, then read the oldest Received: hop for the true origin. For links, compare rendered text with the real href; shortened or lookalike registrable domains stay unverified. For attachments, weight risk by execution capability -- macros in .docm, script containers such as .hta, .lnk, and .svg, or a disk image smuggling a shortcut far outweigh a passive image.

Architecture Diagram

Each receiver-side check consumes a different field: SPF reads the envelope, DKIM reads its own signature, DMARC compares both against the visible From.

Key Takeaways

Envelope identity (Return-Path) and display identity (From:) are separate; SPF authenticates only the former.
SPF is a single TXT record with mechanisms plus a qualifier: -all hard fail invites rejection, ~all soft fail only marks, redirect= delegates the policy.
DKIM publishes a key at selector._domainkey and signs canonicalized headers plus a body hash; d=, s=, bh=, b= are the tags you verify.
DMARC adds alignment of the passing SPF domain or DKIM d= with From:, then sets p=none, quarantine, or reject and requests rua= reports.
Read Authentication-Results and the oldest Received: hop; judge attachments by execution capability, not extension cosmetics.

« Back to Topic 9 — 9.2 »