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 February 2024, Gmail has required senders of more than 5,000 messages a day to publish SPF, DKIM and DMARC, and Yahoo asks bulk senders for the same — though Yahoo deliberately publishes no volume threshold at all. Microsoft went further: from 5 May 2025 it began junk-foldering non-compliant bulk mail to its consumer inboxes, and it now rejects it outright with a documented 550 5.7.515 bounce. In 2026, missing any of these three records means your email is not just filtered as spam — for a growing share of recipients it never arrives at all. 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) Run our SPF record checker, which counts the ten DNS lookups SPF is limited to and names the exact term that breaks the limit. (2) Run the DKIM record checker — leave the selector blank and it searches the published provider selectors for you, so you do not need to know yours. (3) Check what your DMARC policy and alignment mode actually say. (4) Run a full IP blacklist check to see if authentication failures have already caused listings. 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 — and read the caveat in section 5 first, because the current DMARC specification is more cautious about -all than most guides are.
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 — or use a checker that can find your DKIM selector for you.
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.
There is a second, quieter version of this failure: an SPF record that is syntactically fine but exceeds the ten DNS lookup limit set by RFC 7208. Once it does, SPF returns a permanent error for every recipient, and your own servers stop passing — even though they are correctly listed. Our SPF checker counts every lookup branch by branch and names the exact term that crosses the limit.
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 What the Large Receivers Now Enforce
Google runs two tiers. Every sender, at any volume, must have SPF or DKIM. Senders of more than 5,000 messages a day to Gmail accounts must have SPF and DKIM plus DMARC, with the From domain aligned to either the SPF or the DKIM domain. Those requirements took effect on 1 February 2024, and Google's own guidance describes enforcement ramping up from November 2025 with temporary and permanent rejections.
Microsoft is now the strictest of the three and the one that changed most recently. For senders of 5,000 or more messages a day to its consumer services it requires that both SPF and DKIM checks pass — not either one — while requiring only that at least one of them be aligned. Non-compliant mail went to the junk folder from 5 May 2025, and rejection is now live: Microsoft publishes a dedicated page for the 550 5.7.515 bounce a failing sender receives.
Yahoo asks bulk senders for both SPF and DKIM plus a DMARC policy of at least p=none. Unlike the other two, Yahoo deliberately publishes no volume threshold, stating plainly that it will not specify one. If a guide quotes you a Yahoo number, it invented it — the 5,000 figure belongs to Google and Microsoft.
The practical takeaway is the same for all three: half-configured authentication that has been "fine" for years is exactly what the 2025–2026 enforcement wave breaks.
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 SPF Checker (Fastest and Most Complete)
Go to our SPF checker, enter your domain, and optionally enter the IP address you send from. It reads the live record and does the parts a plain DNS lookup cannot.
What it reports:
✅ The record itself, plus whether the domain publishes more than one — two SPF records is a permanent error, not a redundancy
✅ A running count of the ten DNS lookups, branch by branch, naming the term that crosses the limit
✅ Whether the sending IP you entered would pass, with the mechanism that matched it
✅ The length of each DNS character-string, because a record split badly across the 255-octet boundary fails silently
✅ Whether your ~all or -all choice makes sense against the DMARC policy you actually publish
If you only want to see the raw TXT records for a domain, the general-purpose DNS lookup tool will show you every record with its TTL.
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.
What the command line will not do is follow your include: chains and count the lookups inside them, which is where most real SPF failures live.
3 Common SPF Problems and What They Mean
SPF PermError (too many DNS lookups): Your SPF record exceeds 10 DNS lookups. Each include:, a, mx, ptr, exists and redirect= counts — ip4, ip6 and all do not. 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. -all is stricter, but it is not automatically the better choice — see section 5.
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
This is the step that stops most people, because almost every DKIM tool demands the selector before it will tell you anything. There are three ways round it.
Read it from a real message. 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. This method cannot be wrong, because it is what your server actually used.
Let a checker search for it. Our DKIM checker will find your selector automatically: leave the selector field blank and it queries a published list of provider selectors, then shows every one it finds on your domain with that key's length, algorithm and state. You can also paste the whole DKIM-Signature header into it and let it read s= and d= for you.
Check your platform's DNS setup page. Google Workspace, Microsoft 365 and most ESPs show the selector they generated in the admin console where you first enabled DKIM.
One honest limit worth knowing: no search can prove a negative. Amazon SES, Postmark and Salesforce Marketing Cloud generate selector names that cannot be guessed, and some domains — Google's own included — use date-stamped selectors like 20230601. If a search finds nothing, that means "none of the common ones", not "no DKIM".
2 Look Up the DKIM DNS Record
Once you have the selector, enter it and your domain into a checker that validates every tag against the specification rather than just printing the record.
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.
Two things that look broken and are not. A record returned as two quoted strings is normal — a 2048-bit key exceeds the 255-octet limit for a single DNS character-string, so it must be published in parts that the resolver joins back together. And if your provider gave you a CNAME instead of a TXT record, that is also correct: Microsoft 365, SendGrid, Mailchimp, Brevo and HubSpot all delegate DKIM this way so they can rotate keys without touching your DNS.
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 is a revoked key, not a truncated one. RFC 6376 §3.6.1 states that "an empty value means that this public key has been revoked", so it is the correct way to retire a key — and all email signed with this selector will fail verification.
❌ The record carries t=y: the selector is in testing mode. RFC 6376 is explicit that verifiers "MUST NOT treat messages from Signers in testing mode differently from unsigned email", so while this flag is set your signature earns you nothing. It is the single most common silent DKIM misconfiguration.
❌ The key is 1024-bit: valid but below what the specification asks for. RFC 8301 §3.2 says signers "SHOULD use RSA keys of at least 2048 bits". Google and Yahoo both require 1024 as a minimum and recommend 2048, so treat this as a rotation task rather than an emergency.
❌ 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 the DMARC checker to read the record and see the policy and both alignment modes in plain language. 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 | Sensible Value |
|---|---|---|
p= | Policy for your domain (main) | quarantine, then reject |
sp= | Policy for subdomains | Omit unless subdomains differ |
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 | r (relaxed — the default) |
aspf= | SPF alignment mode | r (relaxed — the default) |
A correction worth making: plenty of guides get this backwards. Relaxed alignment (r) is the specification default, and it is the right setting for almost everyone. Strict (s) demands that the signing domain match your From domain exactly — so mail signed by a subdomain, or by an ESP signing as mail.yourdomain.com, stops aligning and starts failing DMARC. Only move to strict if you have read your reports and know every sending source signs with the exact apex domain.
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. 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.
Two nuances from RFC 9989, the DMARC specification published in May 2026 that replaced RFC 7489 — and which almost no guide has caught up with yet. First, it states that a domain publishing p=reject "MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages", because SPF breaks on forwarding while a DKIM signature survives it. That makes DKIM the half that matters more, not the optional extra. Second, it advises that domains hosting users who post to mailing lists "SHOULD NOT publish" p=reject at all, since list software routinely modifies messages in ways that invalidate signatures. p=reject is the right destination for a transactional or marketing domain; it is not a universal goal for every domain.
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 — Read the headers of a message that actually arrived:
This is the most reliable test available to anyone, because it is the receiver's own verdict rather than a prediction. Send a test email from your mail server to a Gmail address you control, open it, click the three-dot menu and choose "Show original". The header block will show:
spf=pass / fail / softfail
dkim=pass / fail
dmarc=pass / fail
Paste the whole header block into our email header analyzer and it will lay out every hop and every authentication result in order, which is far easier than reading raw headers. If the DKIM line fails, the DKIM-Signature header itself carries the s= and d= values you need to check the key behind it — which is the fastest route from "DKIM failed" to knowing why.
Method 2 — A mail-in reflector:
Several services let you send a blank email to an address and receive an automated authentication report back. aboutmy.email is the one we would point you at today; it returns SPF, DKIM and DMARC results plus a structural review of your message. The long-standing check-auth@verifier.port25.com reflector still resolves in DNS and still publishes an MX record, but it has shown no sign of active maintenance for years and a reply is not guaranteed — if you try it and nothing comes back, that is the service, not your mail server.
Method 3 — Check your blacklist status after finding failures:
If you have found authentication failures, run an immediate blacklist check. Use the 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. Note the header.d= value on the DKIM line — if that domain is not yours, the signature is valid but will not align, and DMARC will not count it.
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, so use a report analyzer to turn them into something legible. Free options that are genuinely operational in 2026 include Valimail Monitor (free, no volume cap), Cloudflare DMARC Management (free on all plans if your domain already uses Cloudflare DNS), EasyDMARC's free plan (dashboard, one domain, capped monthly volume), and Postmark's free DMARC tool — which sends a weekly digest by email rather than giving you a dashboard. For a technical audience, the open-source parsedmarc can be self-hosted so there is no vendor to disappear.
One thing worth correcting, because it is widely repeated: Google Postmaster Tools does not read your DMARC reports. It shows the percentage of your Gmail-bound mail that passes SPF, DKIM and DMARC, along with spam rate and delivery errors — useful, but Gmail traffic only, and with no per-sender breakdown of who is failing or spoofing. To actually see which sources are failing, you need one of the aggregate report analyzers above. Pair that 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. Re-run the SPF checker after each edit — it will tell you the exact lookup count you are at, so you are not guessing whether the flattening was enough.
End with ~all during testing, then consider -all once DKIM is also signing — see section 5 for why that order matters.
2 Fix DKIM (Content Integrity — Do This Second)
Generate a 2048-bit RSA DKIM key pair in your mail server or email platform settings — RFC 8301 §3.2 says signers "SHOULD use RSA keys of at least 2048 bits". 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 the DKIM-Signature header appears, then confirm the published key length — a checker that decodes it from the key material the real key length from the key material, so you find out whether you actually published 2048 bits or whether the record was truncated on the way in.
If you are rotating rather than creating, publish the new selector and confirm it resolves before switching your server to sign with it. A checker that lists every selector on the domain with its key length and state makes that a ten-second check instead of a guess.
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. Verify the published policy before you escalate each step.
Recommended rollout — RFC 9989 asks for at least a month at each stage rather than a rushed week:
Month 1: p=none; pct=100 — collect reports, verify all legitimate mail passes
Month 2: p=quarantine; pct=10 → then pct=100 — monitor for issues at each step
Month 3+: p=reject; pct=100 — provided your domain's users do not post to mailing lists
On DNS propagation: there is no fixed waiting period. How long a change takes to be seen depends on the TTL of the record and, more awkwardly, on negative caching — if you checked a name before publishing it, resolvers cached the "nothing here" answer too, for a period RFC 2308 derives from your zone's SOA. That is why a record you definitely published still reads as missing. Check the TTL rather than waiting an arbitrary 48 hours.
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 the 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: run each record through a checker that validates it rather than just printing it — count your SPF DNS lookups, confirm your DKIM key length and selector, and read your DMARC policy and alignment mode. Then send a live test and read the headers on arrival, because a record that looks right in DNS and a signature that verifies at a receiver are two different facts. Review your DMARC reports to catch unauthorized senders, 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 and DKIM together with an enforcing DMARC policy are the baseline — not the gold standard. They are what every inbox provider expects before they will even consider your email's content. And of the three, DKIM is the one to get right first: it is the only one that survives forwarding, which is exactly why the current DMARC specification requires it of any domain publishing p=reject. 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 Email Authentication Now
Count your SPF DNS lookups, find your DKIM selector and key length, and check whether your IP is already blacklisted. All three checks are free and take under 60 seconds.