Include:
Domain adaware.com.mx,
Steps to reproduce, Actions taken and result:
The errors only come from hotmail emails so far, today started this error, before today we could receive emails from these people with hotmail.
[email protected] with error 550 5.7.1 saying: “mx.cloudflare.net rechazó tus mensajes” “mx.cloudflare.net rejected your messages”I’m facing same issue, could not send email from @hotmail.com
I got a similar error reported from a user using hotmail.
After receiving the report, I tried myself with a Hotmail account I have and worked.
Checking the activity log I see this:
So, for some reason, the SPF check failed for that user but not for my test.
It would be great to know why this is happening or why it fails sometimes but not always.
On Fri, 18 Aug 2023 14:16:45 +0000 (UTC), it was noted on a mailing list related to email operations that the SPF record for hotmail.com had been changed, as well as that it did no longer contain include:spf.protection.outlook.com, as it did before.
Before: v=spf1 ip4:157.55.9.128/25 include:spf.protection.outlook.com include:spf-a.outlook.com include:spf-b.outlook.com include:spf-a.hotmail.com include:_spf-ssg-b.microsoft.com include:_spf-ssg-c.microsoft.com ~all
After: v=spf1 ip4:157.55.9.128/25 include:spf-a.outlook.com include:spf-b.hotmail.com include:spf-b.outlook.com include:spf-a.hotmail.com include:_spf-ssg-b.microsoft.com include:_spf-ssg-c.microsoft.com -all
Not only did they remove that include:, they also changed the policy from “~all” (softfail) to “-all” (hardfail), instructing others that honour the SPF standard, to reject deliveries that are not authorized.
Microsoft did (and actually, still do) send a lot of email traffic over IPv6, however, with the removal of the include:spf.protection.outlook.com mechanism for the SPF record of hotmail.com, it literally means that Microsoft removed ALL of their own IPv6 addresses from being authorized to send email on behalf of the hotmail.com domain name.
As late as Thu, 31 Aug 2023 13:13:55 +0000 (UTC), they were still sending over their IPv6 addresses, although their new configuration doesn’t authorize this.
Since larger organisations (for example Microsoft, Google, … et cetera) usually distribute their outbound email deliveries over many different IPv6/IPv4 addresses, you may occasionally see that the deliveries are being tried from servers that their domain actually still authorizes.
The actual problem is with Microsoft/Hotmail, and their new configuration, and it will therefore be them you will need to poke for a solution.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.
