Mail authentication begins with several different records
MX, SPF, DKIM and DMARC solve different problems. MX records describe where incoming mail should be delivered. SPF describes which sending systems are authorised for an envelope domain. DKIM associates a message signature with a published key. DMARC adds alignment requirements and a requested policy for messages that fail its evaluation. One green record cannot substitute for the others.
This audit collects the public records relevant to those mechanisms and applies focused configuration checks. It does not send a test message, authenticate a real email or promise inbox placement. For DKIM, you provide a selector because the tool cannot reliably discover every selector a domain uses. That input keeps the lookup targeted and avoids pretending an absent guessed selector proves DKIM is missing.
Start with the domain and a real DKIM selector
Enter the domain whose mail configuration you intend to review. For an initial overview, the tool queries MX, TXT at the domain and TXT at the direct _dmarc name. If you have a signed message, inspect its DKIM-Signature header and find the s= selector and d= signing domain. Use the signing domain and selector together when checking the published key.
A domain can use several selectors for different providers or during key rotation. Querying one selector says nothing about the others. A provider may also use a CNAME arrangement, and the resolver can return a chain leading to a TXT key. Read the complete record evidence if the configuration is more complicated than a single direct TXT record.
The audit does not enumerate mailbox addresses or attempt delivery. MX presence is useful routing information, but an empty MX answer has several possible interpretations, including a domain not intended to receive mail. A Null MX configuration has a specific meaning and should not be treated like an ordinary destination server.
The Overview tab explains the findings. Measured data lets you search individual fields and values, while JSON report shows the complete export. Export JSON to retain a baseline, or print the findings for your own records. Review the report before sharing it: browser characteristics, token claims, and file names can reveal information about your setup.
Review SPF and DMARC without skipping their rules
SPF should normally have one TXT record beginning with v=spf1 at the relevant domain. Multiple SPF policy records can cause a permanent evaluation error. The audit identifies policy count and highlights an explicit +all, which authorises every source under that mechanism. It also shows the record so you can see includes, redirects and the final qualifier.
This tool does not recursively evaluate SPF includes, count every DNS-dependent mechanism or test a particular sender IP. A syntactically plausible record can still exceed SPF’s lookup limits or authorise an unintended service. For an incident involving a real message, evaluate the actual envelope sender and sending IP, not only the visible From header.
DMARC policies commonly use p=none, p=quarantine or p=reject. A monitoring policy is not the same as a request to reject failing mail. It can be an intentional stage in deployment while the domain owner reviews legitimate senders. This audit queries the direct _dmarc record and does not perform full organisational-domain fallback or evaluate alignment for a message.
Turn the DNS report into a deployment plan
Inventory every legitimate sender before tightening policy: primary mailboxes, support platforms, newsletters, transactional services and older applications can all send on behalf of a domain. A record that looks restrictive can disrupt legitimate mail if one provider is missing. Verify each provider’s documented SPF and DKIM setup, and inspect real authentication results from representative messages.
For DKIM, a published nonempty public key is configuration evidence, not proof that current messages are signed correctly. A message signature must cover the appropriate data, use the expected key and survive transit according to the signature’s canonicalisation rules. A revoked or rotated key can also affect older messages. Use message-level verification when the question is whether a specific email is authentic.
Preserve the DNS report with a timestamp before and after a change. Cached records can delay the view seen by receiving servers. Review DMARC aggregate reports and mail-provider logs after rollout, rather than judging success from one DNS lookup. Authentication improves domain-spoofing resistance but does not guarantee that message content is safe or that a receiver will place it in the inbox.
Mechanisms and what this audit checks
| Mechanism | Included check | Outside this check |
|---|---|---|
| MX | Returned mail-exchange records | Mailbox existence and actual delivery |
| SPF | Policy count and selected broad-policy warnings | Full include recursion and sender-IP evaluation |
| DKIM | TXT key at the supplied selector | Verification of a message signature |
| DMARC | Direct policy record and monitoring policy | Message alignment and organisational fallback |
Strengths and limitations
What this is useful for
The audit puts related DNS evidence in one report while keeping the mechanisms distinct. A user-supplied selector makes DKIM checks meaningful, and explicit limitations prevent a record-presence check from being mistaken for message authentication. It is useful for setup reviews and change documentation.
What to keep in mind
Mail systems are more complex than their public DNS records. The tool does not deliver messages, inspect provider logs, verify signatures or calculate domain-wide deliverability. Missing direct DMARC data can require fallback analysis, and an apparently valid SPF record still needs evaluation against its full mechanism chain.
Common questions
Does p=reject guarantee that spoofed mail is blocked?
It asks participating receivers to reject mail that fails DMARC under the applicable policy. Receivers can apply local decisions, and alignment plus authentication must be evaluated correctly. It does not stop lookalike domains, compromised legitimate accounts or harmful mail that passes authentication.
How do I find the DKIM selector?
Open the original headers of a message sent through the service you want to check. In DKIM-Signature, the s= tag is the selector and d= is the signing domain. Use both from the same signature. Guessing common selector names can miss an otherwise correct configuration.
Are any emails or passwords sent?
No messages are sent and no mailbox credentials are requested. The public domain and optional selector are sent to this server and then to Google Public DNS. The audit reads DNS records only; it cannot see your inbox or authenticate to the mail provider.
Can a domain have more than one SPF record?
A domain can have many TXT records for unrelated purposes, but publishing multiple SPF policy records at the same name can cause SPF permerror. Several allowed senders should be expressed within an appropriate single SPF policy, following the standard’s evaluation and DNS-lookup limits.