The Mechanics of Email Authentication: A Deep Dive into SPF, DKIM, and DMARC Alignment

To understand modern email authentication, one must first recognize the historical design flaw of SMTP: the separation of the transport envelope from the message content.

RFC 5321 defines the Envelope (used for routing by Mail Transfer Agents, specifically HELO/EHLO and MAIL FROM), while RFC 5322 defines the Message Header (what user email clients display in the From: line). Because these two layers can state completely different identities, attackers have exploited this split for spoofing.

SPF, DKIM, and DMARC exist to cryptographically tie these layers together.

1. Sender Policy Framework (SPF): Validating the Transport Envelope

SPF (RFC 7208) validates whether the sending MTA’s IP address is authorized by the domain in the Envelope MAIL FROM (also known as the Return-Path or bounce address).

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all

The 10-DNS-Lookup Hard Ceiling

SPF parsing requires MTAs to resolve DNS records. To prevent Denial of Service (DoS) attacks via infinite DNS amplification loops, RFC 7208 imposes a strict limit:

• Mechanisms requiring DNS lookups: include, a, mx, ptr, exists, and redirect.
• If resolving an SPF record requires more than 10 DNS queries, the MTA returns a PermError (Permanent Error). Many enterprise systems fail deliverability because nested include mechanisms exceed this ceiling.

The Forwarding Problem

If a recipient has an automated forward rule (e.g., forwarding work emails to a personal inbox), the forwarding MTA delivers the email from its own IP address. The destination MTA checks SPF against the original MAIL FROM domain, sees the forwarding server’s IP (which is unauthorized), and marks SPF as Fail. SPF alone cannot survive email forwarding.

2. DomainKeys Identified Mail (DKIM): Cryptographic Integrity

DKIM (RFC 6376) provides tamper-evidence and identity assertion by attaching a cryptographic signature to the message headers.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=example.com; s=202609;
  h=from:to:subject:date:message-id;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=b64EncodedSignatureHere...

Canonicalization Algorithms (c=)

Email transport systems frequently modify whitespace, wrap lines, or reformat headers. DKIM uses canonicalization before hashing to prevent legitimate modifications from invalidating signatures:

• simple: Requires exact byte matching. Any alteration breaks the signature.
• relaxed: Normalizes whitespace (converts sequences of spaces/tabs to a single space, removes trailing spaces, converts header keys to lowercase).

The format is c=header_algo/body_algo (e.g., relaxed/simple).

The Two Hashes

• Body Hash (bh): A SHA-256 digest of the message body.
• Signature (b): An asymmetric signature (RSA or Ed25519) calculated over the listed headers (h=) concatenated with the bh value. The verifying MTA queries DNS for the public key located at <selector>._domainkey.<domain>.

Because DKIM signs message headers and the body hash, it survives forwarding as long as the forwarding server does not rewrite the signed headers or append disclaimers to the body.

3. DMARC: Enforcing Identifier Alignment

An attacker could send an email with:

• Envelope MAIL FROM: attacker@malicious-legit-domain.com (passes SPF)
• DKIM signature: Signed by malicious-legit-domain.com (passes DKIM)
• RFC 5322 Header: From: ceo@target-company.com

Without DMARC (RFC 7489), the email passes both SPF and DKIM independently, yet successfully impersonates the CEO. DMARC solves this by requiring Identifier Alignment.

                           +---------------------------+
                           | RFC 5322 Header From:     |
                           | example.com               |
                           +-------------+-------------+
                                         |
                     +-------------------+-------------------+
                     |                                       |
                     v                                       v
         +-----------------------+               +-----------------------+
         | Envelope MAIL FROM    |               | DKIM Signature d=     |
         | sub.example.com       |               | example.com           |
         +-----------+-----------+               +-----------+-----------+
                     |                                       |
            SPF: PASS (IP valid)                   DKIM: PASS (Sig valid)
                     |                                       |
                     +------> Alignment Check <------+
                                         |
                            DMARC Alignment: PASS

Relaxed vs. Strict Alignment

• Relaxed Alignment (aspf=r, adkim=r): The organizational domain (root domain) must match. An RFC 5322 From: user@example.com aligns with SPF MAIL FROM: bounces@mail.example.com.
• Strict Alignment (aspf=s, adkim=s): The Fully Qualified Domain Name (FQDN) must match identically.

Policy Execution (p=)

• p=none: Monitor mode. Delivers email and generates aggregate telemetry reports (rua).
• p=quarantine: Delivers failing emails to the user’s spam/junk folder.
• p=reject: Instructs receiving MTAs to reject the message during the SMTP transaction with a 550 5.7.1 error code.

Summary Checklist for Mail Operators

1. SPF verifies sender IP against the RFC 5321 envelope return path; it breaks under standard forwarding and must stay under 10 DNS lookups.
2. DKIM provides cryptographic proof that the body and specified headers have not been tampered with.
3. DMARC binds the technical authentication domains of SPF and DKIM to the user-visible RFC 5322 From: header. A message passes DMARC if at least one authenticated protocol (SPF or DKIM) aligns with the visible sender.