Diagnostics

SPF / DKIM / DMARC

Enter a domain and I look up its SPF, DMARC and DKIM records (TXT) over DNS-over-HTTPS, explaining the policy (p=none/quarantine/reject), the mechanisms and whether they are well formed.

TXT queries are resolved over Cloudflare's DNS-over-HTTPS (1.1.1.1) via HTTPS; they never pass through any redzilla server. The analysis and explanation run in your browser.

redzilla.cl — mailauth

SPF —

DMARC —

DKIM —

SPF · v=spf1

Mechanism	Qualifier	Value	Effect

DMARC · v=DMARC1

Tag	Value	Meaning

DKIM ·

Tag	Value	Meaning

Queries over DNS-over-HTTPS (Cloudflare) · the analysis runs locally in your browser.

How it works

The tool queries the three DNS records that authenticate a domain's email: SPF (RFC 7208), the TXT on the domain itself starting with v=spf1 that lists which servers may send on its behalf; DMARC (RFC 7489), the TXT at _dmarc.<domain> that defines the policy on failures (p=none, quarantine or reject); and DKIM (RFC 6376), the public key published at <selector>._domainkey.<domain>, which requires knowing the selector because it cannot be guessed.

The TXT lookups are resolved via DNS-over-HTTPS against the Cloudflare JSON API (1.1.1.1), without passing through redzilla servers. The analysis runs in your browser: the tool breaks the SPF down mechanism by mechanism with its qualifier (+ pass, - fail, ~ softfail, ? neutral), translates every DMARC tag (p, sp, pct, rua, aspf, adkim…) into plain language and checks that the DKIM record contains a valid public key.

Example: auditing the email of your own domain

Enter the domain (for example example.com) and query: the tool fetches the SPF and DMARC in one go.
A healthy SPF looks like v=spf1 include:_spf.google.com -all: only the servers behind the include may send, and the final -all rejects everything else.
If the DMARC says v=DMARC1; p=none; rua=mailto:..., the domain is only monitoring: spoofed mail still gets delivered. The goal is to reach p=quarantine and then p=reject.
For DKIM, try the common selectors from the panel (google, selector1, default…): if your mail runs on Google Workspace, the selector is usually google.

Frequently asked questions

What is the difference between SPF, DKIM and DMARC?

SPF states which servers may send mail for the domain (validated by the source IP); DKIM cryptographically signs each message and publishes the public key in DNS to verify it was not altered; DMARC ties the two together: it defines what to do when they fail (nothing, quarantine or reject) and where to send reports. The three combined are the foundation against spoofing.

What happens if my domain has p=none in DMARC?

Receivers take no action when a message fails authentication: spoofed mail using your domain keeps getting delivered. p=none is only meant as an initial monitoring phase with reports (rua); the recommended practice is to move to p=quarantine and finally p=reject once the reports confirm that all legitimate mail passes.

Why does the tool ask for a selector for DKIM?

Because the DKIM key does not live in a fixed place: it is published at <selector>._domainkey.<domain> and the sender chooses the selector. There is no DNS query that lists them, so you must know it or try the usual ones: google (Workspace), selector1 and selector2 (Microsoft 365), k1 (Mailchimp) or default.

What is the difference between ~all and -all in SPF?

The qualifier on the final all defines the stance toward unlisted servers: -all (fail) asks receivers to reject them and is the strict, recommended posture; ~all (softfail) only marks them as suspicious and is typically used during transition. ?all protects nothing and +all authorizes anyone: it completely defeats SPF.

Was this tool useful?

Disclaimer

We take great care to keep every tool accurate and review it thoroughly; even so, we can't guarantee it is free of errors or take responsibility for how the results are used. We recommend double-checking anything critical.

Found an error? Let us know →