Tip of The Day: SkyDrive SPF record


In a nutshell, if you run hybrid deployment and your MX records are still poining to on premise exchange, you need to update your SPF record to include mail.sharepointonline.com

hmm, why do we need that? Let’s take a flash back.

We are running exchange 2013 on premise environment hybrid with Office 365.

We moved some users to the cloud service but we still keep our MX record pointing to our exchange environment.

Users started to work on OneDrive, formerly SkyDrive, and when they share any document/folder with their colleagues in the cloud/exchange on premise they immediately receive a non delivery report

Unable to send Auto-Generate emails -  Undeliverable

Delivery has failed to these recipients or groups:


A communication failure occurred during the delivery of this message. Please try to resend the message later. If the problem continues, contact your helpdesk.

Diagnostic information for administrators:

Generating server: AM1YL1SMTP003.YLO001.MSOPRD.MSFT.NET


Remote Server returned '< #5.5.0 smtp;553 Sender Policy Framework (SPF) fail>'


Remote Server returned '< #5.5.0 smtp;553 Sender Policy Framework (SPF) fail>'

Original message headers:

Received: from CFE4311788-024 ([]) by

AM1YL1SMTP003.YLO001.MSOPRD.MSFT.NET with Microsoft SMTPSVC(7.5.7601.17514);

Looking into the MX record, our example domain is pointing to other mail server rather than Office365

> set q=mx > myeagle.dev

Non-authoritative answer: myeagle.dev       MX preference = 10, mail exchanger = cluster8a.eu.messagelabs.com myeagle.dev      MX preference = 5, mail exchanger = cluster8.eu.messagelabs.com

cluster8a.eu.messagelabs.com    internet address = cluster8a.eu.messagelabs.com    internet address =

SkyDrive has a built-in SMTP server which helps to send outbound messages (e.g. system notification email, invitation email of shared folder or site).

When a message is sent from SkyDrive, the next hop for routing is determined by MX record lookup.

In current scenario, the MX record of myeagle.dev is pointing to mail gateway of messagelabs.com. That is why the message will be sent to messagelabs.com and sent back to Office 365 if the user in the cloud

MessageLabs check the SPF record to protect the environment from spoofing, so the email is rejected because SPF is setup for hard fail and the SPF record doesn’t include the SkyDrive IPs.

> set q=txt > myeagle.dev

Non-authoritative answer: myeagle.dev       text =

        "v=spf1 a mx include:spf.protection.outlook.com -all"

Digging more in the message header we could see that SkyDrive is sending from am1.mail.sharepointonline.com and that’s the Joshua puzzle we are missing in our SPF.

Submitting host↓↑

Receiving host↓↑

am1yl1smtp003.ylo001.msoprd.msft.net (am1.mail.sharepointonline.com [])


pps.filterd (ZZSDC2PROOF-A1.kering.net [])

ZZSDC2PROOF-A1.kering.net (8.14.5/8.14.5)

smtp2.pprgroup.net (



fnacsmtp2.kering.net (

fnacsmpt1.kering.net (

AM1FFO11FD048.mail.protection.outlook.com (

AM1FFO11FD048.protection.gbl (2a01:111:f400:7e00::185)

AM3PR06CA040.outlook.office365.com (2a01:111:e400:882b::30)

AM3PR06CA040.eurprd06.prod.outlook.com (

AMSPR06MB054.eurprd06.prod.outlook.com (

AMSPR06MB054.eurprd06.prod.outlook.com (

DB4PR06MB061.eurprd06.prod.outlook.com (

Finally changing SPF record solve the issue

> set q=txt > myeagle.dev

Non-authoritative answer: myeagle.dev       text =

        "v=spf1 a mx include:spf.protection.outlook.com include:mail.sharepointonline.com -all"

Case Solved, Enjoy Smile