The fix, in one snippet
dig +short MX example.comIllustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now queries the MX records of the registrable domain and lists each host with its priority. It then resolves every MX hostname to A or AAAA records and reports hosts that do not resolve, hosts that point to private or loopback addresses, and MX targets that are CNAMEs, which RFC 2181 section 10.3 prohibits and some senders reject. A single record of 0 . is recognised as a Null MX (RFC 7505), meaning the domain deliberately accepts no mail, and passes with a note. A domain with no MX records at all is flagged as informational: RFC 5321 section 5.1 says senders then fall back to the domain's A record, so mail attempts go to your web server. The report identifies the provider from well-known hostnames (Google, Microsoft 365, Proton, Zoho, Fastmail) for orientation. Scan.now performs DNS lookups only and never connects to port 25.
Why it matters
Mail delivery follows MX records blindly, so an error there is either an outage or a takeover. An MX pointing at a hostname that no longer resolves loses mail silently; an MX pointing at a domain that has expired is worse, because whoever registers that domain receives your mail, including password-reset messages for every service tied to addresses at your domain. Records left over from a previous provider are a common cause. The "no MX" state has its own problems: fallback-to-A means senders try your web server on port 25, which is at best noise and at worst an open relay if something answers. A domain that does not use email should say so explicitly with a Null MX and a v=spf1 -all SPF record, so that spoofers cannot use it and bounces are immediate. The SPF, DKIM and DMARC guide covers the records that go with MX.
How to fix it
Publish MX records exactly as your provider documents them, pointing at hostnames (never IP addresses, never CNAMEs). Google Workspace now uses a single record:
example.com. IN MX 1 smtp.google.com.Microsoft 365:
example.com. IN MX 0 example-com.mail.protection.outlook.com.A domain that sends and receives no mail:
example.com. IN MX 0 .
example.com. IN TXT "v=spf1 -all"
_dmarc.example.com. IN TXT "v=DMARC1; p=reject"In the Cloudflare DNS dashboard, MX records are always "DNS only" (they cannot be proxied); if the target is a host you run yourself, make sure its A record is also unproxied, since Cloudflare's HTTP proxy does not carry SMTP. Remove records for providers you have left. Verify:
dig +short MX example.com
dig +short A smtp.google.comIf the domain runs its own mail server, publish an SPF record listing it, set up DKIM signing, and review the DNSSEC and CAA checks, which also protect the mail host's certificate.
Where this fits
MX records is check 8 of 8 that the website vulnerability scanner runs under dns and email authentication, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits DKIM selector discovered (info), where no DKIM public key was found under the common selector names, or the key found is weak or revoked. An attacker who has that does not need this, so it is the better use of the same hour.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Certificate chain and hostname validation, where the certificate presented for this hostname did not validate: The chain does not reach a trusted root, an intermediate is missing, the name does not match, or the certificate is self-signed or expired, and Exposed .env configuration file, where a .env configuration file is served from the web root. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: MX records (info severity)
Scanner check id: mx-recordsThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
