MX records: the DNS entries that decide where your domain's email, and your prospects' replies, land.

Definition

MX records (mail exchanger records) are DNS records that name the mail servers responsible for accepting email for a domain. Each MX record holds a priority number and the host name of one mail server, and sending servers look them up before they deliver a message.

MX records are part of the Domain Name System, the same public directory that turns a website name into an IP address. The format is defined in RFC 1035, and the way mail servers use MX records is defined in RFC 5321, the standard for the Simple Mail Transfer Protocol (SMTP).

For a sales team, MX records are not only an IT detail. They decide where replies from prospects, bounce messages and out-of-office notices arrive, and whether the domain you send cold email from looks like a real, reachable mail domain to the servers that receive it.

What is an MX record used for?

An MX record answers one question for every mail server on the internet: where should mail for this domain go? When someone writes to [email protected], their mail server does not know your mail provider. It asks DNS for the MX records of yourcompany.com and connects to the server named there.

That makes the MX record the delivery address of a domain. The website can live on one host, the mailboxes at a different provider, and a marketing platform can send on the domain's behalf, while the MX record points only to the service that receives incoming email.

• Receiving mail. Every message addressed to the domain is routed through the servers its MX records name.
• Failover. Several MX records with different priority numbers give senders a backup server to try.
• Load sharing. Records with equal priority spread incoming mail across servers.
• Declaring no mail. A special null MX tells senders the domain accepts no email at all.

Where the MX record came from

RFC 974, published in January 1986 under the title Mail Routing and the Domain System, explained how mailers should route a message using MX records. It notes that before domains, a mailer could usually open an SMTP connection straight to the host named in the address.

Under the domain system, RFC 974 says, a mailer must instead ask DNS where messages for a name should be delivered, and the answer may be an entirely different host. RFC 1035 later listed MX as record type 15 and marked the older MD and MF mail types obsolete, with the note to use MX.

Today the sending rules live in RFC 5321, published in October 2008, which replaced RFC 2821. The record format itself is still the one in RFC 1035, section 3.3.9.

How MX records work, step by step

RFC 5321, section 5.1, describes the lookup a sending server performs. The steps below follow that section of the standard, in the order a message travels from the sender to your inbox.

The sending server first asks DNS for the MX records of the recipient's domain, the part of the address to the right of the @ sign. If it finds several, it must sort them by preference, where a lower number is more preferred, and try them in order until one accepts the message.

The host name in each MX record must then resolve to at least one address record, an A record for IPv4 or an AAAA record for IPv6. That address is the server the message is actually sent to.

On the other end, RFC 5321 says the receiving server should keep listening on port 25, the SMTP port assigned by IANA, so it can accept those connections at any time.

If the lookup returns a temporary error, the standard says the message must be queued and retried later. If the domain does not exist, the sender reports an error. If MX records exist but none of the servers can be used, that is also reported as an error.

What happens while a mail server is down

A failed delivery is not the end of the message. RFC 5321, section 4.5.4.1, says mail that cannot be sent at once must be queued and retried, that the retry interval should be at least 30 minutes, and that the give-up time generally needs to be at least 4 to 5 days.

Only when the sender gives up does a non-delivery notice go back to the envelope sender, the reverse-path in SMTP terms. That is why a broken MX record on the receiving side can surface days later as a bounce. For the codes inside those notices, see email bounces.

The parts of an MX record

RFC 1035 defines the data of an MX record as two fields. PREFERENCE is a 16-bit integer, so it can hold values from 0 to 65535, and lower values are preferred. EXCHANGE is a domain name of a host willing to act as a mail exchange for the domain.

DNS hosting panels add the usual fields every record has, so a registrar form typically shows five boxes. Google's admin help, for example, lists Type, Name or Host or Alias, TTL, Priority, and Value or Answer or Destination.

The exchange field holds a domain name, not an IP address. That is why a mail provider always gives you a host name to paste into the MX value, and why a separate A or AAAA record for that host must exist on the provider's side.

RFC 1035 also says MX records cause additional section processing: a DNS server answering an MX query adds the address records it has for the mail host. RFC 2181 notes this saves an extra query, and that it does not work when the target is an alias.

MX priority: how the numbers decide the order

MX priority, also called preference or distance, tells senders which server to try first. RFC 1035 and RFC 5321 both say lower values are preferred, so a record with priority 5 is tried before one with priority 10.

The host names above are placeholders written for this page. The equal-priority rule comes from RFC 5321: when several destinations share the same preference, the sender must randomize them to spread the load across the organization's mail exchangers.

The number itself has no meaning beyond the comparison. Priorities of 1, 5 and 10 behave the same as 10, 50 and 100. What matters is which record is lowest and whether two records share a value.

Backup MX servers and the relay rule

A higher-numbered MX record is often called a backup or secondary MX. RFC 5321, section 3.6.2, says a relay named in an MX record may accept or reject the task of relaying mail in the same way it accepts or rejects mail for a local user.

When a backup relays a message onward, section 5.1 tells it to sort the MX list, find its own name, and discard every record at its own preference level and higher. If nothing is left, the message must be returned as undeliverable. This rule stops two backups from passing mail back and forth.

This page's view: a backup MX only helps if it knows the same valid recipients as the primary. A backup that accepts mail for any address and rejects it later sends bounce notices to whoever appeared as the sender, which may be a forged address.

MX record examples

In a DNS zone file, the text format DNS servers read, MX records look like the lines below. This example was written for this page and uses the reserved example.com and example.net names.

example.com.   3600  IN  MX  10  mx1.example.net.
example.com.   3600  IN  MX  20  mx2.example.net.
mx1.example.net.  3600  IN  A  192.0.2.10
mx2.example.net.  3600  IN  A  192.0.2.20

Read each MX line from left to right: the domain, the TTL in seconds, the class IN for internet, the type MX, the priority, and the mail server. The A lines give each mail server its IP address, taken here from a range reserved for documentation.

In a registrar's web panel the same record is usually a form: type MX, host @, priority 10, value mx1.example.net. Google's admin help notes that some registrars require a period at the end of the host name, while others put the priority and destination in the same line.

MX records vs A, AAAA, CNAME, NS, TXT and PTR records

An MX record rarely works alone. It points to a host name, that host needs an address record, and the domain's other email settings live in TXT records. The table below uses the meanings RFC 1035 gives each type, with AAAA from RFC 5321.

The PTR row matters for outgoing mail, not incoming. Google's email sender guidelines ask that sending domains or IPs have valid forward and reverse DNS records, meaning the sending IP's PTR record resolves to a host name whose A or AAAA record points back to the same IP.

Rules from the standards that trip people up

A few rules in RFC 5321 and RFC 2181 explain many broken mail setups. They are short, and each one matches a mistake that shows up in real DNS panels.

• No CNAME as the target. RFC 2181, section 10.3, says the domain name in an MX record must not be an alias. It must have address records, never a CNAME.
• No IP address as the target. RFC 5321 says the data field must contain a domain name that returns at least one A or AAAA record, not a raw IP.
• MX wins over A. If a domain has MX records, RFC 5321 says senders must not deliver to the domain's own address records unless an MX record points there.
• The implicit MX. If a domain has no MX records at all, the address is treated as if it had one with preference 0 pointing to the domain itself, so mail is tried on its A or AAAA address.
• Try more than one. RFC 5321 says a sending client should try at least two addresses before it gives up.

The implicit MX rule is why a domain with only a website still receives delivery attempts. RFC 7505 says that if nothing listens for mail at those addresses, delivery is attempted repeatedly for a long period, typically a week, before the sender gives up. The null MX record described below exists to stop that.

TTL and propagation: how long MX changes take

Every MX record carries a TTL, the number of seconds a resolver may cache it. RFC 2181, section 8, says a TTL is an unsigned number from 0 to 2147483647, and that it is a maximum time to live, not a mandatory one. Resolvers are free to cap long values.

That is why an MX change does not reach every sender at the same moment. Resolvers that cached the old record keep using it until their copy expires. Google's admin help says it can take up to 72 hours for new MX records to be recognized.

This page's advice for a planned switch: note the current TTL a day or more ahead, keep the old mailboxes working until the longest TTL has passed, and do not delete the old provider's account on the day you change the record.

How to check MX records with dig and nslookup

You can check the MX records of any domain in a few seconds from a terminal. Both commands below query DNS and change nothing. This example was written for this page; replace the placeholder with the domain you want to check.

nslookup -type=mx {{domain}}

dig {{domain}} MX +short

nslookup on Windows

nslookup ships with Windows. Microsoft's reference for its set type command lists MX as the record type that specifies the mail exchanger, and A as the default. In the output, each line shows the MX preference and the mail exchanger host name.

dig on macOS and Linux

The BIND 9 manual describes dig as a flexible tool for interrogating DNS name servers. Its +short option prints a terse answer instead of the verbose default, which for an MX query is the priority and mail server of each record. Without +short, the answer section also shows the TTL.

Online MX lookup tools

Web-based MX lookup tools run the same DNS query from their own servers and show the result in a table. Google's admin help points Workspace admins to its Admin Toolbox Dig tool to compare the published MX records with the values Google gives.

When we ran nslookup against example.com on Oct 1, 2026, it returned a single record with preference 0 and a root mail exchanger. That is a null MX, the record a domain publishes when it accepts no email.

MX records for Google Workspace and Microsoft 365

Many B2B teams receive mail through Google Workspace or Microsoft 365. Both publish their own MX instructions in their admin help, and the details below come from those pages as checked on Oct 1, 2026.

Google's help page says it can take up to 72 hours for new MX records to be recognized, and that you then activate Gmail for the domain in the Admin console.

Microsoft's page warns that once the MX record changes, all new email for the domain goes to Microsoft 365, while existing mail stays with the previous host.

How to add or change MX records

MX records are edited where your domain's DNS is hosted, which is usually the registrar but can be a separate DNS provider. The order below was written for this page to avoid losing mail during a switch.

1. Find where DNS is hosted

   Look up the domain's NS records. The company that runs those name servers is where you edit records, even if you bought the domain elsewhere.

2. Set up mailboxes first

   Create users and mailboxes at the new provider before switching, so mail has somewhere to land from the first minute. Microsoft gives the same order.

3. Copy the exact values

   Take the host, priority and value from your provider's admin console, not from a blog post or an old screenshot.

4. Remove or demote old records

   Delete MX records for the previous provider, or give them a higher number so the new provider is preferred.

5. Update any MTA-STS policy

   If the domain publishes an MTA-STS policy, add the new mail hosts to its mx lines before the switch, as explained in the security section below.

6. Check from outside

   Run an MX lookup, send a test message from an outside account, and reply to it to confirm both directions work.

MX records for subdomains

MX records belong to the exact name they are published at. RFC 5321 has the sender look up the domain to the right of the @ sign, so mail to [email protected] is routed by the MX records of sales.example.com, not those of example.com.

Google's admin help reflects this: when you add a subdomain to an existing Workspace account, you enter the subdomain label, such as support, in the Name or Host field. A subdomain used for sending needs its own MX records if replies or bounces are expected there.

MX vs SPF, DKIM and DMARC

MX, SPF, DKIM and DMARC all live in DNS and all affect email, so they are often mixed up. The difference is direction: MX is about mail coming in, while SPF, DKIM and DMARC are about proving that mail going out is really from you.

Microsoft's setup page describes SPF as a TXT record designed to help prevent spoofing, and recommends DKIM and DMARC as well, because some spoofing techniques bypass SPF. It also says a domain should end up with a single SPF record that includes every service that sends for it.

Google's email sender guidelines ask all senders to Gmail accounts to set up SPF or DKIM, and senders of more than 5,000 messages a day to set up SPF, DKIM and DMARC. A correct MX record does not replace any of them. The full picture is on the email deliverability page.

The records still meet in one place: Google's DMARC setup page recommends a rua tag, which names a mailbox for DMARC reports. That mailbox sits on a domain whose MX records must accept mail, or the reports never arrive.

Null MX: how a domain says it accepts no email

A null MX is defined in RFC 7505. It is a single MX record with preference 0 and a target of a lone dot, the root of DNS. Because a dot is not a valid host name, it cannot be mistaken for a real mail server.

{{domain}}.   3600  IN  MX  0  .

A domain that publishes a null MX must not publish any other MX record. Senders then learn on the first attempt that an address cannot receive mail, instead of queuing and retrying for hours or days.

RFC 7505 also warns the other way: mail systems should not publish a null MX for a domain they use in the envelope sender or the From address, and a domain that does so risks having its mail rejected. For domains that send no mail, it points to an SPF policy ending in -all.

The practical use for a company is parked domains, lookalike domains bought for brand protection, and product domains that never handle email. Publishing a null MX and an SPF -all policy on them is cheap housekeeping.

MX records and email security

MX records are public. Anyone can run a free MX lookup and see which email provider a company uses, so the record itself is not a secret to protect. What needs protecting is the ability to modify it, because whoever can change your DNS settings can redirect your incoming emails.

• DNS account access. Limit who can change DNS configuration at the registrar or DNS host, and protect those accounts with strong sign-in settings.
• Change monitoring. Keep a record of the expected MX, SPF, DKIM and DMARC values and check the live zone against it after every change.
• DNSSEC. RFC 4033 says the DNS Security Extensions add data origin authentication and data integrity to DNS. They do not make DNS data confidential.
• Encrypted transfer. Google's sender guidelines ask all senders to use a TLS connection when transmitting email. TLS protects the message in transit, while the MX record only says where to connect.

MTA-STS: the MX list your security policy must match

RFC 8461 defines MTA-STS, a way for a domain to declare that its mail servers accept TLS connections with a trusted certificate. The domain publishes a TXT record at _mta-sts and serves a policy file over HTTPS at mta-sts.yourdomain, under the path /.well-known/mta-sts.txt.

The policy lists allowed MX hosts on mx lines, such as mx: mail.example.com, and a mode of enforce, testing or none. In enforce mode, RFC 8461 says sending servers must not deliver to hosts that fail MX matching or certificate validation, or that do not support STARTTLS.

The link to MX records is direct: change the MX records without updating the policy, and senders that honor an enforce policy will refuse the new servers. RFC 8461 says such failures should be treated as temporary and that senders must check for an updated policy before failing for good.

RFC 8461 also names DANE as a related method that uses TLSA records and requires DNSSEC. MTA-STS relies on certificate authorities instead and does not require DNSSEC.

MX records, SMTP and IMAP: who does what

MX records and mailbox settings answer different questions. The MX record tells other servers where to deliver mail over SMTP. Once the message is stored, your mail app or sales tool reads it through an access protocol such as IMAP.

RFC 9051 describes IMAP4rev2 as a protocol that lets a client access and manipulate email messages on a server, and says it does not specify a means of posting mail. Sending goes through a submission protocol instead.

So a correct MX record does not connect your mailbox to a CRM or sequencing tool, and a working IMAP server connection does not prove that outside mail reaches the mailbox. When replies seem to vanish, check both.

Why a cold email sending domain needs MX records

Some teams send cold email from a separate domain so the main company domain is not exposed to outbound risk. That sending domain needs working MX records, even if nobody plans to read mail there, for three reasons grounded in how SMTP works.

• Replies. A prospect who answers writes to the From or Reply-To address. Without an MX record that accepts mail, the reply bounces and the lead is lost.
• Bounces and notices. RFC 5321 says non-delivery notices are sent to the reverse-path of the original message. They tell you which addresses to remove from the list.
• Return address checks. RFC 7505 notes that many receiving systems reject mail with an invalid return address, and that an invalid return address often signals spam.

A domain with no MX falls back to its A record under the implicit MX rule, which on a bare parked domain may mean nothing answers. That is the profile of a throwaway domain, not a company, and the opposite of what a sending domain should look like.

The domain also has to be yours. An address on a free email domain uses the provider's MX records, so you cannot set them, route replies or publish your own authentication for it.

The fix is simple: set the sending domain up as a real mail domain at your provider, with MX, SPF, DKIM and DMARC, and route replies to someone who answers them. The follow-up only works if the first reply arrived. Then ramp volume slowly, as covered in email warm up.

Gmail sending limits follow the recipient's MX

Google's sender guidelines tie sending limits to MX records. They advise limiting email from a single IP address based on the MX record domain, not the domain in the recipient's address, and to be aware of limits when sending to domains that have a Google.com MX host.

For Workspace work and school accounts, Google gives an example: mail to two different domains counts toward one limit if both have google.com as their MX record. When you pace a sequence, count recipients by mail provider, not only by company domain.

What an MX lookup tells you about a prospect's address

Before a send, an MX lookup on each prospect domain is a cheap first filter. It answers a domain-level question only: can this domain receive mail at all? It says nothing about whether a given mailbox exists.

The last row hides two traps. A domain set up as catch-all email accepts mail for any address, so a mailbox check returns yes even for people who never worked there. And a valid domain can still reject a named mailbox after the send.

That is why an MX check belongs inside a wider email hygiene routine, next to mailbox verification and bounce suppression, rather than replacing them.

MX records and deliverability: what they do and do not do

MX records control where mail arrives, not whether your outgoing mail lands in the inbox. They are a precondition for a healthy sending domain, alongside authentication, list quality and the content and volume of what you send.

What a missing or broken MX record does cause is silent loss: replies and bounce notices that never reach anyone. A team can then keep mailing invalid addresses, which raises bounce rates, while believing nobody answered. If messages arrive but land in the wrong folder, the causes are covered in emails going to spam.

Common MX record problems and how to fix them

The table below was written for this page. The causes tied to an RFC or a provider page are marked; the others are common setup slips worth ruling out first.

Mistakes with MX records

• Buying a lookalike domain for outreach and never adding MX records, so replies and bounces disappear.
• Pointing MX at a CNAME or an IP address because the panel accepted it.
• Leaving old provider records in place after a migration, so part of the mail goes to a mailbox nobody reads.
• Publishing a null MX on a domain that sends mail, which RFC 7505 says risks rejection.
• Confusing MX with SPF and assuming a correct MX record authenticates outgoing mail.
• Copying MX values from an old article instead of the provider's current admin console.
• Switching MX records while an MTA-STS policy in enforce mode still names only the old servers.
• Reading a successful MX lookup on a prospect domain as proof that the mailbox exists.

Before the first sequence goes out

Many sales teams do not edit DNS themselves. The request below asks whoever does to set up a sending domain properly, including MX, before the first step of an outbound sequence is sent. It was written for this page; adjust the placeholders to your setup.

Subject: DNS setup for {{sendingDomain}} before outreach starts

Hi {{dnsOwner}},

We plan to send sales email from {{sendingDomain}} starting {{startDate}}. Before the first message goes out, could you set it up as a full mail domain at {{mailProvider}}?

1. MX records exactly as shown in the {{mailProvider}} admin console, with no leftover records from other providers.
2. One SPF record that includes {{mailProvider}} and any sending tool we use: {{sendingTool}}.
3. DKIM enabled in the {{mailProvider}} console and published in DNS.
4. A DMARC record at _dmarc.{{sendingDomain}}, with reports sent to {{reportAddress}}.
5. Replies to {{replyMailbox}} delivered to a mailbox someone on {{teamName}} reads daily.

When it is done, please send me the output of "nslookup -type=mx {{sendingDomain}}" so we can confirm.

Thanks,
{{senderName}}

Frequently asked questions