No MX Record Finding: Why Your Domain Cannot Receive E-mail

Short answer: “The domain does not receive e-mail (no MX record)” is a notice in the e-mail area of a Site AI Audit report. It means that your domain has no MX record in DNS, so mail sent to addresses at the domain has nowhere to go. If you use e-mail on that domain, add the MX records your mail provider gives you. If you do not, publish a strict SPF record so that nobody can send mail pretending to be you.

What an MX record is

When someone writes to [email protected], their mail server has to find out where to deliver the message. It asks DNS for the MX records of yourdomain.com. “MX” stands for mail exchanger. Each record names a mail server that accepts mail for the domain, with a priority number: the server with the lowest number is tried first, and the others act as fallbacks. Without any MX record, the sending server has no destination, and the message bounces or is delayed and finally returned.

Notice that MX records are separate from the website. Your website can be hosted in one place, your mail in another and your DNS in a third. That is why a perfectly working website can still have a mail problem, and why this finding belongs in a website audit: visitors write to the address on your contact page, and if it does not work, you lose the enquiry without ever knowing.

What the finding says

In the report the finding appears with the title “The domain does not receive e-mail (no MX record)” and the severity notice. The explanation is: if you use e-mail on this domain, messages to you cannot be delivered. The advice is to add MX records if the domain should receive mail, and otherwise to publish a “v=spf1 -all” record to stop spoofing.

The severity is a notice because the audit cannot know your intentions. Some domains are meant to receive no mail at all, such as a campaign site or a domain that exists only to redirect to another. For those domains, the finding is correct and nothing needs fixing. For a company domain with staff addresses, it is an emergency, even though it carries the lowest label. Read it in the light of what you expect the domain to do.

Case 1: the domain should receive mail

If you use addresses at the domain, the MX records are missing or were lost. Typical causes are:

A DNS change. You moved the domain to a new DNS provider and did not copy the records; see changing DNS provider without breaking your email.
A new website setup. A web developer replaced the DNS zone and removed the mail records.
The mail service was cancelled and the records were removed, but you still print the addresses on your site.
The records were never added when a mail provider was chosen.

Look up the correct values in the admin console of your mail provider. Google Workspace, Microsoft 365 and most hosting providers show a list of MX records with priorities. Add them to your DNS exactly as shown. Remove any old MX records that point to a service you no longer use, because a stale record can send mail to a server that discards it.

Case 2: the domain should not receive mail

If the domain never receives mail, no MX record is the right state, but there is still a risk: criminals can send e-mail that pretends to come from your domain. The audit’s suggestion is a strict SPF record with the value “v=spf1 -all”, which says that no server is allowed to send mail for this domain. Combined with a DMARC record, it shows receivers that mail from this domain is always fake. There is also a standard way to declare a domain that does not receive mail, the null MX record, which tells senders at once that delivery is impossible instead of waiting and trying; read about it in null MX records.

How to add MX records correctly

Get the exact values from your mail provider. They give a server name and a priority for each record.
Add one MX record per value. The host or name field is usually “@” or empty, which means the root of the domain.
Use host names, not IP addresses, and make sure the names end correctly according to your DNS panel’s rules.
Remove old records from previous providers.
Wait for DNS to update, then send a test message from an outside address and confirm that it arrives. The article on DNS propagation and TTL explains how long to wait.
Run the audit again. The notice should disappear.

Be careful with a backup mail server. A secondary MX that does not accept mail properly can cause more harm than good, a point covered in the guide to backup MX servers.

What changes once you have MX records

An MX record opens the door to the other e-mail checks. When the domain has MX records, the audit also looks for DKIM keys and may raise the DKIM notice, as the article on the DKIM key not found finding explains. It also evaluates your SPF and DMARC records. In other words, the MX record is the starting point of e-mail health. Once mail is delivered, make sure that your SPF record lists the servers that send for you and that you publish DMARC; the guide to fixing a missing DMARC record is a good next step.

Autodiscover and other helper records

MX records are the essential part, but mail setups also use helper records that make it easy for people to set up their mail programs. If staff cannot add their account on a phone automatically, a missing autodiscover or autoconfig record is a likely reason; the article on autodiscover and autoconfig DNS records covers them. These records are not part of the audit’s findings, but they are worth adding while you are editing DNS anyway.

Test before and after you change anything

Mail problems are easier to solve when you know the starting point. Before you edit DNS, send a message to your address from an outside account and note what happens: does it arrive, bounce or vanish? Save the bounce message, because it usually names the reason, such as “no MX found” or “domain not found”. After the change, repeat the test. This two-step habit turns a vague report of “mail does not work” into a clear cause and effect that you can show to your provider.

Subdomains and mail

The audit checks the main domain. If you use mail on a subdomain, such as a sub.yourdomain.com address for a department, it needs its own MX records. A main domain with working mail does not make a subdomain receive mail. Keep a short list of every name that should receive mail, so that when you change providers you can check each one rather than only the main address.

What bounce messages tell you

If senders report bounces, the text of the bounce is worth reading. A message saying the domain has no mail servers or that no MX was found points directly at this finding. A message about a full mailbox or an unknown user points at the mailbox instead, not the domain, and is a different problem. The article on mailbox full bounces shows how to tell the two apart. Knowing which kind of bounce you have saves time, because the fix for one does nothing for the other.

A worked example

An architecture studio rebuilds its website with a new developer, who also moves the DNS to the hosting company that runs the new site. Two weeks later a client mentions that he got a bounce message when he wrote to the studio. The partner runs a Site AI Audit check, and the report shows the notice about no MX record. In the move, the old mail records had not been copied. She looks up the values in the admin console of the studio’s mail provider, adds three MX records with their priorities and sends a test message from her private address. It arrives within minutes. She asks the client to write again, and she adds a note to the studio’s checklist: after any DNS move, send a test mail and run a check.

Without the report, the problem might have continued for weeks, because nothing on the website itself had changed. To check where your own domain’s mail is routed, check your website with Site AI Audit. The check needs a free account; the plans unlock the full report.

The bottom line

No MX record means nobody can send mail to your domain. If you use the addresses, copy the MX records from your mail provider into DNS and test with a real message. If you do not, publish a strict SPF record so the domain cannot be used for spoofing.

FAQ

Is a missing MX record always a problem?

No. Domains that do not receive mail, such as redirect-only domains, do not need one. For them the finding is informational.

How many MX records should I have?

As many as your mail provider tells you to add, usually two to five, with different priorities.

Can I use an IP address in an MX record?

No. MX records must point to a host name, which then resolves to an address.

How long until new MX records work?

Often within minutes, but it can take longer depending on the time to live of the old records. Test with a message from an outside address.

Why does the audit care about mail on a website check?

Mail problems cost enquiries and orders, and they are invisible on the website itself. A check from the outside is the easiest way to find them.