Features

One workspace for every deliverability failure.

Show prospects the full paid workflow before they log in: incident reports, the email checker, validation, domains, DMARC, sample placement evidence, APIs, webhooks, and team workspaces.

Product showcase

Choose the tool that matches the failure.

The feature switcher walks through the workflows a sender actually buys: diagnose a live incident, prove the message, clean the audience, watch the domain, inspect DMARC, sample placement, and automate the repeatable parts.

Hero workflow

Pro and Agency

Rank likely root causes before the next send.

Incident Report connects the failing email, sending domain, DMARC evidence, sample placement evidence, and list quality into one ranked root-cause fix plan.

Ranked likely causes for low replies, spam-foldering, bounces, and reputation drops
Evidence timeline across report, domain, DMARC, inbox placement, and recipient quality
Fix plan grouped into fix now, retest after changes, and monitor next
Lead/list evidence for catch-all, invalid, risky, and unknown audience segments
Retest checklist that points back to the right WillItInbox tools
Start incident report Compare plans

Deep dive: email checker checks

The 70+ check report is still the technical proof.

The checker breakdown below shows the evidence behind the report score. It supports the broader workspace story by proving exactly how WillItInbox evaluates authentication, infrastructure, headers, content, links, and scoring.

70+

message checks

5

score categories

0-100

report score

01Authentication3502DNS & infrastructure2003Headers1504Content2005Links10Scoring methodology

Authentication

35 of 100 points · 15 checks

The single largest weight in the score. SPF, DKIM and DMARC together prove the message is legitimately from your domain. Without them, mailbox providers default to skepticism — modern Gmail and Yahoo flat-out require all three for bulk senders.

Authentication is what gates inbox placement before reputation or content even matter. A failed DMARC alignment can route a perfectly legitimate transactional email straight to spam, regardless of how clean its body is.

Every check in this category

  • SPF record existsA TXT record at the apex starting with v=spf1.
  • SPF syntax validAll mechanisms parse cleanly with no stray tokens.
  • SPF lookup countTotal DNS lookups stay under the RFC 7208 limit of 10.
  • SPF policy strengthEnds in -all (hardfail) or ~all (softfail), not ?all or +all.
  • SPF authorizes senderThe connecting IP is covered by the published mechanisms.
  • DKIM signature presentA DKIM-Signature header is on the message.
  • DKIM signature validThe signature verifies against the published public key.
  • DKIM key sizePublic key is at least 1024 bits; 2048 recommended.
  • DKIM selector resolvable<selector>._domainkey.<domain> returns a public key.
  • DMARC record existsA _dmarc.<domain> TXT record is published.
  • DMARC policyp=none, p=quarantine, or p=reject — stronger is better.
  • DMARC alignmentFrom-header domain aligns with SPF and/or DKIM identifier.
  • Unified auth timelineSPF, DKIM, and DMARC evidence is presented as one alignment path.
  • ARC chainForwarder authentication chain is present and complete.
  • BIMI record (bonus)Brand indicator with a verified mark certificate.

Common failure

v=spf1 include:_spf.google.com include:mailgun.org include:sendgrid.net include:zoho.com include:_spf.mandrillapp.com -all

Fix

v=spf1 include:_spf.google.com include:mailgun.org -all

Five `include:` lookups plus their nested lookups blow past the 10-query limit and trigger an SPF permerror. Drop the providers you no longer use.

DNS & infrastructure

20 of 100 points · 15 checks

What the connecting server looks like to the receiver. Reverse DNS, blacklist status, and TLS posture quietly decide whether your mail even reaches the spam folder — most rejections at this layer are silent.

Mailbox providers do a sanity check on the IP that hands them your message. Missing PTR records, residential IP ranges, and DNSBL listings put you in the same bucket as botnets — many large receivers will reject the SMTP connection outright.

Every check in this category

  • Reverse DNS (PTR)The sender IP resolves to a hostname.
  • Forward-confirmed rDNSThat hostname resolves back to the same IP.
  • HELO hostname validThe HELO/EHLO greeting is a real, resolvable FQDN.
  • Sender domain MXThe From-domain has at least one MX record.
  • Sender domain A/AAAAThe domain resolves so it can receive replies.
  • Spamhaus ZENCombined SBL+CSS+XBL+PBL — the most authoritative DNSBL.
  • Barracuda ReputationWidely used by mid-market receivers.
  • SpamCopReactive list driven by user complaints.
  • SORBS aggregateMultiple SORBS sub-lists checked together.
  • PSBL, UCEPROTECT, NiX, JIPPG, ivmSIP, S5HSix secondary lists covering long-tail receivers.
  • TLS usedSTARTTLS was negotiated for the SMTP transaction.
  • Dynamic IP detectionThe IP is not in a known residential or DSL range.
  • Advanced SPF/DMARCcheckdmarc-backed policy parsing and warnings.
  • MTA-STS and TLS-RPTInbound transport policy and reporting posture.
  • MX STARTTLSWhether inbound MX hosts advertise clean STARTTLS.

Common failure

Connecting IP: 203.0.113.42 — no PTR record

Fix

203.0.113.42  IN  PTR  mail.example.com.
mail.example.com  IN  A  203.0.113.42

Without forward-confirmed rDNS, Outlook.com and many corporate filters reject before DATA. Ask your hosting provider to set the PTR; it usually takes one ticket.

Headers

15 of 100 points · 18 checks

Boring on the surface, decisive in practice. Mailbox providers parse 50+ headers per message; missing or malformed ones are a strong negative signal because legitimate ESPs always get them right.

A bad Date, an absent Message-ID, or a malformed Received chain look like the work of a script — exactly what filters are trained to catch. Headers are also where bulk-sender requirements like List-Unsubscribe and Feedback-ID live.

Every check in this category

  • Date present and validRFC 5322 format, not in the future, not weeks old.
  • Message-ID formatGlobally unique, contains an @ and a domain.
  • From header existsA single From with a valid mailbox.
  • From not all capsDisplay name uses sentence case, not SHOUTING.
  • To/Cc/Bcc saneAt least one recipient header, no header-injection patterns.
  • Reply-To alignmentIf present, its domain matches the From domain.
  • Subject not all capsSubject in mixed case.
  • Subject trigger wordsNo stacked spam triggers (FREE, ACT NOW, $$$).
  • Received chainHop-to-hop timestamps move forward and hostnames resolve.
  • X-Mailer reputationIf set, references a known mailer rather than a homemade tag.
  • List-Unsubscribe headerRFC 8058 one-click unsubscribe present for bulk mail.
  • List-Unsubscribe-PostCompanion header for one-click POST.
  • Content-TypeExplicit, parseable, with a charset for text parts.
  • MIME-VersionSet to 1.0 on multipart messages.
  • PrecedenceSet to bulk or list when sending campaigns.
  • Feedback-IDOptional Gmail/Yahoo feedback loop identifier.
  • Auto-SubmittedMarked auto-generated for transactional auto-replies.
  • Return-Path matches envelopeBounce path is set and aligned.

Common failure

List-Unsubscribe: <mailbox unsubscribe only>

Fix

List-Unsubscribe: <https://example.com/u/{token}>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Gmail and Yahoo's 2024 bulk-sender rules require BOTH headers AND a working POST endpoint. Mailto-only earns you a hard fail.

Content

20 of 100 points · 17 checks

What's actually in the message. SpamAssassin runs a corpus of hundreds of weighted rules, and we layer modern heuristics on top — image-to-text ratios, hidden text, dangerous attachments, CAN-SPAM compliance.

Even with perfect auth and a clean IP, content can sink a campaign. The hidden cost is partial — content rarely causes outright rejection, but it pushes you into the Promotions tab or the spam folder where engagement collapses.

Every check in this category

  • SpamAssassin scoreAggregate score across the entire rule corpus.
  • SpamAssassin top rulesIndividual rules that fired, with their per-rule score.
  • HTML part presentA text/html alternative exists for richer rendering.
  • Plain-text part presentA text/plain fallback for accessibility and old clients.
  • Image-to-text ratioReal text outweighs image area; image-only mails are a red flag.
  • Hidden textNo display:none, white-on-white, or zero-width characters.
  • Trigger words — pharmaViagra, Cialis and friends — instant filter bait.
  • Trigger words — financeLoan, credit-repair, debt-relief stacks.
  • Trigger words — urgencyACT NOW, LIMITED TIME, EXPIRES TODAY.
  • Trigger words — adult/weight lossTwo more high-risk word categories.
  • Excessive exclamationsMore than ~3 ! per 100 chars in the body.
  • Body sizeEmpty or absurdly large bodies both look automated.
  • Unsubscribe linkA user-visible opt-out link in HTML campaigns.
  • Physical mailing addressCAN-SPAM requires a postal address in commercial mail.
  • Dangerous attachmentsNo .exe, .scr, .bat, .vbs, .iso payloads.
  • HTML clipping riskDetects large HTML bodies and fixed-width layouts likely to clip or render poorly.
  • Mobile rendering riskFlags layout patterns that commonly break in narrow mobile inboxes.

Common failure

<body><img src='cid:hero' /></body>  (image-only marketing email)

Fix

Add a real text body alongside the image. Aim for at least 100 words of meaningful copy and a text/plain alternative part.

Image-only mails get filtered hard because spammers use them to evade text scanners. Even short copy moves the needle dramatically.

Scoring

How we get to 0–100

Each check has a maximum point value. Within a category we sum the points earned and divide by the points possible to get a percentage; the category's contribution to the overall score is that percentage multiplied by the category weight.

Status → score

  • Pass — full credit for the check's max value.
  • Warn — partial credit (typically 50%). The check passed minimally but isn't ideal.
  • Fail — zero credit and a recommendation surfaces in the report.
  • Info — no score impact. Used when a check can't run (e.g. localhost has no public IP).

Score bands

  • 90–100 Excellent — no action needed.
  • 75–89 Good — small fixes will tighten things up.
  • 60–74 Fair — at least one important check is failing.
  • 40–59 Poor — likely deliverability problems.
  • Under 40 — messages will frequently land in spam or be rejected.

Run it on your own email

One test address. 70+ checks. A 0–100 score and a prioritised fix list.

Run a free test