Email Tools
Email problems rarely sit in one place. Routing, sender authentication, transport encryption and reputation each have their own records and their own failure modes, and these tools test them separately so you can tell which layer is at fault.
Email Tools directory
Parse a domain's SPF record, follow every include and redirect, and count DNS lookups and void lookups against the limits receivers enforce.
Look up the DKIM public key published for a domain and selector and check its type, size, syntax, test mode and CNAME delegation.
Walk the _dmarc tree for a domain, read its policy and tags, and check separately whether external report destinations are authorised.
Check a domain or mail-server IP against the DNS blocklist zones the operator has configured and licensed, with per-zone results.
Paste message headers to trace the Received chain and read Authentication-Results, DKIM, ARC and From alignment. Every result is labelled a claim.
Check a domain's MX records, priorities, redundancy, null MX, target resolution and the reverse DNS of every mail host address.
Connect to a domain's MX hosts on port 25, read the greeting and EHLO capabilities and see whether STARTTLS is advertised. No mail is sent.
Test whether a domain's MX hosts offer STARTTLS, which TLS version they negotiate and whether the certificate is valid for the MX host name.
Check a domain's MTA-STS record and HTTPS policy: mode, max_age, certificate and whether the policy covers the MX hosts actually published.
Check the _smtp._tls TXT record that tells senders where to send SMTP TLS failure reports, and validate its report destinations.
Check a domain's BIMI record, whether DMARC is enforced at the level BIMI needs, and whether the hosted SVG logo meets the Tiny-PS profile checks.
How the email tools divide the problem
Delivering a message involves four distinct questions. Where should mail for this domain go? Is this sender allowed to use this domain? Is the connection between servers protected? And does anyone distrust the sender? Each tool answers one of those questions from public DNS or from a short, bounded connection to the domain's own mail servers.
Routing is covered by the mail server diagnostics (MX records and reverse DNS) and, at the connection level, by the SMTP test, which reads the greeting and EHLO reply but sends no mail. Sender authentication is covered by the SPF, DKIM and DMARC checkers. Transport protection is covered by the STARTTLS, MTA-STS and TLS-RPT checkers. Reputation and brand display are covered by the blocklist check and the BIMI checker. The header analyzer works on a message you paste rather than on a domain.
How SPF, DKIM and DMARC relate
SPF publishes the servers allowed to send for the envelope domain. DKIM lets a sender sign a message so that a receiver can verify the signing domain through a public key in DNS. Neither of them protects the From address a person actually sees. DMARC closes that gap by requiring that at least one of the two passes with a domain aligned to the visible From domain, and by telling receivers what to do otherwise and where to send reports.
The order matters in practice. Get SPF and DKIM working for every legitimate sender, publish DMARC at p=none with a reporting address, read the reports, and only then move toward enforcement. A DMARC policy of none is a monitoring stage, while authorising an external reporting address is a separate step that the DMARC checker reports on its own.
How MTA-STS, TLS-RPT and BIMI relate
Between servers, encryption is usually opportunistic: TLS is used if offered, and most senders accept an untrusted certificate or fall back to plaintext. The STARTTLS checker shows what your servers offer. MTA-STS is a published policy that asks compatible senders to insist on validated TLS, and TLS-RPT is the report channel that tells you when senders could not connect securely. Publish TLS-RPT first, run MTA-STS in testing mode, and enforce when reports are clean.
BIMI sits at the end of the authentication chain. It is a logo display feature that requires enforced DMARC, so it is a reward for finishing that work and not a way to start it.
Choosing where to begin
- Mail is not arriving at all: start with the mail server diagnostics, then the SMTP test and STARTTLS checker.
- Mail from your domain lands in spam or is rejected: check SPF, DKIM and DMARC, then read a real message with the header analyzer.
- You want to stop spoofing of your domain: work through DMARC, staged from monitoring to enforcement.
- You want encrypted delivery to be required: STARTTLS first, then TLS-RPT, then MTA-STS.
- You suspect a blocklist problem: use the blocklist check where an operator has enabled zones, and remember that an unconfigured check is not a clean result.
What these tools do not do
They do not send mail, attempt to log in, or probe whether a particular recipient exists. DNS failures are reported as unknown, never as a missing record. Findings from pasted message headers are claims written in the header, not independent proof. For a broader view of a domain use the domain assessment, and for background see the email security baseline guide.
Written by DNS Tools editorial · Last updated 2026-10-09