How to verify DMARC, DKIM, and SPF setup?
Updated on 24 Oct 2026: We clarified DNS and header checks, added forwarding tests, and replaced fixed pass-rate gates with checks of legitimate sending sources.
The reliable way to verify DMARC, DKIM, and SPF is to check three layers: DNS records, real email headers, and DMARC aggregate reports. A single green result is not final, because some checks only inspect DNS, some only inspect one test message, and some miss the specific selector or sending domain used by your platform.
For a fast first pass, Suped's domain health checker checks published authentication records; a DKIM check still needs the sender's selector. For ongoing verification, Suped's product groups receiver-reported results by source and provides alerts and fix steps through DMARC monitoring.
What a verified authentication setup requires
A verified setup requires more than a record existing in DNS. SPF, DKIM, and DMARC each answer a different question, and DMARC only passes when SPF or DKIM passes with an authenticated domain that has relaxed or strict alignment with the visible From domain. Relaxed alignment means the domains share the same organizational domain. Strict alignment means the domains are identical. Check aspf for SPF and adkim for DKIM: r is the default relaxed mode; s requires an exact domain match.
- SPF verifies that the sending IP is authorized by the domain in the envelope sender, also called MAIL FROM. For an empty MAIL FROM, SPF checks the HELO domain instead.
- DKIM verifies that the message has a valid cryptographic signature and that the public key exists at the selector named in the header.
- DMARC verifies that at least one of SPF or DKIM passes and the authenticated domain matches the visible From domain closely enough for DMARC.
DMARC verification flow from DNS records to headers, reports, and source fixes
A checker that only looks for a record at _dmarc.news.example.com can report DMARC as missing even when a message passes under an inherited policy at _dmarc.example.com. A complete DNS check must evaluate policy discovery. If both tests examine the same effective domain and policy, investigate DNS caching and the time each test ran.
One pass is not enough
Treat a domain as verified only when its effective DNS policy is valid, real messages from each production sender pass DMARC, and reports show those senders continuing to pass.
For Gmail and Yahoo bulk sending, verification also means SPF and DKIM are configured, DMARC is published at least at p=none, and direct mail passes alignment for the From domain. Marketing and subscribed mail also need one-click unsubscribe, but that sits outside SPF, DKIM, and DMARC themselves.
Run the DNS checks first
Start with DNS because every later test depends on the records being in the right place. DMARC is queried below _dmarc for the visible From domain or through its inherited policy path. SPF is a TXT record on the domain evaluated from MAIL FROM, while DKIM publishes a public key below the selector and _domainkey for the signing domain. Check the actual From domain, return-path domain, DKIM signing domain, and selector used by each production sender. Do not stop at the root domain.
DNS lookup commands (replace example names)BASH
dig TXT _dmarc.example.com dig TXT bounce.example.com dig TXT selector1._domainkey.example.com
If you prefer a guided check, Suped's DMARC checker parses the DMARC record and shows the policy, reporting addresses, and syntax issues. That is faster than reading a long TXT value by eye, especially when you are checking multiple domains.
Example authentication recordsDNS
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com" bounce.example.com TXT "v=spf1 include:_spf.example.net -all" selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjAN..."
These are illustrative records, not values to publish unchanged. Replace the SPF include with your sender's documented value and use its complete DKIM public key. Some senders use a CNAME at selector._domainkey.example.com that points to a hosted TXT key. Follow that target when checking DKIM, and confirm that signing is enabled in the sending platform after DNS is published.
Common DNS failures
- More than one v=spf1 TXT record at the same domain causes an SPF permanent error. Multiple quoted strings within one TXT record are joined and are not duplicate records.
- A DMARC record belongs at _dmarc.example.com, not at the root record by itself. Publish only one v=DMARC1 record at each DMARC policy name; duplicates cannot be selected as a valid policy.
- A DKIM checker needs the selector used by the sender. Without it, DKIM can look missing.
- RFC 7208 limits SPF evaluation to 10 DNS-querying terms, including nested includes and redirects. This is not a count of raw DNS queries; ip4, ip6, and all do not count toward that limit. Exceeding the limit returns permerror.
- Use RSA DKIM keys of at least 1024 bits for Gmail and Yahoo, and prefer 2048-bit keys where supported.
- A branded CNAME for tracking or platform verification does not prove SPF, DKIM, or DMARC alignment.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
After publishing a change, check the authoritative DNS answer and then the recursive resolvers used for testing. Cached old values remain until their previous TTL expires; lowering the TTL after a change does not shorten an existing cache entry. Missing records can also remain negatively cached, such as a DKIM selector that returned NXDOMAIN. Send a controlled test once the relevant caches refresh. A fixed 24-hour wait does not guarantee that every resolver has the new record.
Verify subdomain policies and report delivery
Check DMARC at the exact visible From domain before assuming the organizational-domain record applies. RFC 9989 specifies a DNS Tree Walk when no valid record exists at that From domain. An exact subdomain record takes precedence. Otherwise, an existing subdomain uses sp= when present or inherits p= from the applicable organizational-domain record. Receivers still using RFC 7489 use public-suffix-based discovery, so do not assume that every receiver has adopted the Tree Walk.
- Publish a separate subdomain record when that mail stream needs a different policy or reporting address.
- Check sp= for existing subdomains and np= for nonexistent subdomains under the organizational domain.
- If rua points to another organizational domain, confirm that destination has authorized reports in DNS.
Subdomain lookup and external report authorization exampleBASH
dig TXT _dmarc.news.example.com dig TXT example.com._report._dmarc.reports.example.net
For a policy at example.com that sends aggregate reports to rua=mailto:dmarc@reports.example.net, the external authorization lookup above uses the policy domain, example.com, as its first part. The returned TXT record must begin with v=DMARC1. A reporting provider can also authorize destinations with a matching wildcard record. Without authorization, conforming receivers ignore that external destination. Confirm that the destination accepts report emails and compressed XML attachments. Not every receiver sends reports, so one receiver's silence does not prove a setup error.
Confirm results in real headers
Next, send a real email from each production system to a mailbox you control and inspect the full headers. The key header line is Authentication-Results. Use the result added by your receiving mailbox provider or trusted inbound gateway, as required by the trust model in RFC 8601; sender-supplied headers are not proof. It shows the receiving system's SPF, DKIM, and DMARC judgment for that message. Compare header.from with smtp.mailfrom and the DKIM header.d value. In the DKIM-Signature header, d= identifies the signing domain and s= identifies the selector. In Gmail, open the message menu and choose "Show original" to see the authentication summary and raw headers.
Passing header exampleTXT
Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
The example assumes default relaxed matching: bounce.example.com and example.com share the same organizational domain. With aspf=s, that SPF result does not match exactly, but the passing DKIM signature for example.com still permits DMARC to pass. If SPF passes only for an unrelated vendor domain, DMARC needs a passing DKIM signature whose domain meets the From-domain matching requirement.
|
|
|
|---|---|---|
pass | The evaluated authentication method passed. | For SPF or DKIM, also check DMARC domain matching. |
fail | Authentication failed. | Fix DNS or sender. |
softfail | SPF gives a weak negative result, commonly from ~all. | This is not an SPF pass; DMARC needs a passing DKIM signature with the required domain match. |
neutral | SPF makes no authorization assertion, such as with ?all. | This is not an SPF pass; check sender authorization and the DKIM result. |
none | No applicable result or record. | Check method and record location. |
permerror | A permanent evaluation error occurred. | Check syntax, duplicate records, and SPF lookup limits. |
temperror | A temporary DNS or lookup error occurred. | Retest after DNS recovers. |
Header outcomes to check before trusting the result
One test message is still only one test. Repeat this for newsletters, invoices, password resets, sales automation, support replies, and any web server that sends mail. A setup can be correct for one sender and broken for another.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A sent-message test is useful because it checks the path that DNS alone cannot see: the return path, the DKIM selector actually used, and the final DMARC result after the receiver evaluates the message.
Verify forwarded mail separately
A direct test does not verify forwarding or mailing-list delivery. Send a controlled test through any forwarding address or mailing list used in an important mail flow, then compare the original and final receiving headers.
- Forwarding often breaks SPF because the final receiver sees the forwarding server's IP instead of the original sending IP.
- DKIM survives when the signed content remains unchanged. Added mailing-list footers or changes to signed headers can invalidate the signature.
- An SPF pass after envelope-sender rewriting applies to the forwarder's domain. It does not establish DMARC domain matching for the original From domain.
- ARC (Authenticated Received Chain), defined in RFC 8617, preserves earlier authentication assessments. A receiver that trusts the chain can use it to override DMARC handling; arc=pass alone does not prove dmarc=pass.
Separate failures on direct mail from failures introduced by forwarding when reviewing reports. Do not add unrelated forwarding IPs to your SPF record just to make an indirect-path test pass.
Check real traffic with DMARC reports
Verification continues after real mail has flowed. Participating receivers usually generate aggregate XML reports daily, as described in RFC 9990, but the first useful data can take 24 to 48 hours to arrive. The reports group messages by source IP and authentication results; each row can summarize many messages. Compare source IPs and message counts with your sender inventory, rather than assuming that every reported source is authorized.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped's DMARC reporting product groups report data by sending source and gives fix steps for authentication issues. Review those source groups against your sender inventory to distinguish legitimate mail from unauthorized use of the domain. Reporting reflects what participating receivers report, rather than a live check of every message.
DMARC enforcement readiness
Assess legitimate sending sources separately from spoofed traffic. A domain-wide pass rate is not a universal enforcement threshold.
Verified legitimate senders
Sources checked
Expected mail streams pass DMARC across normal reporting cycles.
Known sender failures
Investigate and fix
A legitimate sender has a DNS, signing, or domain-matching problem to fix.
Unresolved business mail
Resolve before enforcing
Important mail streams remain unverified or fail DMARC without an understood cause.
A high overall pass rate can hide a low-volume password-reset failure, while spoofed traffic can drive the rate down even when legitimate sources are correct. Review every legitimate mail stream before changing policy; failing unauthorized traffic is an expected result of enforcement.
When checkers disagree
Disagreement usually means the checks are looking at different inputs. A domain checker can say DKIM is missing because it does not know your selector. A message test can show DKIM pass because it read the selector from the actual email header. An SPF check can pass while DMARC fails because SPF passed for a return-path domain that does not match the visible From domain. Some provider-specific checkers inspect only that provider's expected selectors or CNAMEs, so confirm the checker's scope before interpreting a missing-record result.
DNS checker
- Use it to confirm records exist at the right host.
- It cannot prove a production sender uses the record.
- Run it when you need to validate syntax, policy, and DNS location.
Message test
- Use it to confirm what happened to a real email.
- It only proves that one sender and one message path worked.
- Run it when you need the SPF, DKIM, and DMARC result from headers.
When results conflict, ask which domain was checked, which selector was used, which sender sent the test, and what the final Authentication-Results header said. If the underlying concepts are unclear, this standards guide explains how SPF, DKIM, and DMARC work together.
Do not judge from spam placement
A message can pass SPF, DKIM, and DMARC and still land in spam. Authentication verifies domain use. Content, reputation, complaints, and recipient engagement still affect filtering.
Fix authentication gaps before enforcing DMARC
After verification finds gaps, fix each source before tightening policy. A safe rollout keeps p=none while legitimate sources are being fixed, then moves deliberately to quarantine or reject after their normal mail streams are verified. RFC 9989 makes pct historic and defines t=y as policy test mode. Receivers implementing it apply none instead of quarantine, or quarantine instead of reject, to failing messages. Older receivers can ignore that new tag and apply p as published, so do not rely on t=y as a universal rollout safety control.
Alternative DMARC policies (publish one record at a time)DNS
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com" _dmarc.example.com TXT "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com" _dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
If you need to create or rebuild a record, use Suped's DMARC record generator so the syntax is correct before you publish it. Then verify the record in DNS and watch reports before increasing enforcement.
- Inventory every system that sends mail using the domain, including web apps and billing tools.
- Configure SPF and DKIM for each sender; verify that at least one passes with the required From-domain match.
- Verify each source by sending real messages and inspecting headers.
- Monitor DMARC reports across normal sending cycles, including infrequent business mail.
- Move policy only after the remaining failures are known and acceptable.
Where Suped fits
Suped's product helps track verification after the first check. Review source-level reports and authentication alerts after adding a sender, rotating a DKIM key, or changing DNS, then use the reported failures to decide which source needs a fix before changing policy.
A practical verification checklist
A repeatable checklist is simple: check DNS, send mail, read headers, read reports, then fix what the data proves. It keeps the work grounded in evidence instead of tool disagreement.
- Confirm a valid effective DMARC policy for every From domain, including inherited policy where applicable, and check the rua destination and any required external authorization.
- Confirm one SPF record at each actual MAIL FROM domain, no lookup-limit failures, and no stale senders.
- Confirm each sender signs with the expected DKIM domain and selector, with a working TXT key or CNAME delegation.
- On direct test messages, check spf=pass, dkim=pass, and dmarc=pass. DMARC itself needs only one passing method with the required domain match; investigate forwarded mail separately.
- Confirm normal production sources keep passing after several reporting cycles.
When a result is disputed, save the queried DNS name and answer, the test message's receiving-provider Authentication-Results header, and the relevant report row with its reporting period. These details make the discrepancy reproducible.
Frequently asked questions
Yes. DMARC passes when either SPF or DKIM passes and the authenticated domain matches the visible From domain closely enough for DMARC. If SPF fails but DKIM passes with your domain, DMARC can pass.
SPF can pass for the envelope sender domain while the visible From domain is different. DMARC checks the visible From domain, so the SPF result needs the right domain match or DKIM needs to pass with the right domain.
DMARC itself needs only SPF or DKIM to pass with the required domain match. Configure both: Gmail and Yahoo require both for bulk senders, and forwarding often breaks SPF while an unchanged DKIM signature can survive.
Read the DKIM-Signature header in a real message. The selector is the value after s=. Check that selector under _domainkey for the signing domain shown after d=. Multiple selectors can coexist during key rotation, so use the selector from the message you are testing rather than guessing a default.
Check the authoritative answer, then allow cached old records or negative answers to expire under their previous TTLs. Send a controlled test through the affected sender. A fixed 24-hour delay is not a guarantee that every resolver has refreshed.
Check after every new sender, DNS change, rebrand, platform migration, or policy change. For active domains, continuous monitoring is better because failures often appear after a sender changes infrastructure.
