Know what the findings mean.
Authentication, content and sending configuration each tell part of the story. Here is what we evaluate, what each check can establish, and where to start when it needs attention.
SPF authentication
Does the sender’s policy authorize this server?
We evaluate the sending IP against the envelope sender’s SPF policy. A pass confirms authorization for that identity; it does not by itself authenticate the address your reader sees.
Next step: If it fails, check that the envelope domain has one valid SPF record covering your actual sending service.
DKIM authentication
Has the message signature survived delivery?
We verify DKIM signatures using the signing domain’s DNS key. At least one verified signature passes this check. A missing signature is a warning.
Next step: Enable DKIM in your sending service and publish the correct selector record. Changes to signed content can invalidate the signature.
DMARC policy & alignment
Does authentication match the visible From domain?
DMARC combines policy discovery with SPF or DKIM alignment. Authentication on an unrelated domain is insufficient. An aligned pass with p=none is still flagged as a policy warning in our score.
Next step: Align your sending identities and review DMARC reports before moving to quarantine or reject.
SpamAssassin score
Which content and spam signals were triggered?
SpamAssassin evaluates a combination of rules. Its raw score is different from the overall MXValidation score: lower SpamAssassin points indicate fewer detected signals.
Next step: Read the triggered rules together. Fix configuration problems and high-scoring findings before making small wording changes.
Sender IP reputation
Is the sending IP listed by a configured DNS blocklist?
We query SpamCop (reported spam), PSBL (spamtrap observations), and DroneBL (compromised hosts and proxies), with a separate finding for each. A disabled list or access/DNS error produces Unknown, not a clean reputation result. It is not a survey of every reputation system.
Next step: If listed, follow the provider’s explanation and removal process, and investigate the underlying sending activity.
Reverse DNS & hostname
Does the sending IP have a consistent DNS identity?
We check whether its reverse hostname resolves forward to the original sending IP. Reverse DNS is normally controlled by the server or IP provider.
Next step: Ask your sending provider to maintain a meaningful PTR with a matching forward DNS record.
Email headers
Are the message’s identifying fields consistent?
We inspect configured header checks, including missing or notable identity fields. Mailing-list unsubscribe information is relevant for bulk email.
Next step: Review From, Reply-To, Date and Message-ID. Use appropriate unsubscribe headers for subscribed mailing lists.
HTML & MIME structure
Is the email structured for mail clients?
We inspect MIME and HTML characteristics, including plain-text alternatives, active HTML and risky attachment extensions. These checks do not constitute an antivirus scan.
Next step: Include a readable text alternative for HTML mail, use valid MIME, and remove active content or risky attachments.
Links
Do visible URLs and destinations make sense?
We inspect extracted URL syntax, domain DNS and visible URL mismatches. We do not visit the destinations or certify that their content is safe. Incomplete extraction is marked for review.
Next step: Use valid, resolvable domains and make visible URLs match their actual destinations.
SMTP TLS
Was this delivery encrypted in transit?
We report TLS observed between your sending server and our receiving server. It describes this SMTP session, not every delivery from your domain or end-to-end message encryption.
Next step: Enable STARTTLS in your sending service and investigate a test delivery where TLS was not used.
Read the evidence alongside the number
Passed checks normally earn full weight, warnings half, and failed or unknown checks zero. SpamAssassin uses a continuous factor based on its raw score. Missing checks never inflate the result, and coverage is displayed with the score. See the complete scoring rules.
A high score is useful evidence about configuration and content. Inbox providers also make decisions using signals outside this test. MXValidation cannot promise inbox placement.