MX Routing Summary
{{ domainASCII || domain }}
{{ rows.length }} route{{ rows.length === 1 ? '' : 's' }} {{ mailModeBadge.text }} {{ scoreBadge.text }} {{ queryMs }} ms TTL {{ mxTTL }} s {{ resolverUsed }}
{{ recommendationLine }}
Enter a domain, URL host, or mailbox such as example.com, mail.example.org, or admin@example.net.
Auto tries Cloudflare first, then Google if Cloudflare fails; compare mode samples both.
Quick limits expansion; Standard fits routine checks; Deep covers larger cutovers.
Leave on for readiness checks; turn off for MX row evidence only.
{{ resolve_hostsBool ? 'On' : 'Off' }}
Keep on for production reviews and provider migrations.
{{ detect_cname_targetsBool ? 'On' : 'Off' }}
Enable when a recent MX change may still be cached differently.
{{ compare_resolversBool ? 'On' : 'Off' }}
Leave on for compliance checks; disable only for softer migration notes.
{{ strict_rfcBool ? 'On' : 'Off' }}
{{ run_related_checksBool ? 'On' : 'Off' }}
targets
Use 0 for the selected depth default, or set 1-120 targets.
ms
Set 0 for browser defaults; 3500 ms suits normal public DoH checks.
Priority Exchange Null MX CNAME A AAAA Routing notes Copy
{{ row.priority === null ? '-' : row.priority }} {{ row.exchange }} {{ row.isNullMx ? 'Yes' : 'No' }} {{ row.cname.length }} {{ row.a.length }} {{ row.aaaa.length }} {{ row.note || '-' }}
No MX routing rows available
Run a lookup for a domain with active MX, Null MX, or fallback A/AAAA evidence to populate this matrix.
Check Status Evidence Recommendation Copy
{{ check.label }} {{ check.status }} {{ check.note || '-' }} {{ check.recommendation || '-' }}
No compliance checks available
Complete a DNS lookup before exporting MX readiness, Null MX, CNAME, and related TXT checks.
Resolver Status Code AD Time (ms) Answer fingerprint Copy
{{ row.resolver }} {{ row.status }} {{ row.code }} {{ row.ad ? 'Yes' : 'No' }} {{ row.timeMs }} {{ row.answers || '-' }}
No resolver evidence available
Run a lookup to capture resolver status, latency, AD bit, answer count, and route fingerprint evidence.
 

                

            


        

    

                

                

                    

                        

                            Tags: DNS, Diagnostics, Email, Networking
                        

                        

                            Export to PDF
                            Fullscreen
                        

                    

                

            

        

    


                    
        

        

        

            

            
        

        


                    

                

                

                    

                                                    

                                
                            

                                                    

                                
                            

                                                    

                                
                            

                                                    

                                
                            

                                            

                

            

        
                                                                                                                                                                                                                                                        
        

        

            
            

                Customize

                

                    

                        

                            
                            
                        


                        

                            
                            
                        


                        

                            
                            
                        

                    


                    

                        Advanced

                        

                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    :
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                
                                
                            


                            

                                
                                
                            

                        

                    

                

            

            
        


        

            
            
            
        


        
        

    

    

        

  
  
Mail exchanger records are the DNS instructions that tell other mail systems where to hand off inbound mail for a domain. Lower preference numbers are normally tried first, equal values can share load, and a missing MX record does not always mean mail is impossible because SMTP can fall back to the domain's address records.

  
This page is for the moment when you need to see that routing picture clearly instead of guessing from one raw DNS answer. It accepts a domain, URL, mailto link, or email address, extracts the host, converts internationalized names to their ASCII form, and then turns the result into a routing matrix, a scorecard, resolver evidence, charts, and exportable files.

  
The result keeps several states apart that often get blurred together in tickets and change reviews. A domain can publish active MX hosts, intentionally publish a Null MX to reject inbound mail, publish no MX but still have an implicit A or AAAA fallback path, drift into an invalid mixed Null MX state, or expose no SMTP route at all.

  
The check runs in your browser and sends DNS-over-HTTPS requests to public resolvers. It is a routing audit, not a live delivery test. A clean result does not prove port 25 reachability, TLS success, mailbox existence, spam-filter acceptance, or end-to-end delivery.






  
Technical Details

  
The lookup starts with one normalized host name and asks for MX records through the selected public resolver path. If the MX answer set is empty, the page separately checks the domain's apex A and AAAA records so it can tell the difference between an implicit SMTP fallback path and a true no-route condition. When MX answers do exist, the tool parses the numeric preference and exchange host from each row, sorts them into a stable order, and then optionally expands the target hosts for A, AAAA, and CNAME evidence.


  

    
      
      
        
          
        
      
      
        
        Input
        domain, URL,
        or email

        
        Normalize host
        extract hostname,
        trim dot, ASCII form

        
        MX lookup
        Cloudflare, Google,
        or compare both

        
        Host evidence
        priority parse,
        A, AAAA, CNAME

        
        Fallback path
        apex A or AAAA
        when no MX exists

        
        Scorecard
        Null MX,
        alias, redundancy

        
        Evidence
        resolver code, AD,
        timing, fingerprint

        
        Views
        tables, charts,
        JSON, DOCX

        
        
        
        
        
        
        
      
    
    
The page builds one routing story from DNS answers, host evidence, fallback logic, and resolver sampling rather than showing a bare MX response in isolation.

  


  
Resolver choice changes how much comparison evidence you get. In Auto mode the page tries Cloudflare first and falls back to Google only when that first attempt fails hard. If you enable resolver comparison, both resolvers are queried for MX and the page stores a compact fingerprint, response code, authenticated-data flag, timing, and answer count for each one.

  
Validation depth changes how many MX targets are expanded and how much parallel checking happens. The default expansion can also be overridden with Max expanded targets, up to a hard limit of 120. If the page stops expanding before it reaches every active exchange, it inserts a placeholder row so you know the result is partial rather than silently incomplete.


  

    

      
      
        

          Depth profile
          Default host expansion
          Parallel host checks
          Best fit
        

      
      
        

          Quick triage
          8
          3
          Fast confirmation that a route exists and the obvious hosts resolve.
        

        

          Standard
          20
          5
          Routine support work, provider review, and most change windows.
        

        

          Deep audit
          40
          8
          Larger MX sets, pre-cutover evidence, and stricter hygiene review.
        

      
    

  


  

    

      
      
        

          Result surface
          Built from
          What it answers
        

      
      
        

          Routing Matrix
          Normalized MX rows plus optional A, AAAA, and CNAME evidence
          Which hosts are advertised, in what order, and whether the expanded targets look usable.
        

        

          Compliance Scorecard
          Checks for MX presence, Null MX isolation, canonical targets, host resolution, priority parsing, redundancy, resolver agreement, and related TXT markers
          Which findings are pass, warn, or fail and what to fix first.
        

        

          Preference Ladder
          Active MX rows with parsed preference values
          How the route order is meant to work at a glance.
        

        

          Resolver Drift
          Resolver timing and answer counts
          Whether the sampled resolvers appear to agree and how quickly each one answered.
        

        

          Evidence Log
          Resolver status, response code, AD flag, timing, and answer fingerprint
          What each sampled resolver actually returned during this run.
        

        

          JSON and document exports
          The normalized input plus rows, checks, resolver evidence, and related signals
          A structured snapshot for tickets, change records, and later comparison.
        

      
    

  


  

    
Boundary to keep in mind

    
The related SPF, DMARC, MTA-STS, and TLS-RPT rows are marker checks only. They look for the expected version strings at the expected DNS names. They do not fully parse policy content, confirm HTTPS policy hosting, verify report destinations, or prove that every receiving system will enforce those policies the same way.

  






  
Everyday Use & Decision Guide

  
Use the default settings when the question is simply "what route would another mail system probably try right now?" In that case the Routing Matrix and the summary badges usually tell the story quickly. Standard depth is enough for most support work because it expands a useful number of hosts without making the page slow or noisy.

  
Use Deep audit when the lookup is part of a change window, provider migration, or acceptance check before you tell other teams that mail routing is ready. Deep mode expands more hosts, runs more checks in parallel, and makes it less likely that a hidden backup exchange or stale alias escapes review.

  
Turn on resolver comparison when a DNS change is fresh, one office still sees the old provider, or two people report different answers. That is when the Evidence Log and Resolver Drift view become much more valuable than a single lookup result. The important signal is not just timing. It is whether the answer fingerprints are actually the same.

  
No-mail domains need a different mindset. If a domain is supposed to reject inbound mail, the clean result is one isolated Null MX, not an empty zone and not a mixture of Null MX plus active exchanges. For a real mail domain, a single active MX host is not always broken, but it is still a resilience warning because the scorecard will correctly treat the lack of backup routing as weaker design.

  
    
    
  • Check a provider cutover by confirming route order, host resolution, and resolver agreement before and after the change.
    • 
    
  • Check a bounce complaint by separating no-route conditions from weak redundancy, bad aliases, or unresolved MX targets.
    • 
    
  • Check a parked, marketing, or documentation domain by confirming that Null MX is published alone if the domain should never receive mail.
    • 
    
  • Check a large MX set by watching for the placeholder row that signals more active targets exist than the current expansion budget allowed.
    • 
  






  
Step-by-Step Guide

  
If the page reports that a domain is required or rejects an IP literal, fix the input first. This lookup expects a mail domain, not a raw address.

  
    
    
  1. Enter the domain directly, or paste a URL or email address and let the page extract the host portion for you.
    2. 
    
  2. Leave Resolver strategy on Auto for a normal check, or pin Cloudflare or Google if you need one resolver's view specifically.
    3. 
    
  3. Pick Quick triage, Standard, or Deep audit based on how much host evidence you need and how large the route set might be.
    4. 
    
  4. Keep Resolve MX hosts enabled when the result needs to support a real mail-routing decision, because unresolved targets are one of the easiest ways to miss a broken setup.
    5. 
    
  5. Keep Detect CNAME targets enabled during production review so alias-based MX targets are surfaced instead of hidden.
    6. 
    
  6. Turn on Compare resolvers when you expect propagation lag or split behavior between public caches.
    7. 
    
  7. Use Strict RFC scoring when you want an invalid mixed Null MX state to show up as a fail-grade issue instead of a softer warning.
    8. 
    
  8. Raise Max expanded targets only when you need more host coverage. If you set it to 0, the page uses the default limit for the selected depth profile.
    9. 
    
  9. Run the lookup, read the summary badges and Routing Matrix first, then use the Compliance Scorecard and Evidence Log to decide whether the problem is design, propagation, or host readiness.
    10. 
  






  
Interpreting Results

  
The summary strip puts the main facts in one line: how many route rows were produced, which mail mode the tool thinks it found, how many pass, warn, and fail checks exist, how long the lookup took, the sampled TTL when available, and which resolver result became the primary view. The mail-mode badge is the most important of those fields because it tells you what kind of SMTP story the rest of the page is describing.


  

    

      
      
        

          Mail mode
          What the page found
          How to read it
        

      
      
        

          Active MX mode
          One or more explicit MX records were returned.
          Review ordering, redundancy, host evidence, and resolver agreement.
        

        

          Null MX mode
          A single dot exchange was published without active MX hosts alongside it.
          This is the correct pattern for a domain that intentionally accepts no inbound mail.
        

        

          Implicit A/AAAA fallback
          No MX record was returned, but the domain itself resolved to A or AAAA addresses.
          Mail may still be attempted, but the routing signal is weaker and explicit MX is usually clearer.
        

        

          Mixed Null MX state
          Null MX appeared together with active MX hosts.
          This is contradictory and should be cleaned up so the zone advertises one policy only.
        

        

          No SMTP route
          No MX record and no apex fallback addresses were found.
          Treat it as either a deliberate no-mail posture that still needs explicit Null MX or an incomplete mail setup.
        

      
    

  


  
The PASS, WARN, and FAIL counts are triage signals, not proof of message success or failure. A green score can still hide TLS, policy, reputation, or mailbox-level problems that DNS alone cannot answer. A warning also does not always mean immediate outage. For example, one active MX host can work, but it still deserves a resilience warning because there is no backup path.

  
The Evidence Log is the place to verify drift claims instead of relying on a chart alone. Look at the resolver name, DNS response code, AD flag, time, and answer fingerprint together. If the fingerprints differ, that is stronger evidence of propagation lag or split DNS than a timing difference by itself.

  
Read placeholder rows and related-signal rows carefully. A placeholder means more MX hosts exist than the current expansion budget covered. A PASS for SPF, DMARC, MTA-STS, or TLS-RPT means the version marker was found, not that the whole policy is valid or complete.






  
Worked Examples


  

    
Mail-provider migration with two healthy targets

    
A company moves inbound mail to a new provider and publishes exchanges at preferences 10 and 20. The page returns Active MX mode, both hosts resolve cleanly, no CNAME aliases appear, redundancy passes, and both sampled resolvers show the same fingerprint. That is the kind of result you want before closing the change record.

  


  

    
Recent DNS change with stale public cache

    
One team member still sees the old provider after the cutover. With Compare resolvers enabled, the scorecard warns on resolver agreement and the Evidence Log shows different answer fingerprints between Cloudflare and Google. That points to cache or split-view differences. Wait through the TTL window or verify the authoritative zone before assuming the new configuration is broken.

  


  

    
Intentional no-mail domain

    
A brand-protection or redirect-only domain should never accept mail. The correct result is Null MX mode with one dot exchange and a passing Null MX isolation check. In that case the right action is usually to keep the result as a baseline, not to add ordinary MX hosts.

  


  

    
Single active MX host with unresolved target

    
A domain publishes one MX host, but that host returns no A or AAAA answers. The page can still show Active MX mode because an MX record exists, yet the scorecard warns or fails on host readiness and redundancy. That is a useful distinction: the route is declared in DNS, but the infrastructure behind it still looks unsafe.

  






  
FAQ:


  

    Why can a domain still look mail-capable when no MX record is published?
    
SMTP can fall back to the domain's A or AAAA records when no MX answer exists. The page labels that state separately as Implicit A/AAAA fallback so you can tell the difference between a weak routing signal and a complete lack of route.

  


  

    Why is a CNAME under an MX target a problem?
    
MX exchanges are supposed to name canonical hosts directly. If an MX target resolves through a CNAME alias, the routing design becomes less predictable and the scorecard treats it as a hygiene failure when CNAME detection is enabled.

  


  

    Does resolver comparison tell me what the whole internet sees?
    
No. It samples two major public resolver views. That is useful evidence, especially after a change, but it is still not a full propagation census and not an authoritative server audit.

  


  

    Does a PASS on SPF, DMARC, MTA-STS, or TLS-RPT mean the policy is fully correct?
    
No. The page checks for the expected version markers such as v=spf1, v=DMARC1, v=STSv1, and v=TLSRPTv1. It does not fully validate the full policy body or every dependency around it.

  






  
Glossary:

  

    
MX preference

    
The ordering number attached to an MX record. Lower numbers are normally tried before higher numbers.


    
Null MX

    
A special MX form whose exchange is a single dot, used to say that the domain does not accept inbound mail.


    
Implicit fallback

    
SMTP behavior where a sender can try the domain's own address record when no MX record exists.


    
AD flag

    
Authenticated Data. In this page it reflects what the sampled resolver reported, not an independent validation performed by the page itself.


    
TTL

    
Time to live, in seconds. It is a cache hint that influences how long a resolver may keep an answer before refreshing it.

  






  
References: