Skip to main content

Free tool

DMARC, SPF and DKIM checker

Read a domain’s email authentication records live from public DNS and see, in plain English, what needs fixing. No account, and the domain you check never touches Kawaa.

  • SPF, DKIM, DMARC and MX in one read
  • The SPF include chain expanded and its lookup cost counted
  • Nothing sent to Kawaa: the lookup runs in your browser

Resolved live from your browser by a public DNS-over-HTTPS resolver (Cloudflare, with Google as fallback). The domain you check goes to the resolver, not to Kawaa; nothing is stored and no email is sent. DNS cannot list a domain's DKIM selectors, so keys are looked for at the 51 most common selector names, plus a provider's own where the provider is known to sign with one.

What is checked

Four records, one verdict each

Email authentication is three DNS records doing one job: naming who may send, proving the message was signed, and saying what to do when neither holds. The checker reads all three plus the mail exchangers, and reports each separately, because “authentication failed” is not something you can fix; “your SPF costs 14 lookups” is.

  • SPF: who may send

    A TXT record listing the servers allowed to send for the domain. The review expands its include chain and counts the DNS lookups it costs, because the 10-lookup limit is the way a working record quietly breaks: one more sending service and receivers start answering with a permanent error. It also catches the classics: two SPF records where only one is allowed, +all authorizing the entire internet, and the discouraged ptr mechanism.

  • DKIM: signatures that prove it

    Public keys receivers use to verify a message was signed by your domain. DNS cannot list a domain’s keys, so the checker looks them up at the selector names providers actually use (Google, Microsoft 365, SendGrid, Mailchimp, Proton, Fastmail and the rest), the same list the product’s deliverability check probes. A provider using an uncommon selector is missed, and the tool says so rather than declaring DKIM absent.

  • DMARC: the policy on top

    The record at _dmarc that tells receivers what to do when a message fails alignment, and where to send the reports that show who is mailing in your name. The review reads the policy: p=none monitors but stops nothing, quarantine sends failing mail to spam, reject refuses it. It flags a record that is missing, duplicated, invalid, or stuck in monitoring mode.

  • MX: where mail arrives

    The exchangers that accept mail sent to the domain. Most sending domains need working MX for bounce and complaint handling; a null MX is the explicit, valid way to say a domain accepts none.

    The mail servers in detail: the MX lookup

What this is not

A snapshot, not a monitor

  • A point-in-time DNS read, not a monitor. Records can be correct now and broken by the next edit; the product’s DMARC, SPF and DKIM monitoring re-checks on a schedule and alerts on a change.
  • No blacklist, PTR or reputation checks, and no score. The paid deliverability check covers those; this page reviews the four record types above.
  • DKIM keys are found only at the common selector names. DNS has no way to enumerate selectors, so a provider using an uncommon one looks absent here.
  • For a subdomain, the checker walks up to the organizational domain and reads the policy it inherits (and its sp= tag). The boundary is estimated from common public-suffix patterns, not the full Public Suffix List.

The scheduled version exists: DMARC, SPF and DKIM monitoring re-checks your domains once a day by default and emails you when a domain stops passing or its problems get worse, on the Professional plan and above. The full one-off deliverability check (blacklists, PTR and a scored review) is in the deliverability API, and the records themselves are explained in the SPF, DKIM and DMARC guide.

After the check

Where to go from the findings

Set the records up properly

The step-by-step setup guide for SPF, DKIM and DMARC: the records to publish, the order to publish them in, and the mistakes that break legitimate mail.

Read the guide

Learn the vocabulary

Short, plain definitions of the terms on this page (DMARC, SPF, DKIM, alignment, MX), cross-linked so each one makes sense on its own.

Open the glossary

Then look at the list itself

Authentication decides whether receivers trust your mail; the list decides whether they keep seeing engagement. The free verifier checks addresses one at a time, no account.

Verify an address

Questions

About checking a domain

Is this the same check the paid product runs?

No. This page is a live DNS review of SPF, DKIM, DMARC and MX, run from your browser. The product’s deliverability check is an authenticated API call that adds blacklist, PTR and deeper authentication analysis and returns a score, and the monitoring features re-check your records on a schedule with alerts. Think of this page as the read-only snapshot; the product is the watch.

What do you do with the domain I check?

Nothing: it never reaches Kawaa. The DNS questions go straight from your browser to a public DNS-over-HTTPS resolver (Cloudflare, with Google as fallback), and the answers are rendered on the page and forgotten. There is no account, no security challenge and no daily limit, because there is no Kawaa service behind the form to protect.

My provider says DKIM is set up, but the tool finds no key. Who is right?

Possibly both. A DKIM key lives at <selector>._domainkey.<your domain>, and the selector name is the provider’s choice. The checker looks at the most common selector names; a provider using an uncommon one is missed. Your provider’s documentation names the selector; if it is not in the common set, the key can still be there and working.

SPF looked fine last month. Why does it fail now?

Usually the 10-lookup limit. Every include, a, mx, ptr and exists mechanism (and the redirect modifier) costs one DNS lookup, and receivers stop evaluating after 10, answering with a permanent error. Adding a sending service (a new newsletter tool, a CRM, a support desk) adds its include, and the record crosses the limit without anyone editing it. The checker expands the include chain and counts the total, which is the number that matters.

What is a good DMARC record to start with?

v=DMARC1; p=none with a rua= address you actually read. The reports show who sends in your name and whether your legitimate mail passes alignment; once they look clean, move to p=quarantine, then p=reject. Publishing p=reject on day one, before the reports confirm every real sender passes, is how invoices end up in spam folders.

Does a passing result mean my mail will reach the inbox?

No. These records are the entry requirement, not the outcome. Inbox placement also depends on sending reputation, complaint rates, content, and whether the people on the list asked for the mail. A clean authentication setup stops receivers from distrusting you on sight; it cannot make them want the mail.

Watch these records every day

DMARC, SPF and DKIM monitoring re-checks your domains on a schedule and emails you when a domain stops passing or gets worse. On the Professional plan and above.

Get started freeView pricing

No credit card required