MX Records Explained: Where Your Email Actually Goes
MX records tell the internet which server accepts email for your domain. How to read yours, change them safely, and test where mail really lands.
By Matthew Zhao · Editor, Hosted EZ
An MX record — short for mail exchange record — is the DNS entry that tells the rest of the internet which server accepts email for your domain. Web traffic and mail can live at completely different companies, and this one record type is what makes that split work. This guide explains how to read your MX records, change them without losing mail, and prove the result.
These records matter most during a move. Read how to choose a web host if you are rethinking where the site itself lives, and our migration guide before changing live infrastructure. If the mailboxes are moving too, see how to migrate email to a new host.
What an MX record actually contains
Each entry has two parts: a mail server name and a priority number, where lower numbers get tried first. A domain usually lists two or more so mail has a fallback. Treat email delivery as a DNS problem as well as a mailbox problem — a message can leave the sender cleanly and still arrive at the wrong service because the records point somewhere stale.
Make a short note of your current email DNS records before touching anything: the MX entries, their priorities, and their TTLs. Do not put passwords or recovery codes in the note.
List every sender before you edit the records
List every sender that uses your domain before you edit MX entries or the SPF, DKIM, and DMARC records that vouch for them. That includes newsletters, contact forms, invoices, help desks, and staff mail. A record that fixes one sender can break another.
Change one record at a time. Use a fresh lookup after each edit, note the TTL, and allow the old answer time to expire before assuming the change failed.
Test with a real message and read the headers
Test with a real message after each change and inspect the received headers. An inbox is the final result, but the headers show the path: which server accepted the message, and whether it was the one your MX records name.
Send from an outside account, not from a mailbox on the same host. Internal mail sometimes skips DNS entirely and can hide a broken record.
When to stop and ask for help
Stop when the next action could change production mail flow or lock you out of the account. Send support the domain, time in UTC, the exact record, and any bounce text. Include a screenshot when it shows the error, but never passwords or private keys.
The SMTP standard has useful background on how mail routing actually works: the SMTP standard. Use it to understand the terms, then return to the small, reversible next step.
A sensible maintenance habit
Put the final records in a short, dated note: each MX entry, its priority, and which provider it belongs to. Mail problems repeat because nobody remembers which service a record points at or why a priority was chosen. A dated note turns the next incident into a lookup instead of an investigation.
Keep the change auditable
Keep a before-and-after record: the values you found, the time you changed them, and when the old TTL should expire. This is useful even when everything works. Months later, it explains why the records look the way they do.
Do not confuse the DNS dashboard with delivery. A panel can accept a record instantly while senders keep using the cached one for hours. Test from outside, and use a second sending account if a cached answer could mislead you.
If you hand the mail setup to someone else, give them the record rather than a conclusion. "Email is flaky" is hard to investigate. "Messages from this sender bounce since this record changed at 14:00 UTC" gives the next person a useful starting point.
One last check
Before you close the work out, send one more message from an outside account and read its headers end to end. If the accepting server is not the one your records name, an old answer is still cached somewhere — note it and check again after the TTL passes. A quiet confirmation now is much easier than discovering misrouted mail during an invoice run.
Leave a useful handoff
Save the final records and the test results with the date and account involved. Anyone revisiting the mail setup should see which provider receives mail and when that was last verified, without reconstructing it from browser history.
Bottom line
MX records are the address label for your domain's email: a server name, a priority, and nothing else. Read them before you change them, edit one at a time with the TTL in mind, and always confirm with a real message from outside.
Frequently asked questions
What happens if a domain has no MX record?
Senders fall back to the domain's A record, and if no mail server answers there, messages bounce. Set explicit MX entries even when mail and web share a host — relying on the fallback breaks the moment they separate.
Should I change all my email DNS records at once?
No. Change one record, test with a real message, and keep the previous value written down until delivery is stable.
What should I give support when email stops arriving?
Give the domain, the exact address, UTC time, any bounce text, and the records you changed. That is usually enough for support to find the relevant mail logs.
Should I back up DNS records before editing MX entries?
Yes. Export the zone or screenshot the full record list first. DNS has no undo, and the export is the fastest way to restore mail if an edit goes wrong.
About the author
Matthew Zhao
Matthew has spent his career running production server fleets — tens of thousands of machines' worth. He writes about hosting the way he wishes someone had explained it to him: plainly.
About Hosted EZ →Get the next guide in your inbox
One email when we publish something worth your time. No spam, unsubscribe whenever.
