01 / MAIL ROUTING · 5 MIN READ
Mail DNS: Three Different Jobs.
MX, SPF and DMARC describe different parts of mail handling. Read them together without treating them as one pass/fail test.
MX Routes Incoming Mail
An MX answer contains a preference and an exchanger hostname. Lower preference values are tried first. Equal values can distribute attempts; an MX record does not identify all outbound sending systems.
For an illustrative pair such as 10 primary.mxblacklist.info and 20 backup.mxblacklist.info, the lower number has priority. These names are examples, not a claim that those hosts are configured here.
If a domain has no MX, SMTP can fall back to address records under defined conditions. This tool does not follow that fallback, resolve exchanger addresses, connect to port 25, inspect TLS, or verify a mailbox.
Reference: RFC 5321 §5 — mail exchanger resolution.
A Null MX Is an Intentional Answer
A sole 0 . MX record signals that a domain does not accept incoming mail. It is not the same as an empty response or a DNS failure. Combining it with ordinary exchangers is a configuration that needs review.
Reference: RFC 7505 — null MX.
SPF Describes Authorized Sending Sources
SPF is normally published as a TXT record beginning with v=spf1. It evaluates an SMTP identity, not simply the visible From header. Multiple SPF policy records can cause an error; multiple quoted chunks inside one TXT record are different and must be joined.
MXBLACKLIST inspects publication only. It does not expand includes, evaluate redirect chains, count all DNS-triggering terms or decide whether a particular sending IP passes. A visible +all deserves review because it authorizes any sender that reaches that mechanism.
Reference: RFC 7208 — SPF.
DMARC Adds Policy and Alignment Context
The exact-name lookup is _dmarc.mxblacklist.info for the example domain. Common policy values are none, quarantine and reject. A receiver’s final decision also involves its own policies.
RFC 9989, published in 2026, replaced the earlier core DMARC specification. It defines DNS-tree-walk discovery and replaces the legacy pct tag with testing-related t semantics. Do not change a working policy solely from a brief DNS snapshot.
This desk checks only the name entered. It does not discover a parent policy, verify DKIM signatures, or evaluate message alignment. “No exact-name record” therefore does not mean that no DMARC policy applies.
Reference: RFC 9989 — current DMARC specification.
Publication Is Only the First Step
Compare the visible records with the configuration recommended by your actual mail provider. Keep unrelated MX, TXT, verification and autodiscovery records intact. Use delivery logs and provider guidance to verify the real message path.
These are read-only DNS checks, not reports or requests to a blocklist. For listing problems, see how to request a review directly with the provider.