You've moved a sending domain to a new email service provider, launched a campaign, and the bounce report is already filling up. The provider says the mailbox list is fine, yet messages are failing because the domain's DNS still directs inbound mail to the old destination, or nowhere valid at all. That's where MX record verification starts.
MX, or Mail Exchange, records tell sending mail servers which hostnames accept email for a domain. They're the first DNS-level gate in an email verification workflow. A reliable check should go beyond asking whether an MX record exists. It should validate the record syntax, inspect the preference order, resolve each target through A or AAAA records, test SMTP reachability, and account for DNS propagation.
Table of Contents
- What MX Records Do and Why Verification Matters
- Verifying MX Records with dig, nslookup, and PowerShell
- Reading MX Output Like a Deliverability Engineer
- Online MX Checker Tools and When to Use Them
- Why a Valid MX Record Is Not the Same as Deliverability
- Common MX Verification Failures and How to Fix Them
- Adding MX Checks to Your Email Verification Workflow
What MX Records Do and Why Verification Matters
An MX record maps a domain to one or more mail hosts. The formal model dates to 1986, when RFC 974 defined MX records as domain-to-mail-host mappings with a 16-bit preference value. Lower preference values are tried first, and multiple hosts can share the same priority. The scheme was incorporated into the DNS implementation standard in November 1987, replacing older mail-routing record types such as MD and MF.
That history matters because MX isn't an optional convenience layered on top of email. It's the standards-based mechanism that tells another mail server where it can attempt delivery. If the domain has no valid MX path, senders may return bounces or attempt fallback behavior that still doesn't lead to a functioning SMTP service.
The first gate in a layered check
A useful verification pipeline treats MX as a prerequisite, not a final verdict. The sequence usually looks like this:
- Syntax validation: Confirm the address has a usable domain component before querying DNS. A practical email address format validation guide helps separate malformed input from DNS failures.
- MX lookup: Query the domain and record every returned mail exchanger.
- Hostname resolution: Confirm each MX target resolves through A or AAAA records.
- SMTP reachability: Check whether the destination answers an SMTP connection.
- Mailbox-level testing: Use an SMTP RCPT TO probe when the workflow requires evidence about the individual mailbox.
The distinction between those layers prevents a common operational mistake. A domain can publish a perfectly valid MX record while a specific address is nonexistent, protected by a catch-all policy, temporarily rejecting connections, or routed into a quarantine system.
Why migration checks need context
A DNS change may look correct at the authoritative provider while public resolvers still return the previous configuration. Microsoft's DNS guidance notes that changes can take up to 72 hours to propagate, so a single lookup can give a misleading answer during a provider migration. Compare results from more than one public resolver and, when possible, the authoritative nameserver.
For broader prospecting and domain research, teams may also use the MapLeads homepage alongside technical verification. Keep those functions separate. A lead source can identify addresses, but MX verification determines whether the associated domain advertises a receiving-mail path.
Verifying MX Records with dig, nslookup, and PowerShell
Command-line checks show exactly what DNS returns. They help distinguish a missing record, stale cache, malformed target, or unreachable host when a web checker reports only “valid” or “invalid.”
Linux and macOS
Start with the compact answer:
dig MX example.com +short
A typical result is:
10 mail.example.com.
The first value is the preference. The second is the fully qualified hostname that receives mail. The final dot marks the name as absolute rather than relative to the DNS zone.
For resolver status, TTL, and the full question and answer sections, run:
dig MX example.com
The TTL shows how long a recursive resolver may cache the response. That detail matters after an MX migration, when different resolvers can temporarily return different answers.
Check the target returned by the MX query:
dig A mail.example.com +short
dig AAAA mail.example.com +short
An MX record must contain a hostname, not an IP address. That hostname then needs an A or AAAA answer so a sending server can locate a routable destination. DNS MX guidance documents the preference range from 0 through 65535, with lower values attempted first.
Use +trace to follow delegation from the root through the authoritative path. Use +norecurse to ask a server for its own answer without requesting recursive resolution. Comparing those results helps separate an authoritative configuration problem from a cached or resolver-specific view.
Windows
The classic lookup is:
nslookup -type=mx example.com
PowerShell returns structured objects:
Resolve-DnsName -Type MX example.com
Its output includes Name, Type, TTL, Section, and NameExchange, making results easier to filter or log in scripts. After retrieving NameExchange, query its A and AAAA records with Resolve-DnsName before treating the MX result as usable.
A browser-based email address verification workflow can automate several checks for bulk lists. Raw command output remains valuable when investigating one failing domain or comparing DNS views.
The following walkthrough shows each lookup step in practice, from retrieving the MX record to checking its destination:
Reading MX Output Like a Deliverability Engineer
An MX response is small, but every field carries operational meaning. Consider:
example.com. 3600 IN MX 10 mail.example.com.
The domain on the left is the owner name. 3600 is the TTL, IN identifies the Internet class, MX identifies the record type, 10 is the preference, and mail.example.com. is the target hostname.
Preference and target interpretation
The preference number controls delivery order. A sender tries the lowest value first. If two MX records share the same preference, the sending system can distribute attempts between them, so equal values should reflect deliberate architecture rather than accidental duplication.
The target must resolve through A or AAAA records. It must not be an IP address, and it must not be a CNAME. The RFC 2181 discussion of DNS requirements is the relevant standards reference for avoiding an MX target that violates DNS expectations.
The trailing dot is part of the fully qualified name representation. DNS control panels sometimes add it automatically, while others display it differently. The important question isn't whether the interface shows the dot. It's whether the stored target resolves to the intended host without being appended to the wrong zone.
Chain the answer to the network
Once you have the MX target, query both address families:
dig A mail.example.com
dig AAAA mail.example.com
An address response proves name resolution, not successful mail receipt. Follow with an SMTP connection test against the resolved destination and confirm that the service answers on the expected mail port. A CDN hostname, retired provider endpoint, or host that resolves but doesn't accept SMTP can still produce a technically present yet operationally useless MX record.
Before marking the domain healthy, verify:
- Correct target: The hostname matches the active mail provider or mail architecture.
- Valid chain: A or AAAA records resolve for every target you intend to use.
- Intentional priority: Lower values identify preferred hosts, and equal values are deliberate.
- No retired records: Old provider targets have been removed after migration.
- Reachable service: The target responds appropriately to an SMTP connection.
- Consistent views: Public and authoritative results agree after propagation.
Practical rule: Treat an MX answer as an instruction to continue testing, not as permission to declare the mailbox deliverable.
Online MX Checker Tools and When to Use Them
Web-based checkers are useful when a marketer needs a quick answer or a team needs a report that can be shared with a DNS administrator. MXToolbox, Google Admin Toolbox Dig, and DNSChecker can expose returned records without requiring command-line access. They're convenient for spot checks, propagation comparisons, and initial triage.
Their limitation is abstraction. A web interface may normalize the response, query only its own resolver set, or combine MX status with other overlays. That's helpful for a first pass, but it can hide the difference between an authoritative answer and a cached response.
Choose the tool for the question
| Tool | Best For | Limitation |
|---|---|---|
| Online MX checker | Fast triage and stakeholder reporting | May hide resolver, cache, and response details |
| Google Admin Toolbox Dig | Browser-based DNS inspection | Less convenient for repeated automated checks |
| DNSChecker | Comparing resolver views across locations | A positive lookup doesn't prove SMTP reachability |
dig |
Forensic DNS debugging and scripting | Requires command-line familiarity |
nslookup |
Quick checks on Windows and other systems | Output is less structured for automation |
PowerShell Resolve-DnsName
|
Windows scripts and object-based logging | Availability and behavior depend on the local environment |
For propagation troubleshooting, compare a public resolver such as Google's 8.8.8.8, Cloudflare's 1.1.1.1, and the authoritative nameserver for the zone. A disagreement doesn't automatically mean the record is wrong. It may indicate cached data, delegation problems, or a change still moving through the DNS system.
API-driven services fit recurring validation better than interactive forms. They can cache results, record TTLs, retry temporary failures, and attach the domain result to each address in a batch.
Web tools are for triage and communication. CLI tools are for proving what happened.
Why a Valid MX Record Is Not the Same as Deliverability
A bounce investigation can start with a perfectly valid MX answer and still end with an unusable address. MX verification confirms that a domain publishes a mail destination. It does not confirm that person@example.com exists, that the mailbox is monitored, or that the receiving system will accept that recipient.
Catch-all domains make this distinction easy to miss. Their SMTP servers may accept unknown addresses, then discard, quarantine, or reroute the messages. An MX-only check therefore produces a positive domain result while hiding weak list quality. Spam traps can also use domains with functioning mail infrastructure, so correct DNS does not establish that an address is safe to send to.
What deeper verification adds
A production verifier usually continues with an SMTP-level RCPT TO probe against the selected MX host. The probe tests whether the receiving system appears willing to accept the recipient, while separating temporary responses from hard failures. Greylisting and other defensive controls can reject a first attempt even when the mailbox is legitimate.
DNS and SMTP checks have different failure modes. Lookup delays, resolver timeouts, and inconsistent responses require retry logic and resolver redundancy, as explained in email verification guidance on DNS and SMTP checks. Treating every timeout as an invalid address will remove deliverable contacts from a bulk verification pipeline. A workflow such as CleanMyList should preserve these states rather than collapsing them into a single pass or fail result.
Use this decision path:
- No valid MX: Mark the domain as unable to pass the normal receiving-mail check, while applying any fallback policy cautiously.
- Valid MX, unresolved target: Stop and investigate the A or AAAA chain and DNS configuration.
- Valid MX, reachable SMTP service: Continue to mailbox, catch-all, role-account, and reputation checks.
- Temporary SMTP response: Retry according to policy. Do not turn uncertainty into a hard invalid verdict.
- Catch-all response: Lower confidence because the server accepts unknown recipients.
Verification ends with a sending decision, not merely a DNS result. A clean address still belongs in a controlled sending plan that follows proven warm-up schedules. This matters especially after a domain or provider change, when SMTP behavior and reputation signals may not have stabilized.
Common MX Verification Failures and How to Fix Them
Production failures usually come from a small set of configuration mistakes. The repair process should identify the exact DNS response, correct the record at the authoritative provider, and then test from more than one resolver.
Missing or unusable MX
Run:
dig MX example.com
If the response returns NXDOMAIN, the domain itself isn't resolving. If it returns no MX answer, inspect the zone and confirm that the provider supplied the required mail exchanger. Some systems fall back to A-record checks when MX is absent, but an A record may point to a website that has no SMTP listener. Operational MX verification guidance describes syntax validation, MX lookup, target resolution, and SMTP connectivity as separate stages.
Add the exact hostname supplied by the mail provider, then query the authoritative server and public resolvers. Don't approve a bulk list based on an A record alone.
Bad priorities or stale targets
Run:
dig MX example.com +noall +answer
Look for duplicate preference values that weren't intentionally configured, unexpected providers, and hostnames that belong to a retired service. Equal preferences can distribute traffic, so they're appropriate only when the listed systems are designed to receive the same mail.
After a provider migration, remove old MX records unless the architecture explicitly requires them. A resolver can continue returning the old answer until its cached TTL expires, and Microsoft notes that DNS changes may take up to 72 hours to propagate, as documented in Google's DNS propagation guidance.
Broken target resolution
For each target, run:
dig A mail.example.com
dig AAAA mail.example.com
Then test the SMTP service. If the target is a CNAME, an IP address, a CDN endpoint, or a decommissioned hostname, replace it with the provider's valid mail hostname. Finish by repeating the query through multiple public resolvers and logging the returned TTL, preference, and target. Only then should the address list move back into deeper verification.
Adding MX Checks to Your Email Verification Workflow
Bulk validation becomes more efficient when domains are checked before every address receives a deeper probe. Parsing and deduplicating the list first lets a verifier group addresses by domain, perform one MX lookup per domain, and reuse the result across the batch.
A practical pipeline
- Parse and deduplicate: Reject malformed addresses and create a unique domain set.
- Run DNS checks in parallel: Apply a controlled concurrency limit so a large batch doesn't overwhelm a resolver.
- Cache the result: Store MX targets, preferences, TTL, and the lookup timestamp. Reuse healthy results within an appropriate cache window.
- Continue selectively: Send only domains with a valid MX chain to SMTP and mailbox-level checks. Handle timeouts and temporary DNS failures as uncertain states, not automatic invalids.
If no MX exists, a carefully designed system can inspect A or AAAA fallback behavior, but it should not automatically label the domain deliverable. The fallback host still needs an SMTP connection test, and modern receiving systems generally expect a valid MX route.
A CleanMyList-style service fits this pre-filter role by checking domain DNS as part of a broader address assessment, then continuing into SMTP mailbox existence, catch-all behavior, disposable providers, role accounts, historical bounce reputation, and a send-or-skip recommendation. Developers who need to place the same logic inside signup or application flows can review the CleanMyList email verification API. For teams separating DNS checks from mailbox behavior, guidance on SMTP and catch-all detection is useful when designing the downstream stage.
The key operational record is the reason for every verdict. Store whether the domain had MX, whether each target resolved, whether SMTP answered, and whether the result was definitive or temporary. That audit trail makes bounce investigations faster and prevents a transient DNS incident from permanently poisoning a valid list.
CleanMyList checks syntax, DNS and MX configuration, SMTP mailbox existence, catch-all behavior, disposable providers, role accounts, historical bounce reputation, and the final send-or-skip recommendation without sending messages during verification. Upload a CSV or paste addresses, then visit CleanMyList to run a pre-send check before your next campaign.