How to Check Whether SPF, DKIM and DMARC Are Set Up Correctly
You check SPF, DKIM and DMARC at two levels: the DNS records themselves, and a real message that actually passed authentication at a receiving mailbox. A DNS lookup tells you whether the records exist and are well-formed; the Authentication-Results header on a test email tells you whether receivers are accepting them. You need both, because a perfectly valid SPF record can still produce a DMARC failure if the domains don't align.
This walkthrough covers the exact lookups, how to read the output, a worked example with a passing and a failing message, and the mistakes that cause most failures.
What Each Record Does (and What You're Actually Verifying)
SPF is a DNS TXT record on your sending domain listing which servers may send mail for it. You're verifying four things: exactly one v=spf1 record exists, the mechanisms cover your sending IPs, the total DNS lookups stay at or under 10, and the record ends in a qualifier (~all for soft fail, -all for hard fail).
DKIM is a public key published as a TXT record at selector._domainkey.yourdomain.com, matched against the private key your platform uses to sign each message. You're verifying that the selector resolves, that it contains a p= public key, and that a real message carries a valid signature from that selector.
DMARC is a TXT record at _dmarc.yourdomain.com telling receivers what to do when SPF or DKIM fails, and where to send reports. You're verifying the policy (p=), the alignment mode, and the rua= reporting address.
Alignment is where most confusion lives. DMARC doesn't just ask "did SPF pass?" — it asks whether the domain that passed SPF or DKIM aligns with the From: header your recipient sees. Under relaxed alignment (the default), mail.newsletter.example.com aligns with newsletter.example.com. Under strict alignment, they must match exactly. This is why SPF can pass and DMARC can still fail: the envelope-from domain passed, but it wasn't aligned with the visible From domain.
What You Need Before You Start
- Access to the DNS zone for the sending domain, or a way to request changes from whoever manages it.
- The DKIM selector name from your sending platform. It's usually a string like
mf2024ors1, and it must match exactly. - A test mailbox you control at a major provider — Gmail, Outlook or Yahoo — plus the ability to view full message headers.
- A terminal with
dig(macOS, Linux) ornslookup(Windows).
If your domain is set up in Mailerflow, own-domain sending includes guided DKIM, SPF and DMARC setup with automatic verification, so the platform's verification status is the fastest first check before you start querying DNS by hand.
How to Check SPF, DKIM and DMARC Step by Step
Step 1: Look up the SPF record
dig TXT yourdomain.com +short
On Windows:
nslookup -type=TXT yourdomain.com
A correct answer looks like:
"v=spf1 include:_spf.yourplatform.com ~all"
Check for: exactly one v=spf1 record (two records is a permanent error, not a merge), the include: mechanisms covering every service that sends as you, and the trailing qualifier. Now count lookups. include, a, mx, ptr, exists and redirect each count toward the 10-lookup limit; ip4, ip6 and all do not. If you're over 10, receivers return a permanent error and SPF fails for everyone.
Step 2: Look up the DKIM record
dig TXT mf2024._domainkey.yourdomain.com +short
A correct answer looks like:
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."
Check for: the v=DKIM1 tag, a k= key type, and a populated p= value. A p= with nothing after it means the key has been revoked — that's a deliberate signal, not an empty field, and it will fail every signature check. If the lookup returns nothing, the selector name is wrong or the record is on the wrong host.
Step 3: Look up the DMARC record
dig TXT _dmarc.yourdomain.com +short
A correct answer looks like:
"v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r"
Check for: v=DMARC1 first (it must be the first tag), the policy value, and a rua= address you actually monitor. adkim and aspf control strict (s) versus relaxed (r) alignment; if they're absent, relaxed is the default. The record must live at _dmarc.yourdomain.com — putting it on the root domain does nothing.
Step 4: Send a real test message
Send from your production sending path — the same platform, the same subdomain, the same stream — to a mailbox you control. Don't test from a personal mail client; it won't exercise the same infrastructure.
Step 5: Read the Authentication-Results header
In Gmail, open the message, click the three-dot menu and choose Show original. In Outlook, open the message, go to File → Properties (classic) or the message source view, and find the internet headers.
You're looking for a block like this:
Authentication-Results: mx.google.com;
dkim=pass header.i=@newsletter.acme-example.com header.s=mf2024;
spf=pass (google.com: domain of bounce@mailerflow-example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@mailerflow-example.com;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=newsletter.acme-example.com
Three things to confirm: all three results say pass, the header.i= / header.d= DKIM domain matches your sending domain, and the header.from= in the DMARC line matches the From address your recipient sees.
Step 6: Cross-check with a hosted checker
An email authentication checker gives you a second opinion and often flags lookup counts or missing tags faster than manual reading. Treat it as a DNS-only view: it can confirm your records are well-formed, but it cannot tell you how receivers treat your live mail. Only the header from a real send does that.
A Worked Example: newsletter.acme-example.com
The following is an illustrative example, not a real customer setup.
Suppose you send a weekly newsletter from newsletter.acme-example.com through a platform whose DKIM selector is mf2024. Your three lookups return:
$ dig TXT newsletter.acme-example.com +short
"v=spf1 include:_spf.mailerflow-example.com ~all"
$ dig TXT mf2024._domainkey.newsletter.acme-example.com +short
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7..."
$ dig TXT _dmarc.acme-example.com +short
"v=DMARC1; p=quarantine; rua=mailto:dmarc@acme-example.com; adkim=r; aspf=r"
Your test message comes back with:
Authentication-Results: mx.example.net;
dkim=pass header.d=acme-example.com header.s=mf2024;
spf=pass smtp.mailfrom=bounce@newsletter.acme-example.com;
dmarc=pass header.from=newsletter.acme-example.com
Reading it line by line: SPF passes because the sending IP is covered by the include: mechanism, and the envelope-from domain newsletter.acme-example.com aligns with the From domain under relaxed alignment. DKIM passes with d=acme-example.com and s=mf2024, which matches the selector you published. DMARC passes because at least one aligned identifier passed — here, both did.
Now the broken variant. Same domain, but the platform sends with a shared bounce domain as the envelope-from:
Authentication-Results: mx.example.net;
dkim=pass header.d=acme-example.com header.s=mf2024;
spf=pass smtp.mailfrom=bounce@mailerflow-example.com;
dmarc=fail header.from=newsletter.acme-example.com
SPF passed, but it passed for mailerflow-example.com, which does not align with newsletter.acme-example.com. DMARC failed. The fix is one of two things: configure your platform to use an aligned Return-Path (a CNAME on your own subdomain pointing at the platform's bounce domain is the usual approach), or rely on DKIM alignment — which is already working here, so DMARC would pass on the strength of the DKIM line alone if SPF weren't the only thing being evaluated. In practice, aligning both is the durable answer, because forwarded mail often breaks SPF while DKIM survives.
How to Confirm It Actually Works in Production
A single passing test proves the setup at that moment, not that it holds. Three things to do next.
Send to several providers. Gmail, Outlook and Yahoo evaluate alignment and policy slightly differently, and a message that passes in one inbox can fail in another.
Read your DMARC aggregate reports. The rua= address starts receiving XML reports within a day or two. They show every IP and domain sending as you — including ones you forgot about, like an old form handler or a CRM you stopped using.
Check every stream. Transactional and marketing mail often use different subdomains. If mail.acme-example.com authenticates but newsletter.acme-example.com doesn't, only half your mail is protected.
Re-run the checks after any DNS change, platform migration or new sending integration. Mailerflow monitors sending reputation and automatically suppresses bounces and complaints, which cuts down the noise in your reports — but it doesn't replace reading them.
Common Mistakes and How to Fix Them
Two SPF records. Symptom: SPF fails everywhere. Cause: a second v=spf1 TXT record was added instead of editing the first. Fix: merge both into one record.
Over the 10-lookup limit. Symptom: permerror in the SPF result. Cause: too many include: mechanisms. Fix: remove unused services, or flatten the record into ip4/ip6 entries (and remember to update it when IPs change).
Wrong selector. Symptom: no DKIM record found. Cause: the selector in your DNS doesn't match what the platform signs with. Fix: copy the exact selector from your platform's documentation or dashboard.
Revoked or short key. Symptom: dkim=permerror or a signature that never validates. Cause: an empty p= value, or a key below the commonly required length. Fix: regenerate the key pair and republish.
DMARC on the wrong host. Symptom: no DMARC record found even though you added one. Cause: it was published on the root domain instead of _dmarc.yourdomain.com. Fix: move it.
p=none left in place forever. Symptom: nothing fails, but nothing is protected either. Cause: p=none is a monitoring mode, not a destination. Fix: once reports are clean, move to p=quarantine, then p=reject.
Forwarding breaking SPF. Symptom: failures on mail that was forwarded. Cause: SPF doesn't survive forwarding, because the forwarding server isn't in your record. Fix: this is exactly why DKIM matters — it usually does survive, and DMARC only needs one aligned pass.
Subdomain gaps. Symptom: the root domain is protected but a subdomain isn't. Cause: subdomains don't inherit the parent policy the way people assume; sp= sets a separate subdomain policy. Fix: publish explicit records for each sending subdomain.
FAQ
How long do DNS changes take to propagate? Usually minutes, but TTL values can push it to a few hours. If a lookup still shows the old value, check the TTL on the record and wait it out rather than re-editing.
Can SPF pass and DMARC still fail? Yes — that's the alignment case shown above. SPF passed for a domain that doesn't align with the visible From domain.
Do I need DKIM if SPF passes? Yes. SPF breaks on forwarding; DKIM usually survives it. Having both means DMARC still passes when one path fails.
What does p=none actually do? It tells receivers to deliver the message regardless and just send you reports. It's a data-collection setting, not a protection setting.
Why does my email pass in one inbox and fail in another? Providers evaluate alignment and apply policy differently, and some apply stricter checks to bulk senders. Test across at least three providers.
Do I need separate records for a subdomain? Yes. Each sending subdomain needs its own SPF and DKIM records, and its own DMARC record or an inherited subdomain policy.
Next Steps
Fix any failing record today, then send a test to three providers and read the headers. Set up a rua= address you'll actually open, and schedule a re-check in 30 days — after a platform change, sooner.
This article is the entry point of the Authentication Checks cluster; supporting pieces on reading DMARC reports, managing SPF lookup limits and alignment in practice will be linked here as they publish.
If you'd rather not hand-edit DNS, Mailerflow's own-domain sending walks you through DKIM, SPF and DMARC setup and verifies the records automatically. You can see how that works on the deliverability page.
