A mail server may respond with a bounce-back email, also known as a Non-Delivery Report (NDR) if the email is not authenticated. When the email-authentication mechanisms fail, which are normally SPF, DKIM, and DMARC, an email is not authenticated, and may be rejected or quarantined. In such a case, a mail server may respond with the following (or similar) error message:
Your message can't be delivered because the recipient's email provider rejected it.
550 5.7.509: Access denied, sending domain [DomainName] does not pass DMARC verification and has a DMARC policy of reject
This is normally what Microsoft’s email server responds with. However, a Google mail server may respond with a slightly different message, and would be as such:
gmail-smtp-in.l.google.COM: 550-5.7.26 This mail has been blocked because the sender is unauthenticated.
When you get this email, it means that the email you or someone from your domain sent has not been delivered since it could not be authenticated. This means that the recipient’s mail server considered the email as spam, or spoofed. This could negatively impact your domain name, and may eventually land you on the blacklist. Therefore, whatever the issue is, it needs to be fixed.
As it can be understood from the error message itself, the issue lies with DMARC verification. in this post, we briefly describe what DMARC is and its role in email authentication, then continue to provide solutions to rectify the issue for improved email deliverability.
Table of Contents
What is DMARC
DMARC, or Domain-based Message Authentication Reporting And Conformance, is a policy that defines how the mail server handles the emails that are not authenticated successfully. It tells the mail server whether to let the emails go through to the recipient’s inbox, flag it and send it to the spam folder, or completely reject the emails.
Why email fails DMARC check
The statement “has a DMARC policy of reject” in the error message above indicates that the DMARC policy is set to “reject”, and the email was not delivered, resulting in an NDR.
An email will thus only be rejected if the DMARC check fails. A DMARC check may fail in case the SPF and DKIM checks or their alignment fails. Therefore, whether or not an email passes a DMARC check is very much dependent on your SPF and DKIM configurations.
Learn more about how SPF and DKIM work by clicking on the respective link.
A DMARC policy is implemented if an SPF or DKIM check fails; both checks failing are not mandatory to enforce the DMARC policy. Additionally, an email may also be deemed authenticated if it is aligned.
For SPF alignment to pass, the domain name in the MAIL FROM header (return path) must match the domain name in the FROM HEADER. If both domain names do not match exactly, or the domain in the MAIL FROM header is not even a subdomain of the MAIL FROM header, the SPF alignment fails.
For DKIM alignment to pass, the domain in the DKIM header (defined by the “d” tag) must match the domain in the FROM HEADER. If the two domains do not match, or the domain defined in the DKIM header is not even a subdomain of the FROM HEADER, the DKIM alignment fails.
That said, a DMARC check fails if both of the following checks fail:
- SPF or SPF alignment
- DKIM or DKIM alignment
If this were to occur, you would receive an NDR with the error message stating that the sender’s DMARC check failed, and the email would not reach the recipient.
From what we have discussed above, it is understood that the DKIM and SPF records play an important role in DMARC verification. If either one or both are incorrectly configured, you might see the error message “sending domain does not pass DMARC verification and has a DMARC policy of reject”.
However, there can be other reasons why an email might fail DMARC verification, even if the email is authentic and sent from a legitimate source.
SPF or DKIM records are missing or incorrectly configured
You may encounter an NDR stating that the email failed the DMARC check when you do not have an SPF or DKIM record at all, or when it may be misconfigured. An SPF record is mandatory for DMARC verification. However, a DKIM record, although recommended, is not mandatory, and DMARC verification can function without it.
If your domain does not have a DNS SPF record, and the receiving party has a strong DMARC policy, you will most likely receive an NDR stating the error message stating that the email failed the DMARC check and was rejected.
Additionally, if the DKIM record for your domain exists but contains the wrong key, it would likely fail the DKIM check, and hence, the DMARC verification.
You are using an email alias
Using email aliases that also use different domain names can cause emails to get rejected.
An email address’s syntax is “custom@domain.com”. If you use an email alias that has a different domain than your actual domain, the receiving mail server will look up the SPF record for the alias. If the SPF record does not exist, the DMARC verification will fail, resulting in an NDR.
The FROM header is spoofed
Email authentication mechanisms are there to isolate illegitimate and spam emails. Your email may be considered spam if the “FROM:” header is spoofed. There can be instances when outgoing mails are automatically spoofed without the sender knowing about it.
If the FROM header is spoofed, it will fail the authentication, including the DMARC check.
Fix “Sending domain does not pass DMARC verification”
Now that we fully understand what the error message means and why it occurs, here are a few things you can do to fix the error and get your emails through successfully.
Configure the SPF and DKIM records
The first thing you should do is configure your SPF and DKIM records if they do not exist already. You can check whether they exist or not through our Email Security & Deliverability Checker. Here is how:
-
Open the Email Security & Deliverability Checker.
-
Enter our domain name and click Analyze.
Check if SPF and DKIM records exist with Email Security Deliverability Checker
If valid DNS records exist for SPF and DKIM, the tool will highlight the information in green. If they do not exist, the tool will highlight the field in red, as in the example above.
If the records do not exist, you can create them yourself. Note that for this purpose, you must have administrative access to the zone management in the Domain Name Server. If you do, click on the links below to learn in depth about these DNS records and how to create them:
Relax the DMARC policy
As the bounce-back email suggests, the DMARC policy for your domain is set to reject emails that are not authorized. You can alter your current DMARC policy to either “quarantine” or “none“, allowing unauthenticated emails to reach the intended recipient, either in the Inbox or the Spam folder.
For this purpose, you must access the DNS records and change the DMARC policy. To ease the DMARC rule, change the value for the “p” tag from “reject” to either “quarantine” or “none“. The new DMARC syntax will then look something like the following:
v=DMARC1;p=none;pct=100;adkim=r;aspf=r
Include SPF record for service provider
Even when an SPF record for the sending domain exists, it might be configured incorrectly, especially for email aliases.
For this purpose, Email Service Providers (ESPs) have their own servers that include server names allowed to send emails on the domain’s behalf. For example, Google has a dedicated SPF server that you can include in your SPF record. Following this, your SPF record would look something like this:
v=spf1 include:_spf.google.com ~all
Make sure to include the ESPs SPF server in your SPF record. If you are using a different service provider, make sure to get the correct mail server for the SPF record. This information can often be found in different service provider’s support documentation.
Update the REPLY-TO header field
The “FROM” field in an email’s header indicates who the sender is. If you send an email using an address that does not match the one in the envelope “FROM” header, the receiving mail server will consider it spam and reject or quarantine it.
If you are using a different email address, like an alias, then you will need to update the ‘FROM’ field using the email provider’s settings page. However, that requires using specialized tools.
Alternatively, you can change the “Reply-To” header instead in the email that you are sending out.
The “Reply-To” value in the header is the email address that you want the email to go to when the person replies to the email. However, if you change it to your original email address with the corporate domain, the receiving mail server will think that it came from the same address as well, passing the DMARC check.
To set/change the “Reply-To” address in Gmail, use these steps:
-
Log into Gmail and open its settings.
-
Go to the Accounts tab and click “Edit info” in front of “Send mail as“.
Change Send mail as info -
Enter your domain’s email address and save the changes.
Change Reply To address in Gmail
After performing these steps, your emails should no longer be rejected from the recipient mail server based on its DMARC policy, if the issue was caused by using aliases.
If you are using a different email service provider, then I would suggest looking into their documentation to learn how to change the “Reply-To” address.
Conclusion
The “Sending domain does not pass DMARC verification and has a DMARC policy of reject” error message implies that the issue is with the sending party, and not the recipient. Therefore, if anyone informs you that they are unable to send YOU emails and get a reply stating this error message, inform them that it is THEIR DMARC policy preventing emails from getting through.
That said, having appropriate SPF, DKIM, and DMARC policies is always recommended. While the issue may be temporarily resolved by relaxing the DMARC policy, it is not the best approach, as it would allow spoofed and spam to go through as well. You can view aggregate reports of the emails while temporarily relaxing the DMARC policies, while you fix the actual cause.
Once the issue has been rooted out and fixed, I suggest that you review the DMARC policies for maximum email protection.
