Understand the three checks
SPF publishes which systems may send mail for a domain. DKIM adds a cryptographic signature using a selector-specific public key. DMARC evaluates whether SPF or DKIM aligns with the visible From domain and publishes a policy for failures. Passing one check does not automatically pass the other two.
Find the exact domains involved
Email authentication can involve several domains: the visible header From domain, the envelope or Return-Path domain, the DKIM signing domain and the domain that publishes the DNS record. Record each one from the message headers before querying DNS. Checking SPF or DMARC at the wrong domain is a common reason for a false “missing record” diagnosis.
Check SPF without creating a permanent error
Query TXT at the exact envelope domain and confirm there is one effective SPF record beginning with v=spf1. Include every legitimate sender, remove obsolete mechanisms and stay within the DNS lookup limit. Multiple SPF records are not merged; receivers may treat them as a permanent error. An SPF pass also does not prove that the visible From address is aligned.
Check DKIM with the selector
Read the DKIM-Signature header to find d= and s=. Query the public key at selector._domainkey.example.com and confirm the key is present and correctly formatted. A key at the wrong selector, a missing record, a changed signing domain or a message modified after signing can cause DKIM verification to fail.
Understand DMARC alignment
DMARC is normally published at _dmarc.example.com. It passes when SPF or DKIM both authenticates and aligns with the header From domain under the domain’s alignment mode. A message can pass SPF for a provider domain while failing DMARC because the Return-Path domain is different. Forwarding can break SPF while DKIM survives, or it can modify signed content.
Read Authentication-Results instead of guessing
Inspect the receiving server’s Authentication-Results header for spf=, dkim=, dmarc=, header.from, smtp.mailfrom and header.d. Compare those values with the DNS records you queried. Do not treat a sender’s marketing dashboard as the only evidence; the receiving server’s result shows what actually happened for that message.
Use reports before enforcing a strict policy
Start a new deployment with DMARC p=none and a monitored rua destination when appropriate. Review aggregate reports, identify every legitimate sender, fix alignment and remove unknown sources before moving to quarantine or reject. Test subdomains, forwarding and third-party platforms before enforcing a strict policy.
Troubleshoot delivery beyond DNS
SPF, DKIM and DMARC passing does not guarantee inbox placement. Also check reverse DNS, MX readiness, sending volume, bounce and complaint rates, message content, links, From and Reply-To behavior, unsubscribe handling and the reputation of the sending IP and domain. Separate authentication failure from spam filtering.
A safe verification workflow
Send a test message from each legitimate provider to more than one mailbox. Save the complete headers, query SPF, DKIM and DMARC with DNS Lookup, compare the domains and selectors, review reports, change one sender at a time and retest. Never publish private keys in DNS or submit message contents containing personal data to a public tool.
Check real data now
Use the live IIPP tool to inspect the domain or IP address you are working with.
DNS Record Lookup →