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.
This test only receives — it never sends: no email goes out to you or anyone else; you send one message to us. Nothing is stored beyond the result: the address is single-use and expires, the message is analysed and discarded, and the report lives only in memory for a short while. 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 — using the real 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.
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.