How to Add MX Records: Step-by-Step Guides for Every DNS Host

Adding MX records is one of those tasks that's simple in theory but surprisingly easy to get wrong in practice. Every DNS host has a different interface, different terminology, and different quirks. A typo in a hostname, a record added in the wrong place, or a forgotten priority value can silently break email delivery.

This page covers the universal process, the mistakes that trip people up most often, and links to step-by-step guides for every major registrar and DNS provider. If you need to know which MX records to add (the actual hostnames and priorities for your email provider), see MX Records by Email Provider first. For the broader context on how MX records work, see the Complete Guide to MX Records.

Before You Start

Before touching your DNS settings, gather three pieces of information:

1. Your email provider's MX records

Every email provider publishes the exact MX record values you need. You'll need the priority value and mail server hostname for each record. For example, Google Workspace requires five records:

While Microsoft 365 requires just one:

Don't guess. Get the exact values from your provider's documentation or admin panel. See MX Records by Email Provider for the values for every major provider.

2. Where your nameservers point

This is the most common source of confusion. You add MX records at your registrar, but email doesn't work, because your nameservers actually point to Cloudflare, and your registrar's DNS is being ignored entirely.

Check where your nameservers point:

Using dig:

dig ns yourdomain.com +short

Using nslookup:

nslookup -type=ns yourdomain.com

If the nameservers belong to your registrar (e.g. ns1.godaddy.com), manage DNS at your registrar. If they point somewhere else (e.g. ns1.cloudflare.com), manage DNS there instead. Records added at any other provider will be completely ignored.

3. Your current MX records (if any)

Before making changes, document what's currently configured. Run an MX lookup on your domain to see existing records. You'll need this if something goes wrong and you need to roll back, or if you're switching providers and need to know which old records to remove.

The Universal Process

Regardless of which DNS host you use, adding MX records follows the same pattern. The interfaces differ, but the steps are the same:

Common Pitfalls and How to Avoid Them

These mistakes cause the most trouble. Every one of them is something we see regularly from people adding MX records for the first time (and sometimes the tenth time).

Adding records in the wrong place

The problem: You add MX records at your domain registrar, but your nameservers point to Cloudflare (or another DNS provider). The records at your registrar are completely ignored.

How to avoid it: Always check your nameservers first. The authoritative DNS provider (the one your nameservers point to) is where DNS records matter. Everything else is irrelevant.

How to tell: Run dig ns yourdomain.com or use any WHOIS lookup. If the nameservers say cloudflare.com, manage DNS at Cloudflare. If they say godaddy.com, manage DNS at GoDaddy. The registrar and the DNS provider aren't always the same company.

Typos in hostnames

The problem: aspmx.l.google.com vs aspmx.i.google.com. One character difference, a lowercase L vs a lowercase I. The first is correct; the second points to nothing. Email bounces with a cryptic hostname resolution error.

How to avoid it: Never type MX hostnames manually. Always copy-paste from your email provider's documentation. If you're reading from a guide, copy from the guide. If you're reading from your provider's admin console, copy from there. Character-by-character verification is unreliable, as our eyes are bad at distinguishing similar characters in monospace fonts.

Wrong record type

The problem: You create an A record or a TXT record when you meant to create an MX record. Some DNS interfaces default to A records, and it's easy to miss the type dropdown.

How to avoid it: Before saving, explicitly verify the record type says "MX". Some interfaces show the type prominently; others hide it. If your newly added record doesn't appear in the MX section of your DNS dashboard, check whether it accidentally ended up as a different record type.

Trailing dot confusion

The problem: In DNS zone files, hostnames end with a trailing dot (mail.example.com.). This dot indicates the hostname is fully qualified. Some DNS management interfaces expect this dot, others add it automatically, and some will break if you include it, creating a record pointing to mail.example.com.. (double dot, which resolves to nothing).

How to avoid it: Check your DNS host's documentation or help text. If you're unsure, try without the trailing dot first, as most modern DNS management interfaces handle this automatically. After saving, run an MX lookup to verify the record looks correct.

Forgetting the priority

The problem: Every MX record needs a priority value. If your DNS host has a separate priority field and you leave it blank, the priority might default to 0, which is the highest priority. If you're adding a backup server, it accidentally becomes the primary.

How to avoid it: Always fill in the priority field explicitly. Use the exact values from your email provider's documentation. If your provider says priority 10, enter 10. Don't leave it at whatever default the interface provides. See MX Record Priority Explained for more on how priority values work.

Not removing old records

The problem: You switch from Google Workspace to Microsoft 365 but leave Google's MX records in place alongside Microsoft's. Now some sending servers deliver to Google (which no longer has your mailbox) and others deliver to Microsoft (which does). Email arrives unpredictably: you get some messages but miss others.

How to avoid it: When switching providers, delete all old MX records before adding new ones. After adding the new records, run an MX lookup and verify that only your new provider's records appear. There should be zero records pointing to your old provider.

Using IP addresses instead of hostnames

The problem: MX records must point to hostnames, not IP addresses. Entering 10 192.168.1.100 instead of 10 mail.example.com violates RFC 5321. Some mail servers will reject the record entirely; others will silently fail to deliver.

How to avoid it: Always use a fully qualified domain name. If you're setting up a self-hosted mail server, create an A record for your mail server hostname first (e.g. mail.example.com → 192.168.1.100), then create the MX record pointing to that hostname (e.g. priority 10 → mail.example.com).

Guides by DNS Host

Currently Available

These step-by-step guides walk through the exact interface for each DNS provider, including screenshots-worth of detail about where to click and what to enter.

Add MX Records in Cloudflare: Cloudflare's DNS interface is one of the cleanest and most straightforward. Records propagate almost instantly since Cloudflare serves DNS directly. Key detail: MX records are never proxied (orange cloud doesn't apply), so don't worry about the proxy toggle for mail records.

Add MX Records in GoDaddy: GoDaddy's DNS management has been redesigned several times. The current interface puts DNS under Domains → your domain → DNS. The guide covers the current layout, including how to handle GoDaddy's email forwarding settings that can conflict with custom MX records.

Add MX Records in Namecheap: Namecheap has its own email forwarding service and "Email Hosting" section that can interfere with custom MX records. If you're using a third-party email provider, you need to set the Mail Settings to "Custom MX" first. Otherwise, Namecheap will override your MX records with their own.

Coming Soon

Detailed step-by-step guides for these hosts are in progress:

In the meantime, the universal process above works for all of these hosts. The steps are the same; just the interface differs. The most important thing is making sure you're editing DNS at the right provider (where your nameservers point).

Specific Scenarios

Cloudflare Proxy and MX Records

If you use Cloudflare as your DNS provider with the HTTP proxy enabled (orange cloud icon), you might wonder how this affects MX records. The answer: it doesn't.

MX records are never proxied through Cloudflare. They always resolve directly to the IP address of your mail server. This is correct and expected, since email uses SMTP (port 25), not HTTP (ports 80/443), and cannot pass through Cloudflare's HTTP proxy. When you see MX records in Cloudflare's dashboard, they won't have a proxy toggle. They're always "DNS only" (grey cloud). See Cloudflare's DNS documentation for details.

This also means Cloudflare's DDoS protection doesn't apply to your mail server. Your mail server's IP address is visible in your MX records. If DDoS protection for your mail server is a concern, you'll need a separate solution (like a mail proxy service).

Registrar vs External DNS

A domain's registrar and its DNS provider can be different companies. This is common: many people register domains at GoDaddy or Namecheap but point nameservers to Cloudflare for DNS management.

When these are different, only the DNS provider's records matter. Adding MX records at your registrar when nameservers point elsewhere is the #1 reason for "I added the records but nothing happened."

Here's how to tell:

1. Run dig ns yourdomain.com +short to see your nameservers
2. If the nameservers match your registrar (e.g. ns1.godaddy.com), manage DNS at the registrar
3. If the nameservers are different (e.g. ns1.cloudflare.com), manage DNS at that provider instead

If you're not sure which company owns the nameserver hostnames, search for the nameserver domain. It usually makes the provider obvious.

Multiple Domains

If you manage email for multiple domains (common for agencies, IT departments, and businesses with multiple brands), each domain needs its own MX records configured independently. There's no way to share MX configuration across domains in DNS.

This means if you manage 50 domains, you need to add MX records 50 times. And if your email provider changes their MX records (rare but it happens), you need to update all 50 domains.

This is where monitoring becomes essential. You can't manually check 50 domains regularly enough to catch problems. Automated monitoring checks every domain daily and alerts you when something changes. See MX Record Checker for Agencies and MX Record Checker for IT Administrators for multi-domain workflows.

Subdomains

Subdomains do not inherit MX records from the parent domain. If you have MX records for example.com and someone sends email to user@support.example.com, it will bounce, because support.example.com has no MX records of its own.

If you need email at a subdomain, create MX records for that subdomain specifically. They can point to the same mail servers as the parent domain (if your email provider supports it) or to different servers entirely.

One exception: wildcard MX records (*.example.com) can catch email for all subdomains. But wildcards are rarely used for MX records because they apply to every subdomain indiscriminately, including ones you might not want receiving email.

See MX Records for Subdomain Email for detailed instructions.

Self-Hosted Mail Servers

If you're running your own mail server (Postfix, Exim, hMailServer, etc.) rather than using a hosted provider, the MX record setup is similar but you control the hostnames:

1. Create an A record for your mail server: mail.yourdomain.com → your server's IP address
2. Create an MX record: priority 10 → mail.yourdomain.com
3. If you have a backup server, create a second A record and MX record with a higher priority number

Make sure port 25 is open on your server's firewall and that your hosting provider allows inbound SMTP traffic. Many cloud providers block port 25 by default and require you to request an exception.

After Adding MX Records

Adding the records is only half the job. Here's what to do next:

1. Wait for DNS propagation

DNS changes don't take effect instantly. Depending on your TTL settings and how long ago the old records were cached, propagation can take anywhere from a few minutes to 48 hours. For most changes with a reasonable TTL, expect 15-60 minutes.

Don't panic if records don't appear immediately after saving. Check back in 15 minutes, then 30, then an hour. If records still aren't visible after 2 hours, something is likely wrong. Recheck your nameservers and record configuration.

See MX Record Propagation for detailed timing and how to speed it up.

2. Verify with a lookup

Use our MX Record Checker to confirm your records are visible globally. Check that:

• All expected records appear (e.g. all five for Google Workspace)
• Priority values are correct
• Hostnames are spelled correctly (character by character)
• No stale records from a previous provider remain

3. Send test emails

Verification from DNS alone isn't enough. You need to confirm end-to-end delivery. Send a test email from an external account (Gmail, Outlook.com, or any account not on your domain) to an address at your domain. Check that it arrives. Then reply to confirm outbound also works.

If the email doesn't arrive, check your mail server's logs and your spam folder. If it bounces, the bounce message usually explains exactly what went wrong.

4. Set up monitoring

Don't rely on manual checks going forward. DNS records can change unexpectedly due to accidental edits, expired domains, provider issues, or even malicious tampering. Automated monitoring checks your records daily and alerts you the moment something changes, so you can fix problems before they affect email delivery.

References

• RFC 5321: Simple Mail Transfer Protocol - Defines SMTP delivery and the requirement that MX records point to hostnames, not IP addresses
• RFC 1035: Domain Names - Implementation and Specification - Defines the DNS record format, including MX records and trailing dot conventions
• Google Workspace MX record values - Official Google MX setup documentation
• Microsoft 365 DNS records - Official Microsoft 365 DNS configuration guide
• Cloudflare DNS documentation - How to create and manage DNS records in Cloudflare