DMARC Troubleshooting Guide

DMARC failures are frustrating because the symptoms are vague ("email not delivered"), the error messages are technical, and the root causes are spread across multiple systems — your DNS, your sending services, and the receiving server's policies. A single misconfigured DKIM record can cascade into bounced email, confused support tickets, and hours of debugging.

This guide covers the most common DMARC issues, explains what's actually happening under the hood, and gives you specific fixes.

Quick Diagnosis

Before diving into specific errors, start with two things:

1. Run our free DMARC record checker — it parses your record, validates every tag, and flags syntax errors, missing fields, and policy gaps. Many problems are visible in the record itself.
2. Check your aggregate reports — if your record looks correct but email is still failing, the reports will show exactly which sending source is failing, which authentication check it's failing, and why.

If your record looks correct and you don't have reports set up, that's your first fix — add rua=mailto:dmarc-reports@yourdomain.com to your DMARC record. You can't troubleshoot what you can't see.

No DMARC Record Found

What it means: A lookup at _dmarc.yourdomain.com returns no TXT record. Receiving servers have no policy to apply, so they fall back to their own defaults.

Why it happens:

The most obvious cause is that you haven't published a DMARC record yet. But if you believe you have, the issue is usually one of these:

• Wrong DNS location. DMARC records go at _dmarc.yourdomain.com, not dmarc.yourdomain.com (missing the underscore) or _dmarc.www.yourdomain.com (wrong subdomain). In most DNS panels, you enter _dmarc as the host/name field, and the panel appends your domain automatically. If you enter _dmarc.yourdomain.com as the host, some panels will create _dmarc.yourdomain.com.yourdomain.com — a common mistake.

• DNS propagation delay. After adding or changing a DNS record, it can take up to 48 hours for the change to propagate globally, though it usually happens within minutes. If you just published the record, wait an hour and check again.

• Record type mismatch. DMARC must be a TXT record. Some DNS panels have separate fields for different record types — make sure you're creating a TXT, not a CNAME or MX.

• Domain vs subdomain. If you're checking subdomain.yourdomain.com, DMARC first looks at _dmarc.subdomain.yourdomain.com. If that doesn't exist, it falls back to _dmarc.yourdomain.com and uses the organisational domain's policy. This fallback is by design, but it means a "no record found" error on a subdomain might not be a problem if the parent domain has a DMARC record.

Fix: Publish a DMARC record starting with p=none and a rua address. See no DMARC record found: what to do for step-by-step instructions.

DMARC Policy Not Enabled

What it means: Your DMARC record exists, but the policy is p=none — monitoring only.

Is this actually a problem? Context matters:

• You just published your DMARC record last week. This is correct. p=none is the right starting point. Collect reports, identify your senders, verify alignment before enforcing.
• You've been at p=none for 3 months and haven't looked at a single report. This is the problem. The record exists, but it's not protecting anything. You're getting the compliance checkbox without the actual security.
• A security audit flagged it. Auditors and compliance tools flag p=none because it doesn't enforce. They're right — monitoring without enforcement is incomplete. But the fix isn't jumping straight to p=reject. Follow the enforcement guide to get there safely.

Fix: If you've been at p=none for more than a month and your aggregate reports show your legitimate senders are aligned, it's time to move to enforcement. Start with p=quarantine; pct=10.

Full details at DMARC policy not enabled: what it means.

DMARC Fail

What it means: An email was checked against your DMARC policy and failed. Neither SPF nor DKIM passed with proper alignment to the From header domain.

This is the most common DMARC issue and the one with the most varied causes. The table below covers the main scenarios:

The alignment trap: The most confusing scenario is when both SPF and DKIM pass in the authentication results, but DMARC still fails. This happens when neither passing domain aligns with the From header. For example, SPF passes for bounce.mailservice.com (the Return-Path domain) and DKIM passes for d=mailservice.com (the signing domain), but the From header says you@yourdomain.com. Neither mailservice.com nor bounce.mailservice.com aligns with yourdomain.com.

The fix is almost always configuring custom DKIM on the sending service so it signs with d=yourdomain.com. Most ESPs, CRMs, and helpdesks support this — it's typically a pair of CNAME records in your DNS and a toggle in the service's settings.

For a complete troubleshooting walkthrough, see DMARC fail: why it happens and how to fix it.

554 5.7.5 Permanent Error Evaluating DMARC Policy

What it means: The receiving server rejected the email with a hard bounce. The 554 5.7.5 status code specifically indicates a DMARC policy rejection — the server checked your DMARC record, the email failed, and the policy said to reject.

Why it's different from a generic DMARC fail: With p=none or p=quarantine, a DMARC failure results in delivery (to inbox or spam). The 554 error only happens when the receiving server enforces a reject disposition — either because your DMARC policy is p=reject, or because the receiving server has its own strict DMARC enforcement policy regardless of your published policy.

Common causes:

• Your policy is p=reject and the email failed authentication. This is the system working as designed. The email was unauthenticated and your policy says to reject it. If the email is legitimate, fix the sender's alignment.
• Syntax error in your DMARC record. Some receivers interpret an unparseable DMARC record as a hard failure. Check for common syntax errors: missing v=DMARC1 as the first tag, extra spaces, missing semicolons between tags, or invalid tag values.
• The receiver has strict local policy. Some corporate mail servers enforce DMARC rejection even if your policy is p=quarantine or p=none. This is less common but does happen in high-security environments.

Fix: Run your domain through our DMARC record checker to validate syntax. If the record is valid, check your aggregate reports for the specific sender that's bouncing — you'll see the authentication failure details. Fix the sender's SPF or DKIM alignment.

Full details at DMARC permanent error 554: causes and fixes.

DNS Authentication DMARC Fail

What it means: This is a specific error message from email security gateways, most commonly Mimecast. The full message is usually "DNS Authentication - DMARC Fail" in a bounce notification.

Why it's different from a standard DMARC fail: Email security gateways sit in front of the recipient's mail server and apply their own checks. They may evaluate DMARC before the email reaches the destination server, and they may have stricter enforcement policies than the recipient's own DMARC settings suggest.

Common causes:

• The same alignment issues as generic DMARC fail. Start with the troubleshooting table above.
• Gateway-specific behaviour. Mimecast and similar gateways may enforce DMARC rejection even when the recipient's domain has p=none. The gateway is protecting its customers more aggressively than the domain's own policy requires.
• SPF doesn't include the relay. If email passes through an intermediate server (a relay or gateway) before reaching Mimecast, the IP that Mimecast sees might be the relay, not the original sender. If that relay IP isn't in the SPF record, SPF fails.

Fix: Check whether the email passes DMARC when sent to a non-gateway-protected recipient (e.g., a Gmail address). If it passes elsewhere but fails at Mimecast, the issue is likely the gateway's relay IP not being in SPF, or the gateway modifying the message and breaking DKIM.

See DNS authentication DMARC fail: what it means and how to fix it for gateway-specific troubleshooting steps.

Third-Party Senders Failing

This deserves its own section because it's the most common real-world DMARC issue. Nearly every organisation uses third-party services to send email — marketing platforms, CRMs, transactional email services, helpdesks, billing systems. Each one is a potential alignment failure point.

The typical pattern: You set up a new service, configure it to send email as you@yourdomain.com, and it works. Email gets delivered. Then you publish a DMARC record or move from p=none to p=quarantine, and suddenly that service's email starts going to spam or bouncing.

The service was never properly aligned — it was just passing under the radar because your DMARC policy wasn't enforcing.

How to fix each sender:

1. Check SPF first. Log into the service's settings and find their sending IP addresses or SPF include mechanism (e.g., include:spf.sendgrid.net). Add it to your SPF record. This fixes SPF authentication but may not fix SPF alignment — the envelope sender domain still needs to match.

2. Configure custom DKIM. This is the more reliable fix. Most services provide a set of DNS records (usually CNAMEs) that you publish in your DNS. Once published and verified, the service signs emails with d=yourdomain.com instead of their own domain. This gives you DKIM alignment regardless of what happens with SPF.

3. Verify alignment, not just authentication. After making changes, send a test email and check the headers. Look for dkim=pass with d=yourdomain.com (not the service's domain). Or check your next aggregate report for that sender's IP — the DKIM domain should now be yours.

4. Check for envelope sender configuration. Some services let you configure a custom Return-Path domain (also called bounce domain or envelope sender). This fixes SPF alignment. Not all services support this, which is why DKIM alignment is the more universal solution.

Services that commonly need DKIM configuration:

• Marketing: Mailchimp, HubSpot, ActiveCampaign, Brevo, ConvertKit, Constant Contact
• Transactional: SendGrid, Amazon SES, Postmark, Mailgun
• CRM: Salesforce, HubSpot (uses a separate sending config from marketing)
• Helpdesk: Zendesk, Freshdesk, Intercom
• Other: GitHub notifications, Jira, custom applications using SMTP

Each service has its own DKIM setup process. Check the service's documentation for "custom DKIM" or "email authentication" settings.

Debugging Methodology

When none of the specific sections above solve your problem, use this systematic approach:

1. Validate your DMARC record. Run it through our checker. Fix any syntax issues before investigating further.
2. Check your SPF record. Make sure it's valid, under the 10-lookup limit, and includes all your sending sources. An SPF permerror (too many lookups) silently breaks SPF for all senders.
3. Send a test email to a Gmail address. Open the email in Gmail, click the three dots, "Show original." This shows you the full authentication results — SPF, DKIM, DMARC, and alignment — for that specific message.
4. Check your aggregate reports. Find the failing source IP. Look at the authentication details. Is SPF passing? Is DKIM passing? Is either aligning?
5. Check the sending service's DKIM configuration. If DKIM is failing or signing with the wrong domain, the fix is in the service's settings, not in your DNS (though you may need to publish new DNS records the service provides).
6. Test after each change. DNS changes can take time to propagate. After updating a record, wait 15–30 minutes, then test again. Don't make multiple changes at once — it makes it impossible to tell what fixed the issue.

Still Stuck?

If you've worked through these steps and are still seeing failures:

1. Run a check with our free DMARC record checker to validate your full authentication chain
2. Review your DMARC aggregate reports to identify the specific failing source and authentication details
3. Check the sending service's documentation for DMARC/DKIM setup instructions — search for "[service name] DKIM setup" or "[service name] email authentication"
4. Contact the sending service's support — they can verify whether DKIM is configured correctly on their end