MX record is one of the most foundational, but often misunderstood, components of email infrastructure. Whether you’re running a business email through a custom domain or managing enterprise-level email systems, understanding how MX records work is critical to ensuring that messages reach their intended destination.
At its core, an MX (Mail Exchange) record is a type of DNS (Domain Name System) record that directs email traffic for a domain to the correct mail servers. It tells the internet where to deliver your incoming email. Without it, messages sent to your domain will go nowhere.
For email admins, IT professionals, and even small business owners using hosted services like Google Workspace or Microsoft 365, getting your MX records set up correctly is one of the first steps toward a functional and reliable email system. In this guide, we’ll break down what MX records are, how they work, how to set them up properly, and how they fit into the broader context of email deliverability and DNS configuration.
What Is an MX Record?
Technical Definition of MX Records
An MX (Mail Exchange) record is a type of DNS resource record that specifies which server is responsible for receiving email messages on behalf of a domain. Each domain name—like example.com—can have one or more MX records, and each of these records points to a mail server that accepts email for that domain.
In simpler terms, an MX record is a mail routing instruction embedded in your DNS settings. When someone sends an email to user@example.com, their email service queries the DNS system for example.com’s MX record. Based on this record, the system determines which server to deliver the message to.
The MX record doesn’t store any messages itself. It simply acts as a pointer to the actual mail server (defined by a domain name like mail.example.com), which then uses protocols like SMTP to receive the email.
Role of MX Records in Email Delivery
Without a properly configured MX record, email delivery fails. If someone tries to email you at your domain and no MX record exists—or it’s misconfigured—the sender will likely receive a bounce-back or non-delivery report.
MX records are responsible only for incoming mail. They don’t directly affect sending email (that’s handled via SMTP), but if your incoming infrastructure isn’t set up, your domain becomes non-functional for email correspondence.
Moreover, the MX record must reference a hostname that resolves to an IP address—not a raw IP address itself. This hostname should also support DNS resolution and be associated with a functioning mail server that’s prepared to accept and route mail correctly.
How MX Records Fit into Email Infrastructure
Relationship with SPF, DKIM, and Reverse DNS
While MX records handle email reception, they are part of a larger ecosystem that includes sender validation and security protocols. For instance, SPF (Sender Policy Framework) records define which servers are allowed to send emails on behalf of your domain. DKIM (DomainKeys Identified Mail) provides cryptographic signatures to verify message authenticity. DMARC ties these together to enforce policy.
Reverse DNS also plays a role in validating whether the mail server is trustworthy. It ensures that the mail server’s IP address resolves back to a domain name that matches what’s in the email headers. This is a major spam filtering signal used by receiving mail servers.
All of these components must work together. A domain might have a perfect MX record, but if SPF or DKIM is misconfigured, or reverse DNS doesn’t align with your SMTP server, your emails may still land in the spam folder—or be rejected outright.
Interplay with SMTP Server Functionality
The MX record defines the receiving server for a domain, but that server must also be running a mail transfer agent (MTA) like Postfix, Exim, or Microsoft Exchange. These agents listen for incoming connections on port 25 (SMTP) and process the incoming messages.
If the MX record is correct but the server at the target hostname isn’t listening for mail—or is rejecting connections—then email delivery will still fail. Therefore, proper SMTP server configuration goes hand in hand with accurate MX record settings.
Additionally, the SMTP server must be configured to recognize the domain in question as local. Otherwise, it will refuse to relay the mail, again leading to delivery failure.
Understanding MX Record Components
Priority Values and Multiple Records
Each MX record is assigned a priority value—an integer that indicates the order in which mail servers should be used. Lower numbers have higher priority. For example, if your domain has two MX records:
- MX 10 mail1.example.com
- MX 20 mail2.example.com
Then mail will be delivered to mail1.example.com first. If that server is unavailable, the sender’s mail server will attempt to deliver to mail2.example.com.
This allows for redundancy and load balancing. It’s common for large organizations to maintain multiple MX records pointing to geographically distributed mail servers.
If two MX records have the same priority, servers may use a round-robin approach to distribute traffic between them. While this is useful for load balancing, it should be implemented carefully to avoid routing issues or inconsistency.
Hostnames vs. IP Addresses in MX Configuration
An important rule when setting up MX records is that the value of an MX record must always be a fully qualified domain name (FQDN), not an IP address. This domain name must resolve to an A (IPv4) or AAAA (IPv6) record that points to the mail server’s actual IP.
Why not use IP addresses directly? Because IPs can change—especially with dynamic DNS or cloud-hosted infrastructure. Hostnames provide an abstraction layer that can be updated independently, keeping your MX configuration stable even as infrastructure evolves.
This also supports better alignment with other DNS and email security mechanisms, including reverse DNS, which cannot function properly if raw IPs are used in MX records.
When and Why You Need to Update MX Records
Switching Email Providers or Hosting Services
One of the most common reasons to change your MX records is when switching from one email service provider (ESP) to another. For example, if you’re migrating from a cPanel-based mail server to Google Workspace, you’ll need to update your MX records to Google’s specifications.
Failure to do so means emails will continue going to the old server—or bounce entirely if the old server is decommissioned. The same goes for switching between Office 365, Zoho Mail, ProtonMail, or self-hosted environments.
Always coordinate DNS updates with infrastructure changes. Ideally, you should update your MX records only after the new email server is fully configured and tested.
Ensuring Redundancy with Secondary MX Records
Even if you’re not switching providers, you may want to add secondary or backup MX records to improve reliability. If your primary server goes offline due to maintenance, DDoS, or hardware failure, the secondary server can accept messages temporarily.
This is especially important for businesses where email downtime can lead to lost revenue or client trust. Proper failover MX records ensure your domain remains reachable even in adverse conditions.
However, all MX destinations must be prepared to receive and store messages correctly. Having an MX record pointing to a non-functional server can cause more harm than good.
How to Set Up MX Records—Step by Step
Accessing DNS Management Tools
To configure MX records, you need access to your domain’s DNS settings. This is typically done through your domain registrar (like GoDaddy or Namecheap) or hosting provider (such as Bluehost, SiteGround, or Cloudflare). If your DNS is managed elsewhere—for example, through your CDN or cloud platform—you’ll find a DNS management console in that provider’s dashboard.
Once logged in, navigate to the section that allows DNS modifications. This is where you’ll add, edit, or delete MX records along with other records like A, CNAME, and TXT. Be careful when editing live DNS settings; incorrect changes can interrupt email or website functionality.
DNS changes, including MX updates, can take time to propagate across the internet. While propagation often completes in a few minutes, it can take up to 48 hours in some scenarios depending on TTL (Time to Live) values and ISP caching.
Creating Your First MX Record Entry
To set up a new MX record:
- Choose your domain (e.g., yourcompany.com) in the DNS dashboard.
- Click “Add Record” or “Edit” if an MX entry already exists.
- Set the type as “MX”.
- For “Host” or “Name”, use @ to represent the root domain or specify a subdomain if needed.
- Enter the “Value” as the mail server’s domain name, e.g., mail.yourprovider.com.
- Assign a “Priority” number (lower means higher priority).
- Set TTL—default is typically fine unless advised otherwise.
Save your changes and then confirm they were applied using a DNS lookup tool. The most reliable method is querying with the dig or nslookup command-line tools, or using online tools like MXToolbox.
If you’re switching providers, be sure to delete or disable the previous MX record to avoid misrouting. An incorrect or outdated MX configuration is one of the top causes of DNS issues and mail delivery problems.
Testing and Troubleshooting MX Records
Verifying MX Records with DNS Lookup Tools
After setting up your MX records, it’s essential to verify that they’re configured correctly. The fastest method is using a tool like MXToolbox, which allows you to enter your domain and see all current MX records, their priority values, and whether they are resolving correctly.
Alternatively, you can use command-line tools:
- dig yourdomain.com MX (Linux/macOS)
- nslookup -type=MX yourdomain.com (Windows)
These tools return the full list of MX records, the corresponding mail servers, and the priority for each.
If the results match what you intended, your MX configuration is correct. If not, recheck your entries in the DNS manager. Typos, incorrect priority levels, or using an IP instead of a hostname are common mistakes.
Diagnosing Common DNS Issues and Non‑Delivery Reports
Problems with MX records often manifest as bounced emails or delayed deliveries. When emails don’t arrive, the sender might receive a Non‑Delivery Report (NDR), which contains error codes like “MX lookup failed” or “host not found”.
These errors usually point to one of the following:
- The domain has no MX records set.
- The MX records point to non-existent or misconfigured servers.
- There’s a firewall or port block preventing SMTP traffic to the MX host.
Check DNS resolution, confirm that the mail server is accepting connections on port 25, and ensure there are no DNS propagation delays. Also verify that the mail server is ready to accept mail for your domain—some systems reject mail for unknown domains even if DNS is correct.
MX Records in Multi‑Platform Environments
Routing Mail for Subdomains and Services
MX records aren’t limited to root domains. You can configure them for subdomains too. For example, support.yourcompany.com can have a separate MX record from your main domain. This is useful for routing email from different departments or brands to different servers.
Subdomain-specific MX configurations are common in SaaS, CRM, and marketing automation setups where you want granular control over which platform handles what type of email.
Be cautious with wildcard records or catch-all setups that inadvertently affect MX behavior. Each subdomain should be explicitly defined if unique routing is required.
Use Cases with POP3 vs. IMAP Accounts
While MX records determine where your email is delivered, your choice of protocol—POP3 or IMAP—determines how that mail is accessed.
POP3 downloads and usually deletes mail from the server, whereas IMAP synchronizes messages across devices. Regardless of protocol, your MX record must point to the correct receiving server for either to function properly.
If MX records are incorrect, your email client will either receive no messages or display errors about unreachable servers.
Best Practices for MX Record Configuration
Security, TTL Settings, and Mail Server Redundancy
Security is critical in email infrastructure. Always ensure your MX hostnames have proper A/AAAA records and are protected with SPF, DKIM, and DMARC settings. Never point MX records to raw IPs.
For TTL (Time to Live), use values that balance responsiveness and caching. 3600 seconds (1 hour) is typical for MX records. During migrations, you might lower TTL to 300 seconds to speed up propagation.
Ensure redundancy with secondary MX records where possible. Don’t rely on a single point of failure unless your provider has built-in failover.
Documenting Changes and Managing DNS Zones
Keep detailed records of DNS changes, especially when altering MX records. Log the date, purpose, and rollback plan for each modification. This helps during audits, troubleshooting, and team onboarding.
If managing multiple domains, group DNS zones by provider or function and audit them periodically. Tools like Cloudflare, AWS Route 53, and Google DNS support zone exports for documentation purposes.
Advanced MX Record Scenarios
Email Forwarding Services and Third‑Party Routing
Some domains don’t run full mail servers but instead forward incoming mail to another address. These forwarding services still require proper MX records to function.
For example, if your MX points to forward.yourprovider.com, that service will catch all incoming mail and relay it to your actual email. This is common in email aliases and vanity domain setups.
Be cautious: forwarded mail must be compliant with sender authentication protocols, or it may fail SPF/DKIM checks and end up in spam.
Integrating with Cloud Email Providers (e.g., Google Workspace)
Cloud email services provide MX records that must be added to your domain’s DNS. For instance, Google Workspace uses MX entries like ASPMX.L.GOOGLE.COM with priority 1, followed by backup servers with increasing priority values.
You must enter these exactly as specified, or mail delivery may not work. Google and Microsoft both offer setup wizards and DNS validation tools to confirm MX record propagation.
Double-check that other legacy MX records have been removed to avoid conflict or misdelivery.
The Role of MX Records in Email Deliverability
Avoiding SMTP Rejections via Proper DNS Setup
Correct MX records ensure your domain is reachable by external mail servers. If the record is missing, malformed, or pointing to an invalid host, senders will be unable to establish SMTP connections and messages will be bounced or dropped.
Deliverability depends not just on content and IP reputation, but also on infrastructure accuracy. MX records are one of the first things checked by receiving systems.
Supporting Reverse DNS and SMTP HELO Consistency
MX records also support best practices in server identity. When a sending server connects to your MX destination, your system will validate the HELO/EHLO command against DNS.
If your receiving server uses reverse DNS lookups or other trust indicators, having consistent and accurate MX records ensures your email setup passes those checks and avoids spam classification.
Conclusion
MX records are the unsung heroes of email functionality. Without them, your domain has no way to receive incoming messages, no matter how well your SMTP server is configured or how professional your email campaigns are. They form the critical link between DNS and the broader infrastructure of mail exchange.
Setting up MX records properly—and maintaining them with clarity, redundancy, and alignment with modern email protocols—is essential for any organization that wants reliable communication. Whether you’re running a small online store, managing enterprise systems, or building a SaaS platform, understanding and mastering MX records ensures your emails are delivered, trusted, and secure.
FAQs
How many MX records should I have?
Most domains need at least one MX record, but it’s recommended to have a secondary record for redundancy. Some providers offer up to five for load balancing and failover.
Why is my MX record pointing to an IP not recommended?
MX records must use hostnames, not raw IP addresses, to support flexibility, DNS compliance, and compatibility with reverse DNS and security protocols.
Can MX records affect email sending as well as receiving?
No, MX records only direct incoming mail. Outgoing mail relies on SMTP servers and sender authentication protocols like SPF and DKIM.
How long does MX record propagation take?
Changes usually propagate within a few hours but can take up to 48 hours depending on TTL settings and global DNS caches.
Do MX records matter if I’m only using SMTP to send mail?
Yes. Some systems validate sending domains against MX records as a trust signal. Also, replies and bounces will fail if MX records are missing.
