MX (Mail Exchanger) records tell the world which servers handle email for your domain. When someone sends an email to [email protected], the sending server looks up your MX records to find where to deliver it. If these records are wrong, email doesn't arrive.
How MX Records Work
An MX record has two parts:
- Priority — a number (lower = preferred). Senders try the lowest-priority server first.
- Mail server hostname — the server that accepts email (must be a hostname, not an IP address).
A typical setup looks like:
Priority 10 → mx1.mail.example.com
Priority 20 → mx2.mail.example.comThe sending server tries mx1 first. If it's unavailable, it falls back to mx2. This provides redundancy.
Looking Up MX Records
Use the DNS Toolkit Lookup endpoint to check MX records for any domain:
curl -H "X-API-Key: YOUR_KEY" \
"https://api.dnstoolkit.io/dns/lookup?domain=example.com&record_type=MX"The response shows each MX record with its priority, hostname, and TTL. Compare what you see with what your email provider says you should have configured.
Common MX Record Problems
No MX Records
If there are no MX records, senders fall back to the A record — but many mail servers won't attempt this. Always have explicit MX records.
MX Pointing to a CNAME
RFC 2181 says MX records must point to a hostname with an A or AAAA record, not a CNAME. Some mail servers will follow the CNAME, but others will reject the delivery. Fix this by pointing MX records directly to A/AAAA-resolvable hostnames.
MX Pointing to an IP Address
MX records must contain hostnames, not IP addresses. If you put an IP address in an MX record, delivery will fail.
Wrong Priority Values
If your backup server has a lower (higher-priority) number than your primary, all email goes to the backup first. Double-check that the primary server has the lowest priority number.
Missing A Records for MX Hostnames
If your MX record points to mail.example.com but there's no A record for mail.example.com, delivery fails. Use the DNS Toolkit Lookup All endpoint to verify both MX and the corresponding A records exist.
Migrating Email Providers
When switching email providers (e.g., from self-hosted to Google Workspace or Microsoft 365):
- Lower the TTL before the migration — set it to 300 seconds (5 minutes) a day or two in advance
- Update MX records to point to the new provider's mail servers
- Verify propagation — use the DNS Propagation endpoint to confirm the new MX records are visible globally
- Monitor delivery — send test emails from external addresses to confirm they arrive at the new provider
- Restore TTL — once everything is confirmed working, set the TTL back to a longer value (3600 seconds)
Verifying the Full Email Stack
MX records are just one piece. For reliable email delivery, also check SPF, DKIM, and DMARC records. The DNS Toolkit Email Security Posture endpoint audits all of these in a single call, giving you a complete picture of your domain's email configuration.