Getting email to flow reliably starts with one thing: correctly configured MX records. Whether you just moved to Google Workspace, Microsoft 365, Zoho Mail, or a custom mail server, a misconfigured MX record is the fastest way to lose incoming mail silently. Senders get no immediate error, your inbox gets nothing, and tracking down the problem later is painful. This guide walks through exactly what MX records are, how to set them up for the most common providers, how to test that they are working, and how to avoid the mistakes that cause deliverability problems down the line.
What an MX Record Actually Does
An MX (Mail Exchanger) record is a DNS entry that tells the internet which mail server is responsible for accepting email on behalf of your domain. When someone sends a message to you@yourdomain.com, their sending mail server performs a DNS lookup for MX records on yourdomain.com, connects to the server listed, and delivers the message via SMTP. Without a valid MX record, mail cannot be delivered to your domain at all.
MX records have two fields beyond the standard DNS record components: a priority value (also called preference) and a mail server hostname. Lower priority numbers are tried first. If the primary server is unavailable, the sending server falls back to the next lowest priority. This is how redundant mail delivery works.
A typical MX record in zone file notation looks like this:
That trailing dot on the hostname is important in raw zone files — it signals a fully qualified domain name (FQDN). Most DNS control panels add it automatically, so you usually just type the hostname without the dot.
Before You Start: What You Need to Know
Before touching anything in your DNS panel, collect the following information from your email provider:
- The exact MX record hostnames (there is often more than one)
- The priority number for each hostname
- The recommended TTL (time-to-live) for the records
- Whether the provider requires you to remove existing MX records first
- Any required SPF, DKIM, or DMARC records that must also be added
Skipping the SPF and DKIM setup is the most common oversight. You can get mail flowing with just MX records, but without SPF and DKIM, your outgoing messages will be flagged as spam by recipients. Plan to add all three record types in the same session.
Setting Up MX Records for Google Workspace
Google Workspace uses five MX records, all pointing to Google's mail routing infrastructure with different priority values. Log in to your DNS host's control panel and add each of the following as a separate MX record:
The Name or Host field for each record should be set to @ (which represents your root domain) or left blank, depending on your DNS provider's convention. Set the TTL to 3600 seconds (one hour) or whatever Google's current setup wizard recommends. Delete any existing MX records pointing to a previous mail provider before saving, or mail will split between two providers unpredictably.
Setting Up MX Records for Microsoft 365
Microsoft 365 uses a single MX record with a unique hostname per tenant. The hostname follows this pattern:
Your exact hostname is visible in the Microsoft 365 admin center under Settings > Domains > your domain > DNS records. Add it with priority 0 (or 10 — Microsoft accepts either):
Microsoft also requires an Autodiscover CNAME and specific SPF, DKIM, and DMARC entries. Do not skip those — Outlook's spam filters are aggressive and will penalize domains without proper authentication records.
Setting Up MX Records for Zoho Mail
Zoho Mail uses two MX records:
Add all three for full redundancy. As with other providers, set the Name field to @ and clear out any MX records from a previous provider.
Setting Up MX Records for a Custom or Self-Hosted Mail Server
If you run your own Postfix, Exim, or similar mail server, your MX record points to either the server's hostname or its IP address. The correct approach is to point to a hostname, not a bare IP — the MX record specification explicitly prohibits pointing directly to an IP address. Create an A record for your mail server first, then point the MX record to that hostname:
Also confirm that your mail server has a matching PTR (reverse DNS) record. Many receiving servers check that the IP your mail server sends from resolves back to the same hostname. Without a PTR record, your outgoing mail is likely to land in spam or be rejected outright. PTR records are controlled by your server's hosting provider or ISP, not your domain registrar.
Where to Edit MX Records: Common DNS Panels
MX records must be edited wherever your domain's DNS is hosted, which is not always the same place as your domain registrar or your web host. Run a quick NS lookup to confirm:
The nameservers returned tell you which DNS provider controls your zone. Common scenarios:
- Cloudflare: Log in at dash.cloudflare.com, select your domain, go to DNS, click Add Record, choose MX type.
- cPanel (shared hosting): Log in to your hosting control panel, find the Zone Editor or MX Entry section under Email.
- GoDaddy: Log in, go to My Domains, click DNS, scroll to MX Records.
- Namecheap: Log in, go to Domain List, click Manage, then Advanced DNS tab.
- AWS Route 53: Open the Hosted Zone for your domain, click Create Record, choose MX type.
Verifying Your MX Records Are Correct
Do not assume the records are live just because you clicked Save. Use command-line tools to confirm what the internet actually sees.
On Windows, open Command Prompt and run:
On Linux or macOS, use dig:
The output should list every MX hostname you added, along with its priority number. If you still see old records, either the change has not propagated yet, or you edited the wrong DNS zone. To confirm against a specific resolver instead of your local cache, query Google's public DNS directly:
You can also use the DNS Lookup tool to query MX records from multiple locations at once without opening a terminal.
To go one step further and actually test SMTP connectivity to your mail server, use Telnet or OpenSSL:
A successful connection returns a 220 banner from the mail server. If you get connection refused or a timeout, either the port is blocked by a firewall or the hostname is wrong.
Common MX Record Mistakes and How to Fix Them
Leaving old MX records in place
This is the most frequent error. If you add Google Workspace MX records without deleting your previous host's MX records, some mail will still route to the old server. Always remove every existing MX record before adding new ones, unless your provider explicitly tells you to keep them.
Pointing the MX record to an IP address
MX records must point to a hostname, not an IP. If your DNS panel accepts it without error, the record will still be rejected or ignored by standards-compliant mail servers. Create an A record for the IP first, then reference that hostname in the MX record.
Adding a trailing dot inside the DNS panel
In raw zone files a trailing dot is required, but most web-based DNS panels add it automatically. If you type mail.yourdomain.com. with a trailing dot in a panel that adds its own, the resulting record becomes mail.yourdomain.com.. which resolves to nothing. Type the hostname without a trailing dot in GUI panels.
Setting the wrong TTL before a migration
If you are planning to switch mail providers, lower your MX record TTL to 300 seconds (five minutes) at least 24 to 48 hours before the migration. This gives you fast rollback capability. After the migration is stable, set the TTL back to 3600 or higher.
Forgetting SPF after adding MX records
A missing or broken SPF record causes your outgoing mail to fail authentication checks at receiving servers. After setting up MX records, immediately add a TXT record for SPF. For Google Workspace it looks like this:
For Microsoft 365:
Priority Values: What They Mean in Practice
Priority values are relative, not absolute. A record with priority 1 is tried before priority 10, and priority 10 before priority 20. If the lowest-priority server is unreachable, the sending server retries the next one. Equal priority values (two records both set to 5, for example) cause load balancing — the sending server picks one at random. This is intentional for providers like Google that list two records at priority 5.
Do not assign the same priority to records that should be primary versus backup. If your main server and a fallback relay both have priority 10, half your mail might go to the fallback at all times, which is rarely what you want.
After Setup: Ongoing Monitoring
MX records do not need frequent changes, but they can break in unexpected ways. A DNS zone migration, a domain renewal going wrong, or a nameserver change can wipe out DNS records. Set a calendar reminder to verify your MX records quarterly using dig or the DNS Lookup tool. Many email platforms also have built-in DNS health checks in their admin consoles — enable any alerts they offer.
If users report missing emails, the first thing to check is always the MX record. A quick dig command takes ten seconds and rules out the most common cause immediately. From there, check your mail server logs and spam quarantine before escalating to the provider. In most cases the root cause is a DNS change that propagated incorrectly or a record that got deleted during an unrelated update.
Getting MX records right the first time saves hours of troubleshooting later. Take the extra five minutes to verify with dig, confirm SPF is in place, and double-check that old records are removed. That is the complete picture for a working email setup.