Email authentication DNS inspection
SPF and DMARC can be located from the domain. DKIM requires the selector used by the signer, normally visible in the DKIM-Signature header as s=.
SPF authorizes sending hosts for an identity
SPF is published as a DNS TXT record at the owner name being evaluated and begins with v=spf1. It authorizes hosts for SMTP identities such as MAIL FROM and HELO; it is not simply a list of “trusted mail servers”. RFC 7208 permits only one applicable SPF record at an owner name. If selection produces more than one SPF record, evaluation returns permerror.
The famous SPF “10 DNS lookups” rule needs context
RFC 7208 limits terms that cause DNS queries during SPF evaluation. Mechanisms such as include, a, mx, ptr and exists, plus the redirect modifier, participate in that processing limit. The counter shown here is a useful static warning based on the visible top-level terms; it is not a complete SPF evaluator because includes and redirects can recursively introduce additional DNS work and RFC 7208 also defines other limits.
DKIM cannot be checked correctly without knowing the selector
A DKIM signature carries a signing domain in d= and a required selector in s=. With the DNS/TXT key service, the public key is queried below selector._domainkey.domain. DNS does not provide a standard operation that enumerates every selector a sender might have chosen, so this page deliberately does not guess selectors.
An empty DKIM p= means the public key is revoked
RFC 6376 requires the p= tag in a DKIM key record. It contains the public-key data; an empty p= has a specific meaning: the key has been revoked. Therefore an existing TXT record with an empty p= should not be presented as a healthy usable key.
DMARC adds alignment and policy on top of SPF and DKIM results
DMARC policy is published at _dmarc.domain as DNS TXT. DMARC evaluates whether authenticated SPF and/or DKIM identifiers align with the domain in the visible RFC5322.From header. A message can pass SPF or DKIM and still fail DMARC when the successful identifier is not aligned with the From domain.
DMARC none, quarantine and reject are requested receiver policies
The required p= tag requests none, quarantine or reject handling for messages that fail DMARC. sp= can specify a subdomain policy. In RFC 7489, pct= is an optional percentage used for policy application and defaults to 100. These tags describe the published request; final receiver behavior can still be affected by local policy.
Relaxed and strict alignment are not the same as authentication pass/fail
DMARC adkim= controls DKIM identifier alignment and aspf= controls SPF identifier alignment. Their default value is relaxed (r); strict mode is s. These settings determine how closely authenticated domains must match the visible From domain. They do not change whether the underlying DKIM signature cryptographically verifies or whether SPF itself authorizes the sending host.
DMARC reporting addresses deserve separate operational review
DMARC can publish aggregate-report destinations in rua= and failure-report destinations in ruf=. When reports are sent to an external domain, DMARC defines additional DNS authorization checks for that reporting relationship. This lookup displays the published values but does not claim that every external reporting destination has completed that authorization.
This is a DNS configuration lookup, not a test of a specific email
To determine whether a real message passed SPF, DKIM and DMARC, you need message-specific evidence: sending IP, SMTP envelope identity, DKIM-Signature values and cryptographic verification, visible From domain, alignment and usually Authentication-Results from the receiving system. A DNS-only page cannot honestly infer all of that.