SPF and DMARC Checker

Enter a public domain, such as yourdomain.com, then choose Check records. Our server asks Cloudflare (1.1.1.1) for TXT records on that domain (SPF), TXT records on _dmarc.yourdomain.com (DMARC), and MX records (inbound mail). If Cloudflare does not answer a query, it tries Google (8.8.8.8). Each result names the resolver that answered.

• SPF lists senders a domain authorizes. The number shown counts DNS-lookup terms written directly in that record, out of the SPF limit of 10. Includes and redirects can cause more lookups; this tool does not follow them, so a number below 10 is not a full pass.
• DMARC reads the published policy: p=none monitors, p=quarantine asks receivers to treat failures as suspicious, and p=reject asks them to reject failures. sp= sets a subdomain policy, pct= requests a percentage, and rua= lists aggregate-report destinations. The receiving server decides how to apply a policy.
• MX lists inbound mail receivers. A single "0 ." is Null MX, meaning the domain announces it accepts no inbound mail.

Warnings explain a record's visible syntax or policy risk. "Unknown" means DNS did not give this tool a usable answer, not that the record is absent. Resolver caches can show an older value until its TTL expires.

Suppose a domain publishes v=spf1 include:_spf.example.net -all and v=DMARC1; p=none; rua=mailto:reports@example.com.

• The SPF panel shows one direct DNS-lookup term: include:. The included record might require more lookups, which this tool has not counted.
• The DMARC panel shows a monitoring policy and an aggregate-report address. p=none does not ask receivers to block mail that fails authentication.
• The MX panel is separate: it shows where mail is received, not who is authorized to send it.

To verify actual mail, send a message and inspect its Authentication-Results header for SPF, DKIM and DMARC alignment.

Suppose a domain publishes v=spf1 include:_spf.example.net -all and v=DMARC1; p=none; rua=mailto:reports@example.com. These are illustrative records, not a live result for a customer domain.

One direct include does not mean SPF uses only one lookup when evaluated. Includes and redirects can add work, and this checker does not expand them. A monitoring policy, p=none, does not ask receivers to reject failures. MX tells you where mail arrives, not who may send it.

A useful next check is the Authentication-Results header of a real message at its receiver: did SPF or DKIM pass, and did the relevant identifier align for DMARC? A public DNS result cannot prove inbox placement or delivery.

Our email-authentication study explains what a bounded public-record scan can say and what it cannot. Read its methods and limits before comparing those findings with your own domain.

Read the email-authentication study

No. This is a DNS-record check, not a delivery or spam-placement test. Inspect a real sent message at its receiver.

Only direct lookup terms in the domain record are counted. This tool does not expand nested includes or redirects and cannot establish the total evaluated lookups.

DKIM records live at selector-specific names. A domain does not publish a list of all selectors, so guessing one cannot prove DKIM is absent or valid.

No. DMARC depends on real-message authentication and identifier alignment, and receivers can apply their own policies. Check actual messages and aggregate reports.