Tools we actually use,
made public.
The same email-auth inspector, SPF flattener, MTA-STS validator, and BIMI inspector we run during paid audits — published as free, unauthenticated, browser-based tools. Your queries hit Cloudflare's DNS-over-HTTPS resolver directly from your browser; no domain name is logged on our servers. Run them on your own domain. If the results are clean, save the €750. If they show problems, you have a starting point — or buy the Email Authentication Suite at €299/month and we fix it for you.
Four tools, all real.
Each tool answers one question that matters before you can deploy DMARC at p=reject. Together they cover the most common failure modes we find in paid audits: SPF records exceeding the 10-DNS-lookup limit, DMARC records missing the rua reporting endpoint, MTA-STS deployments with the DNS id drifted out of sync with the policy file, and BIMI records published without the underlying DMARC enforcement that makes the logo render at all.
include:, redirect, and a/mx/exists mechanism in your SPF record, counts DNS lookups against the hard 10-lookup limit, and produces a flattened version with the actual IPs in place of the includes. The single most common silent failure mode in modern SPF setups, fixed in your browser in 5 seconds._mta-sts and the HTTPS-hosted policy file at /.well-known/mta-sts.txt. Verifies the id field is synchronised, the policy mode is set, the MX directives match the domain's actual MX records. About half of MTA-STS deployments we audit have at least one half out of sync.default._bimi, fetches the SVG Tiny PS logo, validates the file profile and security model, downloads and inspects the VMC or CMC certificate, confirms DMARC enforcement is at p=quarantine or p=reject. URIports' 2025 analysis found 53.6% of BIMI records contain at least one error — the failures are silent because providers just don't display the logo.Browser → Cloudflare DoH, nothing in between.
We made these tools client-side specifically because the alternative — proxying queries through our servers — would require us to log domain names that are not ours to log. Your domain name does not appear in our access logs because the request never reaches us.
The architecture is exactly two pieces. Your browser. Cloudflare's cloudflare-dns.com/dns-query endpoint. The page you are about to use loads in your browser, executes JavaScript that calls Cloudflare's public DNS-over-HTTPS resolver directly via fetch(), parses the response, and renders the analysis. No request reaches our infrastructure — not the server hosting this page, not our database, not any logging system we operate. The page itself is served as static HTML.
The reason this matters operationally: queries about your DMARC posture are competitive intelligence about your sending operation. If you are evaluating us against SendGrid and you run our DMARC inspector on your domain, we should not be able to learn that you have a SPF gap that suggests you are about to migrate. We cannot, because the query never came to us. Cloudflare logs the DNS request as part of running their DoH resolver — that is between you and Cloudflare — but our visibility into your usage of the tool is exactly the visibility a static HTML page provides: zero.
The technical details for anyone who wants to verify: the page issues a GET request to https://cloudflare-dns.com/dns-query?name={domain}&type=TXT with the Accept: application/dns-json header. Cloudflare returns RFC 8484-compliant DNS-over-HTTPS responses encoded as JSON; our JavaScript parses the answer records and applies the analysis logic. The endpoint supports CORS (access-control-allow-origin: *), which is what makes browser-side use possible at all.
The same approach applies to the SPF flattener — it issues recursive lookups for every include: token in your SPF record (also TXT queries via the same endpoint), then for every a: and mx: mechanism, counting against the 10-lookup ceiling as it goes. The recursion happens in your browser; the result lives only in your tab.
A short decision tree.
All four tools take 30 seconds to run. Here is the order we recommend if you are working through the email authentication stack from scratch, plus the targeted use of each one once specific problems surface.
If you have not deployed DMARC yet, run the DMARC inspector first. It tells you whether SPF or DKIM or DMARC are published at all, whether they are syntactically correct, and whether they are aligned with the From-domain. It also surfaces the most common omission — DMARC at p=none with no rua= tag, meaning you are getting no aggregate reports. Without aggregate reports, every other piece of work is guesswork.
If your DMARC is at p=quarantine or p=reject already and you are seeing intermittent failures, run the SPF flattener. The single most common cause of "DMARC was passing yesterday and failing today" is an SPF record that drifted past the 10-lookup limit because one of your include: targets added a new sub-include. The flattener counts the lookups, identifies the culprit chain, and gives you a flattened record you can publish to remove the dependency.
If you have deployed MTA-STS and are not sure whether it is working, run the MTA-STS validator. The validator checks the DNS record at _mta-sts.{domain}, the HTTPS-hosted policy file, the syntax of the policy, and most importantly the synchronisation between the DNS id and the policy file content. Roughly 38 percent of MTA-STS deployments we audit have an id mismatch from a forgotten bump after a policy update — receivers cache the old version until TTL expires.
If you have deployed BIMI and the logo is not rendering, run the BIMI inspector. The most common reason BIMI does not render is upstream DMARC enforcement state — the BIMI specification requires DMARC at p=quarantine or stricter, and roughly 44 percent of broken BIMI deployments we see are stuck because the publishing domain is at p=none. The inspector surfaces the DMARC dependency precisely because that is the most common failure mode. The fix is in DMARC progression, not in BIMI configuration.
If everything passes cleanly, you do not need our paid audit. The €750 SPF/DMARC Audit covers the deeper work — two weeks of DMARC aggregate report collection to identify every legitimate sender of your domain, the source-by-source remediation of misaligned senders, the staged DMARC progression to p=reject. If the free tools say everything is clean and you have no specific reason to think otherwise, save the money. Roughly 40 percent of clients who run the inspectors and find a problem fix it themselves with the inspector's recommendations and we never hear from them again. The other 60 percent book the audit. Both outcomes are wins.
Run them on your domain.
Open one of the tools, type your sending domain, hit enter. 30 seconds end-to-end. No signup, no email capture, no "create a free account to see results" friction. The output is a real diagnostic — the same data we use during paid audits, in the same format.