Your emails are not reaching the inbox. You check your server — everything looks fine. No error messages, no bounces logged. But somewhere between your mail server and the recipient's inbox, your messages are dying silently. The cause is almost always the same: your IP or domain is failing SPF, DKIM, or DMARC checks — and getting quietly rejected or blacklisted as a result. In 2026, these three email authentication standards are not optional extras. They are the gatekeepers that every major inbox provider uses to decide whether your email is legitimate or spam.
The problem is that SPF, DKIM, and DMARC failures are invisible to most senders. Your mail server reports a successful send. The recipient's server silently discards or spam-folders the message. No bounce, no alert, no error — just silence. And while your emails vanish, your IP reputation deteriorates with every failed authentication. Enough failures, and you end up on a blocklist that takes days or weeks to escape. Knowing how to check your SPF, DKIM, and DMARC status — and interpret what you find — is the difference between an inbox that works and a sending reputation in freefall.
This complete 2026 guide explains what SPF, DKIM, and DMARC actually do, how authentication failures lead to IP blacklisting, the exact tools and methods to check your current authentication status, how to read and interpret DNS records, what a DMARC report tells you about your mail flow, and the step-by-step fixes for every common failure type. By the end, you will know exactly where your email authentication stands — and how to fix anything that is broken.
"SPF, DKIM, and DMARC failures are the silent killers of email deliverability. In my work investigating compromised mail infrastructure, I see the same pattern constantly: a business has been sending emails for years, slowly building reputation, then one misconfigured DNS record or a missing DKIM selector quietly unravels everything. By the time someone notices, the IP is already on multiple blocklists and the domain reputation at Gmail and Microsoft is damaged.
The frustrating truth is that checking your SPF, DKIM, and DMARC authentication takes about ten minutes and costs nothing. Yet most businesses never do it until something breaks. Since 2024, Gmail and Yahoo require all bulk senders to have SPF, DKIM, and DMARC configured — no exceptions. Microsoft followed suit in 2025. In 2026, missing any of these three records means your email is not just filtered as spam — it is increasingly rejected outright before it even reaches the spam folder. Run the checks. Fix what is broken. Your entire email operation depends on it."
Quick Answer: How to Check SPF, DKIM & DMARC Status
To check if your IP or domain has SPF, DKIM, or DMARC issues causing blacklisting: (1) Use TrustMyIP DNS Lookup to query your TXT records for SPF and DMARC. (2) Check your DKIM selector record by querying selector._domainkey.yourdomain.com. (3) Run a full IP blacklist check to see if authentication failures have already caused listings. (4) Send a test email to check-auth@verifier.port25.com for a free automated authentication report. Authentication failures do not directly cause IP blacklisting — but they allow spam to flow through your domain unchecked, which then triggers blacklisting indirectly. Fix SPF first, then DKIM, then DMARC — in that order.
1. SPF, DKIM, and DMARC: What They Actually Do
Before you can check whether your authentication is working, you need a clear picture of what each standard actually does — and why failure matters. These are not interchangeable. They work as a layered system, each solving a different piece of the email trust problem.
Think of email authentication as a three-lock security system. SPF controls which servers are allowed to send email for your domain. DKIM proves that email content has not been tampered with in transit. DMARC tells recipient servers what to do when SPF or DKIM fails — and gives you visibility into who is sending email in your domain's name. Together, they make email spoofing and domain impersonation dramatically harder.
| Standard | What It Does | Where It Lives | Failure Consequence |
|---|---|---|---|
| SPF | Lists authorized sending servers for your domain | DNS TXT record at root domain | Email marked suspicious or rejected; DMARC alignment fails |
| DKIM | Cryptographically signs email to prove content integrity | DNS TXT record at selector._domainkey subdomain | Email unverifiable; spam score increases; DMARC alignment fails |
| DMARC | Enforces SPF/DKIM policy and sends reports to domain owner | DNS TXT record at _dmarc subdomain | No enforcement of spoofing; no visibility into auth failures |
SPF — Sender Policy Framework
SPF works by publishing a list of IP addresses and hostnames that are authorized to send email for your domain. When a recipient mail server receives a message claiming to be from @yourdomain.com, it looks up your SPF record and checks whether the sending IP is on the approved list.
An SPF record looks like this:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.5 ~all
The ~all at the end is a softfail — meaning unauthorized servers are flagged but not hard-rejected. -all is a hard fail — unauthorized senders are rejected outright. Using ~all is safer during setup; switch to -all once you have confirmed all legitimate senders are listed.
DKIM — DomainKeys Identified Mail
DKIM uses public-key cryptography. Your mail server signs outgoing emails with a private key. The corresponding public key is published in your DNS. When a recipient server receives your email, it fetches your public DKIM key and uses it to verify the signature in the email header.
A DKIM DNS record looks like this:
mail._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."
The mail part is called the selector. You can have multiple DKIM selectors — one per sending service. Google uses google, Mailchimp uses k1, SendGrid uses s1. You must know your selector to check your DKIM record correctly.
DMARC — Domain-based Message Authentication
DMARC ties SPF and DKIM together. It specifies what a receiving server should do when an email fails both SPF and DKIM alignment — and critically, it tells receiving servers where to send reports about authentication results. Those reports show you who is sending email from your domain, including unauthorized senders.
A DMARC record looks like this:
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; ruf=mailto:forensic@yourdomain.com; pct=100
The p= tag is the policy: none (monitor only), quarantine (send to spam), or reject (block completely). Start at none to collect data, then escalate to quarantine and finally reject once you are confident all legitimate mail is authenticated.
2. How Authentication Failures Lead to IP Blacklisting
SPF, DKIM, and DMARC failures do not directly cause IP blacklisting in most cases. The relationship is more indirect — but just as damaging. Understanding the chain of events helps you see why authentication is inseparable from IP reputation.
Authentication Failure → Blacklisting: The Chain Reaction
1 No Authentication = Open Door for Spoofing
Without SPF and DKIM, anyone can send email claiming to be from your domain. Spammers and phishing operations actively scan for domains without authentication and use them as cover for campaigns. Your domain sends zero spam — but spam is sent in your domain's name from completely different servers.
Result: Blocklists see spam coming from your domain. Your domain reputation drops. IPs legitimately used by your domain get associated with the spam activity through shared domain reputation signals.
2 SPF Failure Raises Spam Score on Every Email
When your legitimate mail server's IP is not listed in your SPF record, every email you send generates an SPF fail or softfail. Receiving servers add spam score points for this. Enough of these failures, and Gmail, Outlook, and Yahoo start routing your email to spam folders consistently.
Result: Engagement drops (recipients don't see emails). Low engagement is itself a negative reputation signal. A downward spiral begins even without any actual spam being sent.
3 DMARC at p=none Means No Protection at All
Many domains have DMARC configured at p=none — the monitoring-only policy — and never escalate to p=quarantine or p=reject. This means DMARC sends you reports but does absolutely nothing to block spoofed emails. Recipients still receive phishing emails claiming to be from your domain.
Result: When recipients mark those spoofed emails as spam, the complaint is attributed to your domain. Your domain reputation and sending IP reputation suffer for spam you never sent.
4 Gmail and Yahoo Rejection Since 2024
Since February 2024, Gmail and Yahoo have enforced mandatory SPF, DKIM, and DMARC requirements for all bulk senders (sending over 5,000 emails per day). Senders missing any of these records face outright rejection — not spam filtering, but a hard bounce with an error code.
Microsoft Outlook followed with similar enforcement in 2025. In 2026, operating without all three authentication standards in place means a significant portion of your emails never arrive — regardless of your IP reputation or content quality.
3. How to Check Your SPF Record
Checking your SPF record tells you immediately whether your domain has one, whether it is syntactically valid, and whether your actual sending server's IP is authorized. This is the first authentication check you should always run.
SPF Check — Three Methods
1 Method 1: TrustMyIP DNS Lookup Tool (Fastest)
Go to TrustMyIP DNS Lookup. Enter your domain name and select TXT as the record type. Click Lookup.
What to look for in results:
✅ A TXT record starting with v=spf1 — this is your SPF record
✅ Your mail server's IP or hostname listed (e.g., ip4:203.0.113.5 or include:_spf.google.com)
✅ Ends with ~all or -all
❌ No TXT record starting with v=spf1 = SPF is missing entirely
❌ More than one SPF record = invalid configuration — only one SPF TXT record is allowed per domain
2 Method 2: Command Line (nslookup / dig)
Windows (Command Prompt):
nslookup -type=TXT yourdomain.com
Mac / Linux (Terminal):
dig TXT yourdomain.com +short
Look through the output for any line beginning with "v=spf1. That is your SPF record. If you see nothing starting with v=spf1, SPF is not configured.
3 Common SPF Problems and What They Mean
SPF PermError (too many DNS lookups): Your SPF record exceeds 10 DNS lookups. Each include: statement counts. Too many lookups cause SPF to permanently fail for all recipients. Flatten your SPF record by resolving includes to direct IPs.
SPF softfail (~all) vs hardfail (-all): Softfail means unauthorized senders are flagged but not rejected. For stricter protection, switch to -all once your record is verified correct.
Multiple SPF records: Having two TXT records with v=spf1 causes a permanent SPF error. Merge them into a single record.
Missing sending service: You added a new email marketing tool (Mailchimp, HubSpot, etc.) but never updated your SPF record to include their sending servers.
4. How to Check Your DKIM Record
Checking DKIM is slightly more complex than SPF because you need to know your DKIM selector before you can look up the record. The selector is part of the DNS record name. Different email platforms use different selectors — and you may have multiple DKIM selectors if you use more than one sending service.
| Email Platform | Common DKIM Selector | Full Record to Check |
|---|---|---|
| Google Workspace | google |
google._domainkey.yourdomain.com |
| Microsoft 365 | selector1, selector2 |
selector1._domainkey.yourdomain.com |
| Mailchimp | k1, k2 |
k1._domainkey.yourdomain.com |
| SendGrid | s1, s2 |
s1._domainkey.yourdomain.com |
| Amazon SES | Auto-generated | Check SES console for your selector |
| Custom Mail Server | mail, default |
mail._domainkey.yourdomain.com |
DKIM Check — Step by Step
1 Find Your DKIM Selector First
If you are not sure of your selector, check the raw headers of a sent email. In Gmail, click the three-dot menu on any sent email → "Show original". Look for a line like:
DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=google;
The s= value is your selector. In this example, the selector is google.
2 Look Up the DKIM DNS Record
Use TrustMyIP DNS Lookup. Enter selector._domainkey.yourdomain.com (replace selector with your actual selector) and choose TXT record type.
Or use command line:
dig TXT google._domainkey.yourdomain.com +short
Healthy result looks like: A long TXT record starting with v=DKIM1; k=rsa; p= followed by a long base64-encoded public key string.
3 Interpret What You Find
✅ Record exists with public key: DKIM is configured. Verify the key matches what your mail server is using to sign — if keys are rotated but DNS not updated, signatures will fail verification.
❌ NXDOMAIN (record not found): DKIM is not configured for this selector. Email is being sent unsigned — major deliverability risk in 2026.
❌ Record exists but p= is empty: This signals a revoked DKIM key. All email signed with this selector will fail verification. Generate a new key immediately.
❌ Record found but no DKIM-Signature header in emails: Your mail server is not actually signing emails. Check mail server configuration — the DKIM signing module may be disabled or misconfigured.
5. How to Check Your DMARC Record
DMARC is the simplest record to check because it always lives at the same predictable location: _dmarc.yourdomain.com. But reading and interpreting DMARC correctly — especially understanding what the reports tell you — requires knowing what to look for.
Step 1: Look Up Your DMARC Record
Use Free DNS Lookup, enter _dmarc.yourdomain.com, and choose TXT record type. Or via command line:
dig TXT _dmarc.yourdomain.com +short
No record found? DMARC is not configured — your domain has zero protection against spoofing and you receive no authentication reports.
Step 2: Decode the DMARC Tags
A typical DMARC record contains several tags. Here is what each one means:
| Tag | What It Controls | Recommended Value |
|---|---|---|
p= | Policy for your domain (main) | reject (goal state) |
sp= | Policy for subdomains | reject |
rua= | Aggregate report destination | Your monitoring email |
ruf= | Forensic/failure report destination | Your security email |
pct= | Percentage of mail policy applies to | 100 |
adkim= | DKIM alignment mode | s (strict) |
aspf= | SPF alignment mode | s (strict) |
Step 3: Check DMARC Policy Level
This is the most important thing to verify. p=none means you are collecting reports only — no emails are blocked, no spoofing is stopped. In 2026, this is insufficient. If your DMARC is at p=none and has been for more than three months, you have stayed in monitoring mode too long. Escalate to p=quarantine and set a plan to reach p=reject within 90 days.
6. The Definitive Test: Send a Live Authentication Check
DNS record lookups tell you what is configured. They do not tell you whether your mail server is actually signing emails correctly, whether SPF passes from the actual sending IP, or whether DMARC alignment is achieved. For that, you need a live authentication test.
Live Authentication Test Methods — Use These
Method 1 — Port25 Verifier (Free, Most Detailed):
Send a blank email from your mail server to check-auth@verifier.port25.com. You will receive an automated reply with a full authentication report showing SPF result, DKIM result, DMARC result, SpamAssassin score, and plain-text details of every check performed. This is the most comprehensive free test available.
Method 2 — Gmail Header Analysis:
Send a test email from your mail server to a Gmail address you control. Open the email, click the three-dot menu, and select "Show original". The top of the raw headers will show:
SPF: PASS / FAIL / SOFTFAIL
DKIM: PASS / FAIL
DMARC: PASS / FAIL
This is the fastest live check — results directly reflect how Gmail evaluates your authentication.
Method 3 — Check Your Blacklist Status After Failures:
If you have found authentication failures, run an immediate blacklist check. Use blacklist checker to see whether your IP is already listed anywhere as a consequence of those failures. Authentication problems and blacklisting frequently co-occur.
What a passing result looks like:
spf=pass (domain designates [your.IP] as permitted sender)
dkim=pass header.d=yourdomain.com
dmarc=pass (policy=reject)
All three passing is the only acceptable result for serious email operations in 2026.
7. Reading DMARC Aggregate Reports
If your DMARC record includes an rua= tag pointing to an email address, you will receive DMARC aggregate reports — XML files sent daily by Gmail, Yahoo, Outlook, and other major providers. These reports are gold. They tell you every IP address that sent email claiming to be from your domain, and whether that email passed or failed SPF and DKIM.
What DMARC Reports Tell You
- ✓Authorized senders passing: Your legitimate mail servers with SPF and DKIM passing — healthy
- ✓Unknown IPs sending in your name: Third-party services or spoofers — investigate immediately
- ✓SPF passing, DKIM failing: Mail server not signing — fix DKIM signing config
- ✓Volume of failing messages: Shows scale of the problem — 100 failures per day is very different from 100,000
- ✓Which providers report: Shows coverage — Gmail, Yahoo, Outlook all sending reports means good DMARC adoption
DMARC Report Red Flags
- ✗Unknown IPs with high volume: Active spoofing campaign — escalate DMARC to p=reject immediately
- ✗Your own IP failing SPF: Your IP is not in your SPF record — update SPF immediately
- ✗All DKIM failing from one server: DKIM signing broken on that specific server — check signing configuration
- ✗Third-party tool failing: You added a new marketing tool but did not update SPF/DKIM for it — add their servers
- ✗No reports at all: Either no one is emailing with your domain or your rua= address is wrong — verify the mailbox
Raw DMARC XML reports are difficult to read manually. Use a free DMARC report analyzer — Google's Postmaster Tools, DMARC Analyzer free tier, or Postmark's DMARC reporting tool — to visualize your data clearly. Once you understand what your reports are showing, you can track authentication health over time and catch new sending infrastructure that needs SPF/DKIM configuration before it causes deliverability problems. Pair this ongoing monitoring with regular checks of your IP reputation score to catch any downstream blacklisting that results from authentication gaps.
8. Fix Authentication Failures: The Correct Order
If your checks reveal SPF, DKIM, or DMARC problems, fix them in the right order. The sequence matters because DMARC depends on both SPF and DKIM working correctly first.
Authentication Fix Order — SPF First, Then DKIM, Then DMARC
1 Fix SPF (Foundation — Do This First)
List every IP address and service that sends email for your domain. Create or update your SPF TXT record at your root domain. Include all legitimate senders using ip4: or include: mechanisms.
Keep total DNS lookups under 10. If you use many third-party services, flatten their include statements to direct IPs to save lookup count.
End with ~all during testing, then switch to -all once verified. Wait 48 hours for DNS propagation, then recheck.
2 Fix DKIM (Content Integrity — Do This Second)
Generate a new 2048-bit RSA DKIM key pair in your mail server or email platform settings. Publish the public key as a TXT record at selector._domainkey.yourdomain.com.
Enable DKIM signing in your mail server configuration — this step is separate from publishing the DNS record. Both must be done: DNS record published AND mail server configured to sign outgoing mail.
Send a test email and check headers to confirm DKIM-Signature header appears. Use the Port25 verifier for full confirmation.
3 Configure DMARC (Enforcement — Do This Last)
Only add DMARC after SPF and DKIM are both passing. Adding DMARC with p=reject before your authentication is correct will block your own legitimate email.
Recommended rollout:
Week 1–2: p=none; pct=100 — collect reports, verify all legitimate mail passes
Week 3–6: p=quarantine; pct=10 — apply to 10% of mail, monitor for issues
Week 7+: p=quarantine; pct=100 → then → p=reject; pct=100
4 Check for Blacklisting After Fixing
Once authentication is fully passing, check whether your IP ended up on any blocklists during the period of authentication failure. Run a full check at TrustMyIP blacklist checker to confirm your IP is clean across all major lists.
If you find listings, review our complete guide on how to delist your IP from Spamhaus and handle any other listing removals before resuming full email volume.
Conclusion: Authenticate First, Deliver Reliably
Checking your SPF, DKIM, and DMARC authentication is not a one-time task. It is ongoing maintenance that directly determines whether your emails reach inboxes or disappear into spam folders and blocklists. The checks take ten minutes. The consequences of skipping them can take weeks to undo.
The process is clear: use DNS lookup to verify your TXT records exist and are correctly structured, send a live test to Port25 or Gmail to confirm actual pass/fail results, review your DMARC reports to catch unauthorized senders and authentication gaps, and fix problems in order — SPF first, DKIM second, DMARC third. Once all three pass, run a full blacklist check to confirm your IP is clean.
In 2026, SPF, DKIM, and DMARC at p=reject are the baseline — not the gold standard. They are what every inbox provider expects before they will even consider your email's content. Get authentication right, and email deliverability becomes dramatically more reliable. Get it wrong, and even the best email content in the world never reaches its audience.
Continue building your email security foundation: learn how to recover a damaged IP reputation score, understand how IP reputation affects bulk email marketing, and know what to do if you receive a 550 RBL blocked sender error.
Check Your IP & DNS Now
Verify your SPF, DKIM, and DMARC records — and check if your IP is already blacklisted. Both checks are free and take under 60 seconds.