What Is an MX Record? How to Check and Read Yours

An MX (mail exchange) record tells other mail servers where to deliver email for your domain. It lives in your domain's DNS (Domain Name System), the internet's address book. When someone writes to [email protected], their server looks it up and hands the message to the server it names.

It covers incoming mail only, so sending newsletters or invoices from the same domain is a separate job.

Most people meet it during a domain move, a switch to Google Workspace or Microsoft 365, or the morning a client says their email bounced.

What an MX record contains

An MX record has four parts: a name, a priority number, a mail server and a TTL (time to live). Here is one of the five records our own domain, mailgraf.com, published on 25 October 2026.

Part	What it holds	mailgraf.com example
Name (host)	The domain or subdomain that receives the mail. @ stands for the domain itself	mailgraf.com
Priority	Which server senders try first. The lowest number goes first	1
Mail server	The hostname of the server that accepts the mail	aspmx.l.google.com
TTL	How many seconds other servers may keep the answer before asking again	300 (5 minutes)

The mail server has to be a hostname, never a bare number like 192.0.2.10. RFC 5321, the email delivery standard, says that name must lead to an address record (A or AAAA).

A name that leads to a CNAME (an alias record) falls outside the standard (RFC 5321, section 5.1). If your server only has a numeric address, give it a name such as mail.example.co.uk with an A record, and point the MX at that name.

How to check your MX record

You can read any domain's mail settings with one command or a free browser tool, without logging in to your DNS provider. On a Mac or a Linux computer, open Terminal and type:

dig +short MX example.co.uk

Windows has nslookup, the tool Microsoft documents for this job (Microsoft Learn). Open Command Prompt and type:

nslookup -type=mx example.co.uk

Without a terminal, Google's free Admin Toolbox Dig shows the same records in a browser. Type the domain without "www" and choose MX.

This is what mailgraf.com returned at 00:19 London time on 25 October 2026:

$ dig +short MX mailgraf.com
10 alt3.aspmx.l.google.com.
10 alt4.aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
5 alt2.aspmx.l.google.com.
1 aspmx.l.google.com.

Each line is one record, priority first and mail server second. The dot at the end of each name marks it as complete, so nothing gets added to it (RFC 1035, section 5.1).

How MX priority works

A sending server tries the mail server with the lowest number first. It moves to the next number only when that server cannot be reached or asks it to try later.

For mailgraf.com, every sender starts with aspmx.l.google.com at priority 1. Next come the two servers at 5, then the two at 10.

Servers with the same number share the mail. RFC 5321 says a sender must choose between them at random to spread the load. So alt1 and alt2 each take about half of what falls through to priority 5.

The order of the lines tells you nothing. We asked three resolvers for mailgraf.com on the same night: our local one, Google Public DNS (8.8.8.8) and Cloudflare (1.1.1.1). Each listed the five records in a different order. Only the numbers decide where mail goes.

MX records for Google Workspace and Microsoft 365

Both providers give you a single record to add. One name can still stand for several machines.

When we looked it up on 25 October 2026, smtp.google.com returned two IPv4 and two IPv6 addresses. RFC 5321 expects a sender to try those addresses in turn until one accepts the message.

Provider	Mail server value	Priority	What else the provider says
Google Workspace	smtp.google.com	1	Remove any other MX records. Domains set up before 2023 may use the older aspmx values, which are still supported
Microsoft 365	The value on the Add DNS records page of the Microsoft 365 admin center	Highest priority available, usually 0	TTL of 3600 seconds. Exchange Online supports TTLs under 6 hours

The values come from Google Workspace Admin Help, updated 22 October 2026, and Microsoft Learn, updated 23 April 2026. We checked both pages on the day of writing.

mailgraf.com still publishes Google's older five-record set. Google's page says those values need no change as long as email works.

Mistakes when you move email to a new provider

Mail usually goes missing in a move because an old record stayed, the TTL was long or the mailboxes came too late.

Mistake	What happens	Fix
The old provider's record stays	With equal numbers, mail splits at random between old and new. With a lower number on the old one, mail keeps going to the old host while it answers	Delete it, or give it a higher number than the new record, as Microsoft allows
Long TTL before the switch	Servers that cached the old answer keep using it until the TTL runs out. At 86400 seconds, that is up to a day	Lower the TTL, for example to 3600, at least one old TTL before the switch
Mail moved before the mailboxes exist	Mail reaches a provider with no mailbox for that address and bounces	Create the users and mailboxes first, as Microsoft asks, then change the record
Domain added twice	A DNS panel that reads names without a final dot as relative turns the value into smtp.google.com.example.co.uk	Follow your DNS provider's format. Google notes that some panels want the final dot and some do not
Records lost in a nameserver move	The new DNS host only has the records it copied, and email stops when the switch completes	Compare the old and new record lists before the switch. Cloudflare warns that its automatic scan can miss records
Mail server name proxied on Cloudflare	The name the MX record points to resolves to a Cloudflare address, and mail cannot reach the server behind it	Set that name's A record to DNS only. Cloudflare says the MX target must resolve to a DNS-only target

Email not arriving? Check in this order

When mail to your domain stops arriving, the MX record is the quickest thing to rule out.

A surveying practice in Salisbury moved its mailboxes from its web host to Microsoft 365 on a Friday. By Monday a client's email had bounced, and the office manager works down this list.

1. Look up the record. If it still names the web host, the change may not have been saved, or it went to a DNS provider that no longer answers for the domain. dig +short NS example.co.uk shows which company does.
2. Count the lines. Every line should point at Microsoft 365. A leftover web host line is the first mistake in the table above.
3. Allow for caching. Servers that cached the old record keep using it until its TTL runs out, so check the TTL dig shows before changing anything again.
4. Check the mailbox. The address the client wrote to must exist as a mailbox in Microsoft 365, spelled exactly as they typed it.
5. Read the bounce message. Ask the client to forward it. It names the server that refused the mail and gives a code. A code starting with 5 is permanent, and the hard bounce codes explain each one.

What happens if a domain has no MX record

A domain with no MX record can still receive delivery attempts. Under RFC 5321, a sender that finds none falls back to the domain's address record and tries that host, usually the web server.

If nothing there accepts email, senders keep retrying, typically for about a week, before they give up (RFC 7505).

A "no MX record found" error has two usual causes. Either the domain was never set up to receive email, or its records were lost, often in a nameserver move. Cloudflare's email troubleshooting page gives the same two explanations for an empty dig result.

Null MX for a domain that takes no email

A domain that should never receive email can say so with a null MX: priority 0 and a single dot in place of the server.

Senders then fail at once instead of retrying for days, and the bounce should carry the code 556 with 5.1.10. The documentation domain example.com publishes exactly this:

$ dig +short MX example.com
0 .

RFC 7505 says null MX is meant for domains that neither send nor receive email, such as a domain you hold only to protect a brand name.

Do you need to change your MX record to send marketing email?

No. Receiving servers judge your campaigns by SPF, DKIM and DMARC, the email authentication records, and by the domain in the sender address. Your domain's MX record plays no part.

An email platform may still ask for an MX record on a separate subdomain. That record receives bounce reports, the automatic replies sent when a message cannot be delivered.

It sits on the subdomain used as the Return-Path, the hidden address that bounces go back to.

MailGraf works this way. The setup for a root domain usually lists 3 CNAME records, 1 MX record and 1 TXT (text) record. The MX and TXT records belong to the bounce subdomain (Add a sending domain).

The same setup asks you to leave your existing website and email records unchanged. A connected subdomain needs 4 NS records instead, and a MailGraf domain needs no DNS changes.

Our own records show the split. mailgraf.com's MX points at Google, where the team's mailboxes are. Our newsletters are set up to send from news.mailgraf.com, delegated with 4 NS records, and its bounce subdomain, bounce.news.mailgraf.com, has a separate MX record of its own.