Incoming email and Null MX diagnostics
Null MX conflicts with ordinary MX records
A lone MX 0 . is a valid way to declare that a domain accepts no email. Trouble starts when that declaration contradicts the domain's intended use or appears beside ordinary MX records.
A domain expected to receive email publishes a Null MX record, sometimes together with normal mail exchangers.
example.com. 300 IN MX 0 . example.com. 300 IN MX 10 mail.example.net.
Run this automated test on my domain
Enter your domain. MailFixIt checks the relevant DNS records automatically and shows the evidence.
What Null MX means
RFC 7505 defines a single MX record with preference zero and target . as an explicit statement that a domain does not accept email. It is useful for web-only and defensive domains because senders can fail delivery immediately instead of trying an address fallback.
A Null MX record must stand alone. Combining it with ordinary MX targets creates contradictory routing data: one record says there is no mail service while another advertises one.
What the check does and does not prove
MailFixIt reads the public MX set and considers whether you said the domain should receive mail. It reports mixed Null MX and ordinary MX as a conflict and can flag a lone Null MX when the form explicitly says the domain receives mail.
The check cannot determine business intent without that input, confirm mailbox existence, or test whether an advertised server accepts SMTP.
Possible diagnostic results
Intentional Null MX
A single 0 . record is valid when the domain deliberately accepts no mail. No repair is required.
Conflicting MX set
Null MX and ordinary exchangers coexist. Remove the declaration that does not match the domain's intended mail behavior.
Mail expected but disabled
The domain is marked as receiving mail while publishing only Null MX. Obtain the actual provider MX records before editing.
No explicit MX
This is not equivalent to Null MX. SMTP may fall back to address records, so review the intended configuration separately.
How to fix a Null MX conflict
- Decide whether the domain should receive messages at addresses such as
user@example.com. - If it should receive mail, obtain the exact MX targets and priorities from the receiving provider.
- Remove the Null MX record and publish only the provider-approved MX set.
- If it should not receive mail, remove ordinary MX targets and retain one standards-compliant
MX 0 .. - Recheck public DNS before testing delivery.
The target below is fictional. Use the value issued by your provider.
Before: example.com. MX 0 . example.com. MX 10 old-mail.example.net. After: example.com. MX 10 inbound.provider.example.
Rollback by restoring the exact exported MX set if the new receiver is not ready. Do not combine the previous Null MX with the new target.
Verify the repair
Confirm that public DNS returns either one Null MX record or the complete ordinary provider set, never both. For receiving domains, send a controlled external message and keep any SMTP rejection text for deeper diagnosis.
Frequently asked questions
Is a single Null MX record an error?
No. A lone MX record with preference 0 and target . is a valid declaration that the domain does not accept email. It is a problem only when the domain is meant to receive mail or when ordinary MX records are published alongside it.
Does a domain without MX records always reject email?
Not necessarily. SMTP has implicit fallback behavior to an address record when no MX exists. Null MX explicitly states that the domain accepts no email and avoids that ambiguity.
Related email diagnostics
Primary sources: RFC 7505: Null MX, RFC 5321: locating the target host.