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 foo@foo.com, and you set up a redirect with your provider so that it forwards all emails to foo@gmail.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 foo@foo.com'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, bar@gmx.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
From: MAILER-DAEMON@mo557.mail-out.ovh.net

This is the mail system at host mo557.mail-out.ovh.net.

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

foo@gmail.com: host gmail-smtp-in.l.google.com[66.102.1.27] 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 [46.105.33.1]. 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).

The issue

What’s going wrong here? It turns out that the sender domain (in this example, gmx.com) had configured a strict SPF policy that only allowed their own servers to deliver emails from @gmx.com addresses.

We can check this running the following command:

$ host -t TXT gmx.com | grep spf
gmx.com descriptive text "v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 ip4:74.208.122.0/26 ip4:212.227.126.128/25 ip4:212.227.15.0/24 ip4:212.227.17.0/27 ip4:74.208.4.192/26 ip4:82.165.159.0/24 ip4:217.72.207.0/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 @gmx.com addresses!

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 fail” (-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 rejected the @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.

The fix

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:

Your target email system supports fetching emails from other addresses via IMAP or POP3.
The email hosting provider you use for your intermediary address has IMAP or POP3 capabilities, not only redirects.

In order to do this with Gmail, their guide on checking emails from other accounts.

And if your intermediary (redirect) address is on OVH, you can find the proper POP3 settings to use on their configuration guide, either for OVH France or OVH Canada. In short, it’s:

Region	Host	Port
France	`ssl0.ovh.net`	995
Canada	`pop.mail.ovh.ca`	995

The downside

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.

Forcing Gmail to refresh external accounts more often

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. 🤯

The hybrid approach

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:

foo@foo.com to foo@gmail.com
foo@foo.com to foo@foo.com

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.

Wrapping up

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!