mx.null_mx Reviewed July 2026

Quick fix

Decide whether the domain must receive email.

What this finding means

A valid Null MX consists of exactly one MX record with preference 0 and target `.`. It explicitly states that the domain does not accept email. SecuTest flags a Null MX mixed with regular MX records, duplicated, or otherwise malformed.

Interpretation boundary Use the exact evidence in your report. SecuTest reports externally observable conditions; it does not assume ownership, exploitability, compromise, or business intent when those cannot be proven remotely.

Associated attack or threat scenario

Threat type Mail routing ambiguity and unintended mail acceptance

How the attack or failure scenario works

Null MX prevents senders from attempting implicit delivery to the domain's A or AAAA address. When it is mixed with normal MX records or published incorrectly, different senders may choose different behaviors. This is a configuration weakness, not a direct vulnerability, but it can create backscatter, delivery failures, or accidental exposure of a web host to SMTP traffic.

Conditions and limitations

  • The domain publishes a malformed, duplicated, or mixed Null MX configuration.
  • Sending systems encounter conflicting routing data.
  • Abuse impact is higher when an unintended host listens on SMTP or operational teams assume the domain cannot receive mail.

Why it matters

Security and business impact An invalid or mixed Null MX declaration creates contradictory mail-routing instructions and can cause delivery failures or unintended fallback behavior.

Step-by-step fix

Where to make the change

  • The authoritative DNS zone for the registrable domain.
  • The outbound or inbound mail platform when sender authorization, signing, or routing is involved.
  • The DMARC reporting mailbox or reporting service when aggregate reports are required.

Remediation procedure

  1. Decide whether the domain must receive email.
  2. If email is not accepted, remove every normal MX record and publish exactly `0 .`.
  3. If email is accepted, remove the Null MX and publish only the provider's required MX records.
  4. Confirm that no application, website, or certificate workflow depends on receiving mail at the domain before enabling Null MX.

Commands and configuration examples

Replace example values with the hostname, selector, IP address, port, provider, or policy values shown in your SecuTest evidence. Review every example before production use.

Valid Null MX
example.com. 3600 IN MX 0 .

Inspect configuration
dig +short MX example.com

Verify the fix

  1. Run `dig +short MX example.com` and confirm the output is either one `0 .` record or only regular MX records.
  2. For a Null MX domain, verify that TCP port 25 is not intentionally exposed and that external senders return a permanent no-service result.
  3. For a mail-enabled domain, send an external test message and inspect the receiving platform logs.
  4. Re-scan after DNS TTL expiry.
Confirm the externally visible result

After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.

Re-scan your domain

Common mistakes

  • Publishing `0 .` alongside Microsoft 365, Google Workspace, or another mail provider.
  • Using `0 example.com.` and assuming it is equivalent to Null MX.
  • Enabling Null MX on a domain used for password resets, abuse contacts, or automated replies.

Authoritative references