OVH email redirect causes SPF check failure
February 26, 2023
Note: I put OVH in the title but it could happen with any provider that offers email redirects.
Let’s say you have an email address
firstname.lastname@example.org, and you set up a
redirect with your provider so that it forwards all emails to
email@example.com, which would be a common scenario to use Gmail with a
custom domain without paying for Google Workspace (using this as an
example but the problem is not directly related to Gmail).
In my case with OVH, this is configured in
firstname.lastname@example.org's MX plan,
under manage redirections.
It works well most of the time, except when a sender tells me they failed to send me an email.
It could be someone sending me an email from, for example,
email@example.com, who tells me (obviously via another mean) that their
email was returned, with a message similar to this:
Subject: Undelivered Mail Returned to Sender
This is the mail system at host
I’m sorry to have to inform you that your message could not be delivered to one or more recipients. It’s attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can delete your own text from the attached returned message.
The mail system
firstname.lastname@example.org: host gmail-smtp-in.l.google.com[188.8.131.52] said: 550-5.7.26 The MAIL FROM domain [gmx.com] has an SPF record with a hard fail 550-5.7.26 policy (-all) but it fails to pass SPF checks with the ip: 550-5.7.26 [184.108.40.206]. To best protect our users from spam and phishing, the 550-5.7.26 message has been blocked. Please visit 550-5.7.26 https://support.google.com/mail/answer/81126#authentication for more 550 5.7.26 information. h21-20020a05600c351500b003eb3caa4d08si2037016wmq.38 - gsmtp (in reply to end of DATA command)
Note: I use GMX as an example here because it’s a sender domain that I was consistently getting SPF issues with because of my redirect setup.
This doesn’t seem to be a very widely encountered problem, yet I could find a few occurrences of it in the wild like on this Reddit post as well as those Google support threads (in French, and sadly locked so I couldn’t post the solution there).
What’s going wrong here? It turns out that the sender domain (in this
gmx.com) had configured a strict SPF policy
that only allowed their own servers to deliver emails from
We can check this running the following command:
host -t TXT gmx.com | grep spf gmx.com descriptive text "v=spf1 ip4:220.127.116.11/23 ip4:18.104.22.168/26 ip4:22.214.171.124/26 ip4:126.96.36.199/25 ip4:188.8.131.52/24 ip4:184.108.40.206/27 ip4:220.127.116.11/26 ip4:18.104.22.168/24 ip4:22.214.171.124/27 -all"
Note: to be clear, this is not a bad thing. It’s totally legitimate
from GMX to only allow their own servers to deliver emails from
The reason it doesn’t happen with most sender domains is that it’s
common to configure SPF with a “soft fail” (
~all) instead of a “hard
-all) like GMX does. See the difference here.
A soft fail would result in the email being delivered but potentially being flagged as spam, whereas a hard fail gets downright rejected.
Since Gmail do check the origin sender SPF policy and enforces it, it
@gmx.com email being forwarded by my OVH relay.
If you want to learn more about this issue, this post from Tiger Technologies is a very good read.
Sadly there’s no trivial fix for this. The post linked just above mentions a few solutions in the last section but notes that they’re not widely available and might cause other issues. Their conclusion is: for now, we’d recommend simply not forwarding important mail to other ISPs.
What can we do from there? Well in my case, I had to reverse the relationship between my OVH address and Gmail: instead of my OVH address forwarding emails to Gmail, I removed the redirect and configured Gmail to fetch emails from my OVH address via POP3.
Note: this alternative method is not specific to OVH and Gmail. It will work as long as:
In order to do this with Gmail, their guide on checking emails from other accounts.
The main downside of this solution is that instead of OVH pushing mails to Gmail, Gmail has to pull them from OVH periodically. Concretely, this means increased latency. Instead of receiving emails right away, you’ll have to wait until Gmail decides to fetch emails from your external accounts.
There’s no clear rule on how often Gmail checks external accounts. It seems to be proportional to how often you receive new emails: if you often receive new emails, it’ll check quite often, but if you receive just a few messages per day, it can wait 10, 20 or even 30 minutes between refreshes.
Looking into this I found quite a few smart tricks to get Gmail to check your external accounts more often.
The first one is described in this post, and consists in configuring a server of yours to send you an email (on the address you check via POP3) every minute or so. This way, Gmail will notice you’re getting a lot of messages and will check more often.
To avoid your inbox getting flooded by those messages, you can simply add a filter that puts them directly to the trash!
What if you don’t have a server handy to run this script? As described in this Lifehacker post, you can run the code as Google Apps Script on Google Sheets. That’s pretty rad if you ask me. 😂
But what if you don’t want to write code at all? This Stack Exchange comment got you covered: just create a dummy Google Calendar event repeated every X minutes, and set up an email reminder for this event. 🤯
With OVH, there’s another option that allows you have the speed of the redirect when it works, but still receive the messages even when there’s an SPF rejection. The problem of this approach is that it will still result in the “Undelivered Mail Returned to Sender” message being sent to the sender in case SPF fails (even if you do get the email), which is not ideal.
This solution consists in the OVH email redirect settings to “keep a copy of the email at OVHcloud”. This option is only available during the initial redirect creation and can’t be modified later on, so if you initially configured it as “do not store a copy of the email”, you’ll need to delete your redirect and recreate it.
Note: creating a redirect that keeps a copy of the email on OVH materializes as two redirect entries: one from source to source, and one from source to destination.
For example, it’ll show:
Just noting that here because it can be confusing.
On top of that, you also configure Gmail to check your OVH emails via POP3 as explained earlier.
The result is that when the redirect works, you’ll get your emails instantly. When case the redirect fails, the message will still end up in your OVH inbox, which Gmail will fetch eventually, so you’ll still get it that way.
But as I said, because the redirect failed, the sender will still receive back an error email and believe that you didn’t receive their email. I don’t know of a way to avoid that with this solution.
As for the messages that were successfully redirected, be assured that they won’t be duplicated! Even though they will be fetched again when Gmail refreshes the POP3 inbox, Gmail is able to tell that it’s the same message that it already saw and will not show it to you twice. Neat.
In this post we explored the technical details of a common error that happens when an email redirect conflicts with the origin SPF rules.
We saw that we can mitigate it under certain conditions, by reversing the redirect relationship: instead of one email redirecting to another, you need to have the second email checks the inbox of the former.
With Gmail, this can introduce unwanted latency, but there’s a few hacks to work around that.
Finally we saw an hybrid approach that gets “the best of both worlds”, except for the error message still being sent back…
What was your favorite option? Let me know on Twitter!
And if you know of other solutions I didn’t mention, please send me an email! Even if you do strict SPF checks, don’t worry, I’ll receive it. 😉