Find out what is wrong with your domain’s email setup

Enter a domain. We read its public DNS, check the records that email authentication depends on, and show you the exact problem and the exact fix. No account, no email address.

Checks SPF, DKIM, DMARC, MX, MTA-STS, TLS-RPT and BIMI in one pass.

What gets checked

SPF
Syntax, duplicate records, and the true DNS lookup count including every nested include.
DKIM
Key presence and strength across the selectors your provider actually uses.
DMARC
Policy, reporting, subdomain coverage and external reporting authorisation.
MX
Mail exchangers, whether each one resolves, and the misconfigurations that break inbound mail.
MTA-STS
The policy file itself, checked against the mail exchangers you publish.
TLS-RPT & BIMI
Transport reporting, and whether your DMARC policy actually qualifies for BIMI.

What this does not tell you

Email authentication and inbox placement are different things. We can tell you, precisely, whether your published records are correct — that is a matter of reading DNS and applying the specifications. We cannot tell you whether a given message will land in someone’s inbox, because that also depends on your sending reputation, your content, and each receiver’s own filtering, none of which are visible in DNS.

Anyone promising guaranteed delivery is selling something they cannot control. Correct authentication is necessary, and it is the part you can actually fix.

More on what we do and do not measure

Single-purpose tools

Each one runs the same engine, focused on one record type.

Configuration breaks quietly

The common failures are not ones you cause. A provider adds a mechanism to their own SPF record and yours goes over the ten-lookup limit. A key rotation completes and leaves a revoked selector behind. Nobody gets an alert, because nobody changed anything.

Monitoring re-runs this check on a schedule and emails you only when a finding actually changes.