Situation: you may receive this return message:
Remote server returned ‘554 5.7.0 < #5.7.23 smtp;550 5.7.23 The message was rejected because of Sender Policy Framework violation -> 550 5.7.1 This message failed DMARC evaluation of domain sent-via.netsuite.com and was rejected as per DMARC policy. Contact your administrator if this was a legitimate email.>’
Troubleshooting 1:
Your email was rejected by the recipient’s mail server.
Specifically, the recipient is in a group that’s configured to reject messages from external senders (senders from outside the organization).
Only the group owner or an email admin in the recipient’s organization can fix this issue. Contact the group owner or email admin and refer them to this information so they can try to resolve the issue for you.
Troubleshooting 2:
According to the error message, the issue could be related with the SPF policy. Please make sure you have set up the SPF record correctly based on your environment via Set up SPF in Office 365 to help prevent spoofing.
For the further investigation, I’d like to collect the following information to better know your situation.
1. Please collect the entire bounce-back message and send us in Private Message.
2. May I know your current Exchange environment, pure cloud, on-premises or hybrid?
3. Are there any new deployments in your organization since February?
4. Do your customers use Office 365?
Troubleshooting 3: this could be “mail.domain.com” in the dns system. The Solution: Go to the dns system and create a mail.domain.com and point your MX records to that. It’s a bit silly, but it has to be done that way.
Troubleshooting 4: It could be you are sending emails via an unauthorized server. The DMARC policy states that the email address provider and the email address server should be the same. If they are not, this is considered a policy violation, and your emails will be rejected by most DMARC-protected recipients thereby returning the “DMARC unauthenticated mail is prohibited” message.
When you send an email via an unauthorized server, the message is rejected and therefore unauthenticated by DMARC as it fails to pass SPF and DKIM checks.
For example, if your email claims to be from [youremail]@gmail.com but does not come from Gmail SMTP Server and instead comes from another server (let’s assume from OVH Cloud servers), that email will most probably be considered unauthenticated per DMARC policy.
The reason for this is that the address provider (Gmail) and the email address server (OVH Cloud) are different entities. If DMARC finds that your domain does not own your email address provider (such as Gmail), then it will reject your emails as they fail its checks.
Troubleshooting 5: The SPF configuration is not updated to include all senders.
To troubleshoot this issue, you need to go back to your SPF record and make sure it matches the email host domain name. If you have multiple domains, make sure all of them are included in your SPF record.
For instance, if your email is hosted on Outlook then you have to merge Outlook’s SPF syntax (spf.protection.outlook.com) in your SPF record to solve the problem:
The following is an example of an Outlook SPF record:
v=spf1 include:spf.protection.outlook.com -all
Troubleshooting 6: The sender’s domain is not correctly configured.
There are several ways to troubleshoot this issue:
- Verify the SPF and DKIM settings in your domain’s DNS records. To do so, we recommend using the PowerDMARC SPF Record Lookup and DKIM Record Lookup tools. Both of these tools are free and easy to use, and they will give you a clear picture of the errors within your existing records and what your records should look like.
- If you have verified that your DNS records are correct, then verify that your mail server is configured to send emails using the Authentication-Results header field.
- If you don’t already have SPF and DKIM records in place, we recommend setting them up with PowerDmarc’s free tools for generating these records:
Troubleshooting 7: You might have been blocked by the recipient’s DMARC anti-spam filters.
Contact the recipient directly and ask them what their current DMARC policy is set up as (they should be able to provide that information). Then ask them if they would be willing to reconfigure their policy so that it accepts emails from your domain, thereby avoiding being flagged as spam as well as evading the “DMARC unauthenticated mail is prohibited” error.
