6 most common DKIM and DMARC failures and how to fix them

SPF (Sender Policy Framework) is only one piece of the email authentication puzzle. You can have a perfect SPF record and still watch your emails land in spam, get rejected, or fail DMARC. The reason? DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting, and Conformance) introduce their own failure modes that trip up even experienced email administrators.

We see this constantly across the organizations using Red Sift OnDMARC. A marketing team configures SPF correctly but never enables DKIM signing. An IT team publishes a DMARC record at p=none and leaves it there for a year. A third-party sender signs emails with its own domain instead of yours, breaking alignment. These aren't edge cases. They're the everyday reality of email authentication in 2026.

With new email authentication requirements in 2026, SPF alone won't always save you from experiencing mail delivery issues. Where possible, having DKIM AND SPF configured is the best way to ensure optimal delivery rates

The enforcement timeline makes this urgent. Google and Yahoo began requiring SPF, DKIM, and DMARC for bulk senders in February 2024 [1]. Microsoft followed in May 2025, rejecting non-compliant email with error code 550 5.7.515 [2]. These aren't soft guidelines. Gmail shifted from educational warnings to outright rejection in November 2025, and Microsoft started hard-rejecting emails rather than routing them to junk.

The adoption numbers tell the story of how far the industry still has to go. Research across 5.5 million domains found that only 22.7% had a detectable DKIM record, making it the lowest-adopted core email authentication protocol [3]. And while DMARC adoption is growing, 69.6% of domains still lack any DMARC record, and only 6% enforce p=reject [3]. Red Sift's own analysis of 73.3 million domains found that just 2.5% have deployed p=reject [4].

Meanwhile, cybercrime losses keep climbing. The FBI's 2025 Internet Crime Report logged over $20.8 billion in total losses (up 26% from 2024), with phishing and spoofing once again the most-reported crime category at 191,561 complaints [5]. Business email compromise accounted for over $3 billion in losses across 24,768 incidents [5]. Proper SPF and DKIM configurations paired with full DMARC enforcement is how you stop attackers from impersonating your domain to reach your customers. By having DKIM configured across all legitimate sending sources means forwarding scenarios don't break authentication or cause delivery issues downstream.

The compliance pressure is real, too. PCI DSS v4.0.1 mandates DMARC at quarantine or reject for organizations processing payments [6]. CISA, the UK's NCSC, Australia's ASD, and Canada's CCCS all mandate DMARC for government domains. For a full breakdown, see our global DMARC mandates overview. Cyber insurers increasingly require DMARC enforcement as an underwriting condition.

Here are the six DKIM and DMARC failures we see most often and exactly how to fix each one.

What it looks like: Your DMARC reports or email headers show dkim=fail (body hash did not verify). The DKIM signature exists, the public key is in DNS, but verification still fails.

Why it happens: DKIM works by computing a hash of the email body at the point of signing (the bh= tag in the DKIM-Signature header). The receiving server then queries the public key associated with the selector that was originally used to sign the message and recomputes the hash. If anything changes between signing and delivery, the hashes don't match and DKIM fails.

The usual culprits are intermediary systems that modify the message after your mail server signs it:

• Email security gateways that rewrite URLs for safe-link scanning (Microsoft Defender, Barracuda, and similar platforms)
• Anti-spam filters that add or modify headers
• Mailing list software that appends footers, list headers, or unsubscribe links, or rewrites the SMTP MailFrom domain and strips or replaces the original DKIM signature with its own
• DLP (data loss prevention) tools that scan and sometimes alter outbound content
• Auto-forwarding where the forwarding server modifies the message body

This is one of the trickiest DKIM failures to diagnose because the signature itself is valid: the key matches, the selector is correct, and the record is in DNS. The problem is that the message body changed after signing.

How to fix it:

The core principle: DKIM signing should happen as the last step before the message leaves your infrastructure. If any system modifies the email after signing, the signature breaks.

• Reorder your mail flow. If you have a security gateway that rewrites URLs, make sure DKIM signing happens after that rewrite, not before. This often means configuring your email gateway to sign on behalf of your domain rather than relying on your mail server to sign first.
• Use c=relaxed/relaxed canonicalization. DKIM supports two canonicalization modes: simple and relaxed. Relaxed mode tolerates minor whitespace changes and header formatting differences. Set both header and body canonicalization to relaxed (c=relaxed/relaxed) to reduce false failures.
• Identify the modifying system. Compare the DKIM body hash in the original signature (bh=) with what the receiving server computed. If they differ, something in the mail path altered the body. Trace your mail flow from the sending application through any gateways, filters, and relays to find the culprit.
• For mailing lists and forwarding, rely on DKIM \+ ARC. Mailing lists will modify your messages (it's what they do). You can't prevent this. ARC (Authenticated Received Chain) preserves original authentication results through forwarding chains, and major providers like Gmail and Microsoft evaluate ARC when making delivery decisions. On your side, make sure DKIM is always configured so that direct delivery passes. Use Red Sift Investigate to verify that your messages are passing hash evaluation checks before they ever hit a forwarding scenario. For more on how forwarding affects authentication, see our SPF, DKIM, and DMARC configuration guide.

What it looks like: Email headers show dkim=fail (no key for signature) or dkim=permerror. The receiving server can't find or parse your DKIM public key in DNS.

Why it happens: DKIM relies on a public key published in DNS at a specific location: selector._domainkey.yourdomain.com. When the receiving server can't find or read this record, DKIM verification fails completely. This is the most common DKIM failure, and it happens for several reasons:

• The DNS record was never created. Someone enabled DKIM signing in the email service but never added the corresponding public key to DNS. Google Workspace, for example, requires you to generate the DKIM key in the Admin Console and then manually add the TXT or CNAME record to your DNS. If you skip the DNS step, signing happens but verification always fails.
• The record is in the wrong DNS zone. If you manage DNS in multiple places (registrar, Cloudflare, hosting provider), the DKIM record might have been added to an inactive zone. The receiving server queries the authoritative DNS for your domain and finds nothing.
• Truncated 2048-bit keys. DKIM public keys for 2048-bit RSA are long, often exceeding the 255-character limit for a single DNS TXT string. If your DNS provider truncates the key without splitting it into multiple quoted strings, verification fails because the key is incomplete.
• Selector mismatch. The s= tag in the DKIM-Signature header specifies which selector to use for the DNS lookup. If the selector in the signature doesn't match the selector name in your DNS record, the lookup returns nothing. This commonly happens when an ESP rotates selectors and the old selector name remains in DNS while the new one was never added.

How to fix it:

Start by identifying the selector. Look at the DKIM-Signature header in a sent email (in Gmail, click "Show original"). Find the s= tag: this is your selector. You can then query DNS manually, or run the Domain Analyzer within Red Sift OnDMARC.

Enter your domain and the selector value to check against, and it'll surface the full DKIM record along with any configuration issues.

dig TXT selector._domainkey.yourdomain.com +short

If the query returns nothing, the record is missing. If it returns a partial key, it's truncated.

• For missing records: Go to your email service's admin console, find the DKIM setup page, and copy the public key record. Add it to your active DNS zone as a TXT record at selector._domainkey.yourdomain.com.
• For truncated keys: Split the key into multiple 255-character quoted strings within a single TXT record. Most modern DNS providers handle this automatically for CNAME-based DKIM setups.
• For selector mismatches: Verify the selector name in your email service matches the selector in DNS. If your ESP changed selectors, update DNS to match.
• Use CNAME-based DKIM where possible. Instead of publishing the full public key as a TXT record, many ESPs offer CNAME delegation where you point your selector to their DNS. This way, when the ESP rotates keys, they update their side and your DNS stays unchanged.

What it looks like: DKIM was working for months, then suddenly starts failing. Headers show dkim=fail with no obvious DNS or configuration change on your side.

Why it happens: DKIM keys aren't permanent. They need to be rotated periodically for security, and when the rotation goes wrong, authentication breaks silently.

Three common scenarios:

• ESP rotated keys without your knowledge. If you're using TXT-based DKIM (where the full public key lives in your DNS), the ESP can rotate their private signing key at any time. If they issue a new private key but you haven't updated the corresponding public key in your DNS, the signature won't verify. This is the most frustrating failure because nothing changed on your side.
• 1024-bit keys rejected or flagged. NIST recommends 2048-bit minimum for RSA encryption, and the industry has moved firmly in that direction [7]. Some receiving servers now flag or reject emails signed with 1024-bit keys. If you set up DKIM years ago and never upgraded, you might be hitting this limit.
• The x= expiration tag triggered. DKIM signatures can include an optional x= tag specifying when the signature expires. If the email is delayed in transit (queued at a relay, for example) and arrives after the x= deadline, verification fails even though everything else is correct.

How to fix it:

• Upgrade to 2048-bit keys. If you're still on 1024-bit, upgrade now. In Microsoft 365, use the Rotate-DkimSigningConfig PowerShell to upgrade selector key sizes. In Google Workspace, generate a new 2048-bit key in Admin Console \> Apps \> Google Workspace \> Gmail \> Authenticate email. The email protocol configuration guide covers DKIM key management in detail.
• Use CNAME-based DKIM to avoid rotation headaches. When you delegate DKIM via CNAME to your ESP, key rotation happens on their infrastructure. You never need to update DNS manually. Red Sift OnDMARC's takes this further by managing all your DKIM configurations through a single platform.
• Rotate keys on a schedule. Industry best practice (recommended by M3AAWG) is to rotate DKIM keys every 6-12 months with 2048-bit keys. Use meaningful selector names that include dates (like jan2026) so you can tell at a glance when a key was created.
• Avoid or set generous x= tags. If you use the expiration tag, make sure it allows enough buffer for delayed delivery. Many practitioners omit x= entirely to avoid this failure mode.

What it looks like: DKIM verification passes (dkim=pass), but DMARC still fails. Your DMARC reports show DKIM authentication succeeding but alignment failing.

Why it happens: This is the single most common DKIM-related DMARC failure, and it trips up almost every organization using third-party email services.

DMARC doesn't just check whether DKIM passes. It checks alignment: the domain in the DKIM signature's d= tag must match (or be a subdomain of) the domain in the visible From header. When a third-party service signs emails with its own domain instead of yours, DKIM passes but DMARC alignment fails.

Here's how it plays out.

• You use SendGrid to send marketing emails from marketing@yourdomain.com.
• SendGrid signs the email with d=sendgrid.net by default.
• The receiving server checks DKIM: the signature verifies against SendGrid's public key, so dkim=pass.
• Then DMARC checks alignment: does sendgrid.net match yourdomain.com?
• No. Alignment fails. If SPF also fails alignment (which it often does with third-party senders), DMARC fails entirely.

This happens with almost every ESP, CRM, and SaaS platform that sends email. Mailchimp, HubSpot, Salesforce, Zendesk, Freshdesk, Intercom: they all sign with their own domain by default unless you explicitly configure custom DKIM.

How to fix it:

For every service that sends email using your domain, configure custom DKIM signing so the d= tag uses your domain:

• Most ESPs (Mailchimp, SendGrid, HubSpot, etc.): Look for "Domain Authentication" or "Custom DKIM" in the platform settings. The ESP will give you CNAME or TXT records to add to your DNS. Once configured, they sign with d=yourdomain.com instead of their own domain.
• Google Workspace: DKIM signing uses your domain by default, but you must explicitly enable it in Admin Console and add the DNS record.
• Microsoft 365: Custom DKIM signing needs to be enabled via the Microsoft 365 Defender portal. Microsoft provides two selector CNAME records per domain.

After configuring custom DKIM for each sender, check your DMARC alignment mode. DMARC supports two modes (set by the adkim= tag):

• Relaxed (adkim=r): The DKIM signing domain can be a subdomain of the From domain. mail.yourdomain.com aligns with yourdomain.com. This is the default and recommended for most organizations.
• Strict (adkim=s): The signing domain must exactly match the From domain. Use this only if you have a specific security requirement.

Red Sift OnDMARC identifies which senders are passing DKIM verification but failing alignment, showing you exactly which d= domain mismatch is causing the problem. For a deeper explanation of how DKIM, SPF, and DMARC interact, see our comparison guide.

What it looks like: Your DMARC record exists, reports are being generated, but your policy is p=none. Spoofed emails using your domain are delivered to recipients without interference. Your domain is technically "DMARC-enabled" but not DMARC-protected.

Why it happens: Getting stuck at p=none is the most widespread DMARC failure, and it's not a technical error: it's an operational one.

Organizations publish a DMARC record at p=none to start collecting aggregate reports. That's the right first step. But then they never move to enforcement. The reasons are predictable: the reports are hard to read (raw XML), the team isn't sure which senders are legitimate, nobody wants to risk blocking real email, and the project loses priority. Months or years pass. The DMARC record sits at p=none, doing nothing to stop attackers.

The numbers are striking. Across 5.5 million scanned domains, 17.6% have DMARC at p=none [3]. Red Sift's analysis of 73.3 million domains shows that only 14.9% have begun their DMARC journey, with just 2.5% at p=reject [4]. That means the vast majority of domains with DMARC records are in monitoring mode only.

A p=none policy is a reporting tool, not a security control. It tells receiving servers to deliver all email regardless of authentication results and just send you reports about it. Attackers can spoof your domain freely, and every spoofed email reaches its target.

How to fix it:

The path from p=none to p=reject is straightforward with the right tooling and process. Here's the approach we recommend with Red Sift OnDMARC:

1. Identify all legitimate senders. Use your DMARC aggregate reports to build a complete inventory of every service sending email as your domain. OnDMARC does this automatically, classifying senders and showing their authentication status.
2. Fix authentication for each sender. Configure SPF and DKIM for every legitimate source. Make sure at least one (ideally both) passes with alignment for each sender.
3. Move to p=quarantine. Once all legitimate senders are authenticated, change your policy to quarantine. This routes failing emails to spam instead of the inbox. Monitor for a week or two to catch any senders you missed.
4. Move to p=reject. After confirming no legitimate email is being quarantined, move to reject. This tells receivers to block emails that fail DMARC entirely.
5. Use the pct= tag for gradual rollout. If you're nervous about going straight to reject, use pct=25 to apply the policy to only 25% of failing traffic initially. Increase gradually (50%, 75%, 100%) as you gain confidence.

With the right platform, organizations typically reach p=reject in 6-8 weeks. Without one, many never get there. Our step-by-step DMARC enforcement guide walks through the full process.

What it looks like: Both SPF and DKIM show pass in your email headers or DMARC reports, but DMARC still fails. This is one of the most confusing failures because everything appears to be working, and yet it isn't.

Why it happens: DMARC requires alignment, not just authentication. Both SPF and DKIM can pass their respective checks and still fail DMARC if the authenticated domains don't match the visible From header.

Two alignment checks happen simultaneously:

• SPF alignment: The domain in the Return-Path (envelope-from) must match or be a subdomain of the From header domain.
• DKIM alignment: The domain in the DKIM signature's d= tag must match or be a subdomain of the From header domain.

DMARC passes if at least one of these alignment checks succeeds. It fails only when neither aligns.

Here's a real-world example.

• Your company sends customer emails from support@yourdomain.com through Zendesk.
• Zendesk uses its own domain as the Return-Path (@zendesk.com).
• SPF checks Zendesk's SPF record, finds the sending IP, and SPF passes, but the domain is zendesk.com, not yourdomain.com.
• Alignment fails. Zendesk also signs with d=zendesk.com by default. DKIM passes against Zendesk's key, but alignment fails because zendesk.com doesn't match yourdomain.com.
• Both protocols pass authentication but fail alignment. DMARC fails.

This pattern repeats across virtually every third-party sender that hasn't been configured with custom authentication.

How to fix it:

You need at least one protocol to both pass and align. The most reliable approach is to fix both:

• For DKIM alignment: Configure custom DKIM signing on every third-party sender so the d= tag uses your domain. (See failure \#4 above for platform-specific instructions.)
• For SPF alignment: Configure each sender to use your domain (or a subdomain) as the Return-Path. This varies by platform. Salesforce requires disabling bounce management. HubSpot and Marketo offer custom envelope-from settings.
• Use relaxed alignment as your default. With aspf=r and adkim=r (both defaults in DMARC), subdomains count as aligned. If your marketing platform sends with a Return-Path of bounce.yourdomain.com and your From header is yourdomain.com, relaxed alignment passes.

The diagnostic path is simple: check your DMARC aggregate reports. They show authentication results (pass/fail) alongside alignment results for both SPF and DKIM. If you see pass \+ fail alignment, you know exactly which protocol and which sender needs attention.

Red Sift OnDMARC breaks this down per sender, showing at a glance which services are passing authentication but failing alignment and what the domain mismatch is. Check your current status with Red Sift Investigate to see where your alignment stands today.

When troubleshooting, the Authentication-Results header in received emails tells you exactly what happened. Here's what to look for:

For ongoing monitoring beyond individual email checks, DMARC aggregate reports give you a complete view across all sending sources. Red Sift OnDMARC transforms raw XML reports into actionable dashboards, and our top email authentication tools guide covers additional resources for each stage of implementation.

DKIM and DMARC failures follow predictable patterns. Body hash mismatches, missing DNS records, key rotation gaps, alignment mismatches, stalled policies, and the alignment gap between passing authentication and passing DMARC. Every one of them is diagnosable through email headers and DMARC reports, and every one of them is fixable.

The biggest risk isn't complexity. It's inaction. A DMARC record at p=none gives you visibility but zero protection. Every day your domain stays at p=none is another day attackers can impersonate you without consequence.

[1] An update on bulk sender requirements \- Google

[2] Strengthening Email Ecosystem \- Microsoft Community Hub

[3] DKIM Fail: How to Fix Alignment and Verification Errors \- DMARCguard

[4] SPF Flattening: The Hidden Email Infrastructure Problem \- AutoSPF

[5] 2025 IC3 Annual Report

[6] PCI DSS v4.0.1 Summary of Changes

[7] RFC 6376 \- DomainKeys Identified Mail (DKIM) Signatures