Email Authentication Stack
SPF, DKIM, and DMARC — configured correctly, not just present.
Overview
A misconfigured authentication stack causes legitimate mail to be rejected and makes phishing trivially easy. Knowing that SPF, DKIM, and DMARC exist is not enough — you need to build and troubleshoot them. Answer the five questions below at the level of someone who has done this in production and knows where it breaks.
Read before you answer
SPF (Sender Policy Framework) is a DNS TXT record that lists the mail servers authorised to send email on behalf of a domain. The record is published at the domain root (e.g. example.com) and contains mechanisms that evaluate to pass or fail for a given sending IP. Common mechanisms include: `ip4:` and `ip6:` for explicit IP ranges; `include:` to reference another domain's SPF record (used for third-party senders like Salesforce or SendGrid); `a:` and `mx:` to allow the domain's own A or MX records to send; and the catch-all qualifiers `~all` (softfail — treat failures permissively) and `-all` (hard fail — reject on failure). A critical constraint is the 10 DNS lookup limit: SPF evaluation must complete within 10 DNS lookups (each `include:` counts as one), and records that exceed this limit produce a `permerror` result, which many receivers treat as a failure. SPF alone does not authenticate the From: header the user sees — it only validates the envelope sender (SMTP MAIL FROM), which is invisible to end users.
DKIM (DomainKeys Identified Mail) addresses the From: header gap by placing a cryptographic signature in the email header that ties the message to the sending domain. The sending mail server signs each outgoing message using a private key; the receiving server retrieves the corresponding public key from DNS (a TXT record at selector._domainkey.example.com) and verifies the signature. If the message body or headers are modified in transit, the signature verification fails. DKIM survives email forwarding (where SPF typically fails), which makes it the more reliable signal for DMARC alignment. Key management discipline matters: DKIM keys should be rotated periodically (annually at minimum, quarterly for high-risk domains), and old keys should remain in DNS for 48–72 hours after rotation to allow in-flight messages signed with the old key to be delivered.
DMARC (Domain-based Message Authentication, Reporting & Conformance) is the policy layer that makes SPF and DKIM actionable. A DMARC record specifies what receiving servers should do when messages fail both SPF and DKIM alignment: `p=none` (monitor only, take no action), `p=quarantine` (deliver to spam folder), or `p=reject` (do not deliver). DMARC also specifies reporting addresses for aggregate reports (rua=) and forensic reports (ruf=). Aggregate reports (sent as XML, typically daily) show which sources are sending mail claiming to be from your domain and whether they pass authentication — invaluable for discovering shadow IT, misconfigured third-party senders, and phishing attempts. The progression from none → quarantine → reject should be data-driven: move to quarantine only when aggregate reports show that all legitimate sending sources pass authentication, and move to reject only after quarantine has been stable for a sufficient observation period.