SPF Status Fail for Yahoo Inc


Long story short, we have configured Email Routing for some domains and so far so good. However, when trying to signup for the Yahoo FBL, we are unable to receive the verification codes. The emails are failling in the dashboard with “SPF Status: Fail” from [email protected].

Now, I honestly doubt Yahoo would have a problem with their SPF… so we also tried Email Workers, with the hope that we can receive / see the emails. No result.

All other external emails tested so far pass through OK, with forwarding / with worker. So what’s the deal? We cannot even open a support ticket…


To be more blunt… the issue is in Email Routing, as the SPF is valid: SPF Record Checker and Lookup Tool | EasyDMARC

And to top everything up… even legitimate emails coming from @yahoo:

**SPF status**


**DMARC status**


**DKIM status**


So clearly Cloudflare has a problem with Yahoo emails…

Seems they do. This email address comes up often as failing SPF

1 Like

Hi @nbevow, your topic has a solution here.

Let us know what you think of the solution by logging in and give it a :+1: or :-1:.

Solutions help the person that asked the question and anyone else that sees the answer later. Login to tell us what you think of the solution with a :+1: or :-1:.

I see… do you know any solution? How to get the email?..

The best approach is to stop using email forwarding. Delivering to mailboxes via MX routing is considerably more reliable than forwarding in the age of DMARC.

Indeed, but you lose the capability of executing code with the bindings of other Cloudflare services…

Such as?

1 Like

Understood. I missed your earlier mention of Email Workers. (I saw on a second look.) The Cloudflare Email Routing product is far more often the topic of discussion here for delivery issues. My response was directed more specifically at that scenario.

Yes… and unfortunately this is such a “must have” feature that it’s hard to let go.

1 Like

Hi @nbevow,

In this thread we can see other reports of Yahoo’s emails failing SPF checks, which makes us believe this should be an issue on Yahoo side.

1 Like

Latest SPF standard from April 2014 (RFC7208) says “(do not use)” next to the ptr: mechanism:

5.5. “ptr” (do not use)

It mentions various things such as e.g.:

This mechanism SHOULD NOT be published. See the note at the end of
this section for more information.

Note: This mechanism is slow, it is not as reliable as other
mechanisms in cases of DNS errors, and it places a large burden on
the .arpa name servers. If used, proper PTR records have to be in
place for the domain’s hosts and the “ptr” mechanism SHOULD be one of
the last mechanisms checked. After many years of SPF deployment
experience, it has been concluded that it is unnecessary and more
reliable alternatives should be used instead.

But the note also ends with:

It is, however, still
in use as part of the SPF protocol, so compliant check_host()
implementations MUST support it.

I just gave it a try, and changed my SPF policy to use only “ptr:”, as well as having an ending of with “-all” (hardfail).

Sending to a Cloudflare Email Routing domain, Cloudflare Email Routing rejected the message, with the reason:

550 5.7.1 IP address isn’t allowed to send email for email.

This does mean that Cloudflare Email Routing, goes against the SPF standard, by not validating the “ptr:” mechanism, as RFC7208 says that implementations MUST support it.

You can however always argue whether Cloudflare does this in good (or bad) faith, given that it has had a decade of being mentioned as “(do not use)”.

Since Cloudflare does not validate “ptr:”, and Yahoo is depending on the “ptr:” mechanism to pass SPF, the SPF result falls back to neutral, because of Yahoo’s “?all” ending:

If Yahoo is continuing to rely on something (more than) a decade after it’s use is discouraged, I’m not sure that I have much sympaty for Yahoo though…

1 Like