How to Check SPF, DKIM and DMARC Records

Why SPF, DKIM, and DMARC matter

Together, these three records form the foundation of email authentication. Without them:

• Anyone can send email pretending to be from your domain (spoofing)
• Gmail, Outlook, and other providers are more likely to mark your emails as spam
• You have no visibility into who is sending email on your behalf
• Since 2024, Google and Yahoo require DMARC for bulk senders — missing records cause delivery failures

Setting all three correctly gives you a deliverability score that determines whether your emails reach the inbox or the spam folder.

How to check your SPF record

SPF (Sender Policy Framework) is a TXT record on your domain that lists which mail servers are authorized to send email on your behalf. Receiving mail servers check your SPF record to verify that the sending server is on the approved list.

Check SPF via command line

# macOS / Linux
dig TXT yourdomain.com | grep spf

# Windows
nslookup -type=TXT yourdomain.com

A valid SPF record looks like this:

v=spf1 include:_spf.google.com include:mailgun.org ~all

What to look for:

• Starts with v=spf1
• Includes your mail provider's SPF hostname (Google, Zoho, Mailgun, etc.)
• Ends with ~all (softfail — suspicious but not rejected) or -all (hardfail — rejected)
• Does NOT end with +all — this allows anyone to send as your domain and is dangerous

Common SPF problems

Too many DNS lookups: SPF allows a maximum of 10 DNS lookups per evaluation. Each include: statement counts. If you have multiple mail providers, you may hit this limit. The fix is to "flatten" your SPF record using a tool that resolves the includes into their actual IP ranges.

Multiple SPF records: You should have exactly one TXT record starting with v=spf1. Multiple SPF records cause an SPF permerror and authentication fails entirely.

Missing your sending IP: If you send from a server not listed in your SPF record (e.g. a new marketing platform), those emails will fail SPF. Add include:provider.com for each sending service.

How to check your DMARC record

DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM. It tells receiving servers what to do when authentication fails and provides reporting so you can see who is sending email on your behalf.

Check DMARC via command line

# The DMARC record is always at _dmarc.yourdomain.com
dig TXT _dmarc.yourdomain.com

# Windows
nslookup -type=TXT _dmarc.yourdomain.com

A valid DMARC record looks like this:

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

The key tags:

• p=none — monitor only, no action taken (good starting point)
• p=quarantine — failing emails go to spam
• p=reject — failing emails are rejected entirely (strongest protection)
• rua= — email address to receive aggregate reports (highly recommended)
• pct= — percentage of emails the policy applies to (useful during rollout)

DMARC rollout strategy

Don't jump straight to p=reject. The recommended approach:

1. Start with p=none; rua=mailto:dmarc@yourdomain.com — collect reports for 2-4 weeks
2. Review reports to identify all legitimate sending sources
3. Ensure all sources pass SPF or DKIM
4. Move to p=quarantine; pct=10 — apply to 10% of mail initially
5. Gradually increase pct to 100, then move to p=reject

How to check your DKIM record

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing emails. The public key is published as a DNS TXT record; receiving servers use it to verify the email hasn't been tampered with in transit.

Unlike SPF and DMARC, the DKIM record location depends on a selector — a string provided by your email service provider. You need to know your selector before you can look up the record.

Finding your DKIM selector

Common selectors by provider:

• Google Workspace: google
• Microsoft 365: selector1 and selector2
• Zoho Mail: zoho
• Mailgun: mail or smtp
• SendGrid: s1 or s2
• Postmark: check your Postmark domain settings

You can also find the selector by looking at the email headers of an email you've already sent. Look for the DKIM-Signature header — the s= tag shows the selector.

Check DKIM via command line

# Replace SELECTOR with your actual selector
dig TXT SELECTOR._domainkey.yourdomain.com

# Example for Google Workspace
dig TXT google._domainkey.yourdomain.com

A valid DKIM record contains a public key:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...

Check all three at once

Rather than running separate DNS queries, use InfiniUm's DNS Health Monitor to check SPF, DKIM, DMARC, MX, and CAA records simultaneously. It probes 16 common DKIM selectors automatically, calculates a deliverability score from 0-100, and gives you specific fix recommendations for each issue it finds.

What a healthy email DNS setup looks like

# SPF — single TXT record on the root domain
v=spf1 include:_spf.google.com ~all

# DMARC — TXT record at _dmarc.yourdomain.com
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100

# DKIM — TXT record at selector._domainkey.yourdomain.com
v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEY_HERE

# MX records — point to your mail provider
10 smtp.google.com
20 smtp2.google.com

Troubleshooting: emails still going to spam

If all three records check out but emails are still hitting spam, the problem is likely elsewhere:

• Sender reputation: new domains and IPs have no history — warm up gradually by starting with small volumes
• Content filtering: spam-like subject lines, excessive links, or certain phrases trigger content filters regardless of authentication
• IP blacklisting: check if your sending IP is on a blacklist using a service like MXToolbox Blacklist Check
• List hygiene: high bounce rates signal poor list quality, which damages sender reputation over time