When SPF, DKIM, or DMARC fails, your email either lands in spam or gets rejected outright, and the fix depends entirely on which layer is broken and why. Authentication failures are among the most common deliverability problems and among the most fixable, once you know where to look. This guide walks through the specific diagnostics and remediation steps for each authentication layer, in the order you should investigate them.
I want to start with a quiet failure, because authentication problems are almost never loud. On a client audit, the team was convinced their soft engagement was a content problem. They had rewritten subject lines twice. When I pulled their DMARC aggregate reports, the cause was sitting in plain sight: their transactional platform, added during a product sprint a year earlier, was sending from the company's From: domain but signing DKIM under the platform's own domain, and the return-path never aligned either. Every receipt, every password reset, a meaningful share of total volume, was failing DMARC alignment and dragging the domain's reputation down with it. The marketing mail was authenticated correctly and still suffering, because reputation is domain-wide and one unaligned sender poisons the well. We configured a custom return-path and DKIM signing under their domain, and inbox placement recovered over the next two weeks. Nobody had touched the copy.
That is the lesson I keep relearning. Authentication is not optional plumbing, it is the minimum entry requirement, and the failures that hurt most are the ones nobody is looking at. Google's bulk sender requirements and Yahoo's sender standards both mandate passing SPF or DKIM authentication and a valid DMARC record as baseline conditions for inbox access. What most founders miss is that "we set up SPF and DKIM" and "every system sending from our domain passes alignment" are completely different claims, and the gap between them is where the leak usually is.
Understanding the Authentication Stack
SPF, DKIM, and DMARC are three separate but interconnected systems. They check different things, and a failure in any one of them has different implications for DMARC's final verdict.
SPF (Sender Policy Framework) checks whether the IP address that sent the message is authorized to send on behalf of the domain in the SMTP envelope. It is a list of permitted sending sources published in your DNS. When a receiving server checks SPF, it looks up your domain's SPF record and compares the sending IP against that list.
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing message. The receiving server retrieves the public key from your DNS and uses it to verify the signature. A passing DKIM check confirms the message was signed by someone with access to the corresponding private key and has not been modified in transit.
DMARC (Domain-based Message Authentication, Reporting and Conformance) uses the results of SPF and DKIM checks and applies an alignment test: does the authenticated domain match the domain in the From: header that recipients see? DMARC then tells receiving servers what to do when authentication fails. monitor, quarantine, or reject. and provides reporting so you can see what is happening.
A message passes DMARC if it passes either SPF alignment or DKIM alignment. It does not need to pass both. But if neither passes with alignment, DMARC fails regardless of what individual SPF or DKIM checks show. This is the exact mechanism that bit the client above: SPF passed for the platform, DKIM passed for the platform, and neither aligned to the From: domain, so DMARC failed anyway.
Diagnosing SPF Failures
SPF failures break into four categories: missing records, misconfigured records, lookup limit failures, and alignment failures.
Missing SPF record. Check for an SPF record by querying your domain's TXT records. The record will begin with v=spf1. If no SPF record exists, the fix is straightforward: create one that lists every IP address and sending service authorized to send on your domain's behalf. Your ESP, transactional sending platform, CRM, and any other tool that sends email from your domain all need to be included.
Misconfigured record, missing sending sources. This is the most common SPF failure. Your ESP is listed, but your transactional platform is not. Or an old ESP is still in the record but no longer used. Pull a complete list of every system that sends mail from your domain, cross-reference each one against your SPF record, and update the record to reflect the current sending infrastructure.
DNS lookup limit exceeded (permerror). SPF records are limited to 10 DNS lookups when the record is processed. Each include:, a, mx, and ptr mechanism can count as a lookup, and nested includes from ESP records add up quickly. If your SPF record exceeds the 10-lookup limit, it returns a permanent error (permerror), which most inbox providers treat as an SPF failure. Use a tool like MXToolbox's SPF Lookup to count your current DNS lookups. If you are at or above 10, flatten the record by replacing nested includes with their underlying IP addresses or removing sending sources you no longer use.
SPF alignment failure for DMARC. SPF can pass while DMARC still fails if the SPF-authenticated domain (the SMTP envelope sender) does not match the From: domain. This happens most often when you send through a third-party ESP that uses its own return-path domain rather than yours. The fix is to configure a custom return-path (also called a custom bounce domain) in your ESP so the envelope sender domain matches your From: domain.
Authentication failures are often the hidden cause behind deliverability problems that look like content issues. Get a free Deliverability Audit and we will audit your full authentication stack, identify misalignments, and give you a specific remediation plan.
Diagnosing DKIM Failures
DKIM failures are typically caused by one of four problems: DKIM not configured, DNS propagation issues, key mismatch, or message modification in transit.
DKIM not enabled. In many ESPs, DKIM signing must be explicitly enabled and a DNS record added. Follow your ESP's sending domain setup process and you will be given a CNAME or TXT record to publish in DNS. Allow 24 to 48 hours for propagation.
DNS record not published or propagated. Verify the record is live using a DKIM lookup tool. If not found, confirm you added it under the correct subdomain selector: selector._domainkey.yourdomain.com. A selector mismatch makes the record unfindable.
Key mismatch. DKIM uses a private key at your ESP and a public key in DNS. If a key rotation was not completed cleanly, the two keys will not match and DKIM verification fails. Re-configure DKIM from scratch in your ESP and publish the new DNS record.
Message modification in transit. If a forwarding service or intermediate server modifies message headers after signing, DKIM fails. DKIM failures on forwarded mail are expected, which is why ARC (Authenticated Received Chain) exists as a supplementary mechanism.
Diagnosing DMARC Failures
DMARC failures result from either SPF alignment failure, DKIM alignment failure, or both. A message fails DMARC only when both SPF alignment and DKIM alignment fail simultaneously.
Reading DMARC reports. If you have a rua= reporting address set in your DMARC record, you are receiving aggregate reports from inbox providers. These XML reports show, for each IP that sent mail claiming to be from your domain: how many messages were sent, how many passed SPF alignment, how many passed DKIM alignment, and how many passed DMARC overall. Most teams use a DMARC report parsing service (DMARC Analyzer, Valimail, Dmarcian) to make these reports readable.
Identifying unauthorized senders. One of DMARC's most valuable functions is surfacing mail sent from your domain that you did not authorize. If your DMARC reports show a sending IP you do not recognize, investigate it. It may be a forgotten sending tool, a spoofing attempt against your domain, or a misconfigured third-party integration.
Upgrading DMARC policy. Many programs start with p=none, which monitors but does not protect. Once you have verified that all legitimate sending sources pass SPF or DKIM alignment, which DMARC reports confirm, move to p=quarantine or p=reject. A p=none policy means that even if someone is actively spoofing your domain, receiving servers are instructed not to act on that information. Both Google's requirements and Yahoo's standards require a DMARC record for bulk senders, though neither currently mandates enforcement.
Subdomain coverage. Your DMARC record covers your root domain. Subdomains are covered only if your DMARC record includes a sp= subdomain policy tag, or if each subdomain has its own DMARC record. If you send from subdomains (newsletter.yourdomain.com, alerts.yourdomain.com), verify that each subdomain is covered.
Common Multi-Layer Authentication Problems
Some authentication failures involve interactions between layers rather than a single broken component.
ESP sends from its own return-path domain. Many ESPs, by default, use their own domain as the return-path (envelope sender). SPF passes for the ESP's domain, but alignment fails because the envelope domain does not match your From: domain. This is the precise failure I traced in the audit that opens this guide. Configure a custom bounce domain in your ESP so the return-path aligns to a subdomain you control (for example, bounce.yourdomain.com) and SPF alignment passes.
Multiple ESPs with conflicting SPF records. If you use separate systems for marketing and transactional email and each has its own SPF record, you may have duplicate v=spf1 records, which is invalid. A domain can have only one SPF record. All sending sources must be consolidated into a single record.
BIMI configuration revealing underlying DMARC gaps. BIMI (Brand Indicators for Message Identification), which displays your logo in supported email clients, requires DMARC at p=quarantine or p=reject. Attempting BIMI setup sometimes reveals that the underlying DMARC enforcement was never completed. Address DMARC alignment and enforcement before pursuing BIMI.
The engagement layer matters here too. Strong authentication is a necessary condition for inbox placement, not a sufficient one. Once authentication is solid, subject line quality and engagement history drive the final placement decision. Our guide to subject lines that get opened covers the content side of that equation.
Verifying Your Authentication Stack End-to-End
After any authentication change, verify the full stack before resuming normal sending volume. Send a test message to a Gmail or Yahoo address you control and examine the full email headers. Look for:
- Authentication-Results header. Shows SPF, DKIM, and DMARC pass/fail results as seen by the receiving server.
- DKIM-Signature header. Confirms DKIM signing is present on outbound mail.
- Return-Path header. Shows the envelope sender; confirm it aligns with your From: domain for SPF alignment.
Do this for every system that sends from your domain, not just your main ESP. The transactional platform, the CRM, the helpdesk, the event tool, the survey tool. The failure I described at the top of this guide hid for a year precisely because nobody header-checked the transactional stream. If a system can put your domain in the From: line, it can drag your reputation down, so it belongs on the verification list.
For a permanent monitoring setup, Google Postmaster Tools shows authentication pass rates at scale, and DMARC aggregate reports give you ongoing visibility into alignment across all sending sources. Both should be reviewed at least monthly as part of your regular deliverability maintenance.
Long-term program health after authentication is resolved comes down to keeping subscribers engaged enough to sustain positive reputation signals. Our newsletter retention and churn reduction guide covers the engagement side of that work.
Frequently Asked Questions
Does SPF or DKIM matter more for DMARC compliance?
For DMARC, what matters is that at least one of SPF or DKIM passes with alignment. In practice, DKIM alignment is more reliable because it survives email forwarding (unlike SPF) and does not depend on IP address matching. For programs that send through multiple ESPs or have complex forwarding setups, prioritising DKIM alignment is the more durable choice.
Why is my DKIM signature failing only sometimes?
Intermittent DKIM failures often point to a key rotation that was not completed cleanly (the old key was removed from DNS before the new key was fully deployed), or a load-balanced sending infrastructure where some servers are signing and others are not. Pull a sample of failed DKIM messages and compare the d= and s= tags in the DKIM-Signature header to identify which domain and selector is failing.
Can my DMARC policy be too strict?
Yes. Moving to p=reject before all legitimate sending sources pass alignment will cause legitimate mail to be rejected. Use DMARC reports to confirm full alignment coverage before enforcing. A common mistake is moving to enforcement while a minor sending tool (event registration system, HR platform, survey tool) is still sending from your domain without proper authentication.
How do I handle DKIM for transactional email sent through a third-party service?
Most transactional platforms (SendGrid, Postmark, Mailgun, etc.) support custom DKIM domains. Configure signing under your domain rather than the platform's shared domain. otherwise transactional mail passes DKIM for the platform's domain but not yours, preventing it from contributing to your DMARC compliance.
What should I do if I find unauthorized senders in my DMARC reports?
First check whether the source is a legitimate internal tool that was not properly configured, because legacy systems often send from your domain without anyone realising it. If it is not a legitimate tool, treat it as a spoofing attempt and move DMARC to p=reject to cause those messages to be rejected by receiving servers.
Read Next
- Newsletter Retention and Churn Reduction keeps the engagement signals strong after authentication is resolved.
- Subject Lines That Get Opened is the content layer that determines performance once authentication is passing.
Want Help Applying This?
Authentication troubleshooting is straightforward in simple sending setups and complicated fast when you have multiple ESPs, legacy systems, or subdomains. Request a free deliverability audit and we will review your full authentication stack, identify alignment failures, and give you a step-by-step remediation plan.
The client I opened with had done everything they thought they were supposed to do, and a single unaligned sender they had forgotten about was still quietly costing them the inbox. So here is the question I would sit with before you blame your next soft result on copy. Can you name, right now, every system that sends mail from your domain, and do you actually know that each one passes DMARC alignment?