Defaults.Exposed › Fixes › MX Records (Mail Setup)

How to fix MX Records (Mail Setup)

An MX record is the signpost that tells the rest of the world where to deliver email addressed to your domain. If it's missing or broken, every message sent to your business — customer enquiries, password resets, invoices, contracts — bounces straight back to the sender. No MX, no inbox.

Bottom line for your business: If your MX records are missing or wrong, your domain cannot receive email at all. Customers who write to you get an error and assume you're ignoring them or have closed down. You never even see the messages — including the deals, the invoices, and the urgent problems that needed a reply.

What this can cost you

A potential customer fills in your 'contact us' form or emails the address on your card. The message bounces. They don't try again — they go to a competitor, and you never know the enquiry existed.
A supplier emails an overdue invoice and a final notice. Both bounce silently. The first you hear of it is a service being cut off or a debt-collection letter.
You sign up for a new tool, bank portal, or government service and it sends a verification or password-reset email to your domain. It never arrives, and you're locked out of something you need today.
Email worked fine, then someone changed DNS during a website move and the MX records got dropped. For days, every email to the whole company silently vanishes before anyone notices the inbox has gone quiet.
A would-be impersonator notices your domain has no mail setup and no protection, and starts using it — because a domain nobody is watching is the easiest one to abuse.

Why it matters. Email delivery depends on a single DNS lookup: a sending mail server asks 'where do I deliver mail for this domain?' and reads the answer from your MX records. If there is no answer, or it points nowhere, the mail is rejected and bounced. This is the most basic, all-or-nothing piece of email plumbing — when it's wrong, nothing else about your email matters, because nothing arrives. (The one legitimate exception is a domain deliberately set up to receive no email at all, which has its own correct configuration.)

What MX records are, in plain words

When someone sends an email to anyone @ your domain, the sending mail server has to answer one question first: “Where do I deliver mail for this domain?” It finds the answer by looking up your domain’s MX records — short for Mail eXchange. An MX record is simply a signpost in your domain’s settings that says “send email for this domain to this mail server.”

That’s the whole job. MX records don’t store your email, they don’t protect it, and they don’t decide who’s allowed to send as you. They are the address on the envelope that tells the postal system which sorting office handles your mail. Get the address right and mail flows in. Leave it blank or point it at the wrong building and the mail comes straight back marked undeliverable.

This is the most fundamental piece of email setup there is. Every other email control — anti-spoofing, encryption, spam filtering — assumes the mail can actually reach you in the first place. MX records are what make that true.

What this can cost you

Because a broken MX record fails silently for you — you simply stop receiving mail, with no error on your end — the damage tends to be discovered late, after it’s already done. A few realistic situations:

The enquiry that never reached you. A prospect emails the address on your website. To them, the message bounces with a delivery-failure notice; to you, nothing happens at all. Most people don’t phone after a bounce — they assume you’re not interested and approach the next firm on their list. You never find out the lead existed, so you can’t even measure what it cost.
The invoice you “ignored.” A supplier sends an invoice, then a reminder, then a final notice — all bouncing. The relationship sours, a service gets suspended, or a small bill turns into a credit-control problem, all because the mail never landed in front of anyone.
Locked out of your own accounts. You try to reset a password, verify a new banking or government portal, or claim a software licence. The confirmation email is sent to your domain and vanishes. Now a routine task becomes a support-ticket ordeal at the worst possible time.
The website move that quietly killed email. A web designer moves your DNS to a new provider and copies over the website records — but not the MX records. For several days, every email to every address at your company silently disappears before anyone connects “it’s gone a bit quiet” with “our email is broken.”
Looking abandoned. A domain that can’t receive email reads, to customers and to automated trust checks alike, as a business that isn’t really operating. It erodes confidence at exactly the moment you want to look established and reliable.

None of these announce themselves. That’s what makes a missing MX record more dangerous than it sounds: by the time you notice, you’ve already lost mail you’ll never get back.

What it actually is

Your domain’s DNS settings hold several kinds of record. MX records are the ones that govern incoming email. A working setup looks like one or more entries, each naming a mail server and carrying a priority number:

The mail server name (your email provider’s “mail exchange” host).
A priority number — lower numbers are tried first. Multiple records let a provider offer fall-back servers, so mail still gets through if one is busy or down.

What “good” looks like: at least one valid MX record pointing at the mail servers of whatever email provider you actually use — Google Workspace, Microsoft 365, your web host’s mail service, or similar — with the exact server names and priorities that provider tells you to use.

The one important exception. Some domains are deliberately set up to receive no email — for example a domain used only for a website, or held purely to protect a brand. The correct way to declare that is a null MX record: a single MX record with priority 0 and a host of just a dot (.). This is a published internet standard (RFC 7505) and it’s the right answer for a non-receiving domain — senders get an immediate, clear “this domain doesn’t accept email” rejection instead of a confusing delay. On this check, a properly published null MX passes with full marks — it’s a deliberate, correct choice, not a fault. What fails is having nothing at all, which is indistinguishable from a mistake.

Why it matters to your grade. This is a scored check worth up to 25 points in the Email Security category. A domain that should receive email but has no MX records is marked as a medium-severity fail — because, in practical terms, the business behind it cannot be reached by email. A correctly receiving domain, or a correctly published null MX, earns the full points.

How to fix it (free, about 5 minutes)

Hand this to your IT person or web provider — the fix is free. MX records live in your domain’s DNS, the same place your website address is configured. Whoever manages your domain or website can do this in minutes at no cost. You only pay for the mailbox service itself, and only if you don’t already have one.

The fix depends on which of two situations you’re in.

If your domain SHOULD receive email but has no MX records

You need to point your domain at your email provider’s mail servers. Use the exact records your provider publishes — the examples below are typical, but always copy the current values from your provider’s own setup page, because they do change.

Log in to your DNS provider — wherever your domain’s settings live (for example Cloudflare, Blacknight, GoDaddy, your web host, or your registrar).
Add the MX records for your email service:

Google Workspace (current single-record setup):
- MX host: your domain → smtp.google.com, priority 1 (Older Google Workspace accounts may still use the five-server set beginning aspmx.l.google.com at priority 1 and the alt1–alt4 servers at priorities 5–10. Either is valid — match what your Google admin console shows.)
Microsoft 365:
- MX host: your domain → <your-domain-with-dashes>.mail.protection.outlook.com, priority 0 (Microsoft generates the exact hostname for you in the admin centre — copy it from there rather than guessing the format.)
Other providers (your web host’s mail, a hosted Zoho/Fastmail/etc. mailbox): copy the MX host names and priorities verbatim from that provider’s DNS-setup instructions.
Save, then wait. DNS changes take roughly 15–30 minutes to take effect (occasionally longer). Send a test email to an address at your domain and confirm it arrives.

If your domain should NOT receive any email

Publish a null MX so the “no email here” status is explicit and correct:

Log in to your DNS provider.
Add a single MX record with priority 0 and a host of just . (a single dot).
Save. Senders will now get an immediate, standards-compliant rejection, and this check will pass.

If you’re about to move DNS or hosts

Before the move, record your current MX records exactly (and your SPF, DKIM and any other mail records). After the move, re-create every one of them at the new provider with identical values and priorities, and send a test email before you call the migration finished. Forgetting the MX records during a move is the single most common way businesses accidentally take their own email offline.

Common mistakes

Leaving MX blank instead of publishing a null MX. If the domain genuinely receives no mail, say so with a null MX (0 .). Empty is ambiguous and reads as a fault; null MX is the correct, full-credit answer.
Pointing MX at the wrong thing. A surprisingly common error is an MX record aimed at your website server or a stale provider you’ve left. Mail servers will dutifully try to deliver there — and fail. Always copy the records from the provider that actually hosts your mailboxes today.
Dropping MX during a website or DNS move. The website comes back up, everyone relaxes, and email is quietly dead. Treat MX (and the other mail records) as a mandatory part of any move checklist.
Editing priorities by hand. Don’t invent or “tidy up” the priority numbers. Enter exactly what your provider specifies, including all the backup servers, so fall-back delivery keeps working.
Assuming MX protects you from spoofing. It doesn’t. MX is incoming mail only. Forgery protection is SPF, DKIM and DMARC — separate records, checked separately.

In short

MX records are the address on your email envelope. When they’re right — or correctly set to null for a non-receiving domain — mail reaches you and this check passes. When they’re missing, your business is unreachable by email and losing messages it never even sees. The fix is free, takes a few minutes, and is well worth handing to whoever manages your domain today.

FAQ

How do I even know if this is broken? My email seems fine.

If you're receiving email normally right now, your MX records are almost certainly working — this check would pass. The danger is invisible: MX records get knocked out by a website move, a DNS provider change, or a mistyped edit, and the only symptom is that incoming mail goes quiet. Because you don't get an alert when email stops arriving, businesses can lose mail for days. A free check like this one, and noticing if your inbox suddenly goes silent, are how you catch it.

We don't send or receive email on this exact domain — we only use it for our website. Is a missing MX a problem?

Not necessarily — but the correct way to say 'this domain receives no email' is to publish a special record called a null MX (an MX record of '0 .'), not to simply leave MX records out. Doing it properly means senders get an instant, clear 'this domain doesn't take email' rejection, and it actually counts as a pass on this check rather than a fail. Just leaving it blank looks like a misconfiguration. Ask your IT person to add a null MX — it's a one-line, free change.

Is fixing this going to cost me money?

No. Adding or correcting MX records is free — it's a change to your domain's DNS settings, which you already pay for as part of your domain or hosting. You only pay for the email service itself (a Google Workspace or Microsoft 365 mailbox, for example) if you don't already have one. The MX records simply point at whatever mailbox provider you use.

What does 'priority' mean on an MX record, and do I need to worry about it?

Each MX record has a number — the priority — and mail servers try the lowest number first. It exists so a provider can offer a backup server: if the main one is down, mail flows to the next. You don't normally set these yourself; you copy the exact records (including their numbers) from your email provider's setup page. Just make sure you enter them exactly as given.

Can having MX records configured stop people from forging email in my name?

No — that's a separate set of controls (SPF, DKIM and especially DMARC). MX records only handle incoming mail: where messages to you get delivered. Anti-impersonation is about outgoing mail and what receiving servers do with forgeries. You need both: MX so you can receive, and DMARC so nobody can fake your outgoing identity. They're checked separately here for that reason.

I have a website move or DNS change coming up — how do I avoid breaking email?

Before you change anything, write down your current MX records exactly (and your SPF, DKIM and any other mail-related records). When you move DNS to a new provider, the most common cause of a multi-day email outage is that only the website records get copied across and the MX records get forgotten. Re-create every MX record at the new provider, with identical values and priorities, and confirm a test email arrives before you consider the move done.