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.
Live email test: sending and receiving
Test the mail you send and, if you choose, the mail you receive — with a single message. 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. Tick also test the receiving side and the proof in that same message lets us connect to your MX like a real sender.
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 if you ask for them: the receiving-side test (tick the box before generating the address, or use the offer under the report afterwards) delivers one signed proof message to exactly the address you sent from, and the downgrade test asks you for a second message under deliberately unsafe conditions. 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.
Once your message has proved control of the domain, we connect to your MX like a real sender (STARTTLS, DANE, MTA-STS, RCPT, catch-all, postmaster, greylisting, open-relay hint) and deliver one signed proof message to exactly the address you sent from – never a third party. Off by default: without the tick, nothing is sent to your servers.
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.
What the receiving-side option adds
MX reachability
The first three mail exchangers in preference order are resolved and connected to on port 25, exactly as a sending server would (the cap keeps a large MX set from turning one test into dozens of outbound connections; the report names it) — including Null MX (RFC 7505) and the implicit A/AAAA fallback.
STARTTLS offered
Does each probed MX advertise STARTTLS? A single cleartext-only exchanger drags the whole domain down, because senders fall back to the weakest MX. Certificate trust, TLS quality, DANE, MTA-STS and TLS-RPT are graded here too — the main scan adds the full cipher enumeration per MX and checks the same names from the DNS side.
Recipient accepted
Whether your MX accepts the recipient at the RCPT stage (250), temporarily defers it (4xx) or rejects it (5xx) — the real “does mail arrive here?” signal. This check stops at RCPT.
Catch-all
A random, non-existent recipient is probed: accepting it (250) means the domain is a catch-all — more spam exposure and no early rejection of invalid mail.
postmaster@
RFC 5321 §4.5.1 requires every mail-receiving domain to accept postmaster@. We check that it does — a small but real compliance signal.
Greylisting
A 4xx temporary deferral at RCPT is the signature of greylisting. Legitimate senders retry and get through; we surface it so a slow first contact is not a surprise.
Open-relay hint
After an external sender, a RCPT to a foreign domain should be refused (RFC 2505 / BCP 30). If it is accepted, we flag a possible open relay — no message is ever relayed.
Delivery confirmed
Finally, one signed proof message is delivered through the full SMTP DATA stage to exactly the address you proved control of — never a third party — so you learn whether real mail arrives end-to-end, not just whether RCPT is accepted. The message carries an opt-out (reply or abuse@).
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.