How to Use This Tool
- Enter the sending domain, without an email address or URL path.
- Enter a known DKIM selector from your mail service or a message’s DKIM-Signature field.
- Run the DNS check and compare each record with your provider’s current instructions.
Calculation Method
The checker retrieves public TXT records at the entered domain, _dmarc.domain and selector._domainkey.domain. It inspects the published configuration at those exact names.
Worked Example
For domain example.com and selector mail2026, the DKIM lookup name is mail2026._domainkey.example.com. A different selector can legitimately return no key.
Choose the Sending Domain and Selector
Use the domain whose configuration you intend to inspect. The visible From address, the envelope sender and a DKIM signing domain can differ in legitimate mail. This tool does not infer those relationships from a domain alone. It checks the public names entered in the form.
The DKIM selector is the s= value in a DKIM-Signature header. Its matching d= value supplies the signing domain. A provider may rotate keys and use several selectors at once. A missing record at an invented selector does not demonstrate that the domain lacks DKIM.
Records and Message Authentication Are Different
Read SPF Without Overstating the Result
An SPF TXT record starts with v=spf1 and declares which senders are authorized for the relevant envelope identity. Two independent SPF records at one name are a configuration problem; several quoted strings within a single TXT record are a different DNS representation and are concatenated.
An ip4 or ip6 mechanism names an address range. include and redirect can lead to other policies and DNS work. Full SPF evaluation needs the sending IP and envelope identity and must observe processing limits, including the ten DNS-querying-term limit. This exact-name inspection does not claim to traverse every dependency or produce a message-level pass.
Keep DKIM and DMARC Claims Separate
A DKIM DNS record publishes information used to verify a message signature. A readable public key does not show that a sender possesses the matching private key or that a particular message body was unchanged. An empty p= key value can represent a revoked key and must not be called a valid active signature.
DMARC connects authentication to the visible From domain through alignment. A policy such as p=none requests monitoring behavior; it is not proof of broken authentication. The current DMARC specification is RFC 9989. A checker limited to _dmarc at the entered name must say that it has not performed the complete DNS Tree Walk for inherited policy discovery.
Fix Configuration with a Controlled Test
Compare returned values with instructions from the service that actually sends the mail. Do not replace an existing SPF policy with a second record or remove another active sender without an inventory. Keep private keys, passwords and mailbox contents out of DNS and out of support screenshots.
DNS caches can retain an old answer until its lifetime expires. An absent record, an invalid value and a DNS-provider failure need different messages. After a change, send a legitimate test message to an account you control and inspect the receiving system’s authentication results. A DNS check alone cannot promise delivery or protection against every impersonation attempt.
What the Result Means
This is a DNS configuration inspection, not message-signature verification, full SPF evaluation, inherited DMARC policy discovery, spam scoring or a guarantee of delivery.
Common Questions
Can You Discover Every DKIM Selector?
No. Selectors are chosen by the sender. Enter the one from your provider or the s= value in a relevant DKIM-Signature header.
Does a Published Record Mean Mail Passes DMARC?
No. A received message needs a passing SPF or DKIM result aligned with its visible From domain. DNS alone cannot establish that result.