Hello,
Several emails sent to OVH servers and accepted by one of those servers are not in the recipient's mailbox.
It's random, because some newer emails are indeed there.
mx0.ovh.net Ok: queued as 4gPp3P2HSmzDqJZ (11h53)
Ok: queued as 4gPpd85zd2z326tR (12h19)
We are within acceptable times for emails, except when it comes to receiving codes or challenges that are valid for 10 or 15 minutes. It takes 48 minutes for at least one of them.
Yes, I've received calls from clients and I've also noticed variable delays.
Here's a case where a dedicated OVH corp on the subject would be very useful @FabL 
Hello both of you,
For email cases, I’d like the associated ticket numbers where you can include all the details along with the relevant emails and the headers indicating the context (regular email or code to receive, as you mentioned @fritz2cat).
If a member of the @EmailTeam drops by here, they’ll have all the information directly to verify what’s going on.
Thanks for the alert!
^FabL
I didn't submit a ticket. But, oddly enough, I had the transaction numbers of emails that hadn't been delivered yet, thanks to a relay server where I can control how aggressively we handle blacklists, in particular.
Sorry no ticket, for this kind of case I tell the client to wait until tomorrow
Email support is the worst job.
Hello,
As a similar question comes up today: E-mails OVH reçus avec 15 min à 2 h de retard (différé): d'autres utilisateurs concernés ?
Can you wake up the email team, please?
Thanks !!
Hello,
I opened an incident ticket for this issue. The support response was that it was a limitation put in place at the OVHcloud infrastructure level to protect their servers against spam.
The proposed solution is rather surprising: ask our providers and our customers not to send multiple e‑mails at the same time. I explained to them that this was not feasible. When we are waiting for CMRs or other important documents, we cannot ask senders to send their e‑mails at a specific time or spaced an hour apart.
I also told them that it is impossible to work under these conditions and asked them if they could escalate the issue to their superiors. The reply was: “I invite you to change mail provider if this usage no longer suits you.”
I must admit I found that quite absurd…
In any case, I now feel less alone. I hope someone from the mail team will look into the matter to provide explanations or improvement suggestions.
PS: I have noticed the same thing that has already been reported here: it is rather random. Some e‑mails arrive instantly, others with a 10‑ to 15‑minute delay. The longest delays seem to mainly affect redirected e‑mails or when we receive several CMRs or BLs sent to the same address. In those cases, the delay can easily reach one to two hours.
For me there’s something I can’t explain in what OVH claims to have set up.
I’ll remind you what I provided as information on May 26:
If OVH claims to be doing throttling, a bit like Wanadoo did 15 or 20 years ago (Wanadoo allowed at most one incoming connection per source IP – which was a nightmare for large senders), then the messages put on hold should stay outside the infrastructure.
Another equally questionable mechanism is called greylisting, and hardly anyone uses it any more. There, too, the messages put on hold remain outside the receiving‑servers perimeter, using the temporary SMTP 4xx error codes.
In the case I identified above in May, OVH accepts the messages, puts them in a queue, and then does I don’t know what to stack them in a corner in a random order and extract them in an equally random order.
I just get the feeling that it doesn’t protect against spam at all (since the mails are accepted) and can only slow down internal processes.
When you see the number of "Received:" headers in the mails that pass through OVH, you have to think that the processing is probably complex.
I don’t think the OVH team is doing anything, because the person I spoke with on the phone explained to me that it’s their new security policy.
At first, I thought that by posting on the forum they might eventually respond, but I see that’s not the case. It’s already been 13 days since a similar topic was started and there is still no response. For them, everything seems fine, as indicated in the response to my incident ticket:
“As we explained to you, this is a limitation that has been implemented at the OVHcloud infrastructure level. We will not be able to disable it.
The purpose of implementing this is to provide optimal stability and security of our customers’ services while delivering a quality user experience on our shared offers.
Emails are not lost; they will, however, be delivered after a variable waiting period that allows distributing the email reception load across the infrastructure and thus preventing possible anomalies and/or slowdowns on it.
Thank you for your understanding and have a pleasant day.”
I think there is nothing to expect from them.
Personally, I will follow the advice that was given to me on the phone and in my ticket, and turn to other providers.
Yes, OVH applies rate limiting on incoming mail; I’ve been noticing it for roughly four weeks:
May 31 00:15:21 smtp2 postfix/smtp[1068158]: 8490B200DA: host mx0.mail.ovh.net[178.33.252.245] said: 450 4.7.1 Rate limit due to high number of emails sent, retry later (in reply to end of DATA command)
May 31 00:15:27 smtp2 postfix/smtp[1068158]: 8490B200DA: to=xxx.domain.com, relay=mx1.ovh.net[188.165.47.122]:25, delay=6.1, delays=0.06/0/5.9/0.18, dsn=4.7.1, status=deferred (host mx1.ovh.net[188.165.47.122] said: 450 4.7.1 Rate limit due to high number of emails sent, retry later (in reply to end of DATA command))
Gmail does the same quite a lot.
Thanks. That’s interesting. It confirms that OVH is indeed doing rate limiting or throttling.
Your Postfix informs you that OVH has taken notice of the entire message before rejecting it. So it is possible that this rejection is based on elements found in the email’s content, but not on the SMTP envelope.
This explains why emails are delivered out of order, since it is the sending servers that have to retry periodically.
Consequently, analyzing the SMTP headers could mistakenly suggest that the sender’s server was slow to deliver the message to OVH. Failed attempts do not appear in those headers.
OVH, like many other providers, offers low‑cost email; it doesn’t bring them much profit, generates a lot of support tickets, and they try to protect themselves as best they can from a technical solution that is already about 40 years old and no longer suited to today’s Internet reality.
If you have strong professional requirements, switch to more advanced solutions (paid Google, perhaps Exchange at OVH), or set up your own mail server (with all the sending issues that entails, but at least you fully control reception).
Unfortunately, with the ultra‑cheap plans you get what you pay for.
I have my mail at a Swiss competitor; they also sometimes have this kind of problem, you just have to live with it and accept it given the price of the offers. Or, if it really doesn’t work at a professional level, then you have to pay more by moving out of the low‑cost plans.
Hello everyone,
It is indeed a grey-listing mechanism. Our system operates on a statistical basis: it monitors sending volume variations by IP address, sending domain, and the sender/recipient pair.
Generally, a domain that follows email best practices smooths its traffic and relies on a “warmed‑up” IP. This is a standard among mail providers, very effective at countering spam waves originating from compromised servers. It also gives our antispam time to isolate a pattern to better filter subsequent messages.
In recent weeks, we have calibrated the system to handle very specific scenarios. For example, this includes two‑factor authentication (2FA) emails that generate a sharp sending spike on Monday at 9 a.m., followed by very low traffic for the rest of the week.
To avoid penalizing our users, we are currently looking to identify other legitimate use cases of this kind so that we can analyze them.
Feel free to bring them to our attention by replying to this thread.
^FabL
Hi FabL,
Thanks for the clarification.
I also have a few more questions: in the long run, are domains or IP addresses that regularly send emails supposed to be recognized as legitimate, even when there is an occasional batch send of five to ten messages from the client or supplier? Is a whitelist system planned for certain senders or identified use cases, and do you intend to evolve the current setup or will it stay as it is?
I ask because, as mentioned earlier, this behaviour impacts our work quite regularly, regardless of the client or supplier.
For context, we are a small company of seven people, we receive between 100 and 500 emails per week in total, and we already use a filtering solution for our emails (Mailinblack).
So far, we haven’t encountered any particular issues with the deliverability of our messages. We would simply have appreciated being informed in advance of such a change, so we could anticipate the impact.
So far, we haven’t encountered any particular issues with the deliverability of our messages. We would simply have appreciated being informed in advance of such a change, so we could anticipate the impact.
Thanks in advance for your response.