How to check SPF, DKIM and DMARC records for a domain (and fix “too many DNS lookups”)

By EdenWorks · Published 2026-11-02 · Updated 2026-11-02

Why these three records matter now

SPF, DKIM and DMARC are how a receiving mail server decides whether a message that claims to be from your domain really is. Since February 2024, Google and Yahoo have required every sender to have SPF or DKIM, and bulk senders (roughly 5,000+ messages a day to their users) to have SPF, DKIM and a DMARC record. Microsoft announced similar requirements for high-volume senders to Outlook.com addresses in 2025. Even if you send far less, a broken record is one of the fastest ways to land in spam.

The records also break quietly. Someone adds a new sending tool to SPF, a provider rotates a DKIM key, or a DNS migration drops the _dmarc record, and nothing tells you. That is why it pays to know how to check them and, ideally, to check them on a schedule.

One standards note: in May 2026 the IETF published the updated DMARC specification as RFC 9989 (with RFC 9990 and 9991 for reporting), replacing RFC 7489. Existing records keep working; the main visible change is that the pct= tag is gone in favour of a simpler t=y “testing” flag.

1. Check the SPF record

SPF is a TXT record on the domain that starts with v=spf1. On macOS or Linux:

dig +short TXT example.com | grep -i "v=spf1"

On Windows (Command Prompt or PowerShell):

nslookup -type=txt example.com

A typical result looks like this:

"v=spf1 include:_spf.google.com include:sendgrid.net ~all"

How to read it

Remember that SPF checks the envelope sender (the Return-Path / bounce domain), not the From address people see. A marketing tool that sends with its own bounce domain does not need to be in your root SPF record at all; adding it just burns lookups.

2. Fix “SPF PermError: too many DNS lookups”

RFC 7208 section 4.6.4 caps SPF evaluation at 10 DNS-querying terms, counted across every nested include. A receiver that needs an 11th returns permerror, and with a DMARC policy in place that can mean rejection or the spam folder. The spec also recommends failing after more than 2 “void” lookups (names that return nothing), which is what you get from includes for services you stopped using.

Count your lookups

You cannot count by eye, because each include hides its own includes. Expand them one level at a time:

dig +short TXT _spf.google.com
# "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

That single include:_spf.google.com already costs 4 lookups (itself plus three nested includes). Our free SPF/DMARC checker walks the whole tree in your browser and shows the running total.

Ways to get back under 10, in order of preference

1. Delete includes you no longer use. Old CRMs, a help desk you replaced, a newsletter tool from two years ago. This is the answer more often than not.
2. Remove duplicates and unnecessary a/mx. If your mail provider's include already covers your MX hosts, mx is a wasted lookup.
3. Move a sender to a subdomain. Send marketing mail from news.example.com with its own SPF record; it gets its own budget of 10.
4. Use the provider's own bounce domain. Many ESPs let you use a custom Return-Path CNAME, which means their SPF lives on that hostname, not your root.
5. Flatten only as a last resort. Replacing includes with literal ip4: ranges removes lookups, but those ranges change without notice. If you flatten, you must re-check regularly.

After you change DNS, allow for the record's TTL (often minutes, sometimes up to 48 hours) before testing again.

3. Check DKIM (and find the selector)

DKIM keys are published at <selector>._domainkey.<domain>. The catch is that DNS has no “list all selectors” query, so you need the selector name first.

Find the selector

Open any email your domain sent, view the original message / headers, and find the DKIM-Signature header. The s= tag is the selector and d= is the signing domain:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google; ...

Selectors you will often see (not guaranteed; providers let you change them): google (Google Workspace default), selector1 and selector2 (Microsoft 365), k1 (Mailchimp), s1/s2 (SendGrid), and generic names like default or dkim.

Look up the key

dig +short TXT google._domainkey.example.com
# "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

• No answer at all: wrong selector, or the key was never published.
• p= with nothing after it: the key has been revoked. Mail still signed with that selector will fail DKIM.
• A short p= value (roughly 216 base64 characters) usually means a 1024-bit RSA key. Most providers now recommend 2048-bit.
• Microsoft 365 and several ESPs publish DKIM as a CNAME that points to their DNS. dig follows it automatically; if the CNAME target is missing, DKIM fails.

4. Check the DMARC record

dig +short TXT _dmarc.example.com
# "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

If there is no record on a subdomain, receivers fall back to the organisational domain's record (for mail.example.com, that is _dmarc.example.com).

DMARC passes when SPF or DKIM passes and the passing domain aligns with the visible From domain. That is why a correct SPF record alone is not enough: a newsletter sent through a third party with its own bounce domain will only pass DMARC if it is DKIM-signed with your domain.

5. A quick health checklist

• Exactly one v=spf1 record, ending in ~all or -all (never +all or ?all).
• SPF evaluation uses 10 DNS lookups or fewer, with no includes that resolve to nothing.
• Every service that sends as your domain signs with DKIM using your domain (d=), with keys that are not revoked, preferably 2048-bit.
• A _dmarc record with a rua= address, moving from p=none towards quarantine or reject once reports look clean.
• Parked domains that never send mail: v=spf1 -all and v=DMARC1; p=reject, so nobody can spoof them.

6. Monitor for changes automatically

A one-off check tells you today's state. Problems usually appear later: a teammate edits DNS, a vendor's include grows past the lookup limit, or a key is rotated. If you manage more than one or two domains (an agency, an MSP, a cold-email team), a daily automated check that only alerts on changes saves a lot of manual work.

If you already use n8n, we publish a free workflow template that does exactly this. It checks a list of domains every day for the issues in the checklist above, keeps a ledger of each finding (new, changed, fixed or still open), emails a digest, and posts to Slack only when something changes.

Related guides

• How to check SSL certificate expiry and monitor it (before certificates shrink to 47 days)
• How to find broken links on your website, free, and get a weekly report

Sources: RFC 7208 (SPF), RFC 6376 (DKIM), RFC 9989 (DMARC); Google's email sender guidelines. This guide is general information, not a guarantee of inbox placement.