SPF, DKIM and DMARC Protect Different Parts of the Same Message
The three standards work together, but they do not perform the same check. SPF evaluates whether a connecting server is allowed to send for the envelope sender domain. DKIM checks a cryptographic signature attached to the message. DMARC checks whether a successful SPF or DKIM identity aligns with the domain shown in the message’s visible From address.
Start With the Domain Used in Your From Address
Identify the domain after the @ symbol in the address customers actually see, such as receipts@example.com. Then identify the services responsible for sending messages under that identity. A web server’s domain, a bounce domain and the visible From domain can differ, and that distinction matters when interpreting SPF and DMARC.
For each sending service, record its provider, configured From domain, bounce or Return-Path domain, and DKIM signing domain. If the interface offers a DKIM selector field, use the selector documented by your provider or found in an actual DKIM-Signature header. A guessed selector can return no record even when DKIM is correctly configured elsewhere.
Read an SPF Record Without Missing Hidden Lookups
An SPF policy begins with v=spf1. It can authorize individual IPv4 or IPv6 ranges and refer to other domains through mechanisms such as include. The ending qualifier matters: -all is a fail instruction for nonmatching sources, while ~all marks them with softfail. Neither ending should be chosen until every legitimate sending service is accounted for.
A common mistake is adding one complete SPF record for each provider. SPF permits only one SPF policy record at a DNS name. Combine authorized senders into one carefully maintained policy rather than publishing multiple separate records beginning with v=spf1.
The ten-lookup rule is especially important. SPF evaluation permits no more than ten DNS-querying terms, including nested evaluations of include, a, mx, ptr, exists and redirect. Direct ip4 and ip6 entries do not consume that limit. Counting only the visible include entries can therefore underestimate actual evaluation cost.
Why a DKIM Check Needs the Correct Selector
DKIM uses a private key held by the sender and a corresponding public key published in DNS. A signature includes a selector in its s= field and a signing domain in its d= field. For a fictional message signed with selector selector1 for example.com, the public key is sought at selector1._domainkey.example.com.
The selector is not discoverable from the domain name alone. Some services publish a TXT key directly; others use CNAME records pointing to provider-managed keys. Both arrangements require the right selector and DNS configuration. A missing result for one selector says nothing about other selectors on the same domain.
Check your provider’s instructions before replacing a DKIM entry. Publishing a public key is only one step: the sending platform must also sign outbound mail using the matching private key. DNS inspection cannot verify that signatures on real messages will pass.
DMARC Alignment Is More Important Than an Isolated Pass
DMARC is evaluated against the domain in the visible From field. It passes when at least one of these routes succeeds: SPF passes and its authenticated domain aligns with From, or DKIM verifies and its signing domain aligns with From. Both mechanisms do not have to pass simultaneously for DMARC to pass, although configuring both gives legitimate messages more ways to authenticate.
Consider an email whose visible From domain is example.com. If DKIM verifies with d=example.com, that identity aligns. If SPF passes for bounces.other-example.net, that SPF result does not align with example.com; the valid, aligned DKIM signature can still satisfy DMARC. Conversely, an SPF pass for an unrelated provider domain cannot rescue a message when DKIM also fails to align.
Relaxed alignment generally accepts related subdomains under the same organizational domain. Strict alignment requires the authenticated domain to match the visible From domain exactly. The optional DMARC tags aspf and adkim control those modes.
Interpret DMARC Policy Before Tightening It
The DMARC TXT record is normally published at _dmarc.example.com. The p= tag expresses the domain owner’s preferred handling for messages that fail DMARC. A stricter setting can help reduce successful domain spoofing, but it can also expose forgotten legitimate senders.
The rua= tag asks participating receivers to send aggregate authentication reports to specified destinations. These reports help reveal systems sending on behalf of the domain. They are not a guarantee that every receiver will report. Report mailboxes must be monitored and protected because their contents can reveal organizational sending patterns.
Illustrative DNS Records and What They Tell You
The following entries are documentation examples for the reserved domain example.com, not records to paste into a production DNS zone. Real values depend on your authorized mail services.
What Changed in the 2026 DMARC Standard?
RFC 9989, published in May 2026, replaces RFC 7489. The newer standard formalizes DNS tree-walk policy discovery, adds the np tag for nonexistent subdomains and the t testing-mode tag, and makes the older pct sampling tag historic. The historic rf and ri tags should not be treated as current setup requirements.
The standard also recommends publishing an explicit p tag, but an otherwise valid DMARC policy without it is treated as p=none. Older documentation may still describe p as mandatory. Because software and provider documentation do not all update simultaneously, check both the current standard and your provider’s support before adopting newer options such as t=y.
Troubleshoot the Findings in the Right Order
- Missing SPF: Check the authoritative DNS zone and obtain the correct sending policy from each provider before publishing a consolidated record.
- Multiple SPF records: Merge authorized sources into one policy at the same DNS name; do not simply delete a record without identifying its owner.
- SPF permerror: Review syntax and recursively counted DNS lookups. Investigate unused third-party includes rather than removing necessary sources at random.
- DKIM key not found: Confirm the exact selector, signing domain, record type and DNS host name specified by the sending platform.
- DMARC missing or malformed: Inspect the record under
_dmarc and check its tag syntax. DNS caches may briefly show older values following a change.
- DMARC failure despite SPF pass: Compare the envelope sender domain with the visible From domain. If they do not align, investigate aligned DKIM signing.
Do not jump to p=reject as a shortcut to a cleaner result. First establish the actual sources of legitimate mail and review representative messages from each service, including forwarding and automated notifications.
Confirm DNS Findings Against Real Email Headers
A record lookup is a configuration snapshot, not a delivery test. Send a legitimate message through each important service to a mailbox where you can inspect the original headers. Look for Authentication-Results entries reporting SPF, DKIM and DMARC outcomes, and compare the authenticated domains with the visible From domain.
Forwarding can break SPF because the forwarding server may not be authorized by the original sender’s SPF policy. DKIM can survive many forwarding paths, but signatures may fail if an intermediary changes signed content. Also remember that passing email authentication does not guarantee inbox placement: providers consider spam signals, recipient preferences, sender reputation and other factors.
Common Questions About Email Authentication Checks
Can a domain pass DMARC when SPF fails?
Yes. A valid DKIM signature aligned with the visible From domain can satisfy DMARC even if SPF fails.
Does a missing DKIM selector result mean DKIM is disabled?
No. It may mean the selector is incorrect. Verify the selector from your sending service or a signed message before diagnosing a missing key.
Is p=none the same as having no DMARC record?
No. A valid monitoring record can support DMARC evaluation and request reports. It simply does not request quarantine or rejection on the basis of a DMARC failure.
Will correct SPF, DKIM and DMARC records stop all spoofing?
No. They help receivers evaluate domain identity, but do not authenticate the sender’s intentions or message content. Attackers can use lookalike domains or other methods, and receiver enforcement varies.
