Before You Buy Solo Ads: Verify DKIM and SPF With a Test Email

Check SPF by pulling the TXT record at your root domain and check DKIM by querying selector._domainkey on your DNS. Then send a real test message and confirm both dkim=pass and spf=pass appear in the Authentication-Results header. A DNS lookup only proves the records exist. Only a delivered message proves your mail server is actually signing and passing authentication the way it should.

---

TL;DR:

• A DNS lookup confirms only that SPF and DKIM records exist; actual message delivery and passing authentication verify proper setup and signing.
• A valid SPF record must have one v=spf1 entry ending with ~all or -all, avoiding +all, and must not exceed 10 DNS lookups.
• DKIM authenticity depends on matching the selector with a published v=DKIM1 TXT record containing a p= key and real signing during message transit.
• Running a test email through headers to confirm dkim=pass and spf=pass in the Authentication-Results header is essential for genuine verification.
• Always verify DMARC alignment to ensure the domain used in SPF or DKIM matches the visible From domain, otherwise messages might still fail authentication despite passing individual checks.

---

Table of Contents

• Tools and Quick Checks for SPF and DKIM
• How to Check an SPF Record Step by Step
• How to Check a DKIM Record and Find the Selector
• Verify With a Real Message: Reading Authentication-Results
• Troubleshooting the Usual DNS and Selector Problems
• Why You Should Check DMARC Alignment Next
• Why This Matters When You're Buying Solo Ad Traffic
• Verification Beats Trust Every Time
• A Practical Next Step: SoloAdsGuide's Vetting Resources
• Sources
• FAQ

Tools and Quick Checks for SPF and DKIM

Before you dig into DNS syntax, run a fast pass with tools built for this exact job. Each one answers a different question, and knowing which to reach for saves you time.

• SPF record checker: pulls the TXT record at your root domain and flags obvious syntax errors.
• DKIM lookup tool: queries selector._domainkey and returns the public key, though it needs the correct selector to work.
• Mail header analyzer: parses a raw message header and shows you exactly what a receiving server saw.
• Send-a-test-email service: mails a message to an inbox that reports back pass/fail results automatically.

Use a DNS lookup first, since it is instant and tells you whether a record exists at all. Reach for a test message when the DNS check looks fine but delivery problems persist. That gap between "record exists" and "signature verifies" is where most real deliverability issues hide.

How to Check an SPF Record Step by Step

Your SPF record lives as a TXT entry at the root of your sending domain, not a subdomain. Query it with a command like dig TXT example.com or paste your domain into any web-based SPF record lookup tool. You are looking for a single line starting with v=spf1.

A healthy record looks something like v=spf1 include:_spf.google.com ~all. That structure tells receiving servers which services are authorized to send on your behalf, and the tag at the end (~all for soft fail or -all for hard fail) tells them what to do with anything that does not match. A record ending in +all is a red flag. It authorizes literally any server to send as your domain, which defeats the purpose of SPF entirely.

1. Query the TXT record at your root domain using dig, nslookup, or a browser-based tool.
2. Confirm there is exactly one v=spf1 record. Multiple SPF records at the same domain cause a permerror under RFC 7208, and the whole check fails.
3. Run the record through an SPF evaluator like the Kitterman SPF validator, which does more than a raw TXT display. It expands every include: mechanism and counts DNS lookups against the RFC 7208 limit of 10.
4. Watch for a permerror result. It almost always means either duplicate SPF records or too many nested includes pushing you past that 10 lookup ceiling.

Pro Tip: If you've added several third-party senders (a CRM, a support tool, an email marketing platform) over the years, merge them into one SPF record instead of stacking separate ones. A second v=spf1 line breaks the whole check, not just the newest addition.

How to Check a DKIM Record and Find the Selector

DKIM verification starts with a piece of information SPF checks do not need: the selector. You will find it as the s= tag inside a DKIM-Signature header on any message your domain has already sent, or you can pull it directly from your email provider's dashboard.

Once you have the selector, the DNS lookup pattern is fixed: query selector._domainkey.example.com as a TXT record. A valid response looks like v=DKIM1; p= followed by a long public key string. No key, or an empty response, means either the selector is wrong or DKIM was never set up for that record.

• Extract the selector from a DKIM-Signature header (look for s=) or your provider's admin panel.
• Query selector._domainkey.yourdomain.com and confirm you get back a v=DKIM1 TXT record with a populated p= value.
• Do not be alarmed if you find more than one selector published at once. RFC 6376 allows multiple concurrent keys specifically to support key rotation, so old and new selectors can legitimately coexist during a transition window.
• If you are guessing at common selector names instead of using the real one, expect failures. Providers like Amazon SES often use randomized selectors that no generic checker will find without the actual message or dashboard access.

Pro Tip: When a DKIM lookup tool reports "undetectable," that usually means the selector is nonstandard, not that DKIM is missing. Pull the real selector from a sent message before concluding anything is broken.

A DNS lookup only confirms the key is published. It does not confirm any message was actually signed with the matching private key, which is why the next step matters.

Verify With a Real Message: Reading Authentication-Results

DNS presence and actual signing are two different things, and conflating them is the single most common mistake in email authentication checks. A published DKIM key proves nothing about whether your mail server is using the matching private key correctly. Only a delivered message settles that.

1. Send a test email to a mailbox you control (Gmail works well) or to a dedicated email testing service.
2. Open the raw headers. In Gmail, click the three-dot menu on the message and select "Show original."
3. Locate the Authentication-Results header and check for dkim=pass and spf=pass.
4. Confirm the d= value in the DKIM result matches your sending domain, and the s= value matches a selector you recognize.

Gmail's sender guidelines recommend setting up SPF, DKIM, and DMARC together, and they note that messages failing authentication risk landing in spam or being rejected outright. That is the practical cost of skipping the message-level check: a domain can look perfectly configured in DNS and still get flagged if the signing process itself is broken.

Troubleshooting the Usual DNS and Selector Problems

Most SPF and DKIM failures trace back to a handful of repeat offenders. Work through these before assuming something deeper is wrong.

• DNS propagation delays: changes to TXT records can take time to spread, and caching means a checker might return stale results for a while after you publish an update.
• Wrong nameserver edited: confirm you changed records at the authoritative DNS provider, not a secondary dashboard that no longer controls resolution for the domain.
• Selector mismatch: a DKIM check using the wrong selector reports failure even when a different, active selector is working fine. Always pull the selector from an actual sent message.
• Multiple SPF records: this triggers a permerror under RFC 7208. Merge every authorized sender into one record instead of publishing two.
• Excessive lookups: too many nested include: statements push you past the 10-lookup SPF ceiling, and the record silently fails.
• TXT truncation: some DNS provider interfaces split long TXT values incorrectly. Check the raw zone file if a record looks right in a checker but wrong when queried directly.

Pro Tip: If a record looks correct in your registrar's dashboard but public tools can't find it, verify you're editing the domain's actual authoritative nameservers. Mismatched or outdated nameserver assignments are a frequent, invisible cause of "it looks fine but nothing works."

Why You Should Check DMARC Alignment Next

Once SPF and DKIM both pass individually, check DMARC alignment before declaring victory. DMARC lives at _dmarc.yourdomain.com as a TXT record, and it checks whether the domain that passed SPF or DKIM actually matches the domain visible in the From address.

Alignment failures are sneaky. A message can pass SPF for a third-party sending service and pass DKIM under that same service's domain, yet still fail DMARC because neither one aligns with the domain your recipient actually sees. If that happens, Google's DMARC guidance confirms the message can still be treated as unauthenticated, regardless of the individual SPF and DKIM results.

Why This Matters When You're Buying Solo Ad Traffic

Checking SPF and DKIM is not just a technical exercise. It is one of the fastest ways to tell whether a traffic vendor's sending infrastructure is actually legitimate, before you spend a dollar.

• Ask a prospective vendor for a sample signed message and check the headers yourself.
• Confirm the selector and domain in d= match what they claim to send from.
• Verify Authentication-Results shows real passes, not just a domain that has SPF published somewhere.
• Cross-check click tracking against the sending domain to catch mismatches early.

This lines up directly with the 21-question vendor vetting framework built for exactly this kind of pre-purchase verification.

Verification Beats Trust Every Time

Most people treat SPF and DKIM as a one-time setup task, and that is where they go wrong. Records drift. Selectors rotate. A vendor's DNS can look flawless on a Tuesday and break by Friday because someone touched the wrong nameserver. I have never found a vendor claim about deliverability that held up better than five minutes of checking raw headers myself.

The pattern that matters isn't the DNS record. It's whether you actually looked before you trusted. Combine the DNS check with a real message header inspection every time, especially before you commit budget to a sender you don't control.

— Philip Coble

A Practical Next Step: SoloAdsGuide's Vetting Resources

Soloadsguide exists because SPF and DKIM checks answer only half the question when you're buying traffic. They tell you a vendor's domain can authenticate mail. They do not tell you whether that vendor's list is fresh, whether their clicks are real, or whether their claims about response rates hold up.

This site fills that gap with a buyer-first approach: a vendor vetting framework, domain warming guidance, and click verification methods built specifically for people spending money on solo ad traffic. If you've just confirmed a vendor's SPF and DKIM setup checks out, the next move is running their claims through the vendor vetting framework and reviewing how sender reputation risk factors into your decision before you buy. Start there before you send a single dollar to a new source.

Sources

For the technical specifics behind everything above, go straight to the standards: RFC 6376 covers DKIM signatures and selector rotation, and RFC 7208 defines SPF evaluation and lookup limits. For platform-specific guidance, see Google Workspace's spam and spoofing prevention guide and the Kitterman SPF validator for hands-on record testing.

• RFC 7208: Sender Policy Framework (SPF)
• Gmail Help: Email sender guidelines
• Verify SPF, DKIM and DMARC records and fix common DNS mistakes — Hunter Help

FAQ

Do You Need Both SPF and DKIM?

Yes. SPF confirms which servers are authorized to send for your domain, while DKIM confirms the message content was not altered in transit. Google Workspace guidance frames them as complementary, not interchangeable, and using only one leaves a real gap in authentication coverage.

How Can I Check the DKIM Record for a Domain?

Get the selector from a sent message's DKIM-Signature header or your email provider's dashboard, then query selector._domainkey.yourdomain.com as a TXT record. A valid response starts with v=DKIM1 and includes a populated public key under the p= tag.

How Do I Tell if DKIM Is Actually Working?

A DNS record alone does not prove DKIM is functioning. Send a test message to an inbox you control, open the raw headers, and confirm the Authentication-Results line shows dkim=pass with a d= value matching your domain.

How Do I Check if a Domain Has SPF?

Query the TXT record at the domain's root using dig, nslookup, or any SPF record lookup tool, and look for a line starting with v=spf1. If nothing comes back, or if you find more than one SPF record, that domain does not have a working SPF setup.

Recommended

• How to Test Order Solo Ads Without Wasting Your Budget
• Marketers: Verify Solo Ad Traffic With a 100 to 200 Click Test
• Solo Ad Buyers: 50–200 Click Test and 21 Questions to Verify Leads