MX records

An MX record names a host that accepts mail for the domain, plus a preference number saying how it ranks against the others — senders try the lowest first. This check reports whether any are published, and treats one particular record as a special case.

That case is the null MX from RFC 7505: a single record with preference 0 and a target of ., which is the explicit way to say this domain receives no mail. It is graded as a pass, because it does exactly what it should. A sender gets an immediate permanent rejection instead of retrying for days against a domain that was never going to accept anything.

No MX at all is a different thing, and worse. RFC 5321 §5.1 says a sender that finds no MX falls back to the domain's A or AAAA record and attempts delivery there — so mail for the domain is offered to whatever the web server is, which usually refuses it after a delay and occasionally accepts it into a mailbox nobody reads.

If the domain receives mail, publish MX records for it, and give the hosts distinct preference numbers unless you specifically want equal-preference load balancing.

If the domain does not receive mail — a brand you are holding, a domain used only for a website, a subdomain used only for tracking links — publish a null MX (0 .) alongside v=spf1 -all. Between them they say "nothing accepts for this and nothing sends as this", which is the pair of statements that makes a domain unattractive to forge.

Be careful with a backup MX at a higher preference. It only helps if it queues and forwards to the primary and applies the same filtering. A backup that accepts everything and forwards it later is a well-known way to bypass the anti-spam on the primary, and spammers look for exactly that shape.