Why Now Daily.

Published

SPF, DKIM and DMARC: How Email Authentication Works

SPF authorizes sending infrastructure, DKIM verifies a domain's cryptographic signature, and DMARC checks whether either result aligns with the visible From domain while publishing policy and reporting instructions.

Timeline

  1. Inventory: List every service that sends mail for the domain, including marketing, support, billing, forms and internal systems.
  2. Authenticate and observe: Configure SPF and DKIM, publish a monitored DMARC policy, and use aggregate reports to find legitimate or unauthorized sources.
  3. Enforce gradually: Correct alignment and forwarding issues before increasing quarantine or reject policy, then maintain records as providers change.

SPF, DKIM and DMARC authenticate domains involved in email, but they answer different questions. SPF asks whether the connecting server is authorized for an envelope-sender domain. DKIM verifies a cryptographic signature placed on selected headers and the message body. DMARC checks whether a successful SPF or DKIM result aligns with the domain visible to the reader in the From header, then applies the domain owner's published policy and reporting choices. [1][2][3]

SPF is published in DNS as a TXT record listing or including permitted sending systems. A receiving server compares the connecting IP address with the policy for the SMTP MAIL FROM identity. This helps reject unauthorized infrastructure, but it does not by itself authenticate the visible From address. Ordinary forwarding can also make SPF fail because the forwarder's IP may not appear in the original domain's record, so SPF alone is incomplete. [1][4]

DKIM uses a private key at the sender to sign defined message data and publishes the corresponding public key under a DNS selector. A receiver verifies that signature and learns which domain took responsibility for it. Forwarding can preserve DKIM when signed content remains unchanged, while mailing lists, gateways or footers may break a signature by modifying covered fields. Key protection, selector rotation and sufficiently strong keys are operational requirements. [2][4]

DMARC connects authentication to the address people actually see. A message passes when at least one qualifying SPF or DKIM result both succeeds and aligns with the author domain under DMARC's rules. The domain can request no enforcement, quarantine or rejection for failures and can receive aggregate reports. The current DMARC specification recommends using both SPF and DKIM, since either mechanism can encounter legitimate delivery paths that the other survives. [3][4]

Authentication is not a verdict that a message is safe. DMARC does not analyze content, prevent deceptive display names, or establish that an authenticated sender's claim is honest. A criminal can authenticate a newly registered lookalike domain, and a compromised legitimate account may send harmful mail. Receiving systems still need reputation, spam, malware and phishing controls, while recipients must still inspect the actual domain and context. [3][4]

Domain owners should avoid jumping directly to a reject policy. First inventory every legitimate sender, configure SPF without exceeding protocol limits, enable DKIM for each capable platform, and publish DMARC reporting. Google recommends monitoring reports and moving gradually from a no-enforcement policy to partial quarantine before stronger enforcement. Reports can reveal forgotten vendors, misalignment, forwarding patterns and attempted impersonation without exposing message bodies in normal aggregate data. [4][5]

Maintenance continues after deployment. Add a new provider before it sends, remove retired infrastructure, rotate DKIM keys, monitor failure trends and keep subdomain policy intentional. Test actual transactional and marketing streams rather than assuming one successful message represents all mail. Users diagnosing delivery should inspect full authentication results, while administrators should follow their receiving providers' current requirements because size thresholds, key-length rules and enforcement practices can change. [1][2][4][5]

Sources

  1. RFC Editor — RFC 7208: Sender Policy Framework
  2. RFC Editor — RFC 6376: DomainKeys Identified Mail Signatures
  3. RFC Editor — RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance
  4. Google Gmail Help — Email Sender Guidelines
  5. Google Workspace Admin Help — Recommended DMARC Rollout

Related stories