You register a domain, set up an email service, but emails don't arrive. Mail gets delivered but goes to spam. Support says: "check your MX records." You open your DNS panel and see a table of priorities, hostnames, and TTLs. It looks more complicated than it actually is.
MX records are just DNS pointers that tell the internet: "my email lives here." When someone sends you an email, their mail server looks up your MX record to know where to route it. Without proper MX records, emails disappear. With them, mail arrives reliably with failover and redundancy.
How MX Records Work: The Basics
When Alice sends an email to bob@company.com:
1. Alice's mail server extracts the domain: company.com
2. It sends a DNS query: "What MX records exist for company.com?"
3. It gets back: "mail.company.com with priority 10"
4. It resolves mail.company.com to an IP address via an A record
5. It connects to that IP via SMTP and delivers the message
The MX record is the middleman between domain and mail server. It says: "mail for company.com goes to mail.company.com, not web.company.com or anything else."
MX Record Syntax
A typical MX record looks like:
@ MX 10 mail.company.com.
Let's break down each part:
@ — applies to your root domain (company.com). If you write "mail" instead of @, the record applies to the subdomain mail.company.com.
MX — record type. MX = Mail Exchange.
10 — priority (preference). Lower number = higher priority. 10 is tried first, then 20, then 30.
mail.company.com. — mail server hostname (FQDN). The trailing dot is mandatory (it means this is an absolute path in DNS).
Priority and Failover Mechanism
Priority is the key to reliable email delivery. A properly configured MX chain looks like:
@ MX 10 mail1.company.com. (primary, tried first)
@ MX 20 mail2.company.com. (backup if 10 is down)
@ MX 30 mail3.company.com. (third-level backup)
When Alice's mail server sends the message:
1. It tries to connect to mail1.company.com (priority 10)
2. If mail1 doesn't respond, it tries mail2.company.com (priority 20)
3. If mail2 doesn't respond, it tries mail3.company.com (priority 30)
4. If all are unavailable, the message is queued and retried later (bounces if no server responds within hours)
This guarantees that even if your primary mail server fails, email won't be lost—the backup will catch it.
Configuration Examples for Popular Services
Google Workspace
If you use Google Workspace (Gmail for your domain), Google gives you ready-made MX records:
@ MX 5 gmail-smtp-in.l.google.com.
@ MX 10 alt1.gmail-smtp-in.l.google.com.
@ MX 20 alt2.gmail-smtp-in.l.google.com.
@ MX 30 alt3.gmail-smtp-in.l.google.com.
@ MX 40 alt4.gmail-smtp-in.l.google.com.
Enter them exactly as Google specifies in their admin console. Google maintains multiple backup servers so email never gets lost.
Microsoft 365
For Microsoft 365 (Outlook for your domain), there's one MX record, but it's critical:
@ MX 10 company-com.mail.protection.outlook.com.
company-com is your domain reformatted as a hostname (dots replaced with dashes). Microsoft has internal redundancy, so you don't need to add extra MX records.
Self-Hosted Mail Server with Redundancy
If you host your own mail server (Postfix, Sendmail):
@ MX 10 mail-primary.company.com. (primary server)
@ MX 20 mail-secondary.company.com. (backup server in different datacenter)
Both servers should be configured to synchronize mail queues so if primary fails, messages move to secondary, not lost. Use different physical locations or cloud regions.
How to Check MX Records
Checking MX records is the first step when diagnosing email problems. Use our free MX Lookup Tool or the command line:
nslookup -type=MX company.com
dig MX company.com +short
host -t MX company.com
On Windows:
nslookup -type=MX company.com 8.8.8.8
If the MX record is not visible, it could mean:
1. You haven't added the MX record to your DNS panel (most common mistake)
2. DNS cache hasn't refreshed (wait, or clear cache: ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS)
3. You're using the wrong nameserver (verify that your domain registrar is pointing to the correct nameservers)
MX, SPF, DKIM, DMARC: Complete Email Security Stack
MX records tell the internet where to route incoming mail. But to prevent outgoing email from being flagged as spam or spoofed, you need three additional mechanisms:
SPF (Sender Policy Framework) — a TXT record that says: "emails from company.com can only be sent by these IP addresses or mail servers." If a spoofer with IP X tries to send mail claiming to be from your domain, the recipient's mail server will check SPF and recognize it as fake.
DKIM (DomainKeys Identified Mail) — cryptographic signature. When your mail server sends an email, it signs it with a private key. The recipient's mail server verifies the signature using the public key (stored in a DKIM DNS record) and confirms: this is genuinely your email.
DMARC (Domain-based Message Authentication, Reporting and Conformance) — a meta-policy that says: "if SPF or DKIM fails, do this (reject/quarantine)." DMARC also sends reports about which emails attempted to impersonate your domain.
Together, these four mechanisms provide complete email control: MX routes the mail, SPF/DKIM/DMARC protect it.
Common Mistakes When Setting Up MX Records
Mistake 1: MX record points to an IP address. WRONG: @ MX 10 192.168.1.1. RIGHT: @ MX 10 mail.company.com. DNS requires an FQDN. If you later move to a different IP, the record breaks. With a hostname, you only need to update the A record.
Mistake 2: MX record points to a CNAME. WRONG: @ MX 10 mail.company.com. (where mail.company.com is itself a CNAME). CNAME chains in MX records lead to unpredictable behavior. Each MX must resolve directly to an A record.
Mistake 3: Missing trailing dot in the hostname. @ MX 10 mail.company.com (without dot) might be interpreted as mail.company.com.company.com. Always add the trailing dot for FQDN records.
Mistake 4: Non-existent hostname. You added @ MX 10 mail.company.com. but there's no A record for mail.company.com. The sending mail server can't resolve the name and will reject the message. Check the A record for the hostname in your MX record.
Mistake 5: Identical priorities for failover. @ MX 10 mail1.company.com. and @ MX 10 mail2.company.com. means both servers have the same priority. The sending server will pick one randomly (round-robin), which doesn't guarantee failover. Use different priorities: 10, 20, 30.
Monitoring Email Deliverability
Proper MX configuration is the foundation, but it's not enough. Your mail server could be down, SPF might be broken, DKIM might not be signing emails. To monitor the health of your email infrastructure:
TCP checks on ports 25/587/465: verify that your mail server is listening on SMTP ports and responding.
HTTP checks on /health endpoints: if your mail server has a built-in health check endpoint, monitor it regularly.
DNS checks: periodically verify that MX, SPF, DKIM, and DMARC records are present and correct. AtomPing can check them automatically.
If your mail server goes down in the middle of the night, you'll find out immediately through monitoring, not when customers call with complaints.
TTL: MX Record Caching Time
Every DNS record has a TTL (Time To Live) — the duration for which a DNS server can cache the result. By default, MX records have a TTL of 3600 (1 hour).
High TTL (3600+): saves DNS server bandwidth, but changes propagate slowly (up to hours or longer).
Low TTL (300-600): changes take effect within 5-10 minutes, but DNS servers get queried more frequently.
Tip: before a major mail server migration, lower the TTL to 300 a day in advance. This lets you switch quickly if something goes wrong. After the migration, return it to 3600.
Summary: MX Configuration Checklist
✓ MX records are added to DNS (verify via nslookup or MX Lookup Tool)
✓ MX points to FQDN, not IP address
✓ A record exists for each MX hostname and resolves to the correct IP
✓ Priorities are correct: low numbers for primary, higher for backup
✓ SPF, DKIM, DMARC are configured (protection against spam and spoofing)
✓ Mail servers are monitored (TCP checks on SMTP ports, health check endpoints)
✓ DNS cache is cleared, TTL has propagated
Related Resources
- MX Lookup Tool — quickly check MX records for any domain
- DNS Record Types Explained — detailed explanation of A, CNAME, TXT, MX and other DNS records
- IP Blacklist Guide — how to avoid being listed on spam blacklists
FAQ
What is an MX record and why does my email need it?
An MX record is a DNS entry that tells the internet where to deliver email for your domain. When someone sends an email to user@yourdomain.com, their mail server looks up the MX record for yourdomain.com to find out which server should receive that email. Without MX records, email can't be delivered — it's like having a mailbox with no address on it.
What does the priority value in MX records mean?
The priority (also called preference value) determines which mail server to try first. Lower numbers = higher priority. If you have MX records with priority 10 (primary) and 20 (backup), the sender will try priority 10 first. If that server is down, it tries priority 20. You can chain multiple MX records to create failover without losing mail.
Why can't I point an MX record to an IP address?
MX records must point to hostnames (FQDN), never IP addresses. This is enforced by DNS specs. If you hardcoded an IP and later moved that service to a different IP, all your MX records break. With hostnames, you just update the A record, and MX records automatically resolve to the new IP. It's a single point of change instead of many.
What's the relationship between MX, SPF, DKIM, and DMARC?
MX records route incoming mail. SPF, DKIM, and DMARC protect against spoofing. SPF says which IPs can send email from your domain. DKIM cryptographically signs messages. DMARC sets policy for what happens if SPF/DKIM fails. Together, they prevent attackers from impersonating your domain. Without all four, email deliverability suffers and security is weak.
How long does it take for MX record changes to take effect?
MX records are cached by DNS servers (TTL: Time To Live, default 3600 seconds = 1 hour). Changes propagate within minutes, but some servers may cache longer. In practice: changes usually visible within 10-30 minutes, can take up to 24 hours in worst case. Test with tools like nslookup or your registrar's DNS checker.
What happens if I have multiple MX records with the same priority?
If multiple MX records share the same priority value, the mail server picks one randomly (round-robin). This distributes load across servers. However, it breaks failover — if one server is down, mail might still be sent to it and bounce. Best practice: use different priority values (10, 20, 30) so failover is deterministic and clear.