Email DNS edge-case laboratory
A curated library of tricky email-DNS configurations. Every example uses synthetic, reserved values - no scanned customer domain is ever shown - and the “What the scanner reports” column is the genuine output of running each fixture through the same analyzer the live scan uses. It doubles as a plain-language reference and as living QA.
Null MX: a domain that accepts no email
RFC 7505 (Null MX)A single MX record with priority 0 and host "." is the RFC 7505 null MX - a deliberate declaration that the domain receives no mail.
Synthetic DNS
MX 0 .
What the standard says
Receivers must not attempt delivery. This is a valid setup for a parked or send-only domain, not a broken mailbox.
What the scanner reports
This domain accepts no email (null MX)
Overall: No-mail domain (by design)
Null MX mixed with real MX (invalid)
RFC 7505 (Null MX)A null MX (".") is published alongside a real mail server. RFC 7505 forbids advertising any other MX with a null MX.
Synthetic DNS
MX 0 . MX 10 aspmx.l.google.com
What the standard says
Receiving behaviour is undefined - some servers honour the null MX and reject all mail while others use the real MX. Keep only one.
What the scanner reports
Conflicting MX records (null MX plus real MX)
Overall: Critical issues found
Two SPF records on one domain
RFC 7208 (SPF)Two separate TXT records both begin with v=spf1. A domain must publish exactly one SPF record.
Synthetic DNS
MX 1 aspmx.l.google.com TXT @ v=spf1 include:_spf.google.com ~all TXT @ v=spf1 include:mailgun.org ~all
What the standard says
Receivers encountering more than one SPF record produce a PermError, so SPF effectively fails. Merge every sender into a single record.
What the scanner reports
Multiple SPF records found
Overall: Needs attention
SPF that authorises every sender (+all)
RFC 7208 (SPF)The SPF record ends in +all, which tells receivers that any server on the internet may send mail as this domain.
Synthetic DNS
MX 1 aspmx.l.google.com TXT @ v=spf1 include:_spf.google.com +all
What the standard says
+all defeats the purpose of SPF and invites spoofing. A domain that sends mail should end its record in -all (or ~all).
What the scanner reports
SPF allows every sender
Overall: Critical issues found
DMARC record with an invalid policy
RFC 7489 (DMARC)The _dmarc record begins with v=DMARC1 but its policy (p=) is not one of none, quarantine, or reject.
Synthetic DNS
MX 1 aspmx.l.google.com TXT @ v=spf1 include:_spf.google.com ~all TXT _dmarc v=DMARC1; p=enforce
What the standard says
A record without a usable policy is malformed and ignored by receivers, so the domain gets no DMARC protection.
What the scanner reports
DMARC record is malformed
Overall: Needs attention
Receiving and sending providers disagree
RFC 7208 (SPF)Mail is received at Google Workspace (MX), but SPF authorises only Microsoft 365 to send - the receiving provider is not covered.
Synthetic DNS
MX 1 aspmx.l.google.com TXT @ v=spf1 include:spf.protection.outlook.com -all
What the standard says
Often intentional (mail sent through a different service), but if the receiving provider also sends mail, its SPF include is missing and that mail can fail authentication.
What the scanner reports
Receiving and SPF providers may not match
Overall: Needs attention