Free instant deliverability test

See exactly why your emails land in spam

Send a real email to a one-time address. We check authentication, reputation, content and headers — then score the message out of 10 and show you every deduction.

Generate my test address
No signup needed · results in ~15 seconds
17
checks per message
35
blacklists queried
~15s
typical scan time
$0
to run your first test
Start here

Four tools, and the question each one answers

Deliverability problems arrive in one of four shapes. Pick the sentence that sounds like yours.

“I do not know if my records are right”

Read the domain’s SPF, DKIM, DMARC, MX, MTA-STS, TLS-RPT and BIMI straight out of DNS, graded, with the record to publish for anything wrong. Nothing to send, no account.

Check my DNS records →

“I know it is DMARC and I do not want to break anything”

Every tag validated against the spec, the corrected record for the policy you are on, and each stage from monitoring to reject with what to check before moving on.

Fix my DMARC record →

“My records are fine and mail still lands in spam”

Send one real message and get what a receiver sees: authentication from your actual sending IP, 35 blocklists, SpamAssassin rules, content and headers, itemised.

Run a deliverability test →

“I want to understand it, not just fix it”

Guides to authentication, alignment, the SPF lookup limit, blocklist delisting and the bulk-sender requirements — written from what the scanner actually reports.

Read the guides →
A message reaching a receiving mail server and being sorted one of two ways. It reaches the inbox when the sending server is authorised, the signature verifies and the sending IP is clean; it is filtered as spam when there is no reverse DNS, the IP is on a blocklist, or there is no plain-text part. A message reaching a receiving mail server and being sorted one of two ways. It reaches the inbox when the sending server is authorised, the signature verifies and the sending IP is clean; it is filtered as spam when there is no reverse DNS, the IP is on a blocklist, or there is no plain-text part.
The same message, two outcomes. Which one you get is decided by signals you can check before you send.
How it works

Three steps, about fifteen seconds

We don't guess from your DNS records alone. You send us the real message, so the report reflects what a real mailbox provider would actually see.

01

Generate an address

We mint a one-time inbox for you. No signup, no list upload, nothing to install.

02

Send it a real email

From the actual sender you want to test — your app, your CRM, your mail server. Any subject and body works.

03

Read your score

We parse the message we received and score it out of 10, with every check itemised and explained.

Three steps. One: you send, from your real mail server. Two: we inspect, running every check on the real message. Three: you get the reasons, with every point itemised and a score out of ten. Three steps. One: you send, from your real mail server. Two: we inspect, running every check on the real message. Three: you get the reasons, with every point itemised and a score out of ten.
You send a real message from the sender you actually care about. Nothing to install.
What we check

Seventeen checks across four categories

Each one is scored, explained in plain language, and shown with the evidence we based it on.

Four categories of check. Authentication: can receivers prove the mail is really yours? Reputation: is your sending IP already known as trouble? Content: what filters read before a human does. Technical: the headers that mark a message as bulk. Four categories of check. Authentication: can receivers prove the mail is really yours? Reputation: is your sending IP already known as trouble? Content: what filters read before a human does. Technical: the headers that mark a message as bulk.
Every check belongs to one of four questions a receiving server asks.

Authentication

Whether receiving servers can prove the message really came from you.

  • ✓SPF alignment & policy
  • ✓DKIM signature validation
  • ✓DMARC policy & alignment
  • ✓Reverse DNS (PTR)
  • ✓Forward-confirmed rDNS
  • ✓HELO / EHLO hostname

Reputation

Whether your sending IP is already known for the wrong reasons — and, if it is, a direct link to get it delisted.

  • ✓Spamhaus ZEN
  • ✓SpamCop
  • ✓Barracuda
  • ✓PSBL
  • ✓Manitu
  • ✓UCEPROTECT-1
  • ✓SpamAssassin rule scoring

Content

The parts of the message filters read before a human ever does.

  • ✓Plain-text alternative
  • ✓Text / image balance
  • ✓Broken links

Technical

The headers that quietly mark a message as machine-generated bulk.

  • ✓Message-ID header
  • ✓Date header
  • ✓From header
  • ✓Subject header
  • ✓List-Unsubscribe header
  • ✓Precedence header

What SPF, DKIM and DMARC actually prove

Three standards, three different questions. Publishing all three is common; knowing which one is failing is not.

The three email authentication standards and what each one answers. SPF: was this server allowed to send? DKIM: was the message changed in transit? DMARC: what happens when those fail? The three email authentication standards and what each one answers. SPF: was this server allowed to send? DKIM: was the message changed in transit? DMARC: what happens when those fail?
Three standards, three different questions. Most senders publish all three and never learn which one is failing.
Beyond the score

A place to test mail before it's real mail

The score is the front door. Underneath it is a capture-only mail server your staging environment can safely point at.

Full itemised report

Every check with its verdict, the evidence behind it, and the exact SpamAssassin rules that fired — plus how each one moved your /10.

Sandbox inbox

Point your staging environment at our SMTP server. Mail is captured, never relayed — so test sends can never reach a real recipient.

Open sandbox →

API & SMTP access

Drive tests from CI or your own tooling with an API key, or send through the sandbox relay with SMTP credentials.

View API docs →

Scan history

Every test you run signed in is kept in your dashboard, so you can prove a fix actually moved the score.

Open dashboard →

Check your SPF, DKIM and DMARC without sending anything

Type a domain and read its email DNS straight out of the zone: SPF (including the ten-lookup limit that silently breaks records which look fine), DKIM across fifty-odd provider selectors, DMARC policy and reporting, MX, MTA-STS, TLS-RPT and BIMI. Graded out of 10, with the exact record to publish for anything that is wrong.

Open the DNS checker →

Blacklisted? We hand you the removal link.

Finding out your sending IP is on a blocklist is the easy part. Getting off it is where most tools stop. When we find your IP listed, the report decodes the list’s return code to say why you were flagged, tells you whether removal is self-service, needs a manual review, or expires on its own — and links you straight to that list’s removal form with your IP already filled in. And when a list refuses our query or times out, we say so rather than quietly calling it clean.

Fix your DMARC record, one stage at a time

We read the record you have published — or validate one you have been handed and not published yet — then check every tag against the spec and tell you what each fault actually costs you. You get the corrected record for the policy you are on now, plus the exact record for each step from p=none to p=reject, with what to look for in your reports before taking the next one. It also checks the authorisation record your reporting provider has to publish, which is the usual reason a perfect-looking DMARC record produces no reports at all.

Open the DMARC fixer →

Temp mail — also included

Not every address you need is a test address. Mint a disposable mailbox that accepts real inbound email from anyone, read it right here in the browser, then let it self-destruct on its own timer — messages and all. Useful for signup flows, trials and anything you would rather not hand your real inbox to.

Open temp mail →

The writing behind the tools

Everything these scanners check, explained properly: why authentication fails when every record looks right, what the ten-lookup limit really counts, how to move DMARC to enforcement without losing mail, which blocklists are worth worrying about, and what the large mailbox providers now require from bulk senders. Written from what the scanner actually sees, with no invented statistics and nothing that contradicts what the report will tell you.

Read the blog →
Who it is for

Built for the people who get blamed when mail goes missing

Same report for everyone. What differs is which part of it you will care about.

Developers shipping transactional mail

Password resets, receipts and invites are the mail people notice missing. Point staging at the capture-only sandbox so a test run can never reach a customer, then score the real thing from CI with an API key before the release goes out.

Anyone about to send a campaign

A campaign is one-shot: you cannot recall it and the complaints stay on your record. Ten minutes of checking beforehand catches the authentication failure that would have cost you the send.

Agencies and consultants

A shareable, itemised report is a better handover than a screenshot of somebody else’s dashboard. Every scan has a permalink, and the paid plans add a designed PDF for the client who wants a document.

People running their own mail server

Reverse DNS, forward-confirmed rDNS, the HELO name and 35 blocklists checked against the IP that actually connected — the half of deliverability that is about the connection, not the message.

What a score can and cannot tell you

A 10/10 is not a promise of the inbox

What one message can prove
  • ✓Whether SPF passes from the IP that actually connected
  • ✓Whether your DKIM signature verifies, and against which domain
  • ✓Whether DMARC aligns the way a receiver resolves it
  • ✓Whether that IP is listed, on which blocklist, and why
  • ✓What SpamAssassin makes of the content, rule by rule
  • ✓Which headers a filter expects and your sender omitted
What it cannot
  • ✕Your sending history with a given mailbox provider
  • ✕How your recipients treat your mail — opens, deletes, complaints
  • ✕Whether the list you are about to mail actually asked for it
  • ✕Which folder one specific person will find it in

Anything that claims to measure the right-hand column from a single message is guessing. What the score does is remove every variable you control, which is the part you can act on today.

How the score is calculated. Every message starts at ten. A missing reverse DNS record costs 0.8, no plain-text part costs 0.7, and no unsubscribe header costs 0.5; everything else passed. The result is 8.0 out of 10. How the score is calculated. Every message starts at ten. A missing reverse DNS record costs 0.8, no plain-text part costs 0.7, and no unsubscribe header costs 0.5; everything else passed. The result is 8.0 out of 10.
The score is arithmetic, not a verdict. Every deduction is shown with its size and its reason.
Pricing

Start free, upgrade when testing becomes a habit

Anonymous tests are free and always will be. Paid plans exist for teams who test continuously and want history, sandbox and API access.

Free

$0/mo
  • ✓5 tests per day
  • ✓Full deliverability report
  • ✓Blacklist & spam checks
  • ✓Temp mail inboxes included
Create free account
Most popular

Pro

$19/mo
  • ✓Unlimited tests
  • ✓Full history & trends
  • ✓Sandbox + API access
  • ✓More temp mail inboxes
  • ✓Email support
Request Pro

Business

$59/mo
  • ✓Everything in Pro
  • ✓Higher API limits
  • ✓Multiple domains
  • ✓Priority support
Request Business
Paid upgrades are reviewed by a human before they take effect — nothing is charged automatically. See full pricing →
FAQ

Questions worth asking first

No. Generating an address and running a test is free and anonymous. Signing in adds saved history, the sandbox inbox, temporary mailboxes and API access — and lifts the daily limit that applies to anonymous tests from one IP.
Yes. Alongside deliverability testing we run a temp mail service: disposable mailboxes that accept real inbound email from anyone, which you read in the browser and which delete themselves — messages included — once they expire. A free account includes them; the exact lifetime and how many you can hold open at once are shown on the temp mail screen.
A test address is single-use and exists to score one message: you send it one email and get a report. A temp mailbox is a throwaway inbox you hand out to someone else — a signup form, a trial, anything you would rather not give your real address to — and it keeps receiving mail until it expires. Testing is anonymous; temp mailboxes are tied to your account so nobody else can read yours.
Yes — that is what the DNS checker at /dns-checker is for. Type a domain and it reads the records straight out of DNS: SPF (with its ten-lookup limit actually counted), DKIM across the selectors real providers use, DMARC policy and reporting, MX, MTA-STS, TLS-RPT and BIMI. No signup, and it takes a few seconds. What it cannot tell you is whether your mail actually passes authentication in practice — SPF is a policy about sending IPs and DKIM is a signature on a real message, so for that you still send one message to a test address.
Yes — that is what the DMARC fixer at /dmarc-fixer does. Give it a domain and it reads the published record; paste a record you have been handed and it validates that instead, without touching DNS, which is the right moment to catch a typo. Either way it checks every tag against RFC 7489, explains what each fault costs you, and hands back the corrected record for the policy you are already on plus the exact record for each stage from p=none through to p=reject. It also checks whether an external reporting address has published the authorisation record it needs, which is the usual reason a correct-looking DMARC record never produces a single report.
There is a blog at /blog: guides to the things these scanners check, written from what the code actually does. Authentication and alignment, the SPF ten-lookup limit, moving DMARC to enforcement without losing mail, getting an IP delisted, and the requirements the large mailbox providers now place on bulk senders. No invented case studies and no statistics we cannot source — if an article describes what the scanner reports, it describes what this build reports.
It is captured and analysed, never forwarded to anyone. Test messages are deleted automatically once the retention window passes.
It starts at 10 and each problem we find subtracts from it, weighted by how much it actually hurts you at a real mailbox provider. The report shows every deduction, so the number is auditable rather than a black box.
No, and treat anything that claims otherwise with suspicion. A 10/10 means the message itself gives filters nothing obvious to object to. Placement also depends on your sending history, list quality and recipient engagement — none of which a single message can show.
Each address is single-use. Generate a fresh one for each test — that is what keeps one report tied to exactly one message.
The report links you straight to the removal form for each list your IP is on, with the IP already filled in, so you do not have to hunt for it. It also decodes the list’s return code to tell you why you were flagged, and whether that list clears itself automatically or needs you to file a request. Fix the underlying cause first — a compromised host, an open relay, a bad list — because most lists will simply re-add an IP that is still sending the traffic that got it flagged. We surface the link and the reason; the decision to delist is always the list operator’s.
35 public DNSBLs, including the ones receiving mail servers actually consult: Spamhaus ZEN, SpamCop, Barracuda, PSBL, Manitu, all three UCEPROTECT levels, SpamRats, Mailspike, Hostkarma, DroneBL, SEM, GBUdb Truncate and more. Your report lists every one by name with its own result, the return code it gave, and how long it took to answer. If a list refuses our query or does not answer in time we mark it unknown rather than counting it as a pass — an unverifiable list is not the same as a clean one, and reports that blur the two are how people end up surprised. We only query lists we have verified are still live: a defunct blocklist answers "not listed" for every IP on earth, which would pad the count while never being able to tell you anything.
Email 1@parthh.com and a human will read it. That is the address for support, bug reports, billing questions and upgrade requests — there is no ticket portal to fight with.

Find out where you stand

One email, fifteen seconds, no account. If the score is bad, at least you'll know exactly which line to fix.

Run a free test
Check my DNS instead

Rather ask a person first? 1@parthh.com