dotvitals

Domain publishes a null MX (receives no mail)

InfoConfirmedemail.mx.null-mx

What this check looks for

Your domain explicitly declares that it does not accept email. That is a valid and useful configuration for a domain that only hosts a website.

Why it matters

A null MX makes rejection immediate and explicit rather than leaving senders to time out, and it discourages the domain being used as a forged return address.

What it costs your score

This check never deducts. It reports a fact — or reports that something could not be verified — and is shown on the report without moving the score.

Severity
info
Default confidence
confirmed
Status when triggered
info
Deduction
0 points
Family cap
none
Category
Email transport
Module
Email mx
Fix owned by
dns host
In the ruleset since
2026.09

How the whole score is calculated

How to fix it

Nothing to do, unless you intended this domain to receive mail.

A null MX is the correct configuration for a domain that does not handle email.

  1. If the domain should receive mail, replace the null MX with your provider's MX records.

  2. Consider also publishing v=spf1 -all and a DMARC record at p=reject so the domain cannot be forged.

How to confirm it worked

  • dig +short MX ‹domain› — expect '0 .' for a null MX

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Technical detail

‹domain› publishes a single MX record with preference 0 and a target of ., the null MX of RFC 7505. Senders reject the message at submission time with a 5xx. Because no mail is sent from this domain either, the email authentication checks below are reported as not applicable rather than as failures.

Standards and references

Test this on your domain

Run the check that produces this finding, on its own, against any domain.

Open the email mx checker

Other email mx checks