Hi, I'm Serhii
I'm Serhii Tanichev, a software developer based in Europe. For years my day job has been the mail infrastructure of an email service provider: the sending servers, the DNS, the queues, the reputation of shared IP ranges, and the message from a client at seven in the morning saying their campaign stopped arriving. I won't name the platform here, and I won't quote numbers from it. What I can say is that most of the checks in this tool started as something I had to debug on live traffic, usually more than once.
The tester sends nothing on your behalf. You get a disposable address, you send it the message you were about to send anyway, and a couple of minutes later there is a report.
Why I built it
The tools I had used fell into two groups. One group hides everything behind a number and a traffic light, so when the number is bad you still don't know which DNS record to open. The other wants an account, a card and a call with sales before it shows you anything, and then what it shows is a dashboard for a marketing team rather than for the person who has to fix the record.
I wanted the third thing. A report that names the check, quotes the rule the check rests on, and says what to change in the order that will move the score the most. So every warning here cites the section of the RFC it comes from, word for word. Where Google publishes its own requirement, the report links that page as well. If you think a finding is wrong, you can read the source and argue. I mean that. Write to me.
What it checks
The test runs 41 checks in six groups. All of them are described on the How it works page, with what each one costs when it fails.
- Authentication. SPF, DKIM, DMARC and ARC, and whether the signatures actually align with the From domain, which is the part that decides whether DMARC passes.
- Infrastructure. Reverse DNS, HELO, MX records, TLS on the connection, and more than twenty blocklists.
- Spam engines. Two independent filters read the content. One of them reproduces the classic SpamAssassin number, so that score is comparable with what other testers show you.
- Content. HTML structure, images against text, link reputation, list-unsubscribe headers. The things filters weigh, as opposed to the things people worry about.
- Compliance. The bulk sender rules Gmail and Yahoo began enforcing in 2024.
- Advisory. BIMI, MTA-STS, TLS-RPT, DNSSEC. Worth having, never penalised.
Two scores come out of that. The classic 0 to 10, and a 0 to 100 score of my own that weights authentication and infrastructure the way receiving servers weight them today. Under the scores there is a fix plan, written by a language model from the measurements alone. The model never sees your subject line, your headers or your body. It gets a fact sheet, and the points it promises for each fix are recomputed by scoring the corrected message, not estimated.
How it's put together
A receiving mail server (Haraka) that behaves the way a mailbox provider's does, two spam engines (Rspamd and SpamAssassin), a Python service that runs the checks, and a static site in front. There is an API with no keys, an MCP server for agents, a page written for them at /skill/, and the report reads in 31 languages.
I build and maintain it independently, in the time around the day job. Changes go on the changelog as they ship, with the date.
What it costs
Nothing, right now. The first 100,000 reports are free for everyone, with no account, no card and no cap per person. I pay for the server. If that ever changes, the changelog and this page will say so before it does, and the reports that already exist will stay where they are.
Where to find me
Email is the reliable way, hi@email-spam-tester.com. I'm also on GitHub and LinkedIn, and the contact page says what to include in a bug report.
A wrong citation, a check that fires when it shouldn't, an RFC I read too quickly: those get fixed first. A bug in a deliverability tool is a deliverability bug.