SPF Record Check, DKIM, and DMARC: How to Test, Read, and Fix Your Domain
An SPF record check is the first step to figuring out why your business emails land in spam or how scammers spoof your domain. If you run a business, ignoring DNS records puts your email deliverability at risk. Major email providers now require strict authentication for anyone sending mail to their users.
The real-world consequence: failing to configure these records means your invoices, marketing emails, and daily communications disappear into junk folders or get rejected entirely. This guide explains how to test your domain, read the technical results, and fix the errors that hurt your deliverability. While many online tools can run a scan, this guide will help you understand what the results mean for your business.
The Three Records at a Glance
Before you tackle the technical details, you need to know what you are looking for. Here is the short version of what these three records do.
- SPF (Sender Policy Framework): This record publishes a list of approved IP addresses that are allowed to send email on behalf of your domain.
- DKIM (DomainKeys Identified Mail): This record uses a private key to sign your messages so receiving servers can verify the content was not altered in transit.
- DMARC (Domain-based Message Authentication, Reporting, and Conformance): This record requires the sender domain to match your SPF or DKIM records and enforces a policy for emails that fail the test.
You can check all three of these records right now using the free self-assessment. If you want to understand exactly what the tool is telling you and how to fix any issues it finds, keep reading.
SPF Record Check: How to Test Your Sender Policy Framework
If you are wondering what is an SPF record, it is a protocol defined in RFC 7208. Domain owners publish DNS TXT records authorizing specific mail servers by their IP address to send email on behalf of their domain. Receiving mail servers then check the MAIL FROM (envelope sender) domain against that published list.
To perform an email SPF record check, you can use command-line tools like nslookup or dig, or run an online SPF record lookup. When you check domain SPF record data, you are looking for a specific TXT record attached to your root domain that starts exactly with v=spf1.
A typical record might look like this: v=spf1 include:spf.protection.outlook.com -all.
The “all” Qualifier: Your SPF Policy Strength
When you learn how to check SPF record syntax, you must pay close attention to the “all” qualifier at the very end of the string. This tells receiving servers how strictly to treat IP addresses that are not explicitly listed in your record.
| Qualifier | Name | What it Means | Risk Level |
|---|---|---|---|
-all | Fail | Only listed servers are authorized. Anything else should fail authentication. | Most secure setting |
~all | Softfail | Unlisted servers are not authorized, but the message might still be accepted and marked as suspicious by the receiver. | Moderate risk |
+all | Pass | Any server in the world can send email on your behalf. | Massive risk, defeats the purpose of having an SPF record |
?all | Neutral | You are stating no policy either way. | No protection |
You also need to watch out for the strict lookup limit. Receiving servers may treat a PermError as a complete failure, causing your legitimate emails to bounce.
SPF evaluation allows a maximum of 10 DNS lookups (RFC 7208, section 4.6.4).
include,a,mx,ptr,exists, and the redirect modifier each count as one. Go over 10 and you get a PermError.
How to Check Your DKIM Record
A DKIM record check operates differently because you cannot query your root domain to find it. DKIM (DomainKeys Identified Mail, RFC 6376) lets a sending domain cryptographically sign a message using a private key.
The corresponding public key is published in your DNS. Receiving servers verify the signature to confirm that specified header fields, including the from address, and the message body were not altered in transit.
Because you might have multiple services sending email for you (like Microsoft 365 for daily mail and Mailchimp for marketing), you can have multiple DKIM keys. These are organized using selectors.
Find Your DKIM Selector
To check your DKIM record, you need to know your selector. Common providers use predictable selectors:
- Microsoft 365 often uses selector1 or selector2.
- Google Workspace typically uses Google.
You would query the DNS TXT record at selector1._domainkey.yourdomain.com. The result will start with v=DKIM1 followed by the public key data (usually denoted by p=). If this record is missing or the public key does not match the private key signing your emails, the DKIM check will fail.
How to Check Your DMARC Record
A DMARC record check is straightforward. You query the TXT record at the _dmarc subdomain (for example, _dmarc.yourdomain.com).
DMARC (RFC 7489) ties SPF and DKIM to the RFC5322 From address via an alignment check. It lets domain owners publish a policy for failing messages, and it enables aggregate and forensic reporting back to the sender.
Your DMARC record must start with v=DMARC1. The most critical part of the record is the p= tag, which defines your policy level.
| Tag | Action | When to Use |
|---|---|---|
p=none | Receiving servers take no action on failing messages. The domain owner receives reports, but messages are still delivered normally. | Monitoring during initial DMARC deployment |
p=quarantine | Receiving servers treat failing messages as suspicious. They are typically routed to the spam or junk folder rather than the inbox. | Once you have reviewed your reports and are ready to act on failures |
p=reject | Receiving servers outright reject messages that fail DMARC checks, ideally at the SMTP transaction level before the message is accepted. | After you are confident all legitimate senders are correctly authenticated |
You might also see a pct tag in the record. The DMARC pct tag is a plain-text integer from 0 to 100 (defaulting to 100). It controls the percentage of the domain’s mail stream to which the published policy is applied, enabling a gradual rollout.
Per RFC 7489 section 6.6.4, messages not selected for reject due to pct sampling should be treated as though p=quarantine applies. The pct tag must never be applied to DMARC-generated aggregate or forensic reports.
Finally, DMARC alignment requires the domain in the RFC5322 From address to match the domain validated by SPF (the MAIL FROM domain) or DKIM (the d= signing domain).
Relaxed alignment allows organizational domain matches, such as a subdomain of the From domain passing. Strict alignment requires an exact domain match. Read about what DMARC does (our guide) for the full mechanics.
Reading Results: What Pass and Fail Mean
Running an SPF record validator is only helpful if you know how to interpret the output. When you run an SPF record syntax check, you will see combinations of passes and fails that dictate whether your email reaches the inbox or gets blocked.
If SPF and DKIM both pass and DMARC aligns, your email is highly likely to be delivered. If SPF fails but DKIM passes and aligns, DMARC still passes. DMARC only requires one of the two underlying protocols to pass and align.
If both fail, DMARC fails and the receiving server applies your published policy. If you are experiencing unexpected delivery drops, review why emails fail DMARC (our troubleshooting guide).
Failing these checks has severe consequences for deliverability today. Major providers enforce strict rules to protect their users from spam. Google and Yahoo now hold bulk senders to the same authentication bar.
Here is how the two biggest inbox gatekeepers compare.
| Requirement | Yahoo | |
|---|---|---|
| SPF and DKIM | Required for all bulk senders | Required, with valid SPF and DKIM authentication |
| DMARC minimum | A DMARC record is required; p=none is acceptable | A DMARC record with at least p=none, plus From-domain alignment with SPF or DKIM |
| Spam rate ceiling | Below 0.10 percent in Postmaster Tools, with 0.30 percent as a hard ceiling | Below 0.30 percent complaint rate |
| One-click unsubscribe | Required in marketing messages (RFC 8058) | Required, with functioning list-unsubscribe headers honored within 2 days |
| Enforcement date | Began February 1, 2024, for bulk senders (close to 5,000 or more messages per day to personal Gmail accounts within 24 hours) | Began February 2024, with no specific daily volume threshold published |
Google’s spam-rate enforcement is punitive and persistent. Miss the 0.30 percent ceiling and you become ineligible for mitigation. Eligibility returns only after you maintain a rate below 0.30 percent for seven consecutive days.
Google also required bulk senders to implement RFC 8058 one-click unsubscribe by June 1, 2024. Google enforces these requirements with temporary and permanent rejections for non-compliant senders.
Yahoo also requires valid forward and reverse DNS records on top of the authentication basics above.
Poor authentication can also land your sending IP addresses on severe blocklists. The Spamhaus ZEN blocklist is a combined DNS blocklist (DNSBL) that merges four Spamhaus IP lists into one enterprise-grade threat feed:
- Spamhaus Blocklist (SBL) — known spam sources, snowshoe spam, and bulletproof hosting
- Combined Spam Sources (CSS)
- Exploits Blocklist (XBL) — IPs used by hijacked or malware-compromised devices
- Policy Blocklist (PBL) — end-user IP ranges not expected to send direct SMTP
An IP listed in ZEN is typically rejected by receiving mail servers during the SMTP connection phase, blocking delivery regardless of content or authentication.
Fixing Common Domain Security Failures
When you check SPF record health, you will likely find a few common SPF record errors. Fixing these is essential for maintaining your business communications.
| Error | What’s Wrong | Fix |
|---|---|---|
| Missing records | SPF, DKIM, and/or DMARC records are not published. | Add the appropriate TXT records to your DNS host for SPF, DKIM, and DMARC. |
| Weak SPF policies | Your record ends in +all or ?all, leaving your domain wide open to spoofing. | Tighten it to ~all or -all once you are sure all legitimate sending services are included in your record. |
| The lookup limit | The error for SPF record too many DNS lookups is common. As businesses add marketing tools, CRM systems, and ticketing platforms to their SPF record via the include mechanism, they quickly exceed the 10-lookup limit. | Remove unused services, flatten the record into raw IP addresses, or use a dynamic SPF management tool. |
| Stuck on p=none | Many businesses publish a DMARC record with p=none and never move forward. It satisfies basic compliance for Google and Yahoo, but it does nothing to stop scammers from spoofing your domain. | Review your DMARC reports and eventually move forward with choosing your DMARC policy level of quarantine or reject. |
See Where You Stand
Free Email Domain Security Grader: enter your domain, we check your real SPF, DKIM, and DMARC records and grade your spoofability in seconds. free SPF, DKIM, and DMARC domain check
Related Guides
- How to Stop Email Spoofing of Your Business Domain
- Business Emails Going to Spam? Blacklists and Auth Fixes
- DMARC Policy: None vs Quarantine vs Reject Explained
Frequently Asked Questions
How do I check my SPF record?
You can check your SPF record using command-line tools like nslookup or dig, or by using an online DNS lookup tool. You need to query the TXT records for your domain and look for a string that begins with v=spf1. This record will list the authorized IP addresses and include statements for your approved sending services.
What is a SPF check?
An SPF check is a process performed by receiving mail servers to verify that an incoming email comes from an authorized IP address. The server looks up the sender’s domain in DNS, retrieves the SPF record, and checks if the sending server’s IP is listed. If the IP is missing, the check fails.
What should an SPF record look like?
A standard SPF record is a DNS TXT record that starts with v=spf1. It is followed by mechanisms that authorize specific senders, such as include statements for your email provider. It should end with an all qualifier, typically ~all or -all, to define how unauthorized senders should be treated.
How to check SPF record command line?
You can check your SPF record from the command line using the nslookup or dig commands. For example, typing “dig TXT yourdomain.com” in a terminal will return all TXT records for your domain. You can then scan the output for the record beginning with v=spf1.
What is a good SPF record?
A good SPF record accurately lists all legitimate sending sources for your domain without exceeding the 10-lookup limit. It should not contain deprecated mechanisms like ptr, and it must end with a strict policy like -all or ~all to prevent unauthorized servers from spoofing your domain.
How to clean up SPF records?
To clean up your SPF records, start by auditing the include statements and removing any third-party services you no longer use. If you are still hitting the 10-lookup limit, you may need to replace include statements with direct IP addresses (a process called flattening) or use a dynamic SPF management service.
Protect Your Domain and Deliverability
LeadingIT is a Chicagoland managed it and cybersecurity provider that has helped Illinois businesses since 2010. We serve roughly 200 organizations and 2,500+ users from our offices in Woodstock and Manteno.
We configure and enforce SPF, DKIM, and DMARC for client domains as part of LeadingIT’s managed cybersecurity services, and we monitor deliverability and spoofing attempts to keep your business secure. If you need help locking down your email infrastructure, contact us or book a call at 815-788-6041.
