Engineering Glossary · DNS Records
MX Records Decide Where Mail Lands, and Your Server May Ignore Them
Your application sends a confirmation email to an address on your own domain and it vanishes without a bounce.
The short answer
An MX record names a mail server that accepts email for your domain, with a priority number setting the order senders try them in. Lowest number first, equal numbers share the load, and the full set is your inbound mail policy.
The failure that catches developers is not in DNS at all. A web server that also runs mail will, by default, deliver mail for its own domains internally instead of looking up the MX records — so an application sending to a colleague on the same domain drops the message into a local mailbox nobody reads, while identical mail to any other domain arrives perfectly.
By the HostingFast team · Reviewed 12 August 2026
0
Entries with no jargon left over
100+
Terms, all cross-linked
Real
Worked examples, not diagrams
Free
To read, permanently
A sending server reads your MX set, contacts the lowest-priority host first and works upwards if nobody answers. The values must be hostnames rather than addresses, and a single record is entirely valid — extra entries exist for redundancy, not because the standard demands them.
This is also where web and mail formally part company. The site can live on one provider and the mailboxes on another because the A record and the MX set are independent, aimed at entirely different machines.
The local delivery trap, in detail
In cPanel the setting is called Email Routing, and it has three positions: Automatically Detect Configuration, Local Mail Exchanger and Remote Mail Exchanger. If your mailboxes are with an external provider, this must be set to Remote — otherwise the server treats itself as the destination for your own domain and never consults the MX records at all.
The symptom is unmistakable once you know it: mail from your application to any outside address works, mail to your own domain disappears, and no bounce is generated because from the server's point of view delivery succeeded.
Checking the routing your senders actually see
Query the MX set for your domain and read the priorities. Then check what your own server believes, because those are two different questions and the second one is the one that catches people.
For outbound testing, send from the command line on the server itself rather than from the application, so you are testing one layer at a time. If a message from the shell arrives and one from the application does not, the fault is in the application's mail configuration, not in the zone.
Rebuilding MX after a zone move
Trace any story that starts our email died when we changed hosting far enough and it ends at the MX records. Switching nameservers hands the whole zone to a new provider, and a freshly created zone does not contain the mail records you had before.
Rebuild the MX set at the new provider before the delegation moves, and bring the SPF and DKIM records across in the same sitting. Sending servers retry for hours, so acting quickly usually means nothing is actually lost — but you have hours, not days.
Mail on this platform
Mailboxes on your own domain are part of every hosting plan, with webmail plus IMAP, POP and SMTP, and spam and virus screening enabled from the start. There is standalone email hosting too, for a domain whose website lives somewhere else.
If you keep mail with an external provider, everything still works — set the routing to remote, publish your provider's MX records in the zone, and the account happily serves the website while somebody else handles the mailboxes.
The failure modes, written down
A definition that does not tell you how the thing fails is only half an entry. Each one here names the symptom, the check and the setting that produces it.
Mailboxes on your own domain are included in every hosting plan — email is part of what you bought, not an upsell at the checkout.
- 100+ entries, each with its failure mode named
- Panel settings identified by their actual labels
- Cross-linked into SMTP, SPF and DNS
- Written by the engineers who debug this
Why HostingFast
Standard on every plan
The trap named first
Local mail routing is the reason most application mail vanishes, and this entry leads with it.
MX Record, from the sender's side
Priorities and fallbacks explained as the behaviour a sending server actually performs.
Panel labels, exactly
The setting is called Email Routing and it has three positions — no hunting required.
Migration order stated
Rebuild MX before the delegation moves, not after, and why that ordering matters.
Layer-by-layer testing
Send from the shell before you blame the application, so you are testing one thing at a time.
Continues into its neighbours
SMTP, SPF and TXT Record follow directly from here.
Quick Start
From order to online
- 1
Read your published MX set
Query the MX records for your domain and note the hostnames and priorities. This is what every sending server in the world will use.
- 2
Check the server's own routing setting
Open Email Routing in the panel. If your mailboxes are external, this must be Remote Mail Exchanger, not Local.
- 3
Test from the shell before the app
Send a message from the command line on the server. If that arrives and the application's does not, stop looking at DNS.
- 4
Rebuild mail records before a zone move
Recreate MX, SPF and DKIM at the destination provider first, then change the delegation. Reversed, you get an outage with no bounce.
Built In
Loaded onto every plan
- Mailboxes on your own domain included in every hosting plan
- Webmail plus IMAP, POP and SMTP on every mailbox
- Spam and virus screening switched on from the start
- Email routing configurable per domain in the panel
- Standalone email hosting for sites hosted elsewhere
- Daily backups with self-service restores
- 99.9% uptime target, monitored around the clock
- Support answered by humans at any hour
Frequently Asked
What people ask us most often
My application sends to an address on my own domain and nothing arrives. Why?
The server is delivering locally instead of reading your MX records. In cPanel that is the Email Routing setting: if your mailboxes are with an external provider it must be set to Remote Mail Exchanger. Set to Local, the server considers itself the destination, drops the message in a local mailbox and generates no bounce, which is why nobody notices for weeks.
What is the MX priority number actually doing?
It sets the order of attempts. The lowest number is tried first and equal numbers share traffic between them. A single record at any priority is completely valid — additional entries buy redundancy if the first host is unreachable, nothing more. The numbers themselves are relative, so 10 and 20 behave exactly like 1 and 2.
Email stopped right after a nameserver change. Connected?
Directly. The new zone was created without your old MX records, so sending servers now find nothing willing to accept a delivery. Rebuild the MX set at whichever provider the domain now delegates to, and bring SPF and DKIM across in the same session. Senders retry for hours, so quick action usually means nothing is lost.
How do I check mail away from my desk?
Webmail runs in any browser, and every mailbox also speaks IMAP, POP and SMTP, so a phone client, a desktop client and webmail stay in sync on the same messages in the same state.
Keep reading
SMTP
The protocol that carries the message once routing has decided where it goes.
SPF (Sender Policy Framework)
The sender policy record, and the ten-lookup ceiling that breaks it quietly.
How to Create an SPF Record
Publishing a sender policy properly, with the lookup limit explained.
Web Hosting
cPanel hosting on NVMe with LiteSpeed, free SSL and a migration included.
Secure Hosting
Imunify360, isolated accounts and hardened defaults for security-first builds.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Host the site, keep the mailboxes.
Every plan carries the things other hosts bill as extras, plus support that answers when you need it.
View Web Hosting plans