5.2Email/DNS security and authentication protocols

Both email spoofing and DNS cache poisoning ultimately come down to failing to recognize "a fake pretending to be the real thing." CSIRT members and architects must be able to accurately judge which countermeasure is effective against which threat. SPF, DKIM, and DMARC have similar names and their roles are easily confused, so understanding what each one verifies and how it uses the verification result is the core of this section.

5.2.1Sender domain authentication (SPF, DKIM, DMARC)

• SPF (Sender Policy Framework) verifies whether the sending mail server's IP address is included in the list of legitimate sending IPs that the sending domain publishes in DNS. It verifies the domain of the envelope From (the SMTP-level sender), which is why SPF verification tends to fail when the envelope From changes during mail forwarding.
• DKIM (DomainKeys Identified Mail) has the sender attach a digital signature to the mail header/body using a private key, which the recipient verifies with the public key published in DNS. It provides both legitimacy of the header From domain and tamper detection of the mail content; since the signature survives as long as the content is unchanged during forwarding, DKIM is more forward-resilient than SPF.
• DMARC (Domain-based Message Authentication, Reporting & Conformance) is the higher-level framework that, based on the results of SPF and DKIM (at least one must pass, and it must align with the header-From domain — "alignment"), lets the sending domain declare a policy for how to handle failing mail (none/quarantine/reject) and has the receiving side enforce it. It also includes a reporting mechanism that returns authentication results to the sending domain. Critically, DMARC does not perform its own signature verification—it "consumes" the results of SPF/DKIM.