Website Works but Domain Email Does Not: DNS Checks

Your website loads perfectly. Visitors browse it without a hitch. But emails sent to you@yourdomain.com never arrive — no bounce message, no error, just silence. Frustrating? Absolutely. But here's the good news: this is almost always a DNS problem, and it's almost always fixable in a few minutes.

The key thing to understand is that your website and your email are directed by different DNS records. Your website can be perfectly configured while your email records are missing, wrong, or pointing at an old provider. This guide shows you how to check your MX records (the records that route incoming email), identify the exact cause, and fix it yourself.

The Quick Answer: Email and Websites Use Different DNS Records

Think of DNS as the internet's address book for your domain. Different entries in that address book handle different jobs:

• A records tell browsers where your website lives (they map your domain to a server's IP address).
• MX records tell mail servers where your email lives (they map your domain to the servers that accept mail for you).

These are completely independent. Changing your website's A record — moving your site to a new host, for example — does nothing to your MX records. And that's exactly why your website can work flawlessly while email to the same domain quietly fails: the email entries are broken even though the website entries are fine.

If you remember nothing else from this article, remember this: website working + email broken = check MX records first.

MX Records Explained in Plain English

What an MX record does

When someone sends an email to you@yourdomain.com, their mail server doesn't guess where to deliver it. It asks your domain's DNS: "Who handles mail for this domain?" The answer comes from your MX (Mail Exchange) records.

An MX record has three parts:

1. The host — usually @, meaning the record applies to the domain itself (yourdomain.com).
2. The priority — a number like 0, 5, 10, or 20.
3. The target — a hostname (like mail.yourdomain.com or yourdomain-com.mail.protection.outlook.com) where mail should be delivered.

Priority values: lower number = tried first

You can have more than one MX record. Each gets a priority number, and sending servers try the lowest number first. If that server doesn't answer, they try the next-highest. This is how email redundancy works: many organizations list a primary mail server (priority 10) plus a backup (priority 20) that queues mail if the primary is down.

Important detail from Microsoft's official DNS guidance: if you keep old MX records from a previous provider alongside your new ones, mail gets split between the two — some messages go to the new provider, some to the old. Always delete MX records you no longer need.

A healthy MX setup vs a broken one

Healthy:

• At least one MX record exists for your domain.
• Every MX record points to a hostname, not an IP address (the standard forbids IPs in MX targets).
• The hostname in each MX record resolves to a real mail server.
• No leftover MX records from previous providers.
• The mail hostname is not proxied through a CDN like Cloudflare (more on this below).

Broken (common patterns):

• No MX records at all — mail servers find nobody to talk to, and messages bounce or vanish.
• MX records still point to the old host after you switched email providers.
• The MX target is an IP address instead of a hostname.
• You recently changed MX records and DNS hasn't finished propagating yet.

How to Check Your MX Records in 2 Minutes

Before changing anything, look at what your DNS actually says right now. Any of these methods works:

Method 1: Online MX lookup (no commands needed)

The easiest option, especially if you're not comfortable with the command line:

1. Open an online DNS lookup tool such as MXToolbox's MX lookup or Google Admin Toolbox's Dig.
2. Type your domain name (just yourdomain.com, no www).
3. Select MX as the record type and run the check.

You'll get a list of your MX records with their priority values and targets. If the list is empty, you've found your problem: no MX records exist.

Method 2: nslookup (Windows)

1. Open Command Prompt (press Win + R, type cmd, hit Enter).
2. Type: nslookup -type=mx yourdomain.com and press Enter.
3. You'll see the mail exchanger entries and their preferences (priorities).

Method 3: dig (macOS / Linux)

1. Open Terminal.
2. Type: dig yourdomain.com MX +short and press Enter.
3. Each line of output is one MX record: priority number followed by the target hostname.

How to read the result

A healthy result looks something like:

`` 10 mail.yourdomain.com 20 backup.mailprovider.com ``

Each line = one MX record. Lower number = tried first. If you see records pointing at hostnames you don't recognize — especially ones belonging to a hosting company you left months ago — those are leftovers that need deleting.

If you get no results at all, your domain has no MX records, and no mail server on the internet knows where to deliver your email. That's your answer — skip to the fix section.

The 6 Most Common Causes

1. No MX records exist at all

This happens more often than you'd think. Some domain registrations and DNS setups include a website A record by default but no email records — nobody told the internet where your mail should go. Sending servers look up your MX records, find nothing, and the message bounces back to the sender with an error like "no mail server for this domain."

2. Leftover MX records pointing to the old provider

You switched email providers — say from your web host's built-in email to Google Workspace or Microsoft 365 — but the old MX records were never deleted. Now some senders' servers hit the new records and deliver correctly, while others hit the old ones and deliver to a mailbox you no longer check (or that no longer exists). The symptom is maddening: some email arrives, some vanishes.

Fix: Remove every MX record that doesn't belong to your current email provider. Keep only the records your current provider gave you.

3. MX record points to an IP address instead of a hostname

MX targets must be fully qualified hostnames (like mail.yourdomain.com), never raw IP addresses (like 192.0.2.44). This is a hard requirement of the DNS standard, and sending servers may refuse to deliver when it's violated. If you see an IP address in the target field of an MX record, replace it with the correct hostname from your email provider.

4. DNS propagation — you just changed the records

DNS changes don't take effect everywhere instantly. After you add or change MX records, the update has to spread across DNS servers worldwide — this is called propagation, and it can take anywhere from a few minutes to 48–72 hours (though it's usually much faster in practice).

If you changed your MX records recently and email is still misbehaving, wait before panicking. Send a test email from an outside account (not from your own domain) after a few hours and check again. Microsoft's own documentation notes the up-to-72-hour window, while most changes settle far sooner.

5. The mail hostname is proxied (the Cloudflare trap)

This is the single most common cause of "email broke right after I set up Cloudflare." Here's what happens:

• Your MX record points to a hostname like mail.yourdomain.com.
• In Cloudflare, that hostname's A record has the orange cloud (proxied) enabled.
• Cloudflare's proxy only handles web traffic (HTTP/HTTPS). It does not proxy email protocols (SMTP, IMAP, POP3).
• Result: incoming mail servers connect to Cloudflare's IP addresses instead of your real mail server, and delivery fails.

Fix (from Cloudflare's official troubleshooting docs): In your Cloudflare DNS dashboard, find the A record for your mail hostname and switch it to DNS only (grey cloud). The MX record itself is always DNS-only — but the hostname it points to must also resolve to a non-proxied address. Your website's A record can stay proxied; only the mail hostname needs to be DNS-only.

6. The MX hostname doesn't resolve (missing A record)

Your MX record points to mail.yourdomain.com, but that hostname has no A record — DNS lookups for it return nothing. The mail server has an address label with no street behind it. This often happens when someone deletes the mail A record during a DNS cleanup, or sets up MX records at a new DNS provider without recreating the supporting records.

Fix: Add an A record for the mail hostname pointing to your mail server's IP address (your email provider or host can tell you the correct IP).

Step-by-Step: Fixing Your MX Records

Work through these in order. Most email failures are resolved by step 3.

Step 1: Confirm where your DNS is managed

Your DNS might be managed at your domain registrar, your web host, or a service like Cloudflare. Changes must be made wherever the authoritative nameservers point — editing records at the wrong provider does nothing. If you're not sure, check your domain's nameservers (an online WHOIS/RDAP lookup shows them) — the company running those nameservers is where your DNS lives.

Step 2: Find the correct MX values from your email provider

Your email provider — whether it's Google Workspace, Microsoft 365, your web host, or anyone else — publishes the exact MX records you need. This is always documented in their setup guides (Microsoft, for example, lists the MX target, priority, and a 3600-second TTL in its official "Add DNS records" documentation). Copy these values exactly; a single typo breaks delivery.

Step 3: Delete the wrong records, add the right ones

In your DNS manager:

1. Delete all existing MX records that don't match your current provider.
2. Add the new MX record(s) exactly as your provider specifies: correct type (MX), host (usually @), priority, and target hostname.
3. Double-check that no stray records remain.

Step 4: Wait for propagation, then test from an outside account

Give DNS time to propagate (a few hours is usually enough; up to 72 in rare cases). Then send a test email from an account outside your domain — Gmail, Outlook.com, anything not on your own domain. Internal test emails can take shortcuts that mask real problems. If the test arrives, you're fixed.

Common Gotchas

Your website and email can (and often do) live in different places

There's no rule that says your website host and your email provider must be the same company. It's completely normal — and often smart — to host your website with one provider and use Google Workspace or Microsoft 365 for email. The DNS records simply point each service at its own home. When troubleshooting, don't assume changing one affects the other.

Sending works but receiving doesn't — different records, different problem

Receiving email depends on your MX records. Sending email depends on your mail server's configuration plus SPF, DKIM, and DMARC records (which prove your mail is legitimate). If you can send but not receive, focus on MX. If you can receive but your sent mail lands in spam, that's an authentication problem — a different fix entirely.

One stray old MX record can split your mail in two directions

This deserves repeating because it's the sneakiest failure mode: with old and new MX records both present, there's no error message and no bounce — mail just silently goes to two different places, and you only ever see half of it. After any provider switch, audit your MX records and keep only the current provider's entries.

Frequently Asked Questions

My website works fine — does that mean my DNS is okay?

Not for email. Your website uses A records; your email uses MX records. They're independent. A perfectly working website tells you nothing about your mail configuration — always check MX records separately when email fails.

How do I check my MX records?

Use an online MX lookup tool (easiest), or from a terminal run nslookup -type=mx yourdomain.com on Windows or dig yourdomain.com MX +short on macOS/Linux. You're looking for at least one MX record pointing to a hostname your email provider gave you.

I just changed my MX records. How long until email works?

DNS propagation typically takes minutes to a few hours, but can take up to 48–72 hours in rare cases. Test by sending an email from an outside account (like Gmail) after a few hours. If it still fails after 72 hours, the records themselves are likely wrong — recheck them against your provider's documentation.

Can I use Cloudflare and still receive email?

Yes — this is a very common setup. The rule from Cloudflare's own documentation: MX records are always DNS-only, and the hostname your MX points to (e.g. mail.yourdomain.com) must also be set to DNS only (grey cloud), because Cloudflare's proxy doesn't handle email protocols. Your website's records can stay proxied.

I switched email providers and now only some emails arrive. Why?

You almost certainly have leftover MX records from the old provider mixed with the new ones. Sending servers pick among all listed MX records, so mail gets split between the old and new destinations. Delete every MX record that doesn't belong to your current provider.

Why do I need to test from an outside email account?

Emails sent from within your own domain (or your own mail server) can bypass the public MX lookup entirely — your server may deliver them internally without ever consulting DNS. A test from Gmail or another external provider exercises the real public path and shows you what the rest of the world experiences.

Still stuck after checking your MX records? Send a test email from an outside account first — if it arrives, your DNS is fine and the problem lies elsewhere (spam filters, mailbox full, or authentication). If it doesn't arrive after the full propagation window, take your MX lookup results to your email provider's support team; those results tell them exactly where to look. For the bigger picture on getting your domain set up right from the start, see our domain registration guide.