MX route and priority
Shows every public MX answer and identifies a missing route, Null MX, MailerZ targets, and obvious cross-provider conflicts.
PUBLIC DNS DIAGNOSTIC
Find what is stopping your domain email.
Enter a domain to inspect live MX routing, MailerZ conflicts, ownership records, SPF, DMARC, nameservers, propagation, and optional DKIM.
Public records onlyNo login or DNS credentials required
Ready to inspect 8 diagnostic areasMX routing · conflicts · propagation · nameservers · verification · SPF · DMARC · DKIM
What this tool checks
One scan separates public DNS problems from private account problems.
A DNS checker should not pretend to test what it cannot see. This tool diagnoses public configuration; MailerZ delivery history and your account dashboard diagnose private routes, credentials, limits, and message outcomes.
Propagation comparison
Compares Cloudflare and Google Public DNS answers so recent changes and inconsistent public caches are easier to recognize.
Authoritative nameservers
Identifies the DNS service actually answering for the domain, which may differ from the company where the domain was purchased.
SPF and DMARC
Finds missing or duplicate SPF policies, confirms DMARC is visible, and explains what authentication can—and cannot—prove.
Selector-specific DKIM
Checks the exact DKIM hostname when the user supplies the selector shown in the MailerZ dashboard.
MailerZ ownership evidence
Looks for standard public MailerZ records, then explains when the private dashboard token still needs a manual comparison.
How to diagnose correctly
Use evidence in the right order.
Changing several DNS records at once makes the cause harder to prove. Start at delegation, then routing, then authentication, and finish with a real message.
- 01Confirm authority
Make sure you are editing the DNS provider named by the authoritative nameservers.
- 02Confirm public routing
Verify every intended MailerZ MX target and remove obsolete providers only when the cutover is ready.
- 03Confirm ownership and authentication
Compare the exact dashboard verification, SPF, DKIM, and DMARC records with public answers.
- 04Test incoming mail externally
Send from an unrelated provider to a configured alias, then inspect MailerZ delivery history.
- 05Test authenticated sending
Send through MailerZ SMTP and inspect the received headers plus the remote delivery result.
Symptom-to-cause guide
When DNS is not the whole answer.
Use the live scan first, then match the observable symptom. The smallest targeted test is faster and safer than changing every record.
Domain remains unverified
Run the scan and open Authoritative nameservers first. Confirm the MailerZ token was placed in that active zone, at the exact host shown in the dashboard. A correct record in an inactive DNS zone has no effect.
New email never reaches MailerZ
Open Inbound MX route. No MX answer, a Null MX, or another provider’s targets means sending servers are not being directed to MailerZ.
Some messages go to the old provider
Open Competing MX providers. Mixed unrelated providers can produce inconsistent delivery; MX priority is failover order, not controlled traffic splitting.
DNS looks correct in the provider panel
Open Public resolver agreement. The provider panel shows intended configuration; public resolvers show what outside mail servers can currently discover.
Forwarded email goes to spam
DNS is only one layer. Review SPF, DKIM, DMARC, the original message authentication, content, sender reputation, and the destination provider’s filtering result.
Gmail or Outlook rejects forwarding
Read the complete remote SMTP response in delivery history. Separate a permanent policy rejection from a temporary 4xx deferral, bad destination, quota, or authentication issue.
SMTP authentication fails
The DNS scanner cannot test private credentials. Re-copy the exact SMTP username, generated password, secure port, and encryption mode. Rotate any credential that may be exposed.
Send-as identity does not appear
Confirm the client uses MailerZ SMTP for the custom From identity rather than the inbox provider’s default outgoing server. Then send a new test message and inspect headers.
Unknown recipient is held
This is expected when unknown-mail handling is Hold. Create the intended alias or deliberately change the catch-all rule before releasing or retrying the message.
Monthly or hourly limit reached
DNS changes will not solve an account limit. Wait for the correct reset window or choose a plan with enough monthly outgoing and hourly send-as headroom.
What public DNS cannot prove
A green scan is readiness evidence—not a delivery guarantee.
Whether a private alias points to the correct destination Whether SMTP credentials are correct, active, or rate-limited Whether the recipient provider placed mail in inbox, spam, quarantine, or a tab Whether a private MailerZ verification token matches without its expected value Whether a remote provider is temporarily throttling or rejecting a specific message Whether DNS answers have reached every cache worldwide
The first digit tells you whether retrying may help.
4xx responses are normally temporary. 5xx responses are normally permanent until something changes. The complete enhanced code and provider text take priority over these summaries.
421Temporary service or rate conditionKeep the message queued and retry later with backoff.
450Mailbox or policy temporarily unavailableVerify the recipient and allow a later retry.
451Temporary local or processing errorPreserve the full response; retry later rather than changing DNS immediately.
452Insufficient destination resourcesWait for the destination to recover or contact its operator.
550Permanent recipient, policy, or authentication rejectionDo not loop retries. Fix the reason in the full enhanced response first.
551Recipient is not localCorrect the destination or follow an explicitly trusted forwarding address.
552Message too large or storage exceededReduce message size or ask the destination owner to free space.
553Mailbox name or sender not allowedCheck the exact address, sender authorization, and remote policy.
554Transaction rejectedUse the provider text and enhanced code to identify the real policy reason.
What is leftover MX?
Leftover MX is an obsolete Google, Microsoft, or hosting MX record still published beside MailerZ. RFC 5321 sending servers may choose either target, so some messages never reach the new route. Delete competing MX records at cutover. A public scan on this page shows the published set; it cannot see private aliases or SMTP passwords.
Why does forwarded email go to spam?
If a forwarder rewrites the visible Header From, DKIM signatures and DMARC alignment can fail. MailerZ does not rewrite Header From. The destination inbox still applies its own filters, so a preserved From is necessary evidence, not a placement guarantee.
Why did emailing myself from Gmail fail?
Gmail can short-circuit mail sent from an account to itself. That is a bad test for a forwarding path. Send from a different mailbox to the alias, then inspect MailerZ delivery history and the destination inbox.
Can a DNS scan prove delivery?
No. MX, SPF, DKIM, and DMARC answers show public configuration. Inbox placement, credentials, catch-all policy, and destination quotas are private and appear in delivery history or the account dashboard.
Still blocked?
Send support evidence, not only “email is not working.”
Include the diagnostic summary, domain, affected recipient, sender, UTC timestamp, complete SMTP response, message ID when available, and the last successful test. Never send SMTP passwords or private account credentials.