SPF and DMARC checker

Enter a domain to read its SPF and DMARC records from public DNS, with every mechanism and tag explained in plain English. The checker counts the DNS lookups SPF needs, following includes, against the limit of 10, and flags common errors such as two SPF records, +all or a DMARC policy that only monitors. Add a DKIM selector to check that key too.

Free · no sign-up · public DNS lookup only, the domain is not stored

Check a domain's SPF and DMARC

SPF, DMARC and, with a selector, the DKIM key. 20 free checks per day, no sign-up.

We only read the domain's public DNS TXT records. We don't contact its mail servers, don't send anything and don't store the domain.

The answer appears here: the domain's SPF record with each mechanism explained and the DNS lookup count, its DMARC policy and tags, and the DKIM key when you give a selector.

Authentication set up? Keep bounces low by verifying addresses before you send.Verify addresses

The domain's public DNS TXT records are looked up by our server; the domain is not stored or logged; no e-mail is sent. The page counts one anonymous "tool used" event per visit (never the domain), and sends nothing at all when your browser asks not to be tracked.

Clean lists protect your sender reputation

SPF and DMARC prove the mail is yours; bounces from dead addresses still hurt your reputation. Verify addresses before you send. Unknown answers are free.

How it works

SPF. We read the TXT records at the domain and take the one that starts with v=spf1. Each mechanism is explained. A receiver may make at most 10 DNS lookups to evaluate SPF (RFC 7208): include, a, mx, ptr, exists and redirect cost one each, and every include adds the lookups of its own record. We follow includes, reading TXT records only and at most 25 of them, and add the lookups up.

DMARC. We read the TXT record at _dmarc. plus the domain. If there is none, we walk up to the parent domain, as receivers do, and say where the policy came from. Each tag is explained: the policy (p=), the subdomain policy (sp=), pct=, report addresses (rua=, ruf=) and alignment (adkim=, aspf=). When reports go to another domain, we check that it publishes the record that authorises them.

DKIM (optional). Keys are published at the selector, then ._domainkey., then the domain. The selector is the s= value in the DKIM-Signature header of a message you sent. We check that the key is there and not revoked, and read the RSA key size.

Only DNS TXT records are read: nothing connects to the domain's mail servers, no e-mail is sent and the domain is not stored. Each network can run 20 checks a day.

Last updated

How to read the result

  • Has errors: receivers return a permanent error or ignore the record, so SPF or DMARC fails for all mail. Typical causes: two SPF records, more than 10 lookups, an include that points nowhere, a DMARC record without p=.
  • Works, with warnings: the records are valid but leave a gap, such as ~all without DMARC enforcement, p=none, pct below 100 or no report address.
  • Not found: there is no record. Without SPF and DMARC, anyone can send mail that claims to be from the domain, and large mailbox providers are likely to junk or reject its real mail.
  • Unknown: DNS did not answer in time. This says nothing about the records; try again.

Frequently asked questions

What is the SPF 10 DNS lookup limit?

RFC 7208 lets a receiver make at most 10 DNS lookups while it evaluates an SPF record. The include, a, mx, ptr and exists mechanisms and the redirect modifier count, and so does every lookup inside an included record. Over 10, SPF returns a permanent error and fails. Remove includes of services you no longer use, or list fixed ranges with ip4 and ip6, which cost nothing.

Which DMARC policy should I use?

Start with p=none and a rua= address to receive reports, check that every service that sends for you passes SPF or DKIM in alignment, then move to p=quarantine and finally p=reject. A record that stays at p=none forever only monitors: spoofed mail is still delivered.

Do I need SPF, DKIM and DMARC?

For reliable delivery, yes. Since February 2024, Gmail and Yahoo require every sender to set up SPF or DKIM, and bulk senders to have SPF, DKIM and a DMARC record, with the From domain aligned. DMARC is what ties SPF and DKIM to the address people see.

How do I find my DKIM selector?

Open a message you sent from the domain, show the original or the headers, and find the DKIM-Signature line: the selector is the s= value, and the domain is d=. Each sending service has its own selector, such as google or selector1.

Does correct SPF and DMARC mean my mail reaches the inbox?

No. Authentication proves the mail is yours. Inbox placement also depends on your sending reputation, which suffers when you mail addresses that bounce or never engage. Verify lists before you send; the e-mail verification check tells you whether a mailbox exists.

Do you store the domains I check?

No. The domain is checked in memory and the answer is sent back to your browser; nothing is written to a database or a log, and nothing is cached. To keep the tool free and fast, each network can run 20 checks a day; that count is kept in memory under a one-way hash of the network, never the domain.

Why is a domain not supported?

Domains in sanctioned countries and regions, and the mail providers based there, are not supported anywhere on MobileValidate, including this tool. They are refused without a DNS lookup.