Email not delivered in a very strange way

Hello,
It's very curious, here's what’s happening:
I send from an address on my OVH‑hosted server to a series of recipients, several of them at Google. However, one of them returns an error because the mail is redirected by Hotmail.com which (of course) isn’t in my SPF.
Curious, right?

Hello,

To be able to make a diagnosis, the only option is to extract the SMTP headers from the error message you received, as well as the SMTP headers from the original message that is attached to the error message.

You can send me a private message if the information needs to remain confidential.

Hello @HubertL

Hotmail (and other services like Outlook or Live) are very strict about the reputation of source IPs. If the IP of your OVH server has been flagged by their systems (for example, because it’s on a blacklist such as UCEPROTECTL3), your emails can be rejected outright or end up in spam, even if your SPF setup is correct.

The “strange” thing you mention about Hotmail redirecting and SPF could be a consequence of this. Microsoft’s servers may be performing an additional check or altering the mail route because of the low reputation of your source IP.

I suggest the following solutions:

  • Verify the authentication records (SPF, DKIM, DMARC). Make sure they are properly configured. They are the first line of defense and, even if your SPF is fine, correct DKIM and DMARC greatly improve the reliability of your emails.
  • Use Microsoft’s delisting tool. Microsoft has a portal where administrators can request delisting of their IP. You can try it at https://sender.office.com. The process is not immediate, but it’s an important step.

If the problem persists, let me know and I’ll give you another solution, but for now try what I’ve suggested :slight_smile:

Talk to us soon,
Sergio Turpín

@sturpin Unfortunately you are claiming nonsense here. Be careful not to spread false information.

@HubertL We need a sample of the bounced email, to know who rejected what, and which path it took.

Hi @fritz2cat

Thanks for your comment. Let me clarify why I specifically mentioned the UCEPROTECTL3 list in my previous answer. It's not a random statement; it is based on publicly available technical documentation and multiple documented cases.

The reason I pointed out UCEPROTECTL3 is that it is a known and recurring problem that affects service providers such as OVHcloud. This blacklist, unlike others, does not block a single IP but entire ranges of IP addresses (subnets) belonging to an autonomous system.

When a provider like OVHcloud has a high number of spam incidents reported on its network, UCEPROTECTL3 can end up blocking an entire IP range of that provider.

Therefore, when I said the IP might be flagged by systems like UCEPROTECTL3, I was not spreading false information, but pointing out one of the most common and documented reasons why emails from OVH servers can be rejected by Microsoft’s systems.

https://mxtoolbox.com/problem/blacklist/uceprotectl3?page=health_blacklist&hidetoc=0&hidepitch=0&showlogin=1&action=blacklist:mx3.mail.ovh.net&domain=pcba.fr

That said, you are right that it is always better to analyze the specific case. Checking the full headers of the bounced email is essential, because there you can see the exact error codes (such as 550) that give the definitive clue. However, the existence of other possible causes (like a recipient filter or a temporary reputation issue) does not invalidate that UCEPROTECTL3 is one of the most common reasons why emails from OVH end up in Hotmail. My intention was to provide a practical, evidence‑based guide, not to give a single definitive answer.

I hope this explanation clarifies the origin of my statement. Regards.
Sergio Turpín

UCEPROTECT L3 is so punitive for large ASes (for example AS16276 for OVH contains more than 4 million addresses) that there is always at least one subnet that would be flagged for spam. Example: a crook rents a few dozen VPSes (preferably with a stolen credit‑card) and deploys spamware on them. All those VPSes with neighboring IP addresses will trigger a UCEPROTECT L2 alert.

Where it gets nasty, UCEPROTECT plans to demand an express delisting for an outrageous fee.

It’s a outright scam.

Yes, you're absolutely right :slight_smile:

Thank you for your answers. SPF and DKIM are OK, that’s the first thing I checked.
What seemed strange to me is that not only were my other contacts at Google receiving the message properly, but also why go through Hotmail to communicate between OVH and Google?
I’ll look into the SMTP headers.

And that's why they're not taken seriously :wink:

I second that.