554 5.7.5 Permanent Error Evaluating DMARC Policy [SOLVED]

Domain owners may come across the “554 5.7.5 permanent error evaluating DMARC policy” error due to the following reasons: 

1. Incorrect SPF, DKIM, or DMARC record syntax 
2. Redundant or missing characters in DNS records 
3. Lack of support for SPF-aligned emails 
4. DKIM signature domain mismatches

The “554 5.7.5 permanent error evaluating DMARC policy” is a common error that stops the SMTP ports from accepting emails from your domain. The issue usually happens due to a combination of settings in the SPF record, DMARC record, or email service. 

In this guide, we’ll describe how to resolve this issue quickly and easily.

Key Takeaways

• Issues such as incorrect syntax in SPF, DKIM, or DMARC records, redundant characters, or lack of SPF-aligned email support can trigger the “554 5.7.5 permanent error evaluating DMARC policy.”
• This error blocks SMTP ports from accepting emails, disrupting email delivery.
• Ensure your SPF record ends with -all or ~all, avoids neutral policies, and adheres to DNS lookup limits.
• Mismatches between the d= tag in DKIM signatures and sending domains can fail DMARC validation.
• Correct record syntax, adjust DMARC to p=none temporarily, and monitor your mail flow before enforcing your policy again. Check your email provider’s SPF-alignment support, and enable DKIM authentication.
• Use PowerDMARC’s free DMARC Lookup Tool to efficiently identify your records’ errors.

Why Are You Getting  “554 5.7.5 Permanent Error Evaluating DMARC Policy” Error?

If you are facing a “554 5.7.5 permanent error evaluating DMARC policy”, here are some common reasons behind this error:

1. Incomplete or Incorrect DMARC Record Settings

Incomplete DMARC records can lead to errors in DMARC policy evaluation. For example a missing p= tag. If your DMARC record looks something like this: 

v=DMARC1; pct=100;

This is an example of incomplete DMARC settings missing the policy tag. This is an erroneous record. When you set up DMARC, you can either choose to use p=none or p=quarantine/reject.

Similarly, syntax errors in your record like extra characters or spaces can also trigger the 554 5.7.5 permanent error evaluating DMARC policy error. 

v=DMARC1; p:none; pct=100; rua=mailto:[email protected]; 

In this example the “:” is a wrong character since all mechanisms are followed by an equal-to (=) sign, followed by the value. 

The correct sequence of DMARC records

• Your DMARC record should start with the version name v=DMARC1 
• The policy tag is also mandatory and should have a value of none/reject/quarantine 
• All DMARC tags must be followed by “=[value]” and end with a semicolon (;) 
• There should be a single space between the individual mechanisms or tags 
• There should be no spaces between each defined mechanism for example: p=none; 

2. Incorrect DKIM Alignment

DKIM stands for DomainKeys Identified Mail. It is a method of verifying the authenticity of the email sender, which prevents malicious actors from impersonating the email sender’s domain name.

Sometimes you might face issues with your DKIM authentication. A mismatch between the “d=” tag in the DKIM signature, and the sending domain, will result in a failed DMARC evaluation.

For instance, if you have changed your domain name and have not updated it in DKIM records, then it will fail the DMARC policy evaluation as well.

3. Incorrect SPF Record

SPF stands for Sender Policy Framework. It is an email authentication technique used to verify whether an email message comes from a valid sender’s server or not.

DMARC works by checking SPF records to verify if they are valid or not. You must ensure that the SPF records are configured correctly and work with your domain name to avoid this error. A few things to avoid with SPF are as follows: 

• Your SPF record must end with a failure mechanism (-all or ~all) 
• Avoid using a neutral policy for SPF evaluation 
• Avoid exceeding SPF DNS and void lookup limits 

4. Lack of Support for SPF-aligned Emails by Your ESP

Sometimes, if you’re receiving the “554 5.7.5 Permanent Error Evaluating DMARC Policy” error, it may be a problem on your email service provider’s side. Not all email service providers support SPF-aligned emails. Some even handle SPF policies internally which may lead to errors if you have SPF enabled for your domain. 

Fix “554 5.7.5 Permanent Error Evaluating DMARC Policy” in 5 Steps

You can follow the steps below to potentially resolve the “554 5.7.5 Permanent Error Evaluating DMARC Policy” error. But a resolution is not guaranteed. If following these steps don’t fix the error contact us for a free domain security evaluation. 

1. Remove Extra Characters From The Record

The 5.7.5 permanent error assessing DMARC policy may stem from various factors, yet the predominant causes typically include:

• Misused quotation marks
• Surplus characters or symbols within the record
• A lacking semicolon to conclude the record.

Here’s an example of a record that gave this error:

This record might look fine to you at first, but on testing it, we got the “5.7.5 permanent error evaluating DMARC policy” message.

When we checked again, we realized that there was an extra dot at the end of the record—if you look closely at the same record above, you can see that there is a period (dot) (.) at the end. 

Once we removed that dot and ran the test again, it worked perfectly.

Here’s how the same record looked with no errors:

2. Change Your SPF Record From Neutral

If you’re getting an error message that says “5.7.5 permanent error evaluating DMARC policy” when you’re trying to send an email, it’s probably because your SPF record is set to Neutral.

SPF stands for Sender Policy Framework, and it helps make sure that the mail server from which an email is sent is legit. It’s not good enough just to have a server that sends emails; there needs to be some verification that the server is legit. That’s what SPF does: it verifies that your mail server has the right credentials.

Why can’t your SPF record be neutral? 

If messages are allowed to be sent through a neutral server, scammers could send fake emails using your domain name, which means people might think they’re real when they aren’t—and end up clicking on links or downloading files they shouldn’t.

That’s why you should at least change your SPF record to softfail ~all or hardfail -all when you implement DMARC—so that people know a message from your domain name is probably safe.

3. Check If Your Email Service Provider Supports SPF-Aligned Emails

One of the most common reasons for receiving this error is that your email service provider doesn’t support SPF-aligned emails.

Email providers like MailChimp and ProtonMail have their own SPF records, and when you send emails through them, they’re not sending SFP-aligned emails. As such, it’s important for you to check your email service provider’s SPF disposition type to see if it supports SPF-aligned emails.

If it does, then your DKIM signature will be modified during the sending process so that the From address aligns with your own domain (instead of with MailChimp’s domain) and ensures that you pass the DMARC policy evaluation.

If it does not, then you’ll need to use a different email service provider (or change your existing provider’s settings) so that you can send SPF-aligned emails.

4. Shift to p=none Policy for DMARC

If you’re getting a “554 5.7.5 permanent error evaluating DMARC policy” error, it means that the DMARC policy on your domain is preventing you from sending your emails. To fix this, you just need to change your DMARC record with your DNS provider to have a p=none policy.

The DMARC policy tells email providers what to do with emails that fail the SPF and DKIM checks: reject them or quarantine them. If you want to send emails even if those checks don’t pass, you can relax your policy temporarily by setting it to p=none in your DNS settings.

DMARC none is called a “relaxed, no-action or monitoring-only policy”, so it’s not recommended for email spoofing prevention. But changing your DMARC policy to p=none will allow you to deliver your emails to inboxes without being impacted by DMARC errors.

For example, you could change this record:

to this:

What does this mean for you? You can send your email even if it doesn’t pass DMARC. However, you’ll want to ultimately revert to a p=reject or p=quarantine policy to prevent email spoofing on your domain.

5. Set Up DomainKeys Identified Mail (DKIM) Authentication

Should you encounter the error code “554 5.7.5 permanent error evaluating DMARC policy,” it indicates that DomainKeys Identified Mail (DKIM) email authentication hasn’t been activated for your domain—thus, to pass DMARC, you have to have a DKIM email authentication record set up (if you don’t already have SPF).

Here are your steps to do that:

• Sign up on PowerDMARC, and select DKIM record generator from our Power Toolbox. 
• Enter your domain name, define a selector (e.g. selector1) for your record, and hit the Generate button. 
• Our tool will automatically generate your DKIM public and private key pairs. 
• Copy the generated TXT record name and TXT record value (public key value) and publish them on your DNS by accessing your DNS management console. 

DMARC Policy Formatting Requirements

DMARC is an email authentication protocol that allows recipients to verify that emails purporting to be from your domain are actually coming from your domain. This guide will outline some of the important formatting requirements when setting up DMARC for the first time.

•  First, your DMARC record must begin with “v=DMARC1”. This lets email providers know that the record is formatted according to the version of DMARC that’s currently being used (which is 1). 
•  Next, specify your policy. The policy must be either p=none, p=quarantine, or p=reject. This tells email providers what to do when an email fails authentication checks. 
• The policy field in your DMARC record is a mandatory field after the v= version field. The policy can be one of three things: p=none, p=quarantine, or p=reject. “None” means that you want the email provider to do nothing when it sees a suspicious email from your domain—it will simply leave it alone, and might even deliver it. “Quarantine” means that you want suspicious emails from your domain to be delivered as spam or junk mail instead of being delivered as normal mail. Finally, “reject” means that you want suspicious emails from your domain to be rejected and never delivered at all.
•  Use colons as separators between values — it’s a good idea to use colons and not semicolons. Semicolons can cause problems, especially when multiple values are specified on a single line.
•  Don’t use extra characters or bad quotes. Excess whitespace at the end of lines will be treated as part of the record, which can cause problems.

Here’s an example of a good DMARC record:

How To Find Errors In DMARC Record Policy

Having a DMARC record is a good step toward securing your email communication. However, if there are any errors in it, the entire system will be ineffective. This is why it’s important to find any errors and resolve them as soon as possible.

The best way to do this is by using the DMARC lookup tool by PowerDMARC. The tool checks whether or not your record is valid and shows you any potential errors. You can use the tool for free by following these steps:

1. Sign up on PowerDMARC and navigate to the DMARC Lookup Tool in Power Toolbox.

2. Enter your domain name into the empty field.

3. Once your record has been checked, the tool will show you an overview of the published syntax while highlighting errors in your record.

4. If there are any errors, they will be highlighted on the page. 

5. Once you know where the errors are coming from, you can resolve them easily using the instructions provided with each error message.

Are You Worried About The Security Of Your Business Emails?

It’s a real concern. In fact, many cyber attacks start with an email. Verizon’s 2019 DBIR reported that 94% of data breaches start with attacks targeting people via email.  

But that doesn’t mean you have to give up on reaching your customers through email!

Instead, secure all your business emails with email authentication services by PowerDMARC. This will help you gain the trust of your customers and protect your brand from phishing attempts by hackers and other bad actors.

With PowerDMARC, you can ensure that any emails coming from your company are not only safe for customers to open but also easy for them to identify as legitimate communications from your brand by placing your business’s seal on them.

We know that protecting the integrity of your company name and image is important to you, and we want you to be able to do it in a way that makes sense for both parties involved—so that’s why we offer this service at an affordable price point while still giving our clients access to all of our expertise on email authentication techniques.

Is your domain protected against email spoofing? Get your free DMARC trial today!

• About
• Latest Posts

Yunes Tarada

Domain & Email Security Expert at PowerDMARC

Yunes is an Operations Team Lead at PowerDMARC with expert knowledge in email authentication and security. Yunes is a Microsoft-certified Azure Administrator Associate with certifications in CompTIA A+ and many more.

Latest posts by Yunes Tarada (see all)

• Yahoo Japan Enforces DMARC Adoption for Users in 2025 - January 17, 2025
• MikroTik Botnet Exploits SPF Misconfigurations to Spread Malware - January 17, 2025
• DMARC Unauthenticated Mail is Prohibited [SOLVED] - January 14, 2025