Mail Check
Send a real email to a one-time address and have SPF, DKIM, DMARC and blocklists checked against the actual delivery.
This tool needs a free account. Everything else on mailtools stays usable without signing in.
Every other tool here looks at what the DNS says. This one looks at what actually happens: you send a real message from your mail server, your newsletter service or your ticket system to a generated one-time address, and it is checked exactly the way a receiving server would check it. That difference matters more than it sounds. An SPF record can look impeccable and still not cover the server that really sends. A DKIM key can be published in DNS and the signature still be missing or broken on the way out. Only a real message shows that.
What this tool checks
Four things, in the order a recipient checks them. SPF against the IP
address that actually delivered the mail to us and against the envelope sender
(MAIL FROM), not against the visible one. DKIM is verified
cryptographically: the hash over the canonicalised message body and the signature itself
against the key published in DNS. DMARC is then no longer a separate test
but the question whether one of the two passing checks belongs to the domain that appears as
the sender in the mail client. And the delivering IP runs against the same curated
blocklists as in the Blocklist Check.
Reading the result
Green means SPF or DKIM passed and the corresponding domain is aligned with the visible sender, so the mail passes DMARC. An SPF failure is not automatically a disaster as long as DKIM holds: that division of labour is exactly what lets a forwarded message survive, because SPF breaks on every forward while the signature does not. Conversely, a missing DKIM signature is a finding even when SPF currently passes: authentication then hangs by a single thread. A temperror is never a statement about your mail but about our query; it may be gone on the next attempt.
Background
The relevant specifications are RFC 7208 for SPF, RFC 6376 for DKIM (Ed25519 signatures
additionally RFC 8463) and RFC 9989 for DMARC, which replaced the older RFC 7489 in 2026.
Alignment is defined in RFC 9989 section 3.1: relaxed accepts the same
organisational domain, strict requires an exact match, controlled by the
aspf and adkim tags. The decisive point is the one neither SPF nor
DKIM delivers on its own: both say nothing about what appears as the sender in the mail
client. Only DMARC connects the technical check with the visible address, which is why it is
the only one of the three that really addresses spoofing.
Common failure patterns
The most frequent finding is an SPF pass that is worthless because it applies to the service provider's domain rather than your own: from DMARC's point of view it is not aligned and therefore counts for nothing. The second most frequent is a message with no signature at all, because the service offers DKIM but it was never switched on. When the signature breaks in transit, it is almost always a station that touches the message body, such as a virus scanner adding a footer or a mailing list appending an unsubscribe note. And a blocklist hit costs deliverability no matter how clean SPF, DKIM and DMARC look.
Common questions
- Why does my mail land in spam even though SPF and DKIM are fine?
- Because authentication is only half of it. A filter also scores how the message is built: missing headers, a made-up <code>Message-ID</code>, image-only mails without a text part, suspicious links. The Mail Check reports exactly that score as its own finding, together with the rules that contributed points. On top of that comes the reputation of the sending IP, which the Blocklist Check covers.
- How long is the address shown valid?
- 30 minutes. During that time it accepts several messages, each producing its own result. After that it accepts nothing and is deleted; the next time you open this page a fresh one is waiting. You do not have to do anything for that, and there is deliberately no way to stock up on spare addresses: anyone who knows such an address can write to it.
- Is my test mail stored?
- The message body is not. It is needed in memory to verify the DKIM signature and discarded afterwards; it never reaches the database. The result including the header block stays available for one hour and then disappears by itself. Saving it explicitly keeps the result, but not the header block: that one goes after the hour either way.
- Why does DKIM need the message body?
- Because the <code>bh=</code> tag is a hash over the canonicalised body (RFC 6376 section 3.7). A check from the header alone is therefore impossible: without the body there is no way to tell whether the message was altered in transit.
- SPF passes but DMARC does not. How?
- SPF checks the envelope sender, DMARC the visible one. If a provider sends your mail under its own envelope domain, SPF passes for them and is still not aligned with you. The fix: configure your own sender domain at the provider, or have them sign with DKIM using your domain.
- Why don't I get a reply?
- mailtools never replies to incoming mail, neither with a confirmation nor with a bounce. Sender addresses can be forged, and an automatic reply would land with someone who never sent anything. The result appears here on the page only.
- Does this replace the Email Header Analyzer?
- No, they answer different questions. The Header Analyzer reads a message somebody sent you and interprets what other servers wrote into it. The Mail Check verifies for itself, on a message you just sent.