SPF, DKIM, and DMARC are email authentication mechanisms that help receiving systems evaluate whether a message is connected to the domain it claims to represent. They solve different parts of the problem. SPF checks whether a sending server is authorized for an envelope domain. DKIM verifies a cryptographic signature added by a domain. DMARC requires one of those authenticated domains to align with the domain visible to the recipient in the From header and tells receivers how the owner wants failures handled.

Authentication is essential, but it is not a declaration that a message is safe or wanted. A criminal can authenticate a domain they control. A compromised legitimate account can send signed fraud. A marketing campaign can pass every check and still generate complaints. Use authentication to establish domain relationships, then combine it with reputation, content analysis, user expectations, and secure business processes.

The identities inside one email

An email contains several identities that ordinary inbox views may hide. The visible From address is what the reader sees. The envelope sender, often represented by Return-Path after delivery, is used for transport and bounces. DKIM adds a signing domain in the signature. The server also introduces itself with a hostname during SMTP. These values can belong to different organizations in legitimate outsourced sending.

Alignment is the bridge that makes authentication relevant to the visible brand. Without alignment, a platform could authenticate only its own technical domain while displaying any customer in From. DMARC asks whether the SPF-authenticated envelope domain or DKIM signing domain is the same as, or an allowed organizational relative of, the visible From domain.

SPF: authorize the sending path

Sender Policy Framework is published as a DNS TXT record for a domain. It lists which servers or included providers are authorized to send using that domain in the envelope identity. The receiver compares the connecting IP with the policy and records a result such as pass, fail, softfail, neutral, or none.

SPF has an important forwarding limitation. When a message is forwarded, the new server’s IP may not be authorized by the original envelope domain. Some forwarders rewrite the envelope sender to preserve SPF behavior, and receivers can use other evidence such as DKIM or ARC. This is one reason a domain should not depend on SPF alone.

Common SPF mistakes

  • Publishing more than one SPF record instead of one combined policy.
  • Forgetting a service that sends mail for the domain.
  • Leaving former vendors authorized after contracts end.
  • Exceeding the DNS-lookup processing limit through many nested includes.
  • Using a broad +all mechanism that authorizes every sender.
  • Assuming SPF protects the visible From address without DMARC alignment.

DKIM: sign selected message content

DomainKeys Identified Mail uses public-key cryptography. The sender calculates a signature over selected headers and the message body, then places the signature in a DKIM-Signature header. The public key is published in DNS under a selector. The receiver retrieves the key and verifies that the signed content has not changed in a way that breaks the signature.

DKIM can survive ordinary forwarding because it is tied to the message rather than the next server’s IP. It can fail when an intermediary modifies signed headers or body content, such as rewriting a subject, adding a footer, or changing encoding. Signers choose which headers to include, so configuration quality matters.

Key management matters

Use strong keys supported by the provider, protect private keys, and rotate selectors through a documented process. Keep the old public key available during the overlap needed for messages already in transit. Give each major platform its own selector when possible so one compromised key can be revoked without disrupting every stream.

DMARC: require visible-domain alignment

Domain-based Message Authentication, Reporting, and Conformance is published at _dmarc.example.com. A message passes DMARC when at least one aligned mechanism passes: SPF with an aligned envelope domain or DKIM with an aligned signing domain. The policy can request monitoring with p=none, quarantine, or rejection for failures.

DMARC also supports aggregate reports that summarize how receivers see mail claiming the domain. These reports can reveal legitimate services that were never inventoried, unauthorized sources, and configuration errors. Reports contain technical data and should be protected, parsed carefully, and retained according to an explicit purpose.

Relaxed and strict alignment

Relaxed alignment can allow an authenticated subdomain to align with the organizational domain, while strict alignment requires an exact match. The right choice depends on the sending architecture. Strict settings can provide tighter control but may break legitimate delegated services unless domains and signatures are designed deliberately.

A safe deployment sequence

  1. Inventory every sender. Include marketing, support, payroll, billing, authentication, monitoring, ticketing, devices, and shadow IT.
  2. Publish correct SPF. Authorize current sources, remove obsolete ones, and keep lookup complexity within the specification.
  3. Enable DKIM for each platform. Use aligned domains and distinct selectors; verify signatures on real delivered messages.
  4. Start DMARC monitoring. Publish a valid reporting address and inspect aggregate data over representative business cycles.
  5. Fix or separate unknown sources. Do not authorize a system merely because it appears in a report. Confirm ownership and business need.
  6. Move toward enforcement. Use a staged policy and, where supported, a percentage during transition. Watch legitimate failures closely.
  7. Maintain the system. Review vendors, rotate keys, monitor reports, and update records whenever sending infrastructure changes.
Monitoring is discovery, not completion. A permanent p=none policy can provide visibility but does not ask receivers to quarantine or reject unauthenticated impersonation. Move toward enforcement after legitimate sources are aligned.

Subdomains and stream separation

Using subdomains can separate reputation and policy for different streams, such as receipts, marketing, and support. It also makes ownership clearer. A marketing provider might sign and send from news.example.com, while account security notices use security.example.com. The visible From domain should remain recognizable to recipients.

Decide whether the organizational domain’s DMARC policy should apply to subdomains and publish explicit records where different handling is needed. A forgotten subdomain can become an impersonation path. Inventory DNS, certificate, and mail ownership together rather than assuming only the root domain matters.

Authentication through forwarding and mailing lists

Forwarding can break SPF because the forwarding server is not in the original domain’s policy. DKIM may survive if content remains unchanged. Mailing lists can modify the subject, body, or sender and break DKIM; some rewrite the From address to a list-controlled domain. ARC can preserve an authenticated chain of custody, but receivers decide how much to trust it.

Do not weaken a domain’s policy globally to accommodate one legacy path without investigation. Work with the forwarding or list operator, test real messages, and document expected transformations. Where possible, modernize the path or use a dedicated domain whose policy matches the behavior.

Troubleshooting a failure

Read the Authentication-Results header added by a trusted receiving system. Identify the SPF domain and result, DKIM signing domain and selector, and DMARC alignment decision. Compare them with the visible From domain. Then trace which platform sent the message and which DNS records were active at that time.

Check for DNS propagation, duplicate SPF records, missing includes, selector typos, expired keys, body modification, and domain alignment. Use test mailboxes at several providers because one receiving system’s display may hide details. Preserve a known-good sample for regression testing after changes.

What authentication does not solve

SPF, DKIM, and DMARC do not encrypt the message body, prove a human identity, prevent a trusted account from being compromised, or guarantee inbox placement. Transport Layer Security can protect a hop between mail servers, while end-to-end content encryption requires different tools. Brand indicators and certificates add other signals but do not replace secure processes.

Combine authentication with the safe allowlisting model, the phishing verification workflow, and least-privilege access for every sending platform. The best result is not a green dashboard; it is a mail system whose identities, owners, and failure modes are understood.

Authoritative reference

Review Google email sender guidelines ↗

Continue reading