Check MX Settings: Interpret & Fix DNS Records in 2026

You shipped the feature, triggered a test email, and nothing showed up. No inbox event, no useful error, sometimes not even a bounce. When that happens, inspecting application logs first often results in lost time in the wrong layer.

Start with DNS. More specifically, start with your MX records.

If you need to check MX settings, you're really asking one question first: does the internet know where mail for this domain should go? If the answer is no, everything above that layer is noise. That's true for a support inbox, a product notification flow, and especially for AI agents that need mailboxes to work without waiting on a human to open a registrar dashboard.

Why Your Email Isnt Arriving and Where to Start

An MX record is the mail routing entry in DNS for a domain. Think of it as the public delivery instruction for inbound email. When another mail server needs to deliver a message to your domain, it looks up that record to decide which host should accept the mail.

That lookup is not optional in practice. MX records use a strict priority mechanism where lower numerical values indicate higher preference, typically with a primary server at priority 10 and a backup at 20, and over 99.9% of all email delivery attempts depend on correctly configured MX records according to MXToolbox.

The first question to answer

Before you inspect SMTP credentials, webhook handlers, or app logic, check three basics:

• Does the domain publish MX records: If there are none, inbound email has nowhere reliable to go.
• Do the MX hostnames look valid: A typo or dead hostname breaks routing fast.
• Are the priorities sensible: If backup servers are ranked ahead of primary servers, delivery can slow down or fail in odd ways.

Practical rule: If mail isn't arriving, verify DNS before you debug code.

This matters even more in automated systems. Human workflows tolerate delay. A person can retry setup later. An agent workflow usually can't. If mailbox creation, reply handling, or customer-response automation depends on immediate email availability, a bad MX setup becomes a runtime failure, not just a configuration issue.

What to ignore at the start

Don't open with the most complex explanation. You don't need full SMTP session traces yet. You don't need to assume your provider is down. You don't need to guess that spam filtering is the problem.

Start with the layer that decides whether inbound mail can be routed at all.

A good diagnostic path looks like this:

1. Query the MX records
2. Interpret the hostnames and priorities
3. Verify propagation across resolvers
4. Check supporting authentication records after routing is confirmed

That order saves time. It also maps cleanly to how delivery operates on the wire.

The Core Toolkit for MX Record Checks

Start with tools that answer two different questions. A browser lookup is good for fast triage during an incident. Terminal commands are better when you need repeatable output for scripts, CI checks, or an agent deciding whether a mailbox is ready to use.

Use a visual lookup first

A visual MX checker helps you confirm the obvious failures fast. You can usually see whether MX records exist, whether the returned hosts resolve, and whether the domain still points at an old provider. That saves time when support says "mail is broken" but the actual problem is a stale DNS change.

The browser view is also useful when you are checking delegated mail setups across multiple domains or subdomains. That case fails more often than teams expect, because the application domain, the reply domain, and the receiving mailbox domain are not always the same. If you are working through that pattern, keep this guide to an MX record for a subdomain nearby.

Use the visual tool for triage. Do not stop there.

The terminal tools that scale

For direct verification, use dig or nslookup. These commands give you plain DNS answers without UI interpretation, which matters when you are comparing resolver output, testing after a deploy, or feeding results into an automated workflow.

Use the simplest query first:

• Linux or macOS: dig example.com MX
• Short output form: dig +short MX example.com
• Windows: nslookup -type=mx example.com

If the result is empty, inbound routing is not configured for that domain. If it returns hostnames you did not expect, compare them against the mail provider you intended to use. If it returns a mix of current and retired providers, cleanup is overdue and delivery will be inconsistent until DNS caches expire.

For agent-driven systems, terminal output is the safer source of truth. A browser helps a human spot a problem. A script needs predictable output it can parse, store, and act on before provisioning inboxes, enabling reply handling, or routing customer mail.

What to inspect in the answer

Check three fields first:

What to inspect	Why it matters	What good looks like
Priority	Tells sending servers which destination to try first	Lower number for the preferred server
Hostname	Identifies the mail exchanger that should accept inbound mail	A valid host that belongs to your intended provider
TTL	Controls how long recursive resolvers may cache the answer	A value that fits your change and rollback window

TTL gets overlooked. It should not. If you just migrated mail providers and some systems still deliver to the old host, cached MX answers are often the reason. In automated environments, that delay can break onboarding flows or cause an agent to mark a mailbox as unhealthy even though the zone file is already fixed.

A short walkthrough helps if you want to see the lookup flow in action:

Use the browser for fast triage. Use the terminal for answers you can trust in scripts and production checks.

Decoding Your MX Record Results

A raw MX answer is compact. That's useful once you know how to read it.

Most results reduce to a pattern like: a priority number and a mail hostname. If you can interpret those two parts, you can spot most routing errors in seconds.

Priority means preference

The number is not a score. It's an order.

A lower value means higher delivery preference. So a server with priority 10 is tried before one with priority 20. That's the normal primary and backup pattern.

Hostname means destination

The hostname is the mail exchanger another server will contact. It should point to a real host that resolves properly and is meant to receive mail for that domain.

Here's the practical reading model:

• Primary route: Lower priority number, expected to receive normal inbound traffic
• Backup route: Higher priority number, used if the primary path fails
• Broken route: Hostname typo, wrong provider hostname, or an old server left in DNS

Reading tip: Lower number first, then validate the hostname, then ask whether that ordering matches your intended mail provider.

What normal looks like

Provider patterns help with sanity checks. As of 2024, more than 98% of active internet domains have at least one valid MX record configured, and 72% use multiple MX records for redundancy. Google Workspace domains typically use 5 MX records with priorities from 1 to 50, while Microsoft 365 domains use 2 to 3 records with priorities from 10 to 20 according to DNS Robot's MX lookup reference.

That doesn't mean every domain should copy those patterns. It means multiple records and tiered priorities are common and often intentional.

TTL changes how long confusion lasts

TTL tells recursive resolvers how long they can cache the answer. If you just changed providers, TTL is the reason one lookup can show the new record while another still shows the old one.

That matters during migration windows. A record that looks correct in your local query may still be stale elsewhere until cache expiry catches up.

Verifying Propagation and Fixing Common Errors

Your agent sends a signup confirmation to a customer. One resolver sees the new MX records. Another still returns the old provider. The result is intermittent delivery failure that looks random in logs and is hard to reproduce unless you test from multiple vantage points.

Propagation checks matter more in automated systems than in human mail setups. A person can retry later. An AI agent processing replies, ticket updates, or lead routing needs consistent DNS answers right now, because one stale lookup can break an otherwise healthy workflow.

Check more than one resolver

Start with the authoritative answer, then compare it against public resolvers such as Google and Cloudflare. After that, resolve each MX host to its A or AAAA record and test whether the target accepts connections on port 25. If the MX hostname does not resolve, or the server is unreachable, mail delivery will fail even if the MX record itself looks correct.

Do not trust the registrar dashboard alone. Query the live DNS path your senders and receiving systems use. If you need a broader operational reference, Robotomail's guide to DNS records for email delivery and routing covers how these pieces fit together.

The errors that keep showing up

The failures here are usually boring, which is why they waste so much time.

• Old provider records still in the zone: A migration finishes, but the retired MX hosts remain published. Some senders will keep trying them until caches expire or the bad records are removed.
• Wrong hostname entered: One character off is enough. So is pasting the provider hostname into the wrong field format for your DNS host.
• Conflicting MX priorities: The backup server gets the lower number, so traffic goes somewhere you did not intend.
• Resolver cache mismatch: Your local test shows the new record, while other networks still serve the old answer.
• MX host exists, but the mail server is not reachable: DNS looks fine, but the receiving host fails network checks or is not listening for SMTP.

Trailing periods deserve a quick note. Some DNS providers want a fully qualified hostname with a trailing period, and some add it for you. The safe move is to follow your DNS host's format rules exactly and then verify the published answer from the authoritative nameserver.

A practical fix sequence

Use a short, repeatable sequence so the issue does not turn into guesswork.

Problem you see	Most likely cause	Best next action
Old provider still appears	Retired MX records still published or cached	Remove obsolete entries, wait for TTL expiry, then recheck from multiple resolvers
Different answers from different resolvers	Cache divergence during propagation	Compare against authoritative DNS first, then retest after TTL
Hostname looks close but not exact	Typo or DNS host formatting mismatch	Re-enter the provider hostname exactly as documented
Backup appears before primary	Priority values reversed	Assign the lower number to the preferred destination
MX host resolves but mail still fails	SMTP service unavailable or blocked	Test port 25 connectivity and inspect the mail server configuration

This is the point where disciplined validation beats visual inspection. If the zone contains both old and new providers, remote servers will not "figure it out." They will follow the published MX set and priority order.

One last check saves a lot of time in production. Record the TTL before making changes, note the exact time you updated the zone, and keep query results from each resolver in your logs. For agent-driven systems, that audit trail makes it much easier to separate DNS lag from application bugs.

If you also handle outbound workflows, inbound routing fixes are only half the job. Clean MX records do not validate sender identity, which is why teams working on deliverability and reply handling usually pair DNS checks with mastering email authentication for outreach.

Beyond MX Verifying SPF DKIM and DMARC

MX gets mail to the right place. It doesn't prove that a message should be trusted once it gets there.

After routing works, the next layer is authentication. That's where SPF, DKIM, and DMARC come in. Together they tell receiving systems who is allowed to send, whether a message was altered, and what policy to apply when authentication fails.

Each record does a different job

• SPF lists the sending infrastructure that's authorized for your domain.
• DKIM adds a cryptographic signature so receivers can validate message integrity.
• DMARC tells receivers how to treat mail that fails SPF or DKIM alignment and gives policy control.

If you only check MX settings and stop there, you solve reachability but not trust. Mail may route correctly and still perform badly because receivers can't authenticate it.

Why this matters in real systems

In production, routing and authentication are linked operationally even though they solve different problems. Support platforms, notification systems, and agent-driven workflows all need both. The domain must accept inbound mail, and outbound mail must authenticate cleanly.

If you want a clear operational walkthrough on the authentication side, Reachly's guide on mastering email authentication for outreach is useful because it focuses on setup logic rather than vague deliverability advice.

For a broader DNS view, this reference on DNS for email is also handy when you're mapping how MX, SPF, DKIM, and DMARC fit together.

Good deliverability starts with routing. Durable deliverability comes from routing plus authentication.

One practical note for teams using custom domains: Robotomail automatically generates and verifies the necessary MX records when a user adds a custom domain, and it also generates the records for SPF, DKIM, and DMARC, as described in Robotomail's custom domain guide. That doesn't remove the need to understand the records, but it does reduce manual entry mistakes.

Automating MX Checks for AI Agent Workflows

An agent provisions a mailbox, sends a message, then waits on a reply to continue the job. If the MX record is missing, stale, or only visible from one resolver, the workflow stalls even though the domain looked fine in a manual spot check.

That is the difference between human setup and agent execution. A person can wait an hour and retry. An automated system usually has to decide now whether a mailbox is usable, whether to queue work, or whether to fail the run and return a clear error.

Why manual MX checks stop being enough

Manual checks still help during debugging, but they are too slow and too inconsistent to serve as the primary control in an API-first mail flow. Agent systems create domains, subdomains, inboxes, and sending identities as part of runtime operations. The DNS check has to fit that model.

The practical requirement is simple. Validation should happen right after provisioning, from code, with results your application can act on. That means checking more than "does an MX record exist." It means confirming the hostnames resolve, checking from more than one resolver, and treating DNS state as part of workflow health.

If you're mapping this to a broader automation architecture, AI automation vs RPA is a useful framing reference. It explains why agent-style systems need runtime checks and decision points instead of one-time setup steps.

What to validate in an agent-driven flow

A useful MX validation step should do four things:

• Run immediately after domain or mailbox provisioning. Waiting for a human review creates avoidable queue delays.
• Query multiple resolvers. One resolver may have fresh data while another still serves the old answer.
• Verify the MX target is valid. The target host should resolve cleanly and should not point to a malformed or parked destination.
• Return actionable failure states. "NXDOMAIN," "no MX present," and "target host does not resolve" are all far more useful than a generic send failure.

In practice, this check often sits between provisioning and first use. If validation passes, the agent can continue to mailbox warm-up, inbound routing tests, or the next task in the chain. If it fails, the system should retry on a short schedule or surface a DNS-specific error to the operator.

Manual inspection still has a place. I use it to verify edge cases and to confirm what a specific resolver is returning. For production agent workflows, though, MX validation should be automated by default and observable like any other dependency.

If you're building email-enabled agents, Robotomail is worth a look. It's built for API-first mailbox creation and supports custom domains with generated DNS records, including MX, SPF, DKIM, and DMARC. The free tier includes one mailbox, 50 sends per day, and 1,000 monthly sends, while paid plans starting at $19/month add multiple mailboxes and custom domain support, as described in Robotomail's mailbox docs.