Every check, explained in plain English

This page is the reference for every check we run. You don't need to memorize any of it: reports already explain failures in plain English, and each problem links to its fix. It's here for when you want to know what a line on a report actually means.

Checks run at three levels. Domain checks read public DNS and need nothing from you. Path checks read the headers of emails you send to your test address and grade what actually happened. Content checks measure the message itself.

Domain checks

SPF record exists, and only once. SPF is the DNS record naming who may send mail as your domain. Missing is bad; two SPF records is worse, because the standard treats that as a permanent error and every SPF check on your mail fails from then on.

SPF syntax and safety. The record has to parse, must not end in +all (which authorizes the entire internet to send as you), and must stay within SPF's limit of 10 DNS lookups. Past that limit, receivers stop evaluating and your record might as well not exist. Old includes pile up; this is one of the quietest ways a working setup rots.

DMARC record exists. DMARC is a TXT record at _dmarc.yourdomain.com telling receivers what to do when a message claiming to be you fails authentication. Since early 2024, Gmail and Yahoo require one from bulk senders. No email tool can publish it for you; the record is always yours.

DMARC policy strength. p=none observes, p=quarantine sends failures to spam, p=reject refuses them. We also look at whether you're collecting reports (rua), whether the policy covers subdomains, and whether a percentage tag is quietly weakening it. Stricter is not automatically better: tightening a policy while a tool sends unauthenticated is how people spam-folder their own newsletter.

MX records. The records naming servers that receive your mail. Broken or missing MX doesn't just break replies; senders whose domains can't receive mail look disposable to filters.

DKIM at common selectors. DKIM signatures live at named DNS locations (selectors). From DNS alone we probe the names major providers use and verify the keys we find are of respectable length. It's a heuristic: real proof of signing comes from a delivered email, which is the path-level DKIM check.

DNS sanity. Nameserver and zone coherence, records where records should be, suspicious TTLs. Boring until it isn't.

MTA-STS and TLS-RPT. Policies that let you require encrypted delivery to your domain and receive reports about failures. Minor weight, growing importance.

BIMI. The record that lets your logo appear beside your messages in some inboxes. Cosmetic, low weight, checked because it's part of a complete picture.

Domain blocklists. Whether your domain appears on the domain-reputation lists filters consult, Spamhaus DBL class among them. A listing here follows your domain everywhere, whatever IP you send from.

Sending path checks

These run on each email received at your test address, per route. What a sending path is explains the per-route model.

SPF result and alignment. Not "is the record correct" but "did this actual message pass, and does the domain that passed match the From your readers see". Alignment is what DMARC ultimately cares about.

DKIM signature and key quality. Was the message signed, by which domain and selector, did the signature verify, and is the key strong enough.

DMARC outcome. The verdict receivers computed for this exact message. This is the number that decides folders.

Reverse DNS of the sending IP. The sending server's IP should resolve to a name that resolves back (forward-confirmed reverse DNS). Mail from IPs without it looks like mail from nowhere.

Sending IP blocklists. The discovered IP checked against the ZEN-class lists (SBL, XBL, PBL) and others. On shared ESP infrastructure this is reputation you inherit from strangers, which is exactly why it needs watching.

Return-Path domain health. The bounce domain hiding in your headers gets the full domain suite of its own. A rotten bounce domain undermines an otherwise clean setup.

Transport encryption. Whether the message traveled over TLS, read from the hop headers.

Compliance headers. List-Unsubscribe and its one-click variant, which Gmail and Yahoo require from bulk senders. Absence here is a modern, enforced failure, not a formality.

Message hygiene. Sane Message-ID and date, consistent server identification. Sloppiness here correlates with spam, and filters know it.

Content checks

Every received email also gets a free, programmatic content snapshot: total weight and structure, the balance of HTML, text and images, link count and where links point (including link domains checked against blocklists, and whether shorteners are involved), attachments, and whether an unsubscribe is visible in the body.

Separate from that snapshot is the AI content assessment: an expert-style read of your subject line and body with concrete improvement steps. It's interpretive rather than objective, it's presented as exactly that, and it runs only when you trigger it on an email. Paid plans include a monthly allowance for it.

What we don't do

No seed lists, no simulated inbox placement, no "we sent your mail to 40 fake mailboxes" theater. We measure the verifiable layer: the records, routes and signals that mailbox providers actually evaluate. Where a finding is our judgment rather than a measurable fact, the report says so. The free checkers run the domain-level part of this suite on any domain, no account needed.

More in Understanding your results

• The verdict, scores and traffic lights
• What a sending path is