Diagnosing Inbound Email Deliverability: Reading a Spam Score Like a Sysadmin

When a customer reports that your invoices land in Gmail’s spam folder, the useful question is not “is my email spammy?” but “which specific check is failing?” An inbound mail test answers that: you send one message to a generated address, and the tester dissects it with the same machinery a receiving mail server uses — SPF, DKIM, DMARC, DNSBL lookups and a content filter such as SpamAssassin. The result is a score out of 10 plus a per-rule breakdown.

What the score actually measures

The 10-point figure is mostly a content-filter summary, but the breakdown underneath it is where the work is. Typical sections:

• SPF: did the connecting server appear in the TXT record at your envelope domain? A softfail or fail here is the single most common cause of lost mail.
• DKIM: is there a valid DKIM-Signature header, and does the public key published at s1._domainkey.example.com (or wherever d= and s= point) verify the body and headers?
• DMARC: does one of the above identifiers align with the visible From: domain, and is the _dmarc record published at all?
• Reverse DNS and blacklists: does the sending IP resolve back to a hostname, and does it appear on DNSBLs like Spamhaus Zen or Barracuda?
• Body rules: HTML-only mail, tiny font sizes, all-caps subject lines, URL shorteners, missing plain-text part — each adds points against you.

Interpreting 8/10 versus 10/10

An 8/10 with “DKIM signature not present” is far more dangerous than an 8/10 docked for wording, because Gmail and Outlook weight authentication heavily. Practical triage:

1. Fix authentication first. A missing or failing DKIM/SPF combination can push real mail into spam even when content is clean.
2. Then check infrastructure: missing PTR, an IP on a blacklist, or a shared host whose neighbors sent spam.
3. Content rules last. They cost points but rarely decide placement on their own when authentication passes.

You can verify pieces independently from the command line while you work:

dig +short TXT example.com
dig +short TXT default._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short TXT 4.3.2.1.zen.spamhaus.org

Common fixes

• Add ip4: and include: mechanisms to SPF for every service that legitimately sends as you — CRM, helpdesk, newsletter tool. Keep the record under the 10-DNS-lookup limit.
• If the tester shows “DMARC policy not published”, add at minimum v=DMARC1; p=none; rua=mailto:dmarc@example.com, watch the aggregate reports, then move to quarantine and eventually reject.
• Rotate DKIM keys yearly (2048-bit) and keep both old and new selectors published during rotation.

Re-run the test after every change; deliverability work is iterative, and one message with a full rule breakdown tells you in minutes what a week of complaining to postmasters would not. The mail tester on WhoDNS runs exactly this analysis against an address you can send to, with the rule list exposed so you can fix items one by one until the score holds steady at 10/10.