MX receiving route
Identifies receiving mail servers and their priority. A domain without MX usually cannot receive mail reliably.
Check email DNS configuration and find receiving, sending and authentication issues.
Enter a domain, choose or type a DKIM selector, then click Run check.
Email DNS
An email DNS check reviews the public receiving and authentication records published for a domain. It does not send email or change DNS; it reads MX and TXT records and evaluates whether the configuration is complete.
MX routes incoming mail, SPF authorizes senders, DKIM publishes the key used to verify signatures, and DMARC tells receivers how to handle messages that fail aligned SPF or DKIM checks.
Identifies receiving mail servers and their priority. A domain without MX usually cannot receive mail reliably.
Lists systems allowed to send for the domain, reducing spoofing and delivery failures.
Publishes the public key used to verify a signature. The checker needs the selector supplied by your mail provider.
Requires SPF or DKIM alignment and defines reporting, quarantine, or rejection behavior.
A working website does not mean its email configuration is correct. Email DNS problems are often discovered only after a migration, DNS change, or delivery failure.
Find missing, duplicate, or malformed authentication records before mail is rejected or sent to spam.
Confirm that SPF, DKIM, and DMARC form a complete authentication chain that limits unauthorized sending.
Check public records after changing business email, delivery platforms, or DNS providers.
The check reads only public DNS data and normally completes within a few seconds.
Extract a valid domain and validate the DKIM selector format.
Request MX, root TXT, selector._domainkey, and _dmarc records together.
Parse SPF mechanisms, DKIM tags, and DMARC policy while separating missing records from query failures.
Show the findings and recommendations on the current page without writing a database snapshot or creating a result URL.
A missing record and a failed DNS query are different conditions. The checker does not treat a network error as proof that a record is absent.
The record was found and the essential fields for this check were recognized.
The record exists but is weak, duplicated, or still uses a monitoring-only policy.
Authoritative DNS responded normally but did not return the required record.
DNS timed out or was temporarily unavailable. Retry later before drawing a configuration conclusion.
A selector is part of the DKIM public-key hostname, such as default in default._domainkey.example.com. Your business email or sending provider supplies it. Common examples include default, google, selector1, selector2, and k1.
DKIM selectors have no public directory or fixed list of possible values. Blind enumeration would still be incomplete and would create many meaningless DNS requests, so use the selector configured by your provider.
It should not. SPF policy for one domain should be combined into a single v=spf1 record. Multiple SPF records can cause PermError and prevent receiving systems from evaluating authorized senders.
No. p=none is a valid monitoring policy that does not quarantine or reject authentication failures. New deployments can collect rua reports first, then move toward quarantine or reject after authorized senders are confirmed.
Web traffic uses A, AAAA, or CNAME records, while incoming email primarily uses MX. These configurations are independent, so a working website does not prove that email receiving is configured.
No. The tool only reads publicly available DNS records. It does not send mail, sign in to a mailbox, change records, or require domain ownership verification.
Every run performs fresh DNS queries. Results remain only in the current page session and no database snapshot is stored. Provider caches and TTL values can delay the global visibility of a recent DNS change.
Continue checking DNS, registration data, reputation, and availability.