All External Mail to Office 365 Fails SPF, Marked as Junk by EOP in a Hybrid Deployment

Hi folks,

In short, our legitimate emails are landing in Junk folders as EOP (Exchange Online Protection) stamps email messages as junk (SCL5) and SPF-failed. This happens with all external domains (e.g. to client’s domain (

Background info:

We are at the beginning of migrating mailboxes to Office 365 (Exchange Online). This is a Hybrid Deployment/Rich-Coexistence configuration, where:

On-Premise = Exchange 2003 (Legacy) & 2010 (Installed for Hybrid Deployment)
Off-Premise = Office 365 (Exchange Online)
EOP is configured for SPF checking.
MX records are pointing at the on-premises as we haven't completed migrating all mailboxes from on-premise to Exchange Online.

The problem is when external users sends emails to an Office 365 mailbox in the organization (mail flow: External -> Mail Gateway -> on-premise mail servers -> EOP -> Office 365), EOP performs an SPF lookup and hard/soft failing messages with the external facing IP address of the Mail Gateway from which it received the mail.

On-premises mailboxes do not have this problem; only mailboxes migrated to Office 365.

An illustration of the problem with mail flow and details:
Mail Flow from External to Office 365 with EOP
Note: is the public IP address of the on-premise hybrid Exchange 2010 server connector to Exchange Online.

For example (Message headers):

Case 1. Email from to

Authentication-Results: spf=fail (sender IP is;;
dkim=none (message not signed) header.d=none;
Received-SPF: Fail ( domain of does not
designate as permitted sender);

X-MS-Exchange-Organization-SCL: 5
X-Forefront-Antispam-Report: CIP:;CTRY:HK;IPV:CAL;IPV:NLI;EFV:NLI;SFV:SPM;

Case 2. Email from to

Authentication-Results: spf=none (sender IP is;;
dkim=none (message not signed) header.d=none;
Received-SPF: None ( does not designate permitted sender hosts)
X-MS-Exchange-Organization-SCL: 5
X-Forefront-Antispam-Report: CIP:;CTRY:HK;IPV:NLI;EFV:NLI;SFV:SPM;SFS:(6009001)

Case 3. Email from to

Authentication-Results: spf=softfail (sender IP is;;
dkim=fail (signature did not verify);
Received-SPF: SoftFail ( domain of transitioning discourages use of as permitted sender)

X-MS-Exchange-Organization-SCL: 5
X-Forefront-Antispam-Report: CIP:;CTRY:HK;IPV:CAL;IPV:NLI;EFV:NLI;SFV:SPM;

How to stop external emails from being marked as junk by EOP during coexistence stage of a Hybrid Deployment?

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Amit KumarCommented:
We have same infra and same happens with us also. so sometimes we suggest to client that they work on their side to update their SPF records and sometimes we whitelist subjected e-mail address.

I think you can do one more thing, configure your SPF check rule to take action on Hardfail, so at least softfail mails will be in.
wandersickAuthor Commented:
Amit, thanks but if you mean enabling "SPF: Hard Fail" in Advanced Spam Filtering Options, I don't think it would help. Even if it would let soft-failed mails in without going to Junk folder, we needs hard-failed mails in too. For example, the case 1 in my question is a hard-fail case, but it is a legitimate email from Microsoft to our organization.
Amit KumarCommented:
Then better to disable SPF check as MS EOP is very restrictive in SPF check...
Active Protection takes the fight to cryptojacking

While there were several headline-grabbing ransomware attacks during in 2017, another big threat started appearing at the same time that didn’t get the same coverage – illicit cryptomining.

wandersickAuthor Commented:
Regarding disabling SPF check in EOP, I wish I could do that. I can't figure out how to do so in the Exchange admin center web interface.

The closest I could get to is setting up a mail flow rule:
However, it does not work at all (or I don't know the amount of time it requires to take effect).

Anyway, this is not the way I desire it to be, as it would render EOP completely useless for mails with SCL=5 that are really spam rather than legitimate ones.
Amit KumarCommented:
Go to protection in EOP console, then spam filter then see how many rules are there, open them and check advanced filter, there will be one option for SPF hardfail. if it is yes choose it to no and save that rule then monitor.
wandersickAuthor Commented:
Thanks, but we did not modify any of the EOP options; the "SPF: Hard Fail" advanced option is already Off by default. Screenshot-2015-08-16-080255.png
Amit KumarCommented:
Then log a SR in MS and ask them to check, this is weird situation.
wandersickAuthor Commented:
The issue has been solved by Microsoft Office 365 support and/or their backend team.

We did nothing. As far as I know, they found a problem with the TLS tunnel and the mail flow from Exchange 2003 to Office 365 where this line in message header "X-MS-Exchange-Organization-AuthAs: Anonymous" should be "Internal". However, we verified all our settings; nothing should be wrong with TLS. And StartTLS is displayed when running EHLO command on our Exchange 2010 Hybrid server by telnet.

Later, we were informed we had the IP from our Inbound Connector (i.e. public IP of Exchange 2010 Hybrid server) defined in our IP Allow List (It was also suggested by an Office 365 support as a troubleshooting step actually). They let us know we should not need to do this and in fact doing so can cause routing issues. They found that on initial pass the email were not getting marked as Spam so there is also a possible issue here. We then removed the IP from the IP Allow List.

After they fixed it, we found that for internal-originated mail from Exchange 2003 to Office 365:
- X-MS-Exchange-Organization-AuthAs: Internal  (It was "Anonymous")
- SCL=-1 (It was SCL=5)
- Received-SPF: SoftFail (It was the same)

And for external mails (e.g. to Office 365::
- X-MS-Exchange-Organization-AuthAs: Anonymous (It was the same)
- SCL=1 (It was SCL=5)
- Received-SPF: SoftFail (It was the same)

Although SPF check still soft-fails for (external) to Office 365, I believe it should be OK as long as mails go to Inbox instead of Junk folder (I will double-confirm this).

Thanks everyone at Experts-Exchange.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
wandersickAuthor Commented:
Troubleshooting details gone through with Microsoft Support
Thanks, I need to do the same for my org
Gopi VCommented:
Hi Outlook Team,

The issue seems still arises,  when you are sending mails from to ! It is because of validating the SPF record of the return-path domain with the relayed MTAs IP (multiple hops relayed by outlook). So it should be fixed at their outlook end.

For these mails, SCL is 5, and the mail moved to JUNK folder.

And moreover, this is not consistence across all of mails, but this do happened.

From my observation this happens,
1. whenever we are sending from new IP
2. without TLS.

Please look into this.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.