MX Presence & Hygiene

This is the scored MX check (the DNS-category MX record check is informational only). It rewards being explicit about whether your domain receives mail. There are two correct postures, both worth full credit: publish real MX records, or publish a null MX. The only state that loses points is having neither, because absence is ambiguous and triggers an RFC 5321 implicit fallback to your A or AAAA records on SMTP port 25.

How the verdict maps to evidence

• Pass: at least one non-null MX record. Your domain is treated as receiving inbound mail, and the rest of Email Security (SPF, DMARC, MTA-STS, TLS-RPT, DKIM) runs against it.
• Pass: only a null MX (RFC 7505: priority 0, hostname .). Your domain explicitly does not receive mail. Inbound checks are marked not applicable because they cannot apply.
• Warn: no MX records of any kind. Partial credit. Publishing either real MX records or a null MX moves you to full credit.

Path 1: you receive mail. Publish real MX records

Use the records your mail provider documents (Microsoft 365, Google Workspace, Fastmail, ProtonMail, Zoho, your own MTA, etc.). Each provider supplies its own hostnames and recommended priorities; do not invent your own.

yourdomain.tld.   IN  MX  1   aspmx.l.google.com.
yourdomain.tld.   IN  MX  5   alt1.aspmx.l.google.com.
yourdomain.tld.   IN  MX  5   alt2.aspmx.l.google.com.
yourdomain.tld.   IN  MX  10  alt3.aspmx.l.google.com.
yourdomain.tld.   IN  MX  10  alt4.aspmx.l.google.com.

yourdomain.tld.   IN  MX  0   yourdomain-tld.mail.protection.outlook.com.

Lower priority is preferred first. Multiple MX hosts at the same priority are tried in random order for failover. Wait one MX-record TTL, then send a test message to confirm routing.

Path 2: you do not receive mail. Publish a null MX

If your domain is web-only (marketing site, app domain, internal service domain), publish a null MX. It is a single record with priority 0 and a target of one literal dot, which RFC 7505 defines as "this domain does not receive mail." Sending MTAs that respect 7505 will refuse to attempt delivery rather than fall back to your A record.

yourdomain.tld.   IN  MX  0   .

Most managed DNS UIs accept this as priority 0, target dot. If the UI rejects it, switch to zone-file mode and add the record manually. Always confirm with dig MX yourdomain afterward.

Verify the fix

• Run dig +short MX yourdomain @1.1.1.1 to confirm what is published.
• If you receive mail, send a test message to your mailbox at this domain and confirm it arrives within the expected window.
• If you published a null MX, send a test message to anything@yourdomain.tld and confirm it bounces with a clear refusal from your sending MTA (typically "recipient address rejected: domain does not accept mail" or similar).
• Re-run the RedScore lookup. The verdict should move from warn to pass.

Common pitfalls

• Mixing real MX and null MX. They are mutually exclusive declarations. Publishing both is a configuration error; sending MTAs may pick either, with unpredictable results.
• MX pointing at a CNAME. RFC 5321 requires MX targets to resolve via A or AAAA, not CNAME. Some mail servers tolerate it; others refuse silently.
• Forgetting the trailing dot on null MX. The target must be the DNS root (.). Some DNS UIs interpret a bare dot as the current zone; always confirm with dig MX yourdomain after saving.
• Leaving null MX in place after starting to receive mail. If you switch from web-only to mail-receiving, replace the null MX with real MX records or sending MTAs will refuse to deliver.
• Other Email Security checks remaining "not applicable" because of null MX. This is intentional. SPF, DMARC, MTA-STS, TLS-RPT, and DKIM are all inbound-mail checks; if you do not receive mail, they cannot apply. To opt back in, replace null MX with real MX records.