DMARC Troubleshooting Guide: Fix Every Common DMARC Problem

DMARC issues show up in unexpected places — a bounce message you were not expecting, a security scanner flagging your domain, or aggregate reports full of failures you cannot explain. The frustrating part is that the error messages rarely tell you what is actually wrong or how to fix it.

This guide covers the most common DMARC problems domain owners run into, explains what each one means in plain terms, and points you to the right fix. Whether you are setting up DMARC for the first time or debugging a configuration that was working fine until last week, start here.

"DMARC Quarantine/Reject Policy Not Enabled"

This is one of the most common warnings you will see from email security scanners, deliverability tools, and compliance audits. It means one of two things: either your domain has no DMARC record at all, or your record exists but uses p=none, which tells receiving servers to take no action on failing emails.

A p=none policy is useful for monitoring — it lets you collect aggregate reports and see who is sending email as your domain — but it does not actually protect you from spoofing. Scanners flag it because from a security perspective, p=none offers no enforcement.

Quick fix: If you have no DMARC record, create one with p=none and a reporting address first, then work toward enforcement. If you already have p=none, review your DMARC reports for two to four weeks to make sure all legitimate senders are passing authentication, then move to p=quarantine and eventually p=reject. Use the pct tag to roll out gradually.

For the full step-by-step process, see DMARC Quarantine/Reject Policy Not Enabled: How to Fix It.

"No DMARC Record Found"

This error means the receiving mail server looked up _dmarc.yourdomain.com and found nothing. Without a DMARC record, servers have no instructions for handling unauthenticated email from your domain, and most security tools will flag this as a significant gap.

Common causes:

• You never published a DMARC record. This is more common than people expect — many domains have SPF configured but never got around to DMARC.
• The record is published at the wrong DNS location. DMARC records must live at _dmarc.yourdomain.com, not dmarc.yourdomain.com or the root of your domain.
• Your DNS provider expects the full hostname in the record field, and you only entered _dmarc when it needed _dmarc.yourdomain.com (or vice versa).
• DNS propagation has not finished. If you just added the record, give it up to 48 hours, though most changes appear within minutes.

Quick fix: Look up your domain at dmarcrecordchecker.com to confirm whether a record exists. If nothing shows up, create one using our DMARC record generator and add it as a TXT record at _dmarc.yourdomain.com in your DNS provider. Double-check the host field format your provider expects.

For a complete walkthrough, see How to Create a DMARC Record.

SPF or DKIM Alignment Failures

This is one of the trickiest DMARC issues because SPF and DKIM can both pass individually while DMARC still fails. The reason is alignment — DMARC requires that the domain authenticated by SPF or DKIM matches the domain in the visible "From" header of your email.

Here is a concrete example. Your email's From address is hello@yourcompany.com. Your email service sends the message with a Return-Path of bounce@sendgrid.net and signs it with DKIM using sendgrid.net. Both SPF and DKIM pass for sendgrid.net, but neither aligns with yourcompany.com. DMARC fails.

How to fix alignment:

• SPF alignment: Configure a custom Return-Path or bounce domain with your email service. Set it to a subdomain like mail.yourcompany.com and add that subdomain to your SPF record.
• DKIM alignment: Set up custom DKIM signing so your email service signs messages with your domain instead of theirs. Most services — Mailchimp, SendGrid, HubSpot, Amazon SES — support this by having you add CNAME records to your DNS. Generate the right keys at dkimcreator.com.

For a deeper explanation of relaxed versus strict alignment and how to configure it, see DMARC Alignment Explained. If you are seeing alignment failures in your reports and need to trace the source, our guide on Why DMARC Fails and How to Fix It walks through the debugging process.

Legitimate Emails Being Rejected or Quarantined

You moved to an enforcement policy and now some of your own emails are landing in spam or getting bounced. This is the most common consequence of moving to p=quarantine or p=reject too quickly without thoroughly reviewing your DMARC reports first.

Why it happens:

• A third-party service is sending email as your domain but is not included in your SPF record or configured with DKIM signing for your domain.
• You added a new email tool — a CRM, helpdesk, invoicing platform, or marketing automation tool — after setting up DMARC and forgot to update your authentication.
• Your DKIM keys expired or were rotated without updating DNS.
• You skipped the monitoring phase entirely and went straight to enforcement.

Quick fix: Temporarily roll back to p=quarantine (if you are at p=reject) or lower your pct value to reduce the percentage of messages being enforced. Then review your DMARC aggregate reports to identify which legitimate senders are failing. Fix authentication for those senders before increasing enforcement again.

For a detailed comparison of how each policy level works and when to use each one, see DMARC Policy Levels Explained.

Multiple DMARC Records

The DMARC specification requires exactly one TXT record at _dmarc.yourdomain.com. If you have two or more records, the behavior is undefined — most receiving servers will treat this the same as having no DMARC record at all. Your policy is effectively ignored.

This happens more often than you might think. Common causes include editing a record in your DNS provider and accidentally creating a new entry instead of updating the existing one, or migrating DNS providers and ending up with records in both the old and new system during the transition.

Quick fix: Log into your DNS provider and look at the TXT records for _dmarc.yourdomain.com. If you see more than one, delete the extras. Keep the record that reflects your current desired policy. Then verify at dmarcrecordchecker.com that only one record is returned.

For more on how this issue occurs and how to clean it up, see Multiple DMARC Records: Why It Breaks and How to Fix It.

DNS Propagation Delays

You published or updated your DMARC record, but when you check it, the old record still appears — or nothing appears at all. DNS propagation is the time it takes for your DNS changes to spread across the internet's nameservers, and it can cause confusion when you are trying to verify that your changes took effect.

How long to wait: Most DNS changes propagate within a few minutes to a few hours. The often-cited "up to 48 hours" is a worst-case scenario and rarely applies in practice. However, if you have high TTL (time-to-live) values on your existing records, cached copies may persist longer.

What to do while you wait:

• Use a DNS propagation checker to see whether your change has reached different nameservers around the world.
• Lower your TTL value before making changes. If you set your TTL to 300 seconds (5 minutes) a day before you plan to update your record, the old cached version will expire quickly once you make the change.
• Do not make additional changes while waiting. Stacking changes on top of each other during propagation makes it harder to debug if something goes wrong.

For a detailed breakdown of propagation timelines and how to speed things up, see DMARC Propagation Time: How Long Until Your Record Works.

Email Forwarding Breaking DMARC

Email forwarding is one of the most common causes of unexpected DMARC failures, and it catches people off guard because the failures happen on messages you legitimately sent. The problem is that when an email is forwarded, the forwarding server changes the envelope sender (Return-Path), which breaks SPF alignment. If DKIM is not in place or the forwarding server modifies the message body or headers, DKIM can break too.

The result: A perfectly legitimate email that you sent, which passed all authentication when it was originally delivered, fails DMARC when the recipient's mail server forwards it somewhere else.

Quick fix: The most reliable solution is to make sure DKIM is properly configured for your domain. Unlike SPF, DKIM signatures travel with the message and survive forwarding as long as the message content is not modified. With DKIM passing and aligned, your emails will pass DMARC even when SPF breaks due to forwarding.

For organizations dealing with widespread forwarding issues, ARC (Authenticated Received Chain) is an emerging standard that helps preserve authentication results across forwarding hops. See DMARC and Email Forwarding for a full explanation, and DMARC and ARC for how ARC works and when to rely on it.

Subdomain Policy Issues

DMARC policies apply to the exact domain where they are published, but what about subdomains? If you publish a DMARC record at _dmarc.yourcompany.com with p=reject, that policy covers yourcompany.com — but emails sent from marketing.yourcompany.com or support.yourcompany.com are not automatically covered by the same policy.

By default, subdomains inherit the parent domain's policy. However, you can override this behavior using the sp= tag in your DMARC record. Setting sp=reject in your main domain's record applies the reject policy to all subdomains. Setting sp=none would leave subdomains unprotected even if your main domain is at full enforcement.

Common issues:

• You set p=reject but forgot about sp=, so subdomains default to inheriting the reject policy — which may break email from subdomains you were not monitoring.
• You set sp=none intentionally during rollout but forgot to update it later, leaving subdomains unprotected.
• A subdomain has its own DMARC record that conflicts with or overrides the parent domain's policy.

Quick fix: Check your current DMARC record for the sp= tag. If you want all subdomains to follow the same enforcement policy as your main domain, you can either set sp=reject explicitly or remove the sp= tag entirely (subdomains will inherit p=). If specific subdomains need different policies, publish individual DMARC records at _dmarc.subdomain.yourcompany.com.

For a complete guide to managing DMARC across subdomains, see DMARC for Subdomains.

Diagnostic Checklist

When something goes wrong with DMARC, work through this checklist in order. It covers the most common causes of failure and will help you isolate the problem quickly.

Monitor Your DMARC Record

You've created your DMARC record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.