There may be an occasion when you receive information from a receiver that they were not able to deliver or accept your message.


We sometimes get asked to troubleshoot delivery problems for our customers whose sending domains are at enforcement, but where one recipient domain did not accept delivery, frequently due to a possible SPF error.


It can be difficult to troubleshoot, but we have noticed that a usual culprit is a misconfigured SEG (secure email gateway) which may be preventing correctly authenticated emails from reaching the intended inbox.


An example of this would be a domain that uses GreenviewData's Spamhaus (spamh.com) service. Organizations may leverage Spamhaus to check inbound messages for potentially bad email. After checking inbound email, Spamhaus will forward/relay messages to the inbox provider.


Once relayed, the email server may be checking the Spamhaus server's SPF alignment and not the original sender when not configured correctly. Administrators of the email system must disable SPF record checking on their email server(s) to ensure that their email server is not breaking authentication.


From GreenviewData's Documentation:

When using an anti-spam service, you will need to disable any SPF record checking that you may have implemented on your own email server. This is because e-mail will be delivered to you from the anti-spam service, and not directly from the sender's mail server, breaking any SPF record validation done on your end. Instead, you will need to rely on the anti-spam service's SPF record validation, such as using the above feature.


One way to see this example is to dig the MX record for your intended recipient. You will see a record such as the following after doing a dig either on the command line, like the example below, or with an online tool like Google's Dig or DigWebInterface.

dig somerecipient.com mx +short


10 somerecipient-com.relay1g.spamh.com.

20 somerecipient-com.relay1h.spamh.com.

30 somerecipient-com.relay1i.spamh.com.