DKIM signature
Every DKIM-Signature is verified with real cryptography (RSA & Ed25519), not just discovered in DNS — including the l= body-length loophole, missing oversigning and weak keys.
Email sender test (MailFrom)
Test the mail you send — the MailFrom side, like a receiving provider sees it. The domain security check reads your DNS records; this test reads an actual message from your mail system: send one email to a generated one-time address and see exactly how your outbound mail authenticates on the wire — the DKIM signature is cryptographically verified, SPF is evaluated against the real connecting IP, and DMARC alignment is decided for this message, the same decision a receiver like Gmail makes.
The analysis itself only receives: you send one message to us, and nothing goes out to analyse it. Two optional steps do send, and only after you click them: a second message under deliberately unsafe conditions (the downgrade test, which is graded), and a probe to your own mail servers if you choose to test the receiving side as well. Beyond the result nothing is kept: the address is single-use and expires, the message is analysed and discarded, and the report lives only in memory for a short while. Server logs are the exception – see the privacy page. No signup, no tracking.
Send an email from the mail system you want to test to this address:
What it checks
SPF (real IP)
SPF check_host() is run against the IP that actually delivered the message, with the 10-lookup limit and macro handling — the result a receiver would compute.
DMARC alignment
Whether this message is DMARC-aligned (From vs. a passing DKIM domain or the SPF identity), honouring strict/relaxed mode and the published policy — with organizational domains resolved by the RFC 9989 DNS tree walk, not the Public Suffix List.
ARC chain
If a forwarder (a mailing list, say) added an ARC chain, we verify it the way a receiver does — re-checking every ARC-Seal and the latest ARC-Message-Signature — so a receiver can still trust your original SPF/DKIM/DMARC result after the message was altered. Validated against the full ValiMail ARC test suite.
Transport TLS
Did your server use STARTTLS at all, and with which version and cipher? Cleartext delivery and weak/legacy TLS are flagged.
Reverse DNS
Forward-confirmed reverse DNS (FCrDNS) of the sending IP — required by Gmail and Yahoo for every sender — plus the IPv4/IPv6 delivery path.
Delivery path
We parse the Received-header trace of your message and report the path it took to reach us — how many relay hops it passed and how long it spent in transit — flagging an unusually long chain or a large delay that points to queuing or a misconfigured outbound route.
Message hygiene
Message-ID, a valid Date, duplicate or multi-valued From headers, SMTP-smuggling line endings and other signals filters weigh.
Message structure
We parse the MIME structure and flag what hurts rendering or deliverability: an HTML-only body with no plain-text alternative, a missing or unterminated multipart boundary, an unknown Content-Transfer-Encoding, and executable or script attachments that most gateways block. Structure-only — we never decode your content.
List-Unsubscribe
For bulk mail, Gmail and Yahoo require one-click unsubscribe (RFC 8058). We check for the List-Unsubscribe header with an HTTPS URI, the List-Unsubscribe-Post one-click marker, and an aligned DKIM signature covering both headers.
BIMI logo
Would this message be entitled to show your brand logo? We resolve the BIMI record, gate it on this message's DMARC result, fetch the SVG (Tiny PS profile) and verify the mark certificate — chain to a BIMI-authorized CA and the logo bound into it — the way Gmail, Apple Mail and Yahoo do.
S/MIME signature
If your message is S/MIME-signed, the signature is verified the way a recipient's mail client does — content integrity, the certificate's address against your From, a chain to a publicly trusted email root (Mozilla/CCADB email trust bit) and modern algorithms. Publish an SMIMEA record (RFC 8162) and we confirm it matches the certificate that actually signed the message — a check no other tool runs against a live signature. Unsigned mail stays neutral; S/MIME is an optional layer on top of DKIM.
OpenPGP signature & key discovery
The same scrutiny for OpenPGP: a PGP/MIME signature (RFC 3156) or the older inline style is verified against a key that is genuinely published for your address — so the report says whether it still holds for the message as it arrived, and names a gateway that broke it by rewriting the mail after signing. We also look up your address in the Web Key Directory of your own domain: publish your key there and every correspondent's mail client finds it by itself, without a manual key exchange. An Autocrypt header is checked against the rules that decide whether a receiving client accepts it at all. As with S/MIME, no OpenPGP layer costs nothing — only a signature that is claimed and then does not hold.
New to these mechanisms? The email authentication and mail server TLS & DANE guides explain each one. Prefer to build the records first? Open Record Studio.