Saturday, 12 September 2015

Internal email relay: Mailbox unavailable: The server response was: 5.7.1 Sender ID (PRA) Not Permitted

When enabling sender ID filtering on hub transport servers that are used for anonymous internal email relay, you can find that emails are no longer relayed and you get bounce backs with an error like below:

"Mailbox unavailable: The server response was: 5.7.1 Sender ID (PRA) Not Permitted"

You can also use Send-MailMessage to reproduce the error, as below:


Rejection of email that fails the Sender ID checks is not enabled by default. To check these settings, run the below PowerShell command in Exchange 2010 or 2013:

Get-SenderIDConfig | fl Enabled,SpoofedDomainAction



You can also use the Exchange Management Console in Exchange 2010 to check the settings. To do this, open the Exchange Management Console in Exchange 2010 and navigate to Organization Configuration > Hub Transport > Anti-spam then double click on Sender ID Filtering as below:





This issue only happens for anonymous relays because by default Sender ID does not process authenticated email therefore one way to resolve the issue is to use authenticated email relay but this may not work for all applications. The setting for this is called InternalMailEnabled and is enabled by default. Another way to resolve it is to use Set-SenderIDConfig with the -BypassedRecipients parameter to ensure that email sent to these recipients bypasses Sender ID checks. The problem with this approach is that it opens up this recipient to spoofed email. The third way to resolve the issue is to use the same cmdlet with the BypassedSenderDomains parameter where you ensure that email from certain domains is not checked for spoofing but, again, this increases the risk of spoofing for entire domains.

You can confirm the above settings you have in place by running the below command:

Get-SenderIdConfig | fl BypassedRecipients,BypassedSenderDomains,InternalMailEnabled



In our case, we wanted to find a different solution as some clients needed to submit anonymous email. In this example, the SPF record, server and client IP are below:

  • SPF record: "=spf1 ip4:81.0.0.20 ip4:94.0.0.2 a -all"
  • Client IP: 192.168.0.20
  • Server IP: 192.168.0.8


Note that the -all mechanism on the end of the SPF record forces informs the receiving email server that sending from IPs not on the SPF record are not allowed and should result in a hardfail and the email should be rejected. The client IP is not listed as a permitted sender on the SPF record and so this confirms that sender ID filtering is working as it should as it's blocking the email. This is great but it's blocking more than just spoofing from the internet.


To resolve this, you can add your internal IPs to your SPF record but the problem here is that you'll end up with internal IPs on your external SPF record which certainly isn't recommended. However, in our case, we are using split DNS and configured a different SPF record on the internal DNS servers used by the Exchange server which includes the client IPs and left the external SPF record the same:

  • External SPF record: "v=spf1 ip4:81.0.0.20 ip4:94.0.0.2 a -all"
  • Internal SPF record: "v=spf1 ip4:81.0.0.20 ip4:94.0.0.2 ip4:192.168.0.20 a -all"


You need to restart the Microsoft Exchange Transport Service for this to take effect immediately and then you can confirm it has worked by using Send-MailMessage again:


If you want to add entire subnets to be allowed to submit email then you can modify the internal SPF record to include the subnet but be aware that this reduces your security by increasing the chance that a compromised internal computer can spoof emails for your domains. 

  • Internal SPF record: "=spf1 ip4:81.0.0.20 ip4:94.0.0.2 ip4:192.168.0.0/24 a -all"

More information about SPF records can be found here.

No comments:

Post a Comment