Quick MX Records Summary
MX records (Mail Exchanger records) are DNS entries that tell the internet which mail servers are allowed to receive email for your domain. They decide where messages sent to you@yourdomain.com are delivered.
| Item | Value |
|---|---|
| What it is | DNS record that routes incoming email to your mail servers. |
| Key fields | Priority, host/name, mail server hostname, TTL. |
| Required to receive email? | Yes, without MX most domains cannot receive mail at all. |
| Depends on | MX target hostnames must resolve to valid A/AAAA records. |
| Typical propagation | From a few minutes up to 24-48 hours depending on TTL. |
| Related records | SPF, DKIM, DMARC, A/AAAA, PTR (indirectly for deliverability). |
| Who manages it | Whoever controls your DNS zone (registrar, host, or third‑party DNS). |
Introduction: Why MX Records Decide If Your Emails Arrive
MX records are the backbone of inbound email routing: every time someone sends an email to your domain, their server queries DNS for your MX records and then connects to the listed servers to deliver the message. If MX is missing, wrong, or pointing to an offline host, mail will bounce or silently fail. Silent failure is the harder case, and the checklist for email that never arrives starts here.
For any business, this directly impacts sales, support, onboarding, and transactional flows like password resets. A clean MX setup, combined with proper authentication (SPF, DKIM, DMARC), also signals that your domain is well managed, which helps long‑term deliverability.
MX Records Basics (For Absolute Beginners)
What Is an MX Record?
An MX record tells sending mail servers which host is responsible for receiving email for a specific domain. When someone emails user@domain.com, the sender’s server looks up the MX records for domain.com and gets back one or more mail server hostnames with priority values.
The server attempts delivery to the lowest‑priority number first, treating higher‑numbered MX records as automatic failover. This simple mechanism allows for redundancy and high availability without complex configuration on the sender’s side.
MX vs A, CNAME, TXT and Other DNS Records
DNS records each play different roles: A/AAAA map hostnames to IP addresses, CNAME create aliases, TXT store arbitrary text such as SPF, and MX define which hosts receive email for a domain. An MX record must always point to a hostname, never directly to an IP address.
That hostname in turn must have a valid A or AAAA record; if it does not resolve, mail servers will not know where to send traffic and delivery will fail. You also cannot safely combine a CNAME at the zone apex with MX records, which is a common but critical misconfiguration.
Key MX Record Fields Explained
| Field | Description | Example |
|---|---|---|
| Host / Name | Domain or subdomain the MX applies to; often shown as @ for the root. | @ for example.com, or support for support.example.com. |
| Priority | Delivery order; lower values are tried first, higher act as backups. | 10 for primary, 20 for secondary. |
| Mail server | Hostname that receives email for the domain. | mx1.mailhost.com, ASPMX.L.GOOGLE.COM. |
| TTL | How long resolvers cache the MX record before refreshing. | 3600 seconds (1 hour) is common. |
How Email Uses MX Records (Flow)
From “Send” Click to Inbox
When a user hits send, the sending server extracts the recipient’s domain, performs a DNS lookup for that domain’s MX records, and receives a ranked list of mail exchangers. It then looks up the A/AAAA records for the chosen MX hostname and opens an SMTP connection to the resulting IP address.
During that SMTP session, additional checks such as TLS support, SPF alignment, DKIM signatures, and reputation filters are applied before the message is accepted. If the primary MX is unreachable, the sender repeats the process with the next MX according to priority.
Example MX Scenarios
- Single MX: one MX record with priority 10 pointing to a single mail server, simple, but no redundancy.
- Multiple MX: primary at priority 10 and backup at 20 to provide automatic failover.
- Broken A/AAAA: MX exists, but the target hostname does not resolve, so all delivery attempts fail despite “valid” MX.
How to Check Your Existing MX Records
Tools for Every Skill Level
You can inspect MX records with both online tools and CLI utilities. Web tools are ideal for quick checks, while command‑line gives you more control and scriptability.
| Tool | Type | Notes |
|---|---|---|
| Online MX lookup | Web | Great for quick visual checks and sharing screenshots with clients. |
dig MX domain.com | CLI | Standard on most Unix-like systems, supports specifying DNS servers. |
nslookup -type=mx domain.com | CLI | Available on Windows and many servers, easy for beginners. |
When reading results, confirm that you see at least one MX record, verify priorities, and check that each MX hostname resolves to an IP via A/AAAA. Any “NXDOMAIN” or “SERVFAIL” on the MX target is a red flag.
MX Record Lookup From the Command Line
The table above names the commands. Below is what each one actually returns, run against a live domain, so you can compare your own output line for line rather than guessing at the format.
$ dig google.com MX +short 10 smtp.google.com.
+short strips the response down to the answer itself, which is what you want when scripting or when you just need the value. Drop it and dig prints the full response; the part that matters is the answer section.
$ dig google.com MX ;; ANSWER SECTION: google.com. 105 IN MX 10 smtp.google.com.
Read that line left to right: the domain queried, the TTL in seconds still remaining on the cached copy, the class, the record type, the priority, and the target hostname. The TTL is the field people skip and then wonder why a change has not taken effect, because a record with a long TTL is still being served from caches everywhere until it expires. That mechanism is covered in the reference on DNS records, TTL and propagation.
nslookup is the equivalent that ships with Windows, so it is the command to reach for on a machine that has no dig. It works identically on macOS and Linux.
$ nslookup -type=mx google.com Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: google.com mail exchanger = 10 smtp.google.com.
Non-authoritative answer is not a warning. It means the resolver answered from its cache rather than by asking the domain’s own nameservers, which is the normal case and does not make the answer wrong. If you specifically want the authoritative copy, query the domain’s nameserver directly with dig @ns1.example.com example.com MX.
On macOS and Linux, host returns the same information in one line, which is often all you need:
$ host -t MX google.com google.com mail is handled by 10 smtp.google.com.
What the Result Tells You, and What an Empty One Means
An MX record lookup is a DNS query restricted to the MX type, nothing more. It answers one question: which hostnames does this domain nominate to receive its mail, and in what order. It says nothing about whether those hosts are reachable, whether they will accept your message, or whether the mailbox exists. Confirming that the target actually resolves is a separate step, against the A and AAAA records of the mail host.
An empty result is meaningful, not a failed command. If the lookup returns nothing, the domain publishes no MX record at all. A sending server then falls back to the domain’s own A or AAAA record and attempts delivery there, the implicit MX behaviour defined in RFC 5321. Some senders skip that fallback and reject outright, which is why a domain with no MX record tends to deliver inconsistently rather than not at all.
Where to find your MX record without a terminal. The authoritative copy lives wherever DNS is hosted for your domain, usually the registrar or the CDN in front of it, under a DNS or zone editor panel. The values you are supposed to see come from your mail provider rather than from your DNS host: to check MX records for a Google Workspace domain, for example, the expected values are the ones Google publishes in the Admin console setup steps, and the correct test is to look up your own domain and compare against those. Do not copy MX values from another domain, including the examples above. smtp.google.com is what google.com publishes for itself and is not the record a Workspace customer is handed. Provider-side client settings for that platform are collected in the Google Workspace mail server reference.
Configuring MX Records: Step-by-Step
Preparation Checklist Before Editing DNS
- Confirm which email provider is authoritative for the domain and fetch their exact MX values.
- Audit existing MX records and understand what infrastructure they currently point to.
- Lower MX TTL (for example from 3600 to 300) a few hours before a planned migration to speed up propagation.
- Ensure you have access to the correct DNS zone if you are using split DNS or multiple providers.
Generic MX Setup in Any DNS Panel
- Log into your DNS provider or registrar and open the DNS zone editor for your domain.
- Locate existing MX records and note them down before making changes.
- Add or edit MX records using the values supplied by your email host (host, priority, server, TTL).
- Remove obsolete MX records that point to retired or unknown systems.
- Save changes and verify with an MX lookup tool after a few minutes.
Example: Google Workspace / Microsoft 365 MX
| Provider | MX Hostname | Priority | Notes |
|---|---|---|---|
| Google Workspace | ASPMX.L.GOOGLE.COM | 1 | Primary MX server; must be present in every Workspace setup. |
| Google Workspace | ALT1.ASPMX.L.GOOGLE.COM | 5 | First backup MX; improves resilience. |
| Microsoft 365 | tenant-id.mail.protection.outlook.com | 0 | Single MX with priority 0, provided per-tenant by Microsoft. |
Always copy MX values from the provider’s official dashboard or documentation rather than typing them manually to avoid subtle typos.
Understanding MX Priority (And How to Design Failover)
MX priority is the number that defines the order in which mail servers are tried for your domain. Lower numbers mean higher priority: a server with priority 10 is always tried before one with 20. This is how you design redundancy and failover without any extra logic on the sender’s side.
In practice, you’ll usually see either a single MX (for small setups) or several MX records with staggered priorities. The idea is simple: primary servers get the lowest numbers, and backup or secondary servers get higher numbers. If the primary is down or too slow to respond, sending MTAs automatically move on to the next MX in the list.
| Scenario | Priority Pattern | Behavior |
|---|---|---|
| Single mailbox provider | One MX at 10 | All mail goes to that provider; no built‑in failover if it’s unreachable. |
| Primary + backup server | Primary at 10, backup at 20 | Senders always try 10 first, then 20 if 10 fails or times out. |
| Filtering gateway in front of mailbox | Gateway at 10, mailbox host at 20 | Mail hits the gateway first; mailbox host only used if gateway is unreachable. |
One common misconception is that “more MX with random priorities” equals better redundancy. In reality, inconsistent patterns can create unpredictable routing, especially if some targets are misconfigured or underpowered. Keep your priorities simple and deliberate: one clear primary, one or more clearly defined backups, and avoid mixing providers unless you fully understand the routing implications.
- Give your true primary MX the lowest number across all records.
- Use higher numbers only for servers that are genuinely capable of acting as backups.
- Avoid equal priorities unless you intentionally want load‑sharing between identical infrastructures.
MX TTL: Propagation, Migrations and Stability
TTL (Time To Live) is the DNS value that tells resolvers how long they are allowed to cache your MX records before checking for updates again. The higher the TTL, the longer old information can persist after you make a change; the lower the TTL, the faster changes propagate worldwide.
For a stable, mature email setup, a TTL like 3600 seconds (1 hour) or even higher is usually fine. It reduces DNS query load and keeps behavior predictable. However, during migrations or planned reconfigurations, keeping a high TTL can hurt you because remote resolvers will continue to use outdated MX information for hours.
| Situation | Suggested MX TTL | Rationale |
|---|---|---|
| Normal steady‑state operation | 3600-14400 seconds | Fewer DNS lookups, stable behavior once records are correct. |
| Planned email migration | 300-900 seconds (set 24h before) | Speeds up propagation when you switch providers or hosts. |
| Emergency rollback / critical fix | 300 seconds short‑term | Lets you correct mistakes quickly; increase again after things stabilize. |
A good operational pattern is to lower MX TTL at least a day before a planned change, make the change during a low‑traffic window, and then raise TTL again after you’ve verified that mail is flowing correctly. This minimizes both propagation pain and long‑term DNS overhead.
Remember that TTL does not “force” propagation; it just defines how long caches are allowed to keep old data. If you forget to reduce TTL before moving to a new mail provider, some senders may keep delivering to the old MX for many hours, creating split delivery or apparent “missing emails” during the transition.
Advanced MX Use Cases for Power Users
Split Delivery and Dual Delivery
Split delivery routes different recipients at the same domain to different backends, such as keeping some users on on‑prem Exchange and others in the cloud during a migration. Dual delivery sends copies of incoming mail to two systems simultaneously, improving archival and compliance.
These patterns are implemented with a combination of MX configuration, routing rules, and sometimes smart relays or gateways. They are common in larger organizations that cannot migrate everyone at once.
Subdomains for Separate Email Streams
Using subdomains like news.domain.com or billing.domain.com lets you isolate specific email flows with their own MX, SPF, DKIM, and DMARC. This segmentation can protect your primary corporate domain from reputation damage when running high‑volume campaigns.
Each subdomain behaves like its own email “brand” with separate DNS and policy, which is especially useful when combining transactional, marketing, and support traffic.
MX Records and Security Gateways
Many organizations point MX to a security or filtering gateway instead of directly to the mailbox provider. The gateway then performs spam filtering, malware scanning, and policy enforcement before relaying accepted messages to the final destination.
This architecture centralizes logging and control, makes migrations easier, and helps meet compliance requirements in regulated industries.
MX Records, Deliverability and Security
How MX Influences Deliverability
While MX records primarily govern inbound routing, misconfigured MX can indirectly hurt your deliverability by causing bounces, deferred messages, and user complaints. Persistent DNS failures or timeouts are often interpreted as signs of poor domain hygiene.
Healthy MX setups with redundancy and correct DNS responses reduce transient failures and help maintain a clean, predictable mail flow.
MX + SPF, DKIM, DMARC: Minimum Secure Stack
MX records define where your mail is received, while SPF, DKIM, and DMARC define how your outgoing mail is authenticated and policed. Together, they form the minimum DNS posture for a modern business domain.
- SPF lists which hosts may send on behalf of your domain.
- DKIM adds cryptographic signatures to messages.
- DMARC instructs receivers how to handle failures and provides reporting.
Domains that combine correct MX with robust SPF, DKIM, and DMARC are far better protected against spoofing and phishing attacks.
Recommended Baseline Policies
- Publish SPF covering all legitimate outbound systems (mailboxes, CRMs, ESPs).
- Enable DKIM on every platform that sends email for your domain.
- Start DMARC with a monitoring policy (
p=none) and gradually move towardquarantineorreject. - Review reports and adjust DNS entries regularly.
Troubleshooting MX Record Problems
Symptom-Based Troubleshooting Table
| Symptom | Likely Cause | What to Check | ✅ Fix |
|---|---|---|---|
| No one can email the domain | No MX records or MX pointing to non‑existent host. | Run MX lookup; verify at least one MX and that each target resolves. | Create correct MX records and ensure A/AAAA records exist. |
| Some senders fail, others succeed | Partial DNS propagation or multiple conflicting DNS zones. | Query MX from multiple resolvers, verify single source of truth. | Consolidate DNS, remove stale zones, wait for TTL to expire. |
| Intermittent delivery / random bounces | Primary MX unstable, backup misconfigured. | Monitor uptime of MX hosts, inspect SMTP logs. | Stabilize primary host, correct backup MX targets. |
| Very slow inbound mail | Time‑outs or greylisting at MX, DNS latency. | Check MX server response time and DNS performance. | Optimize infrastructure, adjust anti‑spam policies. |
| Only certain addresses fail | Local mailbox or routing rules rather than MX. | Confirm MX works for other users; inspect mailbox server logs. | Fix local mailbox configuration or aliases. |
Common DNS / SMTP Error Codes Tied to MX
- NXDOMAIN: Domain or MX hostname does not exist, check spelling and zone.
- SERVFAIL: DNS server problem or DNSSEC issue, verify DNS health and signatures.
- 4xx codes: Temporary failures such as timeouts or greylisting, usually retried later.
- 5xx codes: Permanent failures like “no such user” or “relay denied.”
DNS Propagation and “Phantom” MX Records
After changing MX records, you may see different answers from different locations for several hours. This is normal and driven by TTL and caching at recursive resolvers.
Use multiple public resolvers to confirm when old MX values disappear, and avoid making repeated emergency changes during the propagation window.
Advanced Conflict Scenarios
- CNAME at the apex conflicting with MX, preventing proper resolution.
- MX pointing to a hostname that only has AAAA but no A record, causing issues for IPv4-only senders.
- Zones duplicated across providers, with only one being updated.
Practical MX Configuration Examples
Small Business Primary Domain
| Type | Name | Value | Purpose |
|---|---|---|---|
| A | @ | IPv4 of web server | Main website. |
| MX | @ | ASPMX.L.GOOGLE.COM (prio 1) | Primary inbound mail. |
| TXT | @ | SPF including mailbox provider and transactional ESP | Authorizes outbound senders. |
| TXT | _dmarc | v=DMARC1; p=none; rua=… | Monitors alignment and abuse. |
Newsletter Subdomain with Separate MX
| Type | Name | Value | Purpose |
|---|---|---|---|
| MX | news | mx1.newsprovider.com (prio 10) | Handles replies for newsletter addresses. |
| TXT | news | Dedicated SPF for ESP infrastructure | Separates reputation from primary domain. |
MX Best Practices and Operational Checklist
- Always maintain at least two MX records for critical domains to provide redundancy.
- Never point MX directly to an IP address or to a pure CNAME.
- Document MX, SPF, DKIM, and DMARC in internal runbooks and keep them updated.
- Review MX configuration during every email or hosting migration.
- Monitor inbound availability and error rates via logs and external probes.
| ✅ Task | Frequency | Owner |
|---|---|---|
| Review MX records and priorities | Quarterly | Email / Infra team |
| Test inbound delivery from major providers | Monthly | Ops / Deliverability |
| Audit SPF / DKIM / DMARC alignment | After any new sending system | Security / Deliverability |
FAQ
Do I need MX records to receive email?
Yes. Without MX records, most modern MTAs will not deliver mail to your domain and will return a bounce indicating that no valid mail exchanger is configured.
Can a domain send email without MX records?
In some edge cases, senders may fall back to A records when MX is missing, but this behavior is not guaranteed and is considered legacy. For any serious use, you should always define proper MX records.
Can I have multiple MX providers for the same domain?
Technically you can configure MX records pointing to different providers, but shared responsibility for the same addresses is complex and risky. In practice, multi‑provider setups are usually implemented via gateways or routing rules, not parallel independent inbox systems.
Why does my MX point to another domain?
It is normal for MX to reference a hostname under a different domain, such as a hosted service like Google or Microsoft. What matters is that the provider controls that infrastructure and that the target resolves correctly.
Do MX records affect spam placement or only delivery?
MX primarily controls whether messages can be delivered at all, but misconfigurations can contribute to bounces and timeouts that hurt your overall sender reputation. In combination with weak authentication, this can increase spam placement.
How often should I review my MX configuration?
At minimum, review MX records quarterly and after any change to email hosting, gateways, or domain ownership. Many issues only surface months after a migration when legacy records were left in place.
Can MX misconfiguration break only some addresses and not others?
Yes. MX defines where mail is delivered, but local mailbox configuration determines which addresses exist and how they are routed. You can have valid MX but broken aliases, catch‑alls, or local rules that affect only a subset of addresses.
Is it safe to use free DNS for business-critical MX?
Free DNS can work, but you must evaluate SLA, redundancy, and support carefully. For domains that carry revenue‑critical mail, premium or enterprise DNS with strong uptime guarantees is often justified.
Should newsletters and transactional email share the same domain and MX?
Segmenting bulk and transactional traffic across subdomains with separate DNS and MX is a common best practice to protect vital flows like password resets. This design also gives you more control over reputation for each stream.
How do MX records interact with email forwarding?
MX determines where the original message is delivered; forwarding happens after the mailbox provider accepts the message and then resends it elsewhere. Complex forwarding chains can affect authentication and spam scoring, so they should be designed carefully.
Don’t forget to clean your list. Boost your inbox rate.
SMTPing catches what regex misses: disposable addresses, role-based emails, catch-all domains, syntax errors, and 9 more invalid types. Free tier renews every day, no card required.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
