Skip to main content

MX Record Lookup

Identify your domain's mail servers

Emails not being delivered? Verify that your MX records point to the correct mail servers. Compare responses from multiple resolvers to detect configuration issues.

In iterative trace mode, the resolver is ignored.
Query multiple public resolvers to compare answers.

Servers and priorities

Display all MX servers with their priorities. The server with the lowest priority receives mail first.

Target validation

Verify that each MX server resolves to a valid A or AAAA record. An MX without an IP prevents delivery.

Multi-resolver comparison

Compare responses from Google, Cloudflare, Quad9 to detect propagation inconsistencies.

Complete diagnosis

Identify orphan MX records, misconfigured priorities, or unreachable servers.

Free and no signup

Test as many domains as you need. No account required.

How to use the DNS lookup engine options effectively

What is the iterative trace?

The trace performs resolution step by step. The resolver first queries the root servers, then the TLD (.com, .fr, .eu), and then the authoritative servers of the target zone. At each step, the page shows the queried server, the answer, the RCODE, and the latency.

  1. 1. Root

    Discovery of the TLD servers for the requested name.

  2. 2. TLD

    Reference to the zone's NS (delegation).

  3. 3. Authoritative

    Final answer (or error) with TTL and latency.

What is it for?

  • Compare answers across resolvers and regions
  • Detect a hot cache, an overly long TTL, or an incomplete delegation
  • Explain a latency difference or an unexpected RCODE

Tip: keep the trace disabled for quick checks; enable it when investigating or preparing a ticket/post‑mortem.

What is the classic trace?

The classic trace queries only the selected resolver (UDP or DoH) and displays the answer as it is perceived from that network vantage point. You get the RCODE, the response sections, and the latency for the client → resolver leg.

  1. 1. Chosen resolver

    Uses the preset or custom configuration to run the query exactly like your service would.

  2. 2. Protocol preserved

    Respects the selected transport (UDP, TCP, or DoH) so you reproduce the real behaviour.

  3. 3. Detailed answer

    Shows the question, answer, and authority/additional sections when present, together with TTL and useful metadata.

Why use it?

  • Check the view of a specific resolver before suspecting delegation issues
  • Confirm cached values and the impact of a TTL or a flush
  • Document a resolution exactly as a client or microservice sees it

Tip: keep the iterative trace option turned off when auditing a given resolver; enable it afterwards to compare with the root → TLD → authoritative path.

How does the propagation test work?

The test queries a set of public resolvers (Google, Cloudflare, Quad9, OpenDNS, ISPs…) in parallel and groups the answers by content and RCODE. You instantly see who already picked up the update.

  1. 1. Multi-point resolvers

    Enables the propagation presets to question several actors spread around the world.

  2. 2. Automatic comparison

    Groups identical answers and highlights divergences or resolver-specific errors.

  3. 3. Actionable summary

    Provides a clear recap, the resolver list, their latencies, and each group's status.

When to use it?

  • Track how a DNS change propagates worldwide
  • Spot stale caches and decide on a targeted flush
  • Share a propagation snapshot in a ticket or post-mortem

Tip: while the propagation test is active, the resolver selector is frozen. Disable the mode to return to single-resolver diagnostics.

What is an MX record?

An MX record (Mail Exchange) indicates which servers receive emails for a domain. When someone sends an email to user@captaindns.com, the sending server queries the MX of captaindns.com to know where to deliver the message.

MX record structure:

FieldDescriptionExample
NameThe domain (@ for apex)@
TypeAlways MXMX
PriorityPreference order (lower = first)10
TargetMail server namemail.captaindns.com.
TTLCache duration in seconds3600

Concrete example:

captaindns.com.  3600  IN  MX  10 mail.captaindns.com.
captaindns.com.  3600  IN  MX  20 backup.captaindns.com.

The server with priority 10 receives mail first. If unavailable, the priority 20 server takes over.


Configuration for common providers

Google Workspace

@  MX  1   ASPMX.L.GOOGLE.COM.
@  MX  5   ALT1.ASPMX.L.GOOGLE.COM.
@  MX  5   ALT2.ASPMX.L.GOOGLE.COM.
@  MX  10  ALT3.ASPMX.L.GOOGLE.COM.
@  MX  10  ALT4.ASPMX.L.GOOGLE.COM.

Microsoft 365

@  MX  0  captaindns-com.mail.protection.outlook.com.

The exact name depends on your Microsoft tenant.

Dedicated server

@  MX  10  mail.captaindns.com.

Make sure mail.captaindns.com has a valid A record.


Best practices

Redundancy

  • Configure at least 2 MX servers with different priorities
  • The backup server should be able to store emails temporarily (store-and-forward)
  • Regularly test failover by stopping the primary server

Correct configuration

RuleExplanation
MX → hostnameAn MX points to a name, never to an IP
Hostname → A/AAAAThe MX target must have an A or AAAA record
No CNAMEThe target must not be a CNAME
Reverse DNSThe mail server IP should have a matching PTR

Avoid

  • MX to IP: MX 10 203.0.113.25 (invalid)
  • MX to CNAME: MX must point to a direct A/AAAA
  • Identical priorities without intention: Can cause unwanted distribution
  • Orphan MX: An MX whose target doesn't resolve to any IP

Troubleshooting common issues

Emails not delivered (bounce)

  1. Verify the MX exists and points to a valid name
  2. Confirm the MX target has an A/AAAA record
  3. Test server accessibility on port 25
  4. Check the reverse DNS (PTR) of the server IP

Emails delivered to wrong server

  1. Check priorities: lowest is contacted first
  2. Remove old MX records after migration
  3. Wait for TTL expiration after changes

Delivery delay

  1. Verify the primary server (low priority) is accessible
  2. If backup receives emails, the primary has an issue
  3. Check SMTP logs to identify retries

Command line verification

Windows (nslookup)

nslookup
set q=mx
captaindns.com

Linux/Mac (dig)

dig MX captaindns.com

Typical result:

captaindns.com.  3600  IN  MX  10 mail.captaindns.com.
captaindns.com.  3600  IN  MX  20 backup.captaindns.com.

Verify the target resolves:

dig A mail.captaindns.com

ToolPurpose
Email TesterTest deliverability and authentication
SPF InspectorCheck SPF record
DKIM InspectorValidate DKIM signature
A LookupVerify MX target resolves
PTR LookupCheck server reverse DNS

Useful resources