What is the ‘554 5.7.5’ permanent error in DMARC and how to fix it?

The response from the remote server was:

550554 5.7.5 Permanent Error Evaluating DMARC policy - https://support.google.com/mail/?p=NoSuchUser 5614622812f47-3c9abcd56a5si510142b6e.2- gsmtp

Have you been receiving this error message lately? If so, then your DMARC has an issue – it has encountered a “554 5.7.5 Permanent Error Evaluating DMARC Policy” error when sending emails. This triggers the email delivery process, ultimately causing emails to either land in spam folders or bounce back with the above response. And not to mention, how failed emails impact your marketing, PR, customer support, internal communication, and operations in general.

While this is one of the common DMARC errors, not much has been discussed about it on the internet. So, we have created a full-fledged guide for you on what this is and how you can fix it at your end without leaving any cybersecurity gap open in your email ecosystem.

What is the “554 5.7.5 Permanent Error Evaluating DMARC Policy” error?

This error prompts when the intended recipient’s mail server fails to evaluate the DMARC policy for emails sent from your domain. This causes emails to either be marked as spam or rejected from entering the mailbox altogether.

This inaccuracy in evaluating the DMARC policy can be due to misconfigurations in your SPF, DKIM, and DMARC records.

SPF record misconfigurations triggering the “554 5.7.5 Permanent Error Evaluating DMARC Policy” error

An SPF record is a TXT format record that includes all the IP addresses and mail servers officially authorized by you to send emails on your organization’s behalf. Upon reception, the receiving server first retrieves the SPF record corresponding to the sender’s domain and verifies if the sender’s IP address or mail server is listed in it.

DMARC policy evaluation is heavily dependent on SPF records– a misconfigured SPF record means a problematic DMARC authentication exercise.

Here are the common errors you may encounter in your SPF record-

Missing SPF record: This means there is no SPF record corresponding to your domain.
Multiple SPF records: Having more than one SPF record for a domain can cause email delivery issues. There should only be one SPF record per domain.
Syntax errors: SPF records must follow a specific syntax. Common syntax errors include missing or extra characters, incorrect use of qualifiers, and improper format.
Too many DNS lookups: The SPF specification limits the number of DNS lookups to 10. Exceeding this limit can cause the SPF check to fail.
Incorrect mechanisms: Using incorrect mechanisms, such as including IP addresses that don’t send emails on behalf of your domain or using mechanisms like +all, which allows all IP addresses, can lead to security vulnerabilities.
Overly permissive policies: Using +all at the end of the SPF record allows all IP addresses to send emails on behalf of your domain, which defeats the purpose of having an SPF record.

Missing ‘include’ statements: If you use third-party services to send email (like marketing platforms or email gateways), you need to include their SPF records using the include mechanism. Missing these can result in failed SPF checks.
Typos in domain names: Typographical errors in domain names within the SPF record can cause legitimate emails to fail SPF checks.
Unupdated SPF records: Not updating SPF records when there are changes in your email-sending infrastructure can lead to failed SPF checks. This includes adding new mail servers or changing third-party email providers.
Not using ‘-all’ or ‘~all’ qualifiers: The -all (fail) or ~all (softfail) qualifiers are important as they define the default policy for all IPs not listed in the SPF record. Not including one can result in unintended consequences.
Using the ‘ptr’ mechanism: The ptr mechanism is deprecated and should not be used. It is also slow and can lead to DNS lookup limits being exceeded.
Unnecessary use of ‘redirect’: The redirect mechanism should only be used when necessary. Unnecessary use can complicate the SPF record and lead to confusion.
Misconfigured ‘ipv4’ and ‘ipv6’ mechanisms: Ensure that the IP addresses specified with ipv4 and ipv6 mechanisms are correct and in the proper format.

There are other SPF issues also that your record may encounter, but we have mentioned the commonly occurring ones. If your SPF record doesn’t have any of the above-listed errors and is still not working properly, then reach out to us. We can take care of the stubborn technical issues.

DKIM record misconfigurations triggering the “554 5.7.5 Permanent Error Evaluating DMARC Policy” error

DKIM is based on cryptographic keys that fulfil the purpose of verifying if an email has been sent from one of the officially authorized mail servers. The first key, called the private key, is known only to the domain owner. The second key, called the public key, is openly available so that recipients’ mail servers can retrieve it. Both the keys are related to each other– a message encrypted by a private key only gets decrypted by its corresponding public key, otherwise, the decryption doesn’t happen, and DKIM verification fails.

When you turn on DKIM for your domain, a digital signature is added to the headers of all outgoing emails, which the recipients’ mail servers match with the public key.

Here are the common errors you may encounter in your DKIM record-

No DKIM signature: Your mail server is not configured to sign all outgoing emails with a valid DKIM signature. This is a common DKIM issue.
Incorrect DNS record: The public DKIM key for your record has to be published properly in the DNS. Typos, missing semicolons, incorrect key format, or publishing the key in the wrong DNS record are some general faux pas by domain administrators.
Mismatched selector: There should be a full-fledged match between the selector used in the DKIM signature and the selector in the DNS record; otherwise, DKIM will fail.
Invalid or expired keys: Do not use DKIM keys that are invalid or expired. We also recommend that you rotate your DKIM keys regularly, as it’s one of the best practices for email security.
Improper key length: Using a key that is too short (e.g., less than 1024 bits) can be a security risk. For stronger security, the best practice is to use at least a 2048-bit key.
Misconfigured mail servers: All of the mail servers that you use for sending emails on behalf of your organization should be configured to sign emails with DKIM.
Key mismanagement: Proper management of DKIM keys is essential. This includes securely storing private keys, not sharing them unnecessarily, and ensuring they are backed up.

DMARC record misconfigurations triggering the “554 5.7.5 Permanent Error Evaluating DMARC Policy” error

Incomplete or misconfigured DMARC settings can cause the “554 5.7.5 Permanent Error Evaluating DMARC Policy” issue. DMARC is an email authentication protocol that uses SPF and DKIM records to specify how email servers should handle messages that fail authentication.

Key DMARC policies

`p=none`: Allows emails to pass even if they fail authentication.
`p=quarantine`: Sends failed emails to the spam or quarantine folder.
`p=reject`: Blocks failed emails outright.

Issues on the recipient’s side

The recipient server may have its own policies affecting DMARC evaluation, such as redirecting failed emails to spam or rejecting them.

Ensuring proper configuration

Align your email settings with the recipient’s policies.
Collaborate with the recipient to understand and adapt to their DMARC settings to resolve the “554 5.7.5 Permanent Error Evaluating DMARC Policy” issue.

Fixing the “554 5.7.5 Permanent Error Evaluating DMARC Policy” error

To eliminate this issue from your DMARC, you need to review SPF, DKIM, and DMARC records. Start by running them through valid lookup tools to understand what’s wrong with them.

Ensure all the authorized IP addresses and hostnames are listed in your SPF record. Also, some email service providers don’t support SPF and DKIM-aligned emails, prompting the “554 5.7.5 Permanent Error Evaluating DMARC Policy” error. So, check what is supported and allowed by your email service provider and make the necessary adjustments and configurations. You can also think about migrating to another email service provider that supports SPF and DKIM alignment or adjusts within the settings with your current provider to ensure alignment.

As for DMARC, temporarily change the DMARC policy from strict (p=quarantine or p=reject) to lenient (p=none). This adjustment will allow your emails to pass authentication checks and not land in the spam folders while you take your time to address the underlying technical problems. Once you have fixed the problem, go back to applying either of the strict policies to stay protected from impersonation and phishing attacks.

We also suggest you ditch the idea of manually generating SPF, DKIM, and DMARC records, as this approach is more prone to retaining inconsistencies and other errors. You may end up adding extra characters, symbols, or spaces while copy-pasting.

Also, if your SPF record has exceeded the lookup limit and needs a tool to shrink it, use our SPF flattening tool.