How to Check Your Domain's SPF, DKIM, and DMARC Records

Most domains only find out their email authentication is broken the hard way: a customer says they never got the invoice, a colleague finds your newsletter in spam, or someone forwards you a phishing email that looks exactly like it came from your company. By then the damage is already spread across a few thousand inboxes.

The frustrating part is that all three of the records that prevent this — SPF, DKIM, and DMARC — live in public DNS. Anyone can look them up in a few seconds. You just have to know where to look and what a healthy record looks like.

Want to check a domain right now? Run it through our free DNS Checker — it queries SPF, DKIM, and DMARC live, flags problems, and tells you what to fix. No signup, nothing stored.

Why This Is Worth Ten Minutes of Your Time

Email authentication used to be an optional hygiene task. It isn't anymore.

In February 2024, Google and Yahoo started requiring SPF, DKIM, and DMARC from anyone sending more than 5,000 messages a day to their users. Microsoft followed on May 5, 2025, applying the same 5,000-a-day threshold to its consumer domains — outlook.com, hotmail.com, and live.com. Non-compliant mail isn't just filtered to Junk — it's rejected outright with a 550 5.7.15 Access denied error. The minimum bar is a DMARC record at p=none that aligns with SPF or DKIM, ideally both.

The gap between "has records" and "records actually work" is where most domains sit. EasyDMARC's 2026 DMARC adoption report, which analysed 1.8 million domains, found that 52.1% now publish a DMARC record — but only around 9% combine an enforcement policy with reporting. Over half of the Inc. 5000 companies they looked at are still parked at p=none, which monitors spoofing without doing anything about it.

Publishing a record is not the same as being protected. Checking is how you find out which side you're on.

The Three Records, Very Briefly

If you want the full mechanics, we have a deeper guide on how SPF, DKIM, and DMARC work together. For the purposes of checking, here's all you need to hold in your head:

• SPF is a single TXT record on your domain listing which servers may send mail as you. It's the guest list.
• DKIM is a public key published on a selector subdomain — something like google._domainkey.yourdomain.com. It lets receivers verify a cryptographic signature on each message.
• DMARC is a TXT record at _dmarc.yourdomain.com that tells receivers what to do when the first two fail, and where to send reports about it.

Three records, three different places in DNS. That last detail is why so many people conclude "DKIM isn't set up" when it's actually working fine — they looked in the wrong place.

How to Check Your SPF Record

SPF is the easy one. It's a TXT record on the domain itself, starting with v=spf1.

With the DNS Checker: enter your domain on the DNS Checker page. You'll get the raw record value back, along with flags for syntax problems and missing mechanisms.

From a terminal, if you prefer:

dig +short TXT yourdomain.com | grep spf1

# or on Windows
nslookup -type=TXT yourdomain.com

A healthy result looks something like this:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

What you're checking for:

• Exactly one record starting with v=spf1. Two is not twice the protection — it's a permanent error that invalidates both.
• Every sending service is listed. Your mail provider, your marketing platform, your helpdesk, your billing system, your CI pipeline that emails deploy notifications.
• An all mechanism at the end. ~all (softfail) is the safe default while you're still finding stray senders; -all (hardfail) is stricter and appropriate once you're confident the list is complete.

How to Check Your DKIM Record

Here's where most manual checks fall apart. There is no fixed location for a DKIM key — it lives under whatever selector your email provider chose, and providers don't agree on names.

Google Workspace typically uses google. Microsoft 365 uses selector1 and selector2. Plenty of smaller services use default, mail, or something entirely custom like k1 or s1024.

That means a plain TXT lookup on your domain will never find DKIM. You have to guess the selector, or query each candidate:

dig +short TXT google._domainkey.yourdomain.com
dig +short TXT selector1._domainkey.yourdomain.com

The DNS Checker does this part for you — it tests the common selectors (google, selector1, selector2, default) automatically and shows you which one responded. If none of them hit and you're certain DKIM is enabled, open your email provider's DKIM setup page; it will tell you the exact selector name it publishes under.

Another way to confirm DKIM from the receiving side: send yourself a message, download it as an .eml file, and read the Authentication-Results header — it records the pass/fail verdict for SPF, DKIM, and DMARC as the receiving server saw it. Our EML Viewer will display those headers without you needing a desktop mail client, and our guide to EML files covers what else is hiding in there.

How to Check Your DMARC Record

DMARC always lives in the same place: a TXT record at _dmarc on your domain.

dig +short TXT _dmarc.yourdomain.com

A typical record:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100

Read it left to right. p= is the policy — none means monitor only, quarantine sends failures to spam, reject blocks them. rua= is where aggregate reports get delivered. If there's no rua, you have a policy but no visibility, which is a bit like installing a smoke alarm and disconnecting the speaker.

The DNS Checker surfaces the policy and the reporting addresses separately, so you can see at a glance whether you're monitoring, enforcing, or neither.

Once DMARC is live and reports start arriving, those reports are dense XML that nobody enjoys reading by hand. Feed them into our DMARC report analyzer — it parses the file and shows you volume, pass and fail rates, and which source IPs are sending as your domain.

The Five Problems You're Most Likely to Find

1. Two SPF records

Almost always caused by adding a new email service and pasting its SPF snippet as a new TXT record instead of merging it into the existing one. The result is a permerror and SPF failing for everything. Fix: delete one, and merge all the include: mechanisms into a single v=spf1 record.

2. Too many DNS lookups

SPF permits a maximum of 10 DNS lookups when evaluating a record. Each include:, a, mx, and redirect counts, and nested includes count too — one include: for a big provider can quietly consume several. Cross the limit and SPF returns permerror, exactly as if the record were malformed. Fix: remove services you no longer use, and consider SPF flattening if you genuinely need that many senders.

3. DKIM under a selector nobody remembers

Common after a provider migration. The old selector is still published, the new one never was, and mail signs with a key that doesn't resolve. Fix: re-publish the key your current provider gives you, under the selector it specifies.

4. No DMARC record at all

The most common finding by a wide margin. Without _dmarc, receivers have no instructions for handling mail that fails SPF and DKIM, so spoofed messages claiming to be from you have a much better chance of landing. Fix: start with v=DMARC1; p=none; rua=mailto:you@yourdomain.com;. It changes nothing about delivery and starts the reports flowing immediately.

5. Permanently parked at p=none

p=none is a starting line, not a destination. It tells you about spoofing without stopping any of it. Fix: spend a few weeks reading your aggregate reports, confirm every legitimate sender is passing, then move to p=quarantine and eventually p=reject.

Checking Domains You Don't Own

Because SPF, DKIM, and DMARC are all public DNS records, you can check any domain — not just yours. That's genuinely useful:

• Vetting a vendor or partner before you route business mail through them.
• Investigating a suspicious message — if the sending domain has no authentication at all, that's a meaningful signal.
• Comparing against a benchmark. The DNS Checker has one-click buttons for the major providers, so you can see what a well-configured domain looks like: gmail.com, outlook.com, yahoo.com, protonmail.com, icloud.com, and zoho.com.

Every check has its own URL, in the form /tools/dns-checker/yourdomain.com. That makes results easy to bookmark, drop into a ticket, or send to whoever administers your DNS — they open the link and see the live lookup for themselves rather than a screenshot of yours.

Make It a Habit, Not a Project

Email authentication isn't a thing you set up once. Records drift. Somebody signs up for a new sending platform and adds a second SPF record. A provider rotates a DKIM key. A domain gets transferred and the _dmarc record doesn't come with it.

A reasonable rhythm:

• After any change to your email stack — new provider, new marketing tool, new transactional service.
• Quarterly for your primary sending domain, as a five-minute sanity check.
• Once for every domain you own but don't send from. Parked and legacy domains are attractive spoofing targets precisely because nobody is watching them, and a p=reject record with no senders costs nothing.

Check Your Domain Now

All three records are public, the lookups take seconds, and the fixes are usually a single TXT record edit in your DNS control panel. There's very little standing between "I'm not sure" and "I know."

Run your domain through the free DNS Checker — live SPF, DKIM, and DMARC lookups with plain-English explanations of anything that looks wrong. Nothing is stored, and there's no account to create.

Related Reading and Tools

• Understanding Email Authentication: SPF, DKIM, and DMARC — the full explanation of how the three protocols fit together
• DNS Checker — live SPF, DKIM, and DMARC lookups for any domain
• DMARC Analyzer — turn DMARC's XML aggregate reports into something readable
• EML Viewer — inspect Authentication-Results and other headers on a message you've received
• What Are EML Files? — what's inside an email file, and what the headers can tell you