What this page checks, and why these five
Sending mail that gets attributed to your domain is a solved problem with a short list of requirements. A route has to exist so mail has somewhere to go. The sending hosts have to be declared so receivers can tell authorised mail from spoofed mail. A policy has to state what to do when both authentication checks fail. Reporting has to be on, because otherwise the policy is being applied with no feedback. And a signing key has to be published somewhere a receiver can find it.
Those five are the DNS-visible requirements, and this page runs them in one pass so the result is a list rather than five tabs. Everything else that affects deliverability — reputation, engagement, complaint rates, content — is not in DNS, and the report says so instead of implying a completeness it does not have.
Reading the state column
Each check reports one of five states, and the words are chosen so that they cannot be mistaken for a score. Ok means the check passed on the evidence available. Partial means something is present but weaker than it could be — a single mail host, a policy in monitoring mode, a record that permits unauthorised senders. Monitor means a policy exists whose whole purpose is to observe rather than to act. Missing means the record was not found. Unknown means the check could not answer, which is reserved for cases where absence proves nothing.
The distinction between missing and unknown is the one worth preserving. DKIM is the clear case: because the selector is arbitrary, not finding a key at the common names is evidence about the names tried and nothing more. Reporting that as a failure would be a false statement, and a tool that overstates its reach is worse than one that admits a limit.
Why the fix order is not the same as the list order
The order in the report comes from dependencies, not from how easy each item is. A receiving route has to exist before authentication is worth discussing, because mail with nowhere to go is discarded regardless of how well it is signed. SPF and DKIM have to pass for every legitimate sender before DMARC is tightened, because a policy of reject applied prematurely loses mail silently — the sender is never told, and the receiving side has no reason to explain.
Reporting comes fourth for the same reason in reverse. Aggregate reports are what turn tightening from a guess into a measured change, so the sequence is: publish a policy in monitoring mode, read what the reports show, repair the senders that fail, then tighten. Skipping the reporting step means discovering the missing sender only after their mail starts being refused.
The DKIM key check comes last because it is the least likely to be a real defect and the hardest to prove. Treat it as a prompt to inspect a real message rather than as a verdict.
What each missing piece actually costs you
A missing MX record is not a deliverability problem; it is a total failure of receiving, and mail to that domain is rejected or dropped. If the domain is meant to receive mail, this is the only item that matters until it is fixed.
A missing or over-limit SPF record removes the cheaper of the two authentication checks and undermines DMARC, which needs at least one check to pass in alignment with the domain the recipient sees. Because SPF commonly fails on forwarded mail for structural reasons, losing it is more consequential than it first appears.
A missing DMARC record leaves the decision to the receiver’s own reputation model, which is a reasonable place to be for a domain that sends nothing and a poor one for a domain that sends to customers.
A missing reporting address means the policy cannot be evaluated. It is the difference between a configuration and a managed one.
What authentication cannot do
It cannot make a message wanted. A mailbox provider weighs how recipients interact with mail from a sender, and no amount of correct DNS changes the fact that a hundred recipients who never open a message and ten who mark it as spam produce a negative signal. That signal is outside DNS entirely.
It cannot fix a sending history. A domain that has been used to send unwanted mail carries that association for a long time, and correct configuration afterwards is a precondition for recovery rather than a cure. The list of individual observations that speak to such a history are on the IP reputation check, and the question of being explicitly blocked is on the IP blacklist check and the blacklist removal guide.
It cannot confirm what happened to a specific message. That comes from the receiver, either through their own reporting or through the aggregate reports DMARC requests. What the report above can do is refuse to invent a number: there is no deliverability score here, because a single figure would compress five independent facts into something that cannot be acted on. The DMARC policy guide covers how to move through the policy states, and why legitimate email goes to spam covers the parts of the problem that live outside DNS.