SPF, DKIM and DMARC Test: Check Your Records

An SPF, DKIM and DMARC test checks that the three authentication records on your domain exist, are valid and agree with each other. It has two parts. First, look up the records in DNS: one SPF record on the domain, a DKIM key at <selector>._domainkey.<domain> and a DMARC record at _dmarc.<domain>. Then send an email to a mailbox you can open and check that its Authentication-Results header shows spf=pass, dkim=pass and dmarc=pass. For the DNS part, run the free SPF, DKIM and DMARC checker: it reads all three records and MX for any domain.

SPF is the Sender Policy Framework, DKIM is DomainKeys Identified Mail, and DMARC is Domain-based Message Authentication, Reporting and Conformance. When all three pass, receiving servers can tell your mail apart from mail that only pretends to come from your domain. That protects your recipients from phishing and your domain from a damaged reputation.

If you only need to know what cold email domains must have, read SPF, DKIM and DMARC for cold email.

How to Check SPF, DKIM and DMARC

Paste your domain into the free SPF, DKIM and DMARC checker. It needs no sign-up, counts SPF lookups, finds DKIM keys at common selectors or the one you enter, reads the DMARC policy and lists MX records. To test by hand, look up three TXT records: the one starting with v=spf1 on the domain, <selector>._domainkey.<domain> and _dmarc.<domain>. Then send a message to a Gmail address you own and look for spf=pass, dkim=pass and dmarc=pass in Authentication-Results. On Outreach2day domains all three records are set up automatically.

Why You Need to Test Your Email Authentication

Authentication records break quietly. A new tool gets added without an SPF entry, a DKIM key is rotated without a DNS update, a second SPF record appears after a migration. Nothing warns you until mail starts failing.

A common attack shows what is at stake: someone sends a fake invoice "from" your CEO to your finance team. If your domain has no enforced DMARC policy, the receiving server has no instruction to reject that message.

The Real-World Impact of Misconfiguration

A broken setup sends password resets, quotes and invoices to spam and leaves your domain open to phishing and business email compromise (BEC). See our email deliverability best practices for the other factors.

Mailbox providers now require authentication from bulk senders. Since February 2024, Google requires SPF or DKIM from everyone who sends to Gmail, and SPF, DKIM and DMARC (at least p=none, with alignment) from anyone sending 5,000 or more messages a day to personal Gmail accounts (Google sender guidelines). Microsoft applies the same three requirements to domains that send 5,000 or more messages a day to Outlook.com, Hotmail.com and Live.com addresses; since May 5, 2025 non-compliant mail is rejected with error 550 5.7.515 (Microsoft support).

Email Authentication Protocols at a Glance

Check SPF, DKIM and DMARC by Hand

Use dig on macOS and Linux, nslookup on Windows, or Google Admin Toolbox Dig in a browser. Replace example.com with the domain in your From address.

1. Look up SPF. Query the domain's TXT records and find the one that starts with v=spf1.

2. Look up DKIM. Query the TXT record at <selector>._domainkey.<domain>.

3. Look up DMARC. Query the TXT record at _dmarc.<domain>.

4. Read a real message. Send an email from the domain to a mailbox you own and check its Authentication-Results header.

On Outreach2day domains, SPF, DKIM, DMARC and a redirect to your website are set up automatically; these steps confirm them.

SPF Record

dig +short TXT example.com
nslookup -type=TXT example.com

A domain can have many TXT records; exactly one may start with v=spf1:

"v=spf1 include:_spf.mailprovider.example ip4:192.0.2.10 ~all"

Check that it ends in ~all or -all, lists every service that sends as the domain, and stays within 10 DNS lookups. Each include costs one lookup plus the lookups inside it. In the words of Microsoft's SPF guide, "having fewer than 10 include: statements doesn't guarantee fewer than 10 DNS lookups."

DKIM Key

dig +short TXT selector1._domainkey.example.com
nslookup -type=TXT selector1._domainkey.example.com

Replace selector1 with the s= value from the DKIM-Signature header of an email you sent. A published key starts with v=DKIM1; k=rsa; p= and a long base64 string. Some providers publish a CNAME at the selector that points to a key they host, as Microsoft 365 does for selector1 and selector2 (Microsoft DKIM guide); dig follows it. An empty answer means a wrong selector or no key, and an empty p= means the key was revoked (RFC 6376, section 3.6.1).

DMARC Record

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

"v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Look for one record (Microsoft's DMARC guide says to "ensure only one _dmarc TXT record exists"), a p= of none, quarantine or reject, and a rua= address for reports. RFC 9989 reads a record without p= as p=none and drops the pct tag; a test phase now uses t=y (RFC 9989, section 4.7). If the domain has no record yet, the DMARC record generator writes one for your rollout stage.

Read the Authentication-Results Header

DNS shows what you published. The header shows what a receiver decided about a real message, including problems DNS cannot show, such as a provider that signs with its own domain.

Send an email from the mailbox you are testing to a Gmail address you own. In Gmail on a computer, open it, click More next to Reply and choose Show original (Google: trace an email with its full header). The page starts with an SPF, DKIM and DMARC summary. Below it, search the header for Authentication-Results, as Google's DKIM troubleshooting steps direct. The field has this shape (RFC 8601):

Authentication-Results: mx.example.net;
    spf=pass smtp.mailfrom=anna@example.com;
    dkim=pass header.d=example.com header.s=selector1;
    dmarc=pass header.from=example.com

• smtp.mailfrom: the envelope (Return-Path) domain that SPF checked

• header.d, or header.i in Gmail: the domain that signed DKIM

• header.from: the From domain that DMARC compares with the other two

DMARC passes when spf=pass or dkim=pass is on a domain with the same organizational domain as header.from (relaxed alignment, the default).

In Outlook, open the message's internet headers. Microsoft 365 adds compauth, a composite result, and shows dmarc=bestguesspass when the domain has no DMARC record and the message would have passed one (Microsoft: anti-spam message headers).

For Google Workspace values, use Google's Admin Help: set up SPF, set up DKIM and set up DMARC. To audit many domains at once, the email DNS audit skill runs these checks in Claude or ChatGPT.

Read the Result

Each check returns one result per message:

Sources: SPF in RFC 7208, sections 2.6 and 8.5; DKIM in RFC 8601, section 2.7.1; DMARC in RFC 9989, sections 5.3.5 and 4.7; Microsoft 365 handling in its DMARC guide, with the Honor DMARC record policy setting on.

How to Do a Proper SPF Record Test

A "pass" from an SPF checker only tells you the record parses. You also need to see what it authorizes and how many DNS lookups it costs. A good checker expands every include and lists the servers allowed to send for you; confirm that every service that sends your mail is on that list. This is part of a working cold email infrastructure.

If SPF is wrong, DMARC has only DKIM to rely on. Fix SPF first.

Errors That Break SPF

A record can parse and still be broken. Check for these:

• More than 10 DNS lookups: SPF allows at most 10 mechanisms that need a DNS lookup (include, a, mx, ptr, exists and the redirect modifier), counting nested includes (RFC 7208, section 4.6.4). Go over the limit and the check returns permerror. ip4, ip6 and all do not count.

• The ptr mechanism: RFC 7208 says it SHOULD NOT be published because it is slow and unreliable. Remove it.

• Two SPF records on one domain: more than one v=spf1 record is also a permerror (RFC 7208, section 4.5). Merge them into one.

Checking Your DKIM Signature Setup

SPF authorizes servers. DKIM signs each message with a private key; the receiver checks the signature against the public key you publish in DNS. Your test has to confirm that the signature verifies and that it is made for your domain.

To test it, send a message from your domain to a mail analyzer. These tools give you a one-time address, read the headers of the message you send, and report what a receiving server sees.

Making Sense of Your DKIM Test Results

A passing test means the public key in your DNS verifies the signature on the message. The report shows "DKIM: pass" and the signing domain in d=. For DMARC, d= must be your From domain or share its organizational domain (for example mail.yourcompany.com for yourcompany.com); a signature from your provider's own domain passes DKIM but does not help DMARC. If the report says "DKIM signature did not verify", check in this order:

1. Does d= match the domain you expect?

2. Does the selector in s= exist in DNS and hold the current key?

3. Did something change the message after signing (a footer, a link rewriter, a mailing list)?

Running Your DMARC Test and Making Sense of Reports

DMARC passes when SPF or DKIM passes for a domain that aligns with the visible From address (RFC 9989, the DMARC standard that replaced RFC 7489 in May 2026). Your record also tells receivers what to do with mail that fails (p=none, p=quarantine or p=reject) and where to send reports (rua=).

First check the record itself with any DMARC checker. Typical mistakes: a missing mailto: in the report address, policy= instead of p=, or a record published at the domain instead of at _dmarc.<domain>.

Reading DMARC Aggregate Reports

Within a day or two, aggregate (RUA) reports start to arrive from providers such as Gmail and Yahoo. They are XML files, usually one per provider per day. A DMARC report parser turns them into tables.

Each report shows:

• Sending sources: the IP address of every server that sent mail using your domain.

• Results per source: SPF and DKIM results and whether they aligned.

• Volume per source: message counts, so a sudden spike from an unknown IP stands out.

Turning Reports Into Fixes

Work through the reports with two questions.

Do you recognize every IP address? An address that belongs to none of your providers or tools is either an unlisted internal system or someone spoofing your domain.

Which legitimate senders fail alignment? If your CRM or marketing platform fails, set up its custom domain authentication so it signs with your domain. Failing mail also drags down your spam test score.

Once every legitimate source passes, move the policy from p=none to p=quarantine and then to p=reject. Until then, DMARC only reports; it does not protect.

Troubleshooting Common Email Authentication Errors

Most failed tests come from a short list of misconfigurations. Read the exact error, then fix that one thing.

Fixing SPF PermError

"PermError: too many DNS lookups" means the record needs more than 10 lookups. Options:

• Remove include entries for services you no longer use.

• Replace an include with the provider's ip4/ip6 ranges ("flattening"). This works, but you must update the record when the provider changes its IP addresses.

• Move a sending service to a subdomain with its own SPF record.

Two v=spf1 records on one domain also cause a permerror. Merge all sources into one record.

The SPF flattening tool counts what each include costs, merges duplicate records and flattens only the includes you pick. To rebuild the record from your list of senders, use the SPF record generator.

Fixing DKIM Signature Failures

"DKIM signature did not verify" usually means the public key in DNS does not match the private key used to sign.

Copy the key from your sending service again and paste it into the TXT record. Check for extra spaces, missing characters and line breaks. Some DNS panels split long keys into several quoted strings; that is allowed, as long as nothing is lost.

After a key rotation, publish the new key before the provider starts signing with it.

A DMARC failure is a symptom. It means SPF and DKIM both failed or neither aligned with the From domain. The reports show which one.

Fixing DMARC Alignment Failures

DMARC fails when neither SPF nor DKIM passes for a domain aligned with the From address. A message can pass SPF and still fail DMARC.

Example: your marketing tool sends with a Return-Path on sendgrid.net. SPF passes for sendgrid.net, but your From address is yourcompany.com, so SPF does not align. If the tool also signs DKIM with its own domain, DMARC fails.

Fix it in the sender's settings: turn on "custom domain", "domain authentication" or "sender authentication" so it signs DKIM with your domain and, where supported, uses a Return-Path on your domain.

Common Authentication Errors and Their Fixes

For Google Workspace values and Admin console steps, use SPF, DKIM and DMARC for Google Workspace. Keep this test guide for reading message results and fixing failures.

Your Top Authentication Testing Questions, Answered

How Do I Check SPF, DKIM and DMARC?

Look up the records, then read a real message. Run dig +short TXT (or nslookup -type=TXT on Windows) for example.com, <selector>._domainkey.example.com and _dmarc.example.com. Then send an email to a Gmail address you own, open Show original and check Authentication-Results for spf=pass, dkim=pass and dmarc=pass. The steps are in Check SPF, DKIM and DMARC by Hand.

Is There a Free SPF, DKIM and DMARC Checker?

Yes. Our SPF, DKIM and DMARC checker is free and needs no sign-up. It counts SPF lookups, finds DKIM keys at common selectors or the one you enter, reads the DMARC policy and lists MX records. The lookups run in your browser through Cloudflare's public DNS resolver, and nothing is stored. Google's Admin Toolbox Check MX is another free option.

What Does an SPF, DKIM and DMARC Check Show?

What you published: whether the domain has one SPF record, how many of its 10 lookups it uses and how it ends; whether a DKIM key exists for the selector and how long it is; and which DMARC policy is set and where reports go. How a given message was treated is in its Authentication-Results header; the Read the Result table explains each value.

How Long Until My DNS Changes Actually Work?

New records are usually visible within minutes, unless a resolver cached the earlier "no record" answer; that answer can stay cached for up to the zone's negative-caching TTL (RFC 2308). Changed records can take longer: resolvers keep the old value until its TTL (time to live) expires. Check the TTL on the record you changed; with a TTL of 3600 seconds, most resolvers see the new value within an hour.

An online SPF, DKIM and DMARC test may show the change right away. DMARC aggregate reports cover a full day, so expect the effect there a day later.

I'm Passing Everything, So Why Do My Emails Still Go to Spam?

Authentication proves who sent the message. It does not prove anyone wants it. When all three checks pass and mail still lands in spam, look at:

• Sender reputation: check whether your domain or IP is on a blocklist, and check Google Postmaster Tools for your spam rate.

• Content: broken links, link shorteners, image-only messages and misleading subject lines.

• Engagement and complaints: Google asks all senders to keep the spam rate in Postmaster Tools below 0.1% and never reach 0.3% (Google).

How to avoid spam filters goes through what filters check besides authentication.

Passing SPF, DKIM and DMARC is the minimum for inbox placement.

Should I Use "Strict" or "Relaxed" DMARC Alignment?

Alignment compares the From domain with the SPF and DKIM domains. It is set separately for SPF (aspf) and DKIM (adkim).

Strict (s) requires an exact match: mail signed by marketing.yourdomain.com fails a strict check for a From address on yourdomain.com.

Relaxed (r) is the default and accepts any domain with the same organizational domain. Most businesses that use third-party senders should keep relaxed.

Do My Subdomains Need Their Own SPF Records?

Yes, if they send mail. SPF is checked for the exact domain in the Return-Path, so the record on yourdomain.com does not cover support.yourdomain.com. Each sending subdomain needs its own SPF record.

DMARC works differently: a subdomain without its own DMARC record falls back to the record of the organizational domain, and the sp= tag sets the policy for subdomains.

Cold email goes out from separate domains, each with its own SPF, DKIM and DMARC records. Domains for cold email covers how to choose and set them up.

What Are SPF, DKIM and DMARC Records?

Three DNS records that let receiving servers check that mail claiming to come from your domain really does. SPF is a TXT record on the domain that lists the servers allowed to send for it; DKIM is a public key at <selector>._domainkey.<domain> that verifies the message's signature; DMARC is a TXT record at _dmarc.<domain> that checks SPF or DKIM passed for the visible From domain and tells receivers what to do when neither does. Google requires all three from anyone sending 5,000 or more messages a day to personal Gmail accounts.

How Do I Set Up SPF, DKIM and DMARC for Cold Email?

Give every sending domain its own SPF record, DKIM key and DMARC record; p=none with a rua report address meets Google's and Yahoo's bulk-sender rule. Test each domain with the checker and a real message before warmup starts. With Outreach2day cold email infrastructure, the three records and a redirect are set up automatically on every domain, and SPF, DKIM and DMARC for cold email lists what each domain needs.

Outreach2day sets up SPF, DKIM, DMARC and a redirect to your website automatically on every domain, along with mailboxes and warmup, so you do not have to maintain DNS by hand.