SPF & DMARC Checker

How to use this SPF & DMARC checker

1. Enter a domain name.
2. Optionally add a DKIM selector if you know it (check your email provider's setup docs).
3. See each record's presence and raw value instantly.

Why do I need a DKIM selector?

Unlike SPF and DMARC, which always live at a fixed, predictable location, DKIM records are published under a selector name chosen by whoever configured your email (like "google" or "s1") — without knowing that selector, there's no fixed place to look, so it can't be auto-discovered.

How to read an SPF record's mechanisms and qualifiers

An SPF record is a short, specific syntax listing which sources are allowed to send mail for a domain, and reading it correctly means understanding both its mechanisms and its qualifiers. Common mechanisms include ip4: and ip6: (a specific allowed IP address or range), mx (allow whatever servers are listed in the domain's own MX records), and include: (delegate to another domain's SPF record, commonly used to authorize a third-party email service like Google Workspace or an email marketing platform). Each mechanism can carry a qualifier prefix that determines what happens on a match: + (pass, the default if no qualifier is shown), ~ (softfail, treat as suspicious but usually still deliver), or - (hardfail, reject outright). The final "all" mechanism sets the default behavior for anything not explicitly matched, and its qualifier — commonly ~all or -all — is one of the most consequential single characters in an entire SPF record.

The SPF 10 DNS lookup limit — a real, common failure mode

RFC 7208 imposes a hard limit of 10 DNS lookups per SPF evaluation, and exceeding it causes the entire SPF check to fail (a "permerror") regardless of whether the actual content would otherwise have passed. This limit is easy to hit without realizing it, because each include: mechanism counts as a lookup, and if that included domain's own SPF record contains further include: mechanisms, those nested lookups count too — a domain using several third-party services (a CRM, a marketing platform, a support tool, a transactional email service) each requiring their own include: can silently accumulate past 10 lookups without anyone noticing until mail starts failing SPF unexpectedly. Auditing an SPF record's actual lookup count, especially after adding a new email service, is a genuinely important but frequently skipped step.

DMARC policy levels and why starting with p=none matters

DMARC's policy tag (p=) has three possible values with very different real-world consequences: none (take no enforcement action, just collect reports on what would have happened), quarantine (treat failing mail as suspicious, typically routing it to spam), and reject (block failing mail outright). The standard, recommended rollout practice is starting with p=none and reviewing the aggregate reports DMARC generates for a period of time before moving to quarantine or reject, specifically because it's common for an organization to have legitimate mail sources — an old marketing tool, a forgotten transactional email service, a shared mailbox someone set up years ago — that would fail SPF or DKIM and get silently blocked if reject were applied immediately without that monitoring period first.

Why DKIM needs a selector and can't be auto-discovered

Unlike SPF and DMARC, which always live at a single predictable DNS location for a domain, DKIM records live at a location that includes a selector name chosen by whoever configured the signing: selector._domainkey.yourdomain.com. This selector-based structure exists specifically to allow multiple DKIM keys to coexist for the same domain — useful for using several different email services simultaneously, each with its own key, and essential for rotating keys periodically for security without a gap where no valid key is published. The tradeoff is that without knowing the specific selector in use, there's no fixed place to look, which is exactly why this tool requires you to provide it rather than being able to guess or discover it automatically.

Limitations of this tool

This tool reads and displays the raw SPF, DMARC, and (with a selector) DKIM record text for a domain — it doesn't count or validate an SPF record's DNS lookups against the 10-lookup limit described above, doesn't verify that a DKIM key is actually being used correctly on real outgoing mail (that requires inspecting an actual signed message's headers), and doesn't check whether DMARC aggregate reports are actually being delivered to and reviewed at whatever address the record specifies. Use it to quickly confirm these records exist and see their raw content, and pair it with more specialized email deliverability testing for a complete picture.