On January 31, I troubleshooted (troubleshot?) an email issue for roughly 3 and a half hours.
Steps to Recreate:
Sending email from domain1.com (managed by us through Provider 1) to domain2.com (managed by us through Provider 2), where Provider 2 is forwarding to a GoDaddy-powered email on a domain we don’t manage.
The email would arrive in the Provider 2 mailbox but not the GoDaddy-powered mailbox. No errors would be sent back to the original sender.
I wasn’t sure if it was an issue impacting all incoming mail (sent to domain2.com forwarding to GoDaddy-powered email), or only mail from particular domains, so we tested these scenarios (successes in green, failures in red):
domain1.com (Provider 1) to domain2.com (Provider 2) forwarding to GoDaddy email
domain1.com (Provider 1) to domain2.com (Provider 2) forwarding to Gmail
Gmail to domain2.com (Provider 2) forwarding to GoDaddy email
Gmail to domain2.com (Provider 2) forwarding to domain1.com (Provider 1)
domain3.com (Provider 3) to domain2.com (Provider 2) forwarding to GoDaddy email
So I got in contact with Provider 2, and they gave me an actual error message to look at.
550 5.1.1 [Provider 2 IP] is not allowed to send from <[domain1.com]> per its SPF Record. Please inspect your SPF settings, and try again.
The thing that baffled me was why domain1.com would need SPF records set for Provider 2 if Provider 2 wasn’t sending on its behalf, but sending on domain2.com’s behalf. The next thing I decided to look at was the message headers in the email from the second scenario, “domain1.com (Provider 1) to domain2.com (Provider 2) forwarding to Gmail.” Here, I was able to compare the error message from Provider 2 with the headers in the Gmail-received message.
spf=fail (google.com: domain of email@example.com does not designate [Provider 2 IP] as permitted sender [...] dkim=pass
Then I decided to compare SPF records from domain1.com with domain3.com and noticed one difference that stuck out.
The issue turned out to be caused by the “-all” part of the domain1.com SPF record combined with the fact that Provider 2 does not do “on behalf of” with their verified sending domains. They leave the “from” field as the original sender. Our other email providers use we have (we have 3-4 others) use our domain for verified sending and set the reply-to header to be the original sender.
When I talked to support at email Provider 2, she suggested I change from strict/fail “-all” to soft-bounce “~all” in the SPF record because DKIM would, in theory, catch any domain spoofing that “~all” missed.
Hopefully this helps explain the differences and the possible issues that you may face if your SPF records are set to fail (“-all”) on unspecified domains/IP addresses!