About the Mail Tester
This mail tester scores an email you actually send, not just the DNS records behind it. Generate a one-time throwaway address, send a real message to it from the system you want to check, and within seconds you get a score out of 10 with a full breakdown of every factor that moved it. Because it reads the real message as received, it can report the actual SPF, DKIM and DMARC verdicts that the receiving side generated for that specific email, the spam-filter score and which rules it triggered, the sending IP's reverse-DNS and blacklist status, and content checks like a missing plain-text part or List-Unsubscribe header.
It is the way to answer why mail is going to spam with evidence from a genuine send rather than inference from published DNS records. Run the mailcheck deliverability tool first to fix the domain's SPF, DMARC and MX setup, then send a real test here to confirm an actual message passes end to end, since some problems, a signing key that doesn't match what's published, a sending system that silently isn't signing at all, only show up on a live message. It also works as a dkim inbox tester specifically: DKIM here reflects the exact selector and signature your sending system used on this send, not a guess at common selector names.
Each test address is single-use and built for one message only. The result is held in memory, not written to any database, and both the address and the stored result expire and are discarded after 30 minutes, wiped entirely on a redeploy in the meantime. Treat the address as public test infrastructure and don't send anything sensitive to it.
How to use it
- Click to generate a one-time test address in the form test-token@mt.invoker.tools.
- Send a real email to that exact address from the mail system you want to test.
- Keep the tab open, it polls automatically and updates the moment the message arrives.
- Read the grade and the score out of 10 first, then open the breakdown for the exact point deductions.
- Work through the ranked issues list, worst first, since it's sorted by how many points each one cost.
- Send a second test after fixing the top issue to confirm the score actually improved.
Examples
- Find out why a newsletter lands in spam by seeing the actual spam-filter score and rule names it triggered on a real send.
- Confirm a new sending domain's DKIM signature actually verifies, not just that a DKIM record exists in DNS.
- Check the spam score of a transactional email (password reset, order confirmation) before rolling it out to real customers.
- Verify a mail server's sending IP isn't blacklisted, based on the IP the message actually arrived from rather than a guessed MX IP.
- Test whether a bulk-mail platform is including a List-Unsubscribe header, worth a small but real deduction if it's missing.
Exactly how the 10-point score is built
Every test starts at 10 and loses points per factor. The full list of what was subtracted and why is always shown, not just the final number.
- Spam filter: subtracts the raw spam-filter score if it's above zero. A clean message under the threshold loses nothing.
- DKIM: minus 1.5 if the signature doesn't verify as pass, the single biggest deduction on the list.
- SPF: minus 1.0 if the result on this message isn't pass.
- DMARC: minus 1.0 if the result on this message isn't pass.
- IP blacklist: minus 1.5 if the sending IP is listed on a checked blacklist.
- Reverse DNS: minus 0.7 if the sending IP has no forward-confirmed PTR record (FCrDNS).
- List-Unsubscribe header: minus 0.3 if it's missing from the message.
- Plain-text part: minus 0.3 if the message is HTML-only with no text part.
- Subject line: minus 0.5 if the subject is empty.
- Grade: A at 9.0 or above, B at 7.5 or above, C at 6.0 or above, D at 4.0 or above, F below that.
Why sending a real message catches what DNS checks can't
SPF, DMARC and DKIM checks, and the composite mailcheck tool, all read whatever a domain currently publishes in DNS. That tells you the setup is theoretically correct, but it can't catch a sending system that quietly stopped signing messages, one that signs with a key that no longer matches what's published, or a message body that a spam filter genuinely flags. This tool instead reads the Authentication-Results header the receiving side generated for the exact message you sent, and a live spam-filter score from the same real send, so a pass here means a real message from your real sending system actually authenticated and scored well, not that the theory checks out.
How the test works end to end
- Generate a one-time address: test-token@mt.invoker.tools, unique per test.
- Send a real email to it from the exact system, server or account you want to verify.
- The message arrives over inbound mail routing and is scored automatically, no action needed on your end.
- The page polls for the result and updates the moment it's ready, usually within seconds.
- Both the address and the result expire after 30 minutes and are then gone entirely, no database, nothing persisted.
Getting a useful test out of a single send
- Send from the actual production system or server you plan to use, not your personal inbox, since the IP and signing setup are what get scored.
- Fix what mailcheck already flags first (missing SPF, DMARC at p=none, no MX PTR) so the token isn't spent on a known issue.
- Include a real subject line and, if your platform supports it, both a plain-text and an HTML part to test the content checks too.
- Don't send anything confidential. The address is single-use but effectively public test infrastructure, and results are discarded after 30 minutes, not sooner.
Frequently asked questions
Is this a dkim inbox tester?
Yes. DKIM is one of the three authentication results read directly from the real message you send, using whatever selector and key your sending system actually signed with, not a guess at common selector names the way the DNS-only mailcheck tool has to.
What's the difference between this and the mailcheck deliverability checker?
mailcheck reads a domain's published DNS records without sending anything, instant but theoretical. This tool has you send one real email and reads the actual SPF, DKIM and DMARC results and spam score generated for that specific message, which catches problems DNS alone can't, like a signing key mismatch.
Does this actually send an email, or just check DNS?
It requires a real email. You send an actual message to the one-time address it generates, and the score is based entirely on how that specific message arrived and what it contained.
Can I reuse the test address?
No, each address is single-use and tied to one test session. Generate a new one for another test.
What happens to my email after the test?
It's received, scored, and then discarded. Nothing is written to a database. The live result sits in memory and expires after 30 minutes, or sooner if the server redeploys in that window.
Why did DKIM fail here when my provider's dashboard says it's set up correctly?
A provider's dashboard usually confirms the DNS record exists and is well-formed. This test instead verifies the signature on the specific message you sent, which will fail if the sending system used the wrong key, didn't sign at all, or a relay modified the body after signing, none of which a DNS-only check would catch.
What counts as a good score?
9.0 or above (grade A) means clean authentication, no blacklist hit, forward-confirmed reverse DNS, and no content flags. Anything below 6.0 (C or worse) usually traces to one or two specific deductions in the breakdown, most often a failed DKIM or SPF result or a blacklisted IP.
Where does the spam-filter score come from?
From the receiving side's own spam filter, the same rspamd/SpamAssassin-style engine used in production inbound mail handling, run against the message as it actually arrived. The score and the specific rules it triggered are both shown.
Can I test a specific subject or content to see what it scores?
Yes, send whatever subject and body you want tested. The tool scores exactly what arrives, including whether it has a plain-text part, an HTML part, and a List-Unsubscribe header.
How long do I have to send the test email after generating the address?
The address and the pending test both expire 30 minutes after you generate them. If nothing arrives in that window, generate a fresh address and try again.