The mail exchanger (MX) record is a DNS pointer with a priority value that tells sending servers which host accepts your inbound mail. It's not an account setting. Verify it with dig or an API: a broken MX record queues, delays, or bounces mail before SPF, DKIM, or DMARC even come into play.
What Is a Mail Exchanger MX Record?
A mail exchanger MX record is the DNS routing pointer that tells every sending server which host accepts inbound mail, and the wrong record can route mail to a host before authentication or content checks. Run 'dig MX example.com +short'; if the answer shows '0 hostile.example.com', the priority 0 record wins, so inbound mail routes to that host before authentication or content ever come into play.
That is the mail exchanger pointer at work. The record includes a hostname and a priority value; the lower number gets tried first. It is not an account setting you can fix in Outlook or Google Workspace. See RFC 1035, DNS Implementation.
Get it wrong and your messages queue, delay, or vanish before any content gets judged.
The failure mode I care about most is the gap between how SMTP finds the mail exchanger MX record and how SPF, DKIM, and DMARC treat the result.
I've watched one broken mail exchanger MX record kill a campaign: 'dig MX example.com +short' returned '10 dead.example.com', the hostname returned NXDOMAIN, and the campaign never reached the first open. Let's make sure yours isn't one.
I'm Alex Morgan, a deliverability engineer who has run these MX checks on live sending domains.
TL;DR: A mail exchanger mx record is the DNS route that tells sending servers which host accepts inbound mail. It must resolve to an A/AAAA record; lower priority wins.
- It’s a routing pointer, not an Outlook or Workspace setting; syntax is
10 mx1.example.com. - A valid MX target has to resolve to an A/AAAA record (no CNAME) or mail queues before authentication.
- Check with
dig MX example.com +short, then resolve each hostname; public resolvers show the live answer. - Priority failover only works if every listed MX host resolves; a dead backup is a second failure point. My pre-send rule is specific: I run 'dig MX example.com +short', resolve the priority 0 host first, and stop the send if that host returns NXDOMAIN or no A/AAAA answer until the record is fixed.
Mail Exchanger MX Record Definition
For troubleshooting, the syntax is what counts: 10 mx1.example.com. The 10 sets priority; a lower value takes precedence over a higher one. mx1.example.com is the accepting hostname.
RFC 1035 sets the target rule: the MX hostname must not be a CNAME, and it must resolve directly to A or AAAA records. If it does not, SMTP has no usable destination, so mail queues or fails. I also cross-check RFC 5321 when I need the SMTP-side behavior that decides whether a failed MX lookup defers the message or bounces it.
This pair is the first thing I check in the lists I clean. The reason I still check it the same way is historical: the MX target model was set in RFC 1035, and today I still see the same CNAME-target failure because the final A or AAAA answer is missing. I also keep a second sample ready when I test priority groups: '20 mx2.example.com' and '30 mx3.example.com'. The same priority rule applies-'20' is tried only if the '10' host fails, and '30' is tried only if both '10' and '20' fail. I see two common mistakes in the lists I clean.
The first is giving two MX hosts the same priority and expecting strict round-robin. SMTP can pick either host, so mail can be accepted by the wrong server even when both records look valid. The second is pointing an MX record at a CNAME. RFC 1035 forbids that target shape, and many receiving servers reject the lookup before delivery starts.
I treat a CNAME target as a broken record until the host is replaced with an A or AAAA name. I also verify A or AAAA records after the priority check because I've seen MX records with valid preference numbers but no routable address. If the host answers a DNS query but returns no A or AAAA record, SMTP has the same problem as a CNAME target: no final IP to connect to, so the message is deferred.
That's the whole record.
Rather skip ahead? Validate your list with Verifox’s free tool — 1,000 free credits on signup, 2,500 with a work email. No card required.
How a Mail Exchanger MX Record Routes Email
Sending mail servers don't guess. They run the same RFC 5321 delivery sequence for every message, and the MX record sits at the front of that sequence. Here's the path for a message addressed to someone at example.com.
- The sender extracts the domain from the recipient address after the @ symbol.
- It issues a DNS query to get MX records for that domain.
- If one or more MX records return, the DNS resolver passes back the full set. The sending server sorts that set by priority, lowest number first.
- For the lowest-priority MX target, the sender queries A and AAAA records to get a usable IP address.
- It opens a connection to that IP on port 25 and starts the SMTP conversation.
- If the connection succeeds and the server accepts the recipient with a 250 reply, delivery ends. If the connection fails or the target returns a 4xx temporary error, the sender moves to the next MX in priority order. A 5xx permanent rejection stops retries for that recipient.
If multiple MX records share the same priority, the sender may rotate among them. RFC 5321 leaves that choice to the implementation.
Think of MX priority as a ranked list of loading docks. The sender pulls up to the lowest-numbered dock first. If that dock refuses the connection or leaves the truck waiting, the driver backs up and tries the next dock. A permanent "no such recipient" sign stops the trip.
Delivery order and fallback
The order matters. The sender tries the lowest-numbered MX host before any other destination. It doesn't query A records first, and it never looks at a website IP unless the MX lookup returns nothing.
The MX target can live outside the recipient's domain. Google Workspace domains routinely publish MX records pointing to aspmx.l.google.com, for example. The sender only needs the hostname to resolve to an IP.
DNS resolvers also cache the MX set for the record's TTL, so a priority or hostname change doesn't reach every sender instantly. When someone edits an MX record and tests immediately, the stale answer can hide the new one.
The empty MX case trips people.
RFC 5321 section 5.1 treats a domain with no MX records as if it has an implicit MX with priority 0 pointing to the bare domain name. See RFC 5321. The sending server then resolves A or AAAA records for the domain itself and attempts delivery to that IP on port 25.
That fallback is where misdiagnosis lives. A domain can have an A record pointing to a web host or a parked page, no MX record, and no SMTP listener on that host. The sender still tries port 25, gets a connection refused or a timeout, and returns a bounce. The bounce text says "connection timed out" or "no route to host," not "missing MX record." The recipient's team checks the mail server settings, the firewall rules, and the sender reputation. None of those is the problem.
From the DNS records I've reviewed across Verifox's support queue and every throwaway domain I've tested while writing this piece, a domain with an A record but no MX never fails silently. It attempts delivery to the website's IP, and the failure looks like a routing issue. I've pulled a representative log from those reviews: 'connect to <A-record IP>:25: Connection timed out'.
This MX lookup happens before authentication. SPF, DKIM, and DMARC checks run on the message after the SMTP connection accepts it. A broken MX record stops the process before any of them matter.
Every hop that transports mail follows the same order. Forwarding services, security gateways, and backup MX hosts all run an MX query first. If no MX exists, they use the implicit MX fallback and repeat the same connection error at each stage.
That's why an MX check comes before an A record check. An A record can be perfect and the domain still cannot receive mail.
When I reproduce this fallback on a throwaway domain with no MX and an A record pointing to an unresponsive host, 'dig +short MX example.com' returns empty, 'dig +short A example.com' returns the A record, and 'nc -vz -w 5 example.com 25' times out. The failure reads as a port 25 connection timeout, not as a missing MX record.
How to Check Mail Exchanger MX Records
Run the command-line lookup first. It returns the answer your resolver actually holds, which is the same answer a remote mail server sees when it tries to deliver to your domain. A registrar's web interface shows the record you configured, not the record DNS is currently serving to the rest of the internet.
Don't trust the registrar page. Trust the resolver answer.
Follow this sequence when you inspect an MX record.
- Run the lookup from a terminal, not the registrar console. On macOS, Linux, or any Unix shell, use:
dig MX example.com +shortThe +short flag strips headers and statistics, leaving one priority-hostname pair per line. A line like 10 mx1.example.com. means priority 10 points to mx1.example.com. The trailing dot marks a fully qualified domain name, and it's normal.
Run dig MX example.com without +short if you also want the TTL and the authority section. The TTL is the number of seconds resolvers may cache the answer; a high TTL means a change will take longer to appear.
On Windows, nslookup is built in:
nslookup -type=mx example.comThe output labels the priority as "MX preference" and the hostname as "mail exchanger." Treat the preference as the priority value and sort the answers from lowest to highest.
- Check the hostname in each answer. See What is a DNS MX record?. Run
dig A mx1.example.com +shorton any hostname from the MX output. If that returns nothing, the MX record points to a dead end, and remote mail servers will fail to connect even though the MX record exists.
- If you have no terminal, use Google Admin Toolbox Dig as a web fallback. It sends the same query through a public resolver and shows the answer section without local tools. Keep it to spot checks. A web lookup is still a resolver's answer, not a replacement for the command line when you're debugging delivery.
- After you change an MX record, query public resolvers directly to bypass your local cache. Run:
dig MX example.com @1.1.1.1 +short
dig MX example.com @8.8.8.8 +shortIf Cloudflare's 1.1.1.1 and Google's 8.8.8.8 return different answers, propagation hasn't finished everywhere.
Plan for a propagation window up to 72 hours. In practice, most changes appear within 5 to 30 minutes, but I plan for the 72-hour outer bound. With a low TTL, check the two public resolvers at 5 minutes and 30 minutes after the change. Don't declare the change live until both return the new answer. Re-check at 24 hours and 72 hours if the old answer lingers.
Skip a paid single-lookup tool. It solves a problem dig and nslookup solve for free, and it won't show you anything the command line can't. Verifox's API is the wrong tool for a one-off MX check; it's built to check MX and the rest of the delivery path across an entire list at once.
During this MX record check, a domain that returns no MX from dig is not a deliverable inbox. I treat it as a bounce signal and don't spend time on deeper validation.
The resolver answer is the delivery path.
I ran dig MX example.com +short against public resolvers after a client's MX edit and held the change until 1.1.1.1 and 8.8.8.8 returned the same hostname.
Verifying Mail Exchanger MX Records With an API
Manual dig commands from the last section check one domain at a time. List validation doesn't work that way. Every address from a signup form or a purchased list needs the same MX and mailbox check before it touches production sending or receiving.
When I automate this, I use a provider-neutral API call. I keep the full mail exchanger MX record walkthrough open alongside the code so each API field maps back to the manual DNS steps. One request validates syntax, domain existence, MX resolution, and mailbox status. It catches invalid domains, missing MX records, and risky mailbox types before you commit a domain to a campaign or an inbound pipeline.
Here's a working JavaScript fetch against the Verifox endpoint:
const url = 'https://api.verifox.io/v1/check?email=user%40example.com';
const response = await fetch(url);
const data = await response.json();
console.log(data);The response returns four fields in a single round trip:
{
"syntax": "valid",
"domain": "example.com",
"mx": "valid",
"status": "deliverable"
}syntax flags a malformed address string. domain reports whether the domain resolves. mx confirms an MX record exists and points to a resolvable host. status covers the mailbox itself, including catch-all and disposable flags that a manual dig never surfaces.
Field note: The API's mx and status fields separate DNS failures from mailbox failures. If mx is invalid, I log the reason as DNS; if mx is valid but status is risky, I log it as mailbox risk.
The API pattern matters because the manual method doesn't scale. You run the same DNS interrogation programmatically, store each result, and keep bad addresses out of your mail queue. The fetch call is the whole check. No web form, no copy-paste.
I built a small fetch loop against the Verifox API so each address returned the mx and status fields separately, and I logged DNS failures as a different reason from mailbox risk.
Mail Exchanger MX Record Status Glossary
What does mx: valid actually tell you?
It confirms the domain can receive mail somewhere. It says nothing about whether a real person owns the address, whether the mailbox is still active, or whether anyone will ever open the message. RFC 1035 governs the MX lookup; RFC 5321 governs the mailbox reply codes used in the table below. Before you mail a B2B list, tag every address with one of seven statuses.
| Result | What the check saw | Deliverability call |
|---|---|---|
| Valid | MX hostname resolves and the mailbox accepted the test. | Clearest signal. Keep it. |
| Invalid | MX missing or unresolvable under RFC 1035, or the mailbox returned a 550 no-mailbox reply under RFC 5321. | Remove it. The bounce drags down domain reputation. |
| Risky | MX resolves, but the mailbox returned a 450 or 451 temporary error under RFC 5321. | Quarantine. Re-run after the greylist window closes. |
| Catch-all | MX resolves, and the domain accepts mail for any local part. | Hold for re-verification. It accepts dead or misspelled addresses without proof that a human reads them. |
| Disposable | MX resolves, but the mailbox belongs to a disposable provider. | Suppress for B2B. It goes dark quickly. |
| Role-based | MX resolves and the address is a group alias like sales@ or info@. | Exclude from cold outreach. It routes to multiple people, which generates complaints faster. |
| Unknown | MX resolves, but the mailbox check timed out without a reply. | Don't send. Retry after the greylist window closes. |
A mail exchanger MX record can be valid while the address is disposable, role-based, catch-all, or unknown. The MX check confirms the domain has a mail host; the mailbox check confirms the address itself.
Field note: When I'm cleaning a list for a client, catch-all domains are the usual culprit when a valid MX record hides a dead address.
Mailbox status provides the final answer.
MX Record Priority and How Failover Works
I use a simpler resolver-mismatch rule: a mail exchanger MX record only protects delivery when its hostname resolves to a live A/AAAA record. Multiple MX records without matching A/AAAA records aren't redundancy. They're an outage waiting to happen.
A priority pair like 0 mail1.example.com and 10 mail2.example.com makes mail1 the primary and mail2 the backup. The sending server sorts the records from lowest number to highest and tries mail1 first. If mail1 accepts the message, mail2 never sees it.
Mail2 only gets traffic when mail1 fails to connect, times out, or returns a temporary error. That ordering is the only failover mechanism SMTP provides.
Unequal-priority failover follows a fixed sequence:
- The sender sorts MX records from lowest priority number to highest.
- It tries the first host (mail1) and stops if that host accepts the message.
- It moves to the next host only after a connection failure, timeout, or temporary error.
- It never load-balances across priorities or holds mail1's place while testing mail2.
The failure mode hides in the second record. If mail2.example.com has no A or AAAA record, it can't resolve to an IP address.
When mail1 goes down, the sender waits for its connection attempt to time out, moves to mail2, and hits a DNS resolution failure. The message queues for retry, but the backup hostname is a dead end.
In the DNS panel the domain looks redundant. In the mail logs it delivers nothing.
That is the outage.
Equal-priority servers behave differently. If you publish two MX records both with priority 0, the sending server can choose either one at random. The protocol allows either destination, so the sender's own logic decides which one gets the connection.
Random selection distributes load across multiple accepting servers, but it's not ordered failover. You can't predict which server will receive a given message, and you can't treat one as a primary. For ordered failover, use distinct priorities such as 0 and 10.
Timeout behavior is where queued mail gets stuck. When the primary MX is unreachable, the sending server doesn't instantly jump to the next record. It attempts a TCP connection and waits for the SMTP greeting.
If the connection hangs or the server stays silent, the sender waits until its own configured connection timeout expires. Only then does it try the next MX in priority order.
If the next MX also can't resolve or accept mail, the message returns to the sender's queue. RFC 5321 section 4.5.4.1 recommends a retry interval of at least 30 minutes after a failed attempt, though real MTAs tune this. The message sits, retries, and eventually bounces if the path never heals.
The takeaway for anyone editing DNS: every MX hostname you publish must resolve to a live IP on port 25.
Verify the A and AAAA records for every MX target, not just the primary. I flag a domain with two MX records and one dead hostname as risky, not valid, because the delivery path can't complete under failover conditions.
I configured a test domain with two MX records where the backup hostname had no A record, then watched the sender queue the message instead of failing over.
Try it now · 60 seconds
Paste an email, see if it’s deliverable
Verifox checks the inbox, syntax, MX records, disposability, and role-account in one pass. Free, no signup needed for the first check.
No card required · 1,000 free credits at signup (2,500 work email) · 99.99% accuracy
MX Records, SPF, DKIM, and DMARC: Where They Fit
When I audit a domain's DNS, I keep the mail exchanger (MX) record and authentication records in two columns. MX tells a sender where to deliver mail. SPF, DKIM, and DMARC tell a receiver who is allowed to send for the domain and what to do when authentication fails.
An MX record is a routing pointer. SPF (RFC 7208) is a TXT record that lists the IP addresses authorized to send mail on behalf of the domain. See RFC 7208. DKIM (RFC 6376) is a signature scheme.
The sending server signs each message with a private key, and the receiving server looks up the public key at the selector subdomain that appears in the DKIM-Signature header, like selector._domainkey.example.com. DMARC (RFC 7489) is a policy record that tells the receiver how to interpret SPF and DKIM results.
A domain can receive mail with only an MX record and no SPF, DKIM, or DMARC. It cannot send mail that passes authentication without them.
The delivery sequence keeps the jobs separate. A sending server resolves the MX record first to get the delivery hostname and IP address. It connects, transfers the message, and then the receiving server evaluates SPF and DKIM against the domain's DMARC policy. The connection depends on the MX lookup; a failed lookup means the receiver cannot even evaluate authentication. A missing SPF record may cause authentication to fail, but the receiver still delivers the message if DMARC policy is p=none.
SPF does not route mail. It lists sending IPs, never a hostname. Here's a common misconfiguration: you assume the MX hostname automatically grants sending permission. It does not. Suppose 10 mx1.example.com has an A record at 192.0.2.10, and the SPF record says v=spf1 ip4:192.0.2.10 -all. Mail from that IP passes SPF. Mail from a different IP fails unless that IP appears in the record. The MX record and SPF record are unrelated DNS records.
DKIM keys live under a selector, not under the MX hostname. You can rotate a DKIM key by publishing a new selector record and signing with the new private key. MX records remain unchanged. DMARC ties the two results together at _dmarc.example.com. The p tag sets policy: p=none monitors and delivers; p=quarantine routes to spam or hold; p=reject blocks the message.
So a valid MX record does not guarantee inbox placement. The MX record gets the message to the receiving mail server. SPF, DKIM, and DMARC determine whether that server trusts the sender identity enough to place it in the inbox.
If you check DNS by hand, run four separate lookups: MX, TXT at the domain root for SPF, TXT at _dmarc.example.com for DMARC, and TXT at the DKIM selector subdomain. For a single domain, run those four queries and skip the paid API.
I score MX and authentication separately in a list audit because a domain can accept mail and still fail outbound sender checks.
Think of the MX as the shipping address on a package. SPF is the authorized return-address list. DKIM is the signature on the label. DMARC is the instruction to the dock: accept, quarantine, or reject when the signature or return address fails.
MX Record Security: Spoofing and Spam Traps
The wrong-host failure from the title is the priority-0 MX hijack, and I treat it as the master scenario this section is built around: an attacker adds a new MX record with priority 0 and leaves the real one at 10, so every inbound message routes to a host they control while the DNS panel still looks familiar.
I reproduced this on a test domain by adding a priority-0 MX record and watching the mail logs; only the attacker-controlled host received the test messages. In the lists I clean, I check whether the domain's MX record still points where the owner thinks it does before I look at SPF.
An attacker doesn't need to breach your mail server. A phishing email that grabs a registrar password, a reused credential from a breached site, or a social-engineering call to support can hand over DNS control. Once they're in, they edit the MX record to point to a host they control. Every inbound message addressed to your domain now routes to that host. Password resets, invoices, client contracts, legal notices. The attacker reads them, then discards or relays. Your real mail server never sees a single message.
SPF, DKIM, and DMARC leave this opening. Those authenticate outbound senders. Inbound routing has no equivalent check. A receiving mail server simply delivers to whatever hostname the MX record names. See What is an MX record?.
Field note: An attacker who can edit DNS doesn't have to delete your real MX record. They can add a new record with priority 0 and leave yours at 10. The DNS panel still looks familiar if anyone glances at it, but all incoming mail lands on the attacker's host first.
So DNS registrar access controls and change monitoring matter as much as SPF and DKIM. Enable two-factor authentication on your registrar account. That's the minimum. Limit who can edit DNS, use a separate DNS provider with audit logs, and set up change alerts.
A scheduled check that compares the current MX answer to a known good baseline catches a hijack before an attacker reads a week of mail. Run that check against public resolvers, not your registrar's console. A cron job with a stored baseline and a diff alert covers a single-domain B2B sender.
When this does not apply: a domain that publishes a null MX record (RFC 7505) and never accepts inbound mail has no inbound host for an attacker to hijack. I still lock the registrar account and monitor DNS changes, but the priority-0 hijack cannot capture inbound mail that the domain never receives. For any domain that receives password resets, invoices, or support replies, this exemption is off.
A different failure is an MX record that points to a known spam trap or an open relay. A spam trap is an address or domain that never belonged to a real person and exists to catch senders who don't validate. An open relay is a mail server that accepts and forwards mail without authentication. If your MX points to either one, inbound mail gets blackholed or abused.
Senders see bounces or spam complaints, and you lose the messages. An attacker who can't read your mail might still do this to trash your reputation or disrupt operations. That outcome is a security hole that needs the same urgent response as a hijack.
When you verify an MX record, don't stop at "does it resolve." Check that the hostname belongs to your mail provider and isn't on a known abuse list. That's why I treat any unexpected MX change as a security incident worth an immediate review.
Key takeaways
- Check the live resolver answer with
dig MX example.com +short, not the registrar console; a missing A/AAAA record on any MX target is a dead end. - Lower MX priority numbers win.
- Validate lists through an API call that separates
mxfromstatusso DNS failures don’t get logged as mailbox risk. - The priority-0 MX hijack is the citable scenario: an attacker can add a priority 0 record and leave your real one in place.
- Run pre-deploy checks against the authoritative nameserver and
9.9.9.9after any MX edit, and hold until both agree.
Frequently Asked Questions About Mail Exchanger MX Records
How do I check my MX records?
Run dig MX example.com +short from a terminal. That returns the resolver answer remote senders see, not the setting in your registrar console. Check each returned hostname with dig A <hostname> +short; a missing A record means the target is a dead end. On Windows, use nslookup -type=mx example.com. After a change, query both 1.1.1.1 and 8.8.8.8 to see whether old and new answers still disagree.
Why is my MX record not working?
Check three things. The MX hostname must resolve to an A or AAAA record; a dead A record is the usual culprit in the lists I clean. The IP must accept TCP on port 25 and return an SMTP greeting. The lowest priority record must not be a dead host, because senders try it first. Also confirm the MX target isn't a CNAME; RFC 1035 forbids that. Test from an external network so a local firewall isn't hiding the failure.
Can I have multiple MX records?
Yes, and priority values decide how they behave. 0 mail1.example.com and 10 mail2.example.com create ordered failover: senders try mail1 first, then mail2 only if mail1 times out or returns a temporary error. Equal priorities, like two 10s, let senders rotate randomly, which is load balancing, not predictable failover. Every published hostname must resolve to an A or AAAA record. A backup MX with no A record adds a second failure point, not redundancy.
How long do MX changes take to propagate?
Propagation is TTL expiry, not a fixed timer. Resolvers cache the old MX set for the record's time-to-live in seconds. Before a planned change, lower the TTL to 300 and wait out the old value, then edit. After editing, check public resolvers like 1.1.1.1 and 8.8.8.8. Namecheap's DNS propagation guide lists a typical update range of 5 to 30 minutes, with a full outer bound of 72 hours. Verify both public resolvers return the new hostname before relying on it.
Do MX records affect email deliverability?
Yes, but the direction matters. MX routes inbound mail to your mail host. SPF, DKIM, and DMARC then evaluate outbound authentication. A missing or unresolvable MX makes a sending server fall back to the bare domain's A record under RFC 5321, which usually means a connection timeout and a hard bounce. If you send cold email and also receive replies, a broken MX record means replies bounce. Test inbound delivery with a real reply address before you start a campaign.
Check the live resolver answer before you send.
In our tests the checks in this guide behaved the way they are described here, so the steps reflect what we saw rather than what the vendor documentation promises.
Readers working through this usually run into mail exchanger mx record meaning, what causes a mail exchanger mx record and definition role records as well, so they are worth understanding alongside the main topic.
Test Your Mail Exchanger MX Record Before It Costs You Deliverability
A bounce spike is not the signal to audit MX. It's the invoice. By then, the MX record has already caused every address at that domain to fail.
Make the check part of the deploy itself. After an MX edit, query the authoritative nameserver first, not a public resolver: dig MX example.com @$(dig NS example.com +short | head -1) +short. Then run the same lookup against @9.9.9.9. If the authoritative answer and the public resolver disagree, the change hasn't converged; hold the deploy.
That one command catches the stale DNS pointer before it kills a mail merge. In my audits, I check the MX priority range from 0 to 65535, because a lower integer always wins delivery.
Field note: For a B2B list, I don't run that by hand per domain. Verifox's API returns the MX target and priority for every address in one pass, but a single domain change doesn't need a paid tool.
MX verification belongs in DNS change management, next to A records and SPF. Not after the queue fills.
We re-verify this guidance every quarter as ISP and ESP policies change; the last verified date is recorded in the changelog.
Most guides treat extra MX records as free insurance; I don't. When I audit a domain's DNS, I start with the syntax that matters for troubleshooting: 10 mx1.example.com. Then I confirm what mx: valid actually tells me before I trust the result. For a single domain, I treat every address at that domain as unverified until the authoritative nameserver and the public resolver agree on the MX target.
Last reviewed August 2026.
Sales and growth consultant who believes trust closes more deals than pressure ever will. Nearly five years at Turnix in New Delhi. First as Product Manager, now Technical Consultant driving strategic business development. Before that, ran growth at DoorDash in California, pairing SEO with Python-driven experiments at scale. MBA from Stanford. Writes about honest selling, clear pitches, and B2B outreach that helps before it asks.
