SPF, DKIM, and DMARC examine different identities in an email message. SPF evaluates whether an IP is authorized for the SMTP envelope domain. DKIM verifies a cryptographic signature made by a signing domain and detects changes to the signed content. DMARC compares one or both authenticated domains with the domain visible in the From header, then publishes a requested policy and reporting addresses. The three protocols work together, but none is a substitute for the others.
This distinction matters because recipients see the From header, while SMTP and signing systems may use provider-owned domains behind the scenes. A message can pass SPF for a vendor's bounce domain and still fail DMARC for `example.com`. It can also fail SPF after forwarding yet pass DMARC through an aligned DKIM signature that survives transit. A sound deployment gives each legitimate sender at least one stable aligned path and uses aggregate reports to find the paths that do not.
The work begins with sender inventory, not DNS syntax. List every service that sends with the domain in the visible From address, including employee mail, transactional systems, support platforms, marketing tools, billing systems, and devices. Record its envelope domain, DKIM signing domain and selector, owning team, and shutdown plan. Without that map, an SPF include or DKIM selector can stay in production long after the service that required it has disappeared.
Quick path: Build a sender inventory, use SPF Builder to draft the envelope authorization, confirm active keys with DKIM Discovery, and publish a reporting DMARC policy with DMARC Builder. Review aggregate reports before requesting quarantine or rejection.
Why SPF, DKIM, and DMARC matter in practice
Authentication gives receivers evidence about domain responsibility, not a guarantee that a message is wanted or harmless. A correctly authenticated account can still send spam, and an attacker can authenticate mail from a lookalike domain. Receivers combine SPF, DKIM, and DMARC with reputation, complaint rates, content, connection behaviour, and local policy. Domain owners should deploy the protocols to make legitimate mail identifiable and unauthorized use of their exact domain easier to reject, without presenting authentication as a complete anti-phishing system.
The protocols also fail differently. SPF depends on the connecting IP and can break when a message is forwarded without rewriting the envelope sender. DKIM can survive forwarding if signed fields and body content remain within the signature's canonicalization rules, but mailing lists and gateways may modify messages enough to break it. DMARC needs only one aligned authentication path to pass, which is why a deliberate deployment uses both SPF and DKIM instead of expecting either one to survive every route.
- SPF is about path authorization, not brand identity by itself.
- DKIM is about signed accountability and message integrity.
- DMARC is about alignment, policy, and visibility into how receivers see the domain.
- Operationally, the stack only works when inventory and ownership stay current.
How SPF, DKIM, and DMARC work
SPF begins with the domain used in the SMTP MAIL FROM command, or the HELO identity in the null-return-path case. The receiver evaluates that domain's SPF record against the connecting IP. Mechanisms such as `ip4` and `ip6` authorize address ranges directly, while `include`, `a`, `mx`, and `exists` can trigger DNS work. The result authenticates the envelope identity. It does not authenticate the address a person sees in the From header, and SPF does not travel with the message after the SMTP session.
DKIM adds a `DKIM-Signature` header containing a selector, signing domain, hashes, and signature. The receiver uses the selector and `d=` domain to find the public key in DNS, then verifies the signed headers and body hash. A pass means the holder of the private key signed the message and the signed material verified. It does not prove the author's personal identity or encrypt the message. Key protection, selector rotation, and control of the signing service remain operational responsibilities.
example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"
selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"DMARC reads the visible RFC 5322 From domain and checks alignment. Under relaxed alignment, an authenticated subdomain can align with its organizational domain. Strict alignment requires an exact domain match. An aligned SPF pass or an aligned DKIM pass is enough for DMARC to pass. The policy record can request none, quarantine, or reject for failing mail and can direct aggregate reports to `rua`. Those reports show how participating receivers observed the domain's traffic and are the main feedback loop for rollout.
DMARC does not tell a receiver that aligned mail must be delivered. It only supplies an authentication result and a requested disposition for failures. Receivers can still block authenticated mail for abuse or reputation reasons, and they can apply local handling to messages that fail. This separation is healthy: domain authentication establishes responsibility for an identity, while anti-abuse systems decide whether the specific traffic should be accepted.
Where teams usually get it wrong
Vendor setup instructions often optimize for the vendor's green check rather than the domain's full mail architecture. Adding every requested include to the apex SPF record can exceed the evaluation limit or authorize more infrastructure than needed. Accepting a provider-owned DKIM domain may produce a DKIM pass without DMARC alignment. Publishing DMARC enforcement before testing payroll, support, devices, and regional systems can reject legitimate mail that was absent from the initial inventory. Review the identity used at each layer, not just whether a vendor says authentication is enabled.
Multiple SPF records at one name are another common error; receivers must not merge them into one policy. Old DKIM selectors are often left published with no record of whether the corresponding private keys still exist. DMARC reporting addresses can stop receiving mail because a mailbox was removed or an external destination was not authorized. Each control needs a lifecycle: creation, validation, ownership, rotation or review, and retirement. DNS publication alone is not maintenance.
A more reliable operating model
Make aligned DKIM the preferred path for most third-party senders because it remains attached to the message and is less dependent on fixed provider IP ranges. Configure a branded envelope domain when the provider supports it so SPF can align too. Keep SPF narrowly tied to real envelope senders, and separate mail streams onto subdomains when that gives them distinct ownership and policy. The goal is not perfect symmetry between all three records. It is at least one dependable aligned path for every legitimate stream.
A practical workflow
For each sender, capture a real delivered message and inspect Authentication-Results, Return-Path, the visible From domain, and every DKIM signature. Confirm which SPF domain was evaluated, whether it aligns, which DKIM signature passed, and whether its `d=` domain aligns. Test through normal production routes, including forwarding or gateways that are part of the expected path. A DNS record can be syntactically correct while the provider still sends with an unexpected identity.
Publish DMARC reporting at `p=none`, route aggregate reports to a managed destination, and classify the observed sources. Fix expected streams that lack alignment. Unknown traffic needs investigation, but unaffiliated spoofing does not need to be made to pass. Once important legitimate senders show stable alignment across representative receivers and business cycles, advance policy in controlled stages. State which failures trigger rollback and who can approve it before changing the record.
Treat non-sending domains explicitly. A domain that never sends mail can publish a restrictive SPF policy and DMARC rejection, provided the team has confirmed that no operational system uses it. Subdomains need a conscious plan as well: inheritance and the DMARC `sp` tag can affect names that were never reviewed individually. Keep a record of domains authorized to send and domains intentionally closed to mail so future projects do not quietly reuse the wrong one.
Plan key rotation before it is urgent. Publish a new DKIM selector, confirm that messages sign with it and verify publicly, then stop using the old private key before removing its DNS record. Keeping selectors distinct lets old in-flight messages verify during the transition. Record which provider holds each private key. A TXT record proves only that a public key is available; it says nothing about how the private half is protected.
What good monitoring looks like
Monitor changes to SPF, `_dmarc`, and active selector records. Report new aggregate sources, expected senders losing alignment, selectors approaching a planned rotation date, and SPF policies approaching the DNS-query limit. An alert should identify the mail stream and owner whenever possible. A raw notification that a TXT value changed is useful for tampering detection, but it is not enough to tell a responder whether mail will fail.
Compare DNS observations with provider and change-management records. A selector disappearing may be an expected rotation, an accidental deletion, or an attacker removing evidence after a compromise. DNS history can show when a value was observed, while DMARC reports show how receivers evaluated messages. Neither source identifies the person who changed a provider account. Preserve provider audit logs and private-key custody records for that part of the investigation.
Where DomScan helps
DomScan provides separate tools because the protocols answer separate questions. SPF Builder creates a record and estimates direct lookup-causing terms in the proposed policy, but nested includes still require full evaluation. DKIM Discovery checks a set of likely selectors and cannot prove that every active selector was found. DMARC Builder creates policy syntax and reporting options, but it does not ingest aggregate reports. Use the results with your sender inventory and delivered-message tests rather than treating any builder output as deployment approval.
Independent references: Review RFC 7208 and RFC 6376 for baseline details and neutral operational guidance.
A finished rollout can answer four questions for every legitimate sender: which envelope domain SPF authenticates, which domain DKIM signs with, which path aligns with the visible From domain, and who owns the configuration. When those answers remain current, DMARC enforcement becomes a controlled policy decision instead of a leap of faith.