A DMARC fail occurs when an email doesn’t pass the DMARC authentication check — meaning both SPF and DKIM either failed outright or failed to align with your visible From address. The receiving server can’t verify that the message legitimately came from your domain.
What makes DMARC tricky (and frustrating) is that SPF and DKIM can technically pass their individual checks while DMARC still fails. The culprit is usually alignment — the authenticated domains don’t match the domain recipients actually see in the From header.
Why DMARC failures should not be taken lightly:
- Emails get quarantined or rejected based on your policy
- Legitimate messages land in spam (or disappear entirely)
- Marketing campaigns and transactional emails stop reaching recipients
- Security gaps leave your domain vulnerable to spoofing
- Repeated failures damage sender reputation over time
DMARC failure typically signals one of two scenarios:
- Either your legitimate sending sources aren’t properly configured
- Or someone is actively trying to spoof your domain
Distinguishing between them — and fixing the former — requires understanding what actually triggers these failures.
What causes DMARC to fail?
DMARC failures stem from four main categories: alignment problems, third-party misconfigurations, DNS errors, and mail routing complications. Most legitimate failures fall into the first two.
Alignment issues
DMARC requires that authenticated domains match your From header domain. SPF alignment checks the Return-Path domain — DKIM alignment checks the signing domain (d= tag).
| Alignment type | What must match |
| SPF alignment | Return-Path domain ↔ From header domain |
| DKIM alignment | DKIM d= domain ↔ From header domain |
An email passes DMARC if either SPF or DKIM passes and aligns. Both failing alignment means DMARC fails — even if the underlying authentication succeeded.
Third-party senders
The most common cause of legitimate DMARC failure. Services like Mailchimp, Salesforce, HubSpot, and Marketo send email on your behalf, but their default configurations often use their own domains for authentication.
- CRM systems aren’t added to your SPF record
- Transactional email providers haven’t been authorized in DNS
- Help desk software sends from their infrastructure without a custom DKIM
- Marketing platforms use default DKIM signatures (d=sendgrid.net instead of d=yourdomain.com)
Until you configure custom authentication for each service, their emails fail alignment.
DNS configuration errors
Technical mistakes in your DNS records break authentication entirely:
- SPF exceeds the 10-DNS-lookup limit
- DMARC record missing the v=DMARC1 tag
- DKIM keys expired or rotated without DNS updates
- Syntax errors in DMARC record (typos, missing tags)
- Multiple SPF records for one domain (only one is allowed)
Email forwarding
Forwarding breaks SPF by design — the forwarding server’s IP isn’t in your SPF record. If DKIM also fails (because the forwarder modified the message), DMARC fails completely.
Forwarding scenarios that trigger failure:
- Auto-forwards to personal addresses
- Security gateways that rewrite headers
- Shared mailboxes routing to external destinations
- Mailing lists that modify subject lines or add footers
How does DMARC alignment actually work?
Alignment is DMARC’s core concept — and the source of most confusion. Understanding it clarifies why “passing” SPF or DKIM doesn’t guarantee DMARC success.
The alignment requirement
DMARC verifies that the domain in your visible From header matches the domains authenticated by SPF and DKIM. Recipients see your From address (the “friendly” address); DMARC confirms the authentication matches it.
Without alignment, an attacker could authenticate mail from their domain while forging your domain in the From header. Alignment closes that gap.
Relaxed vs strict
DMARC alignment has two modes:
| Mode | SPF tag | DKIM tag | Matching rule |
| Relaxed | aspf=r | adkim=r | Subdomains can match root domain |
| Strict | aspf=s | adkim=s | Exact domain match required |
Relaxed alignment (the default) allows mail.example.com to align with example.com. Strict alignment requires an exact match — mail.example.com wouldn’t align with example.com.
Most organizations use relaxed alignment because it accommodates subdomains for different email streams (marketing, support, transactional) while still preventing spoofing of entirely different domains.
The “pass one” rule
DMARC passes if either SPF or DKIM passes and aligns. You don’t need both:
- SPF passes + aligns → DMARC passes (even if DKIM fails)
- DKIM passes + aligns → DMARC passes (even if SPF fails)
- Both fail or both misalign → DMARC fails
DKIM is especially valuable because it survives forwarding (when the message body isn’t modified). SPF almost always fails on forwarded mail because the forwarding server’s IP isn’t authorized.
What happens when DMARC fails?
The consequences depend on your published DMARC policy — the p= tag in your DNS record that tells receivers how to handle failures.
Policy outcomes
Here are the DMARC policy outcomes:
| Policy | Tag | Action on failure |
| None | p=none | Deliver normally, just report |
| Quarantine | p=quarantine | Send to spam/junk folder |
| Reject | p=reject | Block at the gateway, bounce back |
A p=none policy lets everything through (useful for monitoring before enforcement). Quarantine and reject actually protect against spoofing, but also affect legitimate mail with authentication problems.
Reputation damage
Beyond immediate delivery impact, repeated DMARC failures erode your domain’s standing with mailbox providers:
- Future emails face increased scrutiny
- High failure rates signal potential spoofing
- Gmail and Outlook track authentication history
- Even properly authenticated mail may get filtered
Fixing DMARC failures goes beyond just recovering blocked messages — it’s about protecting long-term deliverability.
Business impact
For enterprise marketing teams, DMARC failures create operational problems:
- Campaign emails vanish into spam folders
- Customer communication becomes unreliable
- Password reset and security emails get blocked
- IT spends hours troubleshooting instead of building
- Transactional messages (invoices, confirmations) don’t arrive
How do you diagnose DMARC failures?
Pinpointing why DMARC failed requires checking authentication results, reviewing reports, and tracing the sending source.
Email headers
Authentication results appear in message headers. Look for the Authentication-Results header:
Authentication-Results: mx.google.com;
dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE)
header.from=example.com;
spf=pass smtp.mailfrom=different-domain.com;
dkim=pass header.d=another-domain.com
This example shows SPF and DKIM both passing — but DMARC failing. The authenticated domains (different-domain.com, another-domain.com) don’t match the From header (example.com). Alignment failure.
Aggregate reports
DMARC reports (sent to the address in your rua= tag) provide comprehensive visibility:
- Which IPs are sending mail for your domain
- Alignment status for each authentication method
- Volume of compliant vs non-compliant messages
- Whether SPF/DKIM passed or failed for each source
Without reports configured, you’re flying blind. A DMARC record without rua= is essentially useless for troubleshooting.
Source investigation
When reports show failing sources, determine if they’re legitimate:
- Check if the IP belongs to a known vendor
- Verify whether proper authentication was configured
- Review if the service should be sending on your behalf
- Research unfamiliar sources (could be legacy systems or attackers)
Legitimate sources need authentication fixes. Unknown sources may indicate spoofing attempts — which DMARC is correctly blocking.
How do you fix DMARC failures for legitimate senders?
Once you’ve identified why DMARC is failing, fixes typically involve authorizing sending sources, correcting DNS records, or adjusting alignment settings.
Authorize third-party senders
For each service sending email on your behalf:
SPF authorization:
- Add the service’s include mechanism to your SPF record
- Example: include:_spf.google.com for Google Workspace
DKIM authorization:
- Configure custom DKIM with your domain as the signing domain
- Generate keys in the sending platform
- Add DKIM TXT records to your DNS
- Verify the d= tag matches your domain
| Service | SPF include | DKIM setup required |
| Google Workspace | include:_spf.google.com | Yes (custom domain) |
| Microsoft 365 | include:spf.protection.outlook.com | Yes (custom CNAME) |
| Mailchimp | include:servers.mcsv.net | Yes (verify domain) |
| Salesforce | include:_spf.salesforce.com | Yes (custom keys) |
| SendGrid | include:sendgrid.net | Yes (DNS records) |
Fix DNS errors
Common corrections:
- Fix syntax errors in policy tags
- Rotate expired DKIM keys and update DNS
- Add missing v=DMARC1 tag to DMARC record
- Remove duplicate SPF records (keep only one)
- Reduce SPF lookups using SPF flattening if exceeding 10
Handle forwarding failures
SPF inherently fails on forwarded mail. Compensate by:
- Prioritizing DKIM (survives most forwarding scenarios)
- Accepting that some forwarding will always cause failures
- Using relaxed alignment to accommodate routing variations
- Implementing ARC (Authenticated Received Chain) for intermediary servers
DKIM is your safety net for forwarding — make sure it’s properly configured for all sending sources.
What’s the recommended approach to DMARC policy?
Moving to enforcement too quickly blocks legitimate email. The industry-standard approach is gradual escalation.
Start with monitoring
Set p=none initially:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
This policy:
- Generates reports for analysis
- Delivers all mail regardless of authentication
- Identifies all sending sources before enforcement
- Reveals authentication gaps without impacting delivery
Run monitoring for at least 30 days (longer for complex organizations) to capture all legitimate senders.
Move to quarantine
Once legitimate sources are authenticated:
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
Quarantine sends failing mail to spam rather than rejecting it outright. Recipients can still find messages if something was missed — providing a safety buffer during transition.
Enforce with reject
After confirming quarantine doesn’t affect legitimate delivery:
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Reject blocks unauthorized mail at the gateway. Spoofing attempts never reach recipients. This is the end goal — full protection against domain impersonation.
Percentage rollout
Use the pct= tag to apply policies gradually:
v=DMARC1; p=reject; pct=10; rua=mailto:dmarc@example.com
Only 10% of failing mail gets rejected; the rest follows the next-lower policy (quarantine, then none). Increase the percentage as confidence grows.
When should you use advanced fixes?
Standard authentication adjustments solve most DMARC failures. Advanced techniques address edge cases that basic configuration can’t handle.
ARC implementation
Authenticated Received Chain (ARC) preserves original authentication results across forwarding hops. When an intermediary server forwards mail:
- ARC stamps the original SPF/DKIM/DMARC results
- Each hop adds its own ARC seal
- The final receiver can verify the chain back to the source
ARC helps with mailing lists, shared mailboxes, and security gateways that modify messages. Implementation requires coordination with your email infrastructure or ESP.
Policy bypasses
For senders who can’t or won’t fix their authentication (business partners with legacy systems, for instance), create targeted bypasses:
- IP-restricted exceptions for known servers
- Separate handling for specific source domains
- Inbound policies that skip DMARC for specific senders
Bypasses sacrifice security for deliverability — use sparingly and restrict to trusted IPs.
Subdomain segregation
Complex organizations benefit from separating email streams by subdomain:
- support.example.com for help desk
- notify.example.com for transactional
- marketing.example.com for campaigns
Each subdomain can have its own SPF, DKIM, and DMARC records — isolating authentication issues to specific streams without affecting others.
DMARC failures reveal authentication gaps — visibility is the fix
DMARC failing isn’t inherently bad. The protocol is working correctly — it’s telling you something is misconfigured, or someone is spoofing your domain. The problem is discovering failures after campaigns bounce or customers stop receiving emails.
Continuous monitoring catches problems before they escalate:
- Identify new vendors that need authentication
- Catch DNS changes that break existing records
- See which sources are failing before delivery drops
- Distinguish spoofing attempts from configuration mistakes
EmailWarmup.com provides the visibility that makes DMARC manageable:
- Reputation monitoring and alerting
- Expert analysis of authentication failures
- 24/7 support from deliverability specialists
- Free email deliverability test across 50+ providers
- DNS authentication verification (SPF, DKIM, DMARC)
Don’t wait for bounced campaigns to discover DMARC problems. Monitor continuously and fix failures while they’re small.
Schedule a free consultation with an email deliverability consultant if you are having trouble with DMARC.
Frequently asked questions
Here are some commonly asked questions about DMARC failure:
DMARC fail means an email didn’t pass the DMARC authentication check — either SPF and DKIM both failed, or they passed but didn’t align with the From header domain. The receiving server couldn’t verify the sender’s legitimacy, so it handles the message according to your DMARC policy (deliver, quarantine, or reject).
Alignment failure. SPF and DKIM authenticated different domains than the one in your visible From header. DMARC requires the authenticated domain to match what recipients see. Check that your sending services use your domain for DKIM signing and that SPF’s Return-Path domain matches your From address.
Identify which senders are failing using DMARC reports, then authorize them properly. Add legitimate sources to your SPF record, configure custom DKIM with your domain as the signing domain, and verify alignment settings. For third-party services, follow their documentation to set up domain authentication specific to your organization.
No. Start with p=none to monitor traffic without blocking anything. Analyze reports to identify all legitimate sending sources and fix authentication gaps. Move to p=quarantine once confident, then to p=reject after confirming quarantine doesn’t affect valid mail. Rushing to reject blocks legitimate emails you didn’t know about.
Yes. Forwarding typically breaks SPF because the forwarding server’s IP isn’t in your SPF record. If the forwarder also modifies the message (adding footers, changing headers), DKIM breaks too — causing complete DMARC failure. DKIM is more resilient to forwarding when messages aren’t modified, making it critical for forwarding scenarios.
