Why DMARC Fails and How to Fix Common DMARC Errors

Few things are more frustrating than seeing "554 5.7.5 permanent error evaluating DMARC policy" in a bounce message, especially when you thought your email authentication was set up correctly. DMARC failures can block legitimate emails, send them to spam, or generate confusing error messages that are hard to decode.

This guide covers the most common DMARC errors, explains what each one actually means, and walks you through how to fix them. Whether you are seeing failures in bounce messages, DMARC reports, or email headers, you will find the answer here.

"554 5.7.5 Permanent Error Evaluating DMARC Policy"

This is one of the most searched DMARC errors, and it usually means the receiving mail server tried to check your DMARC record but could not process it properly. The message was rejected because the server could not evaluate your policy.

Common causes:

• Your DMARC record has a syntax error, such as a missing semicolon, an invalid tag, or a misspelled value.
• You have multiple DMARC TXT records on _dmarc.yourdomain.com. You should only have one.
• Your DMARC record is published at the wrong DNS location, like dmarc.yourdomain.com instead of _dmarc.yourdomain.com.
• Your DNS provider has a configuration issue that prevents the record from being returned properly.

How to fix it:

"No DMARC Record Found"

This error appears in email headers, delivery reports, or DMARC checking tools when the receiving server looked up _dmarc.yourdomain.com and found nothing. It means you either do not have a DMARC record at all, or it is published in the wrong place.

Common causes:

• You never created a DMARC record for your domain.
• The record is published at the wrong subdomain. It must be at _dmarc, not dmarc or the root domain.
• DNS propagation has not completed yet. If you just added the record, it can take up to 48 hours to propagate, although most changes appear within minutes.
• Your DNS provider requires the full subdomain including your domain name in the host field, and you only entered _dmarc when it expected _dmarc.yourdomain.com.

How to fix it:

First, check whether you actually have a record by looking it up at dmarcrecordchecker.com. If the tool finds nothing, you need to create one. If you recently added a record, wait a few hours and check again — DNS propagation may still be in progress.

If you are sure you added the record but it is not showing up, log into your DNS provider and verify the host field. Some providers automatically append your domain, so you should enter just _dmarc. Others require the full _dmarc.yourdomain.com. Check your provider's documentation if you are unsure. Google Workspace users should verify that their DMARC record does not conflict with any records Google's setup wizard may have created.

SPF or DKIM Alignment Failures

Your DMARC record might be perfectly valid, but emails still fail DMARC because of alignment issues. DMARC requires that the domain in either your SPF or DKIM check matches (aligns with) the domain in the "From" header of your email.

What alignment means: If your email's "From" address is info@yourcompany.com, then either the SPF-authenticated domain or the DKIM-signing domain must also be yourcompany.com (or a subdomain of it, under relaxed alignment). If the SPF domain is sendgrid.net and the DKIM domain is also sendgrid.net, neither aligns with yourcompany.com, and DMARC fails — even though SPF and DKIM both passed individually.

How to fix alignment failures:

• For SPF alignment: Make sure your Return-Path (envelope sender) domain matches your From domain. Many email services let you configure a custom Return-Path or bounce domain. Set it to a subdomain of your domain, like bounce.yourcompany.com, and add that to your SPF record. For more on how SPF and DMARC interact, see our SPF vs DMARC comparison.
• For DKIM alignment: Configure your email service to sign messages with your domain instead of theirs. Most services (Mailchimp, SendGrid, HubSpot, etc.) let you set up custom DKIM signing by adding CNAME records to your DNS. Generate the right DKIM keys at dkimcreator.com.

You only need one of SPF or DKIM to align for DMARC to pass. But having both configured gives you a safety net.

Misconfigured DMARC Policy

Sometimes the DMARC record is valid and the DNS is correct, but the policy itself is causing problems. This usually happens when an organization moves to p=quarantine or p=reject before all their legitimate senders are properly authenticated.

Signs of a policy problem:

• Legitimate emails from your marketing platform, CRM, or helpdesk are landing in spam or being rejected.
• Your DMARC aggregate reports show legitimate IP addresses with fail dispositions.
• Internal users or customers report not receiving expected emails.

How to fix it:

If you moved to enforcement too quickly, step back to p=none temporarily while you sort out your authentication. Check your DMARC reports to identify which senders are failing. For each one, verify that SPF or DKIM is properly configured and aligned.

Once all legitimate senders pass, move back to enforcement gradually using the pct tag. Start with pct=10 at p=quarantine and increase over time. Our DMARC policy levels guide covers this process in detail.

DNS Propagation Delays

If you just created or updated your DMARC record and it does not seem to be working, DNS propagation is likely the cause. Changes to DNS records are not instant — they need to propagate across the global DNS infrastructure.

What to expect:

• Most changes appear within five to thirty minutes.
• Some DNS providers and ISP resolvers cache records for longer. If your TTL (time to live) was set high on the old record, it may take up to 48 hours for the new record to be seen everywhere.
• Different mail servers may see the old and new record at the same time during propagation.

What to do: Be patient. Check your record at dmarcrecordchecker.com periodically. If the tool shows your new record, propagation is working. If it still shows the old record after 48 hours, double-check that you saved the changes at your DNS provider.

Preventing Future DMARC Failures

The best way to avoid DMARC problems is to catch them before they affect your email delivery. Here are three habits that help:

Review your DMARC reports regularly. Aggregate reports show you every source sending email as your domain. If a new service starts failing, you will see it in the data before it becomes a problem.

Test changes before deploying. When you modify your SPF, DKIM, or DMARC records, verify them with a lookup tool before and after. A simple typo can break everything. Developer teams can build DNS validation into their deployment pipelines to catch these errors automatically.

Monitor continuously. DNS records can change unexpectedly — a provider migration, an expired DKIM key, or an accidental deletion can all cause DMARC failures. Automated monitoring catches these issues before your recipients notice.

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.