Emails sent to your Exchange Online mailboxes may be delivered to the Junk Email folder of Outlook, and modified with the following message in the email body:
This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing
If you know that the email is legitimate, and is not a spoofed email, the cause of the issue may be an incorrectly configured Sender Policy Framework (SPF) record that does not specify the IP address of the server or host that sent the junked email as an allowed sender.
Update, March 2018 – I originally wrote this article to address what was a minor issue that mostly impacted domain owners’ emails to themselves. For example, email notifications sent from an external website or SaaS application to your internal users, using your own domain. As of early 2018, changes to Office 365 ATP are resulting in a high rate of these false positives due to more aggressive filtering of email that fails domain authentication checks (SPF, DKIM, DMARC, and other signals that ATP users). Read more here.
Fixing Your Own SPF Record
When you add an email domain to your Office 365 tenant Microsoft presents an SPF record that they recommend be added to your public DNS zone. The SPF record is created as a TXT record, and will look similar to this:
v=spf1 include:spf.protection.outlook.com -all
The default SPF record nominates Microsoft’s servers that handle outbound email for Exchange Online as permitted senders for your domain. All other IP addresses on the internet that try to send email using your domain will fail the SPF check, and if SPF lookups are being used to prevent spam, spoofing, and phishing attacks (as they are in Exchange Online Protection), the email will be rejected or junked as shown in the example above.
However, it’s quite normal for businesses who use Office 365 for email to have other sources of email for their domain, such as the web server that hosts their public-facing website, or a SaaS application (such as payroll, marketing, or monitoring systems) that sends email “From” the domain. It isn’t always necessary to add the host names or IP addresses for external systems to your SPF record, depending on how they send email. For example, if you have an external application using Amazon SES for SMTP, adding Amazon SES to your SPF record isn’t always required. In many cases you’ll have no control over how the external system sends email though, and adding them to your SPF record will be necessary.
In the example message shown at the start of this article, the SPF check failed because the host sending the email is not in the SPF record. This can be seen by viewing the message headers of the junked email.
The headers can be difficult to read, so you may need to copy and paste them into the message analyzer in the Microsoft Remote Connectivity Analyzer. Look for the “Received-SPF” header.
For third party systems and SaaS applications you should check with their technical support to see whether they provide any advice as to what you should add to your SPF record. Often they’ll provide an IP address, range of IPs, or a specific host name. If they don’t provide advice, or if you control the server that is sending the emails and already know the IP address, you can go ahead and add the IP to your SPF record. For this example, the IP 203.206.161.219 needs to be added, so the original SPF record would be updated as follows:
v=spf1 ip4:203.206.161.219 include:spf.protection.outlook.com -all
There are other mechanisms for configuring SPF records. If you need assistance building an SPF record for your domain try SPF Wizard. Just be sure to maintain the “include:spf.protection.outlook.com” that is required for Exchange Online.
After updating your SPF record and waiting for the old record to expire from DNS caches, your emails should deliver successfully to inboxes without being junked by Exchange Online Protection.
To learn more about SPF, read my SPF primer for Exchange admins.
Fixing Someone Else’s SPF Record
Since you have no control over other the DNS records for other peoples’ domains, you can’t directly fix a problem with their domain authentication. If you’re seeing a high rate of false positive junk mail for another domain, and you believe that the issue is caused by their SPF implementation, you should start by getting in contact with their email administrators.
That can be a challenge if you don’t have their contact details, or if they outsource their support to a third party. Sometimes it’s necessary to get in touch with the person who sent the email that was junked, then ask them to escalate the matter internally to their help desk, or provide you with the contact details. Even then, the conversation can quickly turn into a finger pointing exercise where the domain owner doesn’t want to take responsibility for fixing their domain authentication issues.
If it helps, point them at this advice from Microsoft, particularly this quote:
The newest anti-spoof features help protect organizations from external domain spoof. Office 365 honors emails from external domains having proper SPF, DMARC, and DKIM authentication settings enabling them to pass authentication, and junks messages that fail this authentication. The challenge occurs when external domains do not have these settings properly configured…. (We recommend) admins of sender domains into Office 365 update SPF, DKIM, DMARC configurations so emails can pass the stricter authentication rules.
The longer the other domain owners ignore the problem, the worse the situation will get for them. If they want to reliably send to Office 365 customers, they’ll need to fix their domain authentication problems. Eventually, their own users may end up putting enough pressure on them to fix the problem.
Hello,
We created a rule that blocks spf = none headers.
Mail comes from contoso.com and spf pass is marked. So far there is no problem.
However, if out-of-office automatic reply is enabled on contoso.com, spf is marked as none in the header of the incoming mail.
Thank you
[This sender might be impersonating a domain that’s associated with your organization. Learn why this could be a risk at http://aka.ms/LearnAboutSenderIdentification.%5D
Is this a legitimate notification from O365 ATP. If it is so then why not it is validating all of the email headers? I could see only one email impersonated email got caught..
Any suggestions please..?
Hi Pual,
i am having issue When sending message from Exchange online the sender IP Appear as “client IP” not Exchange online IP and it fail in Dmarc Check, do you know how to change this ?
What are they using to send the email?
Paul
Thanks for writing this amazing article.
After reading it the first impression was that my SPF record was probably faulty. But when I checked the DNS configurations, SPF was already set as :
v=spf1 a mx ip4: include:spf.protection.outlook.com -all
But the emails are still heading to the spam box.
Any clues on what I could be missing here.
You’ll need to look at the headers of the messages to see whether SPF is failing, or any other domain auth failures. Maybe the messages are getting junked due to the SCL score. Only the headers can tell you that. If it’s someone else’s domain sending the emails, then it’s not your SPF record that comes into play, it’s theirs.
Also make sure you’ve read the article linked to in the update note early in the article above.
I checked the headers and found that the SPF was indeed failing. I could take corrective measures from there.
Thanks for your response and time.
Hi Paul,
Thanks for this! It solved my problem!
Jeff
I’ve just started getting this from salesforce.com generated emails too claiming to be from my company. The offending line in the headers is shown below.
authentication-results: spf=pass (sender IP is 13.108.254.142)
******smtp.mailfrom=ltjxifctld8qe.3-1o56eae.na57.bnc.salesforce.com******; mydomain.org;
dkim=none (message not signed) header.d=none;mydomain.org; dmarc=none action=none
****** header.from=mydomain.org*******
I’ve added the **** around the lines – in this case, the mail is from guid.bnc.salesforce.com but claims to be mydomain.org. Although spf records match, Microsoft does not have a high enough reputation score for ltjxifctld8qe.3-1o56eae.na57.bnc.salesforce.com and therefore flags the mail as potentially spoofed.
The scary thing is that the help page says to add the senders domain to the whitelist….. you should never add your own domain to a whitelist!
As to turning off the safety tips – you can turn them off, but then you are also turning off the valid alerts that warn users of phishing emails.
I’m looking to see if there is an option to tweak the safety tips whitelist – so far I’m not seeing one.
Check with Salesforce to see whether you can have them use DKIM signing for the messages they are sending on your behalf.
I am now seeing this on emails sent through Mail Chimp, as well as emails to an alias of my email address with .io instead of .com…
This feature is basically a nightmare, why can we not just turn it off?
Hi Paul,
Another approach can be Transport rules to allow IP white listed and bypass SPF check, that way sender server (if internal) can send emails safely to internal users.
Hello Paul,
I have a client who’s forwarding the emails received from his old email address to the new one and set up an auto-reply on his old email.
The thing is that when the auto-reply comes in, a “This sender failed our fraud detection checks…” message comes up.
Office 365 is hosting the new email address while GoDaddy is hosting the old one.
Any suggestions? Would a DKIM on the new email address do any good? Thanks!
Forwarding + an auto-reply seems like an odd combination to me. Either way, you’ll just need to start by checking the basics. Look at the headers of the auto-reply for clues. Check whether SPF is set up correctly for the old and new domains.
If the auto-reply is something like “My new email address is blah@newdomain.com, please update your contacts” consider just ditching that entirely since the old email address forwards to the new one anyway.
If our phone is configured in ActiveSync but we always get the message that there is an impersonation when he sends us an email, we must do how?
I don’t have any plain ActiveSync devices handy to test, and I’ve never seen this problem in the field before. You could open a support case with Microsoft to look into it. I don’t think the use of ActiveSync should trigger that fraud detection alert.
Ok…..
Thanks for your reply
Hi Paul ,
We have added the required SPF record for our On-Premise server and after that this message is not displayed for emails send from on-premise to EXO .
But the problem exist for Automatic Reply , suppose if I send an email to user On-premise mailbox and if On-premise user is set OOF the Autoreply message comes with this message showing it as spoof
Is this a hybrid configuration?
Not an hybrid configuration , we are using third party solution for migration.
If we check the message header for automatic reply ww see spf none and it shows smtp.helo instead of smtp.from , and spf lookup is done for smtp.helo sender host nane
I’d say that’s the problem then. The on-prem server will need to be included in your SPF server so that Exchange Online doesn’t treat the messages as being spoofed.
Is the a way to get alerts sent to me when ever any of my users receive an email that contains the “This Sender Failed Our Fraud Detection Checks and May Not Be Who They Appear to Be.” message in them?
Is there also a way the generate a report regarding users that get these emails?
I do not mind if my users see this message in the affected messages they receive, but I would like to be aware of who is getting messages that are tagged like this as well, in case action is needed.
You might be able to use a mail flow rule (transport rule) to detect that text string and forward a copy of the messages to another mailbox. It depends whether the text gets added before or after mail flow rules are processed. I would assume it gets added before, but you’ll need to test it.
I’ve been working on this issue for weeks with Office 365 support. We finally resolved this issue by adding a rule to bypass spam with the sending server’s IP AND enabling DKIM.
Hi Paul,
After migrating Exchange 2010 to Office 365, we used our ISP’s SMTP relay for “Scan to Email”. Every time user scan’s, it goes to Junk folder and email says “This Sender Failed Our Fraud Detection…..” . They unjunk it but next time still goes to Junk.
According to your article above, if I include IP address of my ISP’s SMTP relay address, would that work?
Many thanks.
Try creating a rule in Office 365 to bypass spam from the sending server’s IP. Also enable DKIM. This is in Protection/DKIM. You will have to set up CNAMES via DNS for DKIM to work.
Hi Paul,
My client when send sample to him he is getting error as “”This sender failed our fraud detection checks and may not be who they appear to be. learn about spooling”. He is unable to know why this msg is coming. He asking suggestion and reason why it is coming. Please post me asap.
Thanks.
Try creating a rule in Office 365 to bypass spam from the sending server’s IP. Also enable DKIM. This is in Protection/DKIM. You will have to set up CNAMES via DNS for DKIM to work.
Hey Paul,
Dealing with a situation much like you described (sender failed messages when sending to a specific email address), we looked at the SPF records and found out they needed to be updated. Got that taken care of, but we were still seeing the error message over 3 days later.
Worked with O365 support to look at message headers (we did this initially as well after the first encounter with the error) and they had us condense down from 3 SPF records to 1. We checked with our domain registrar who told us we were already only using 1.
Examining the headers again with O365 support we found out the Proofpoint server IP address was not included in the SPF record (and supposedly this was what was causing the failure message).
We included the Proofpoint IP into the SPF record and were met with some success, now the message only is displayed when sending externally (or when we BCC the specific address)
Curious if you have any guesses as to why this is happening.
thanks!
I don’t understand your mail flow from that description, so it’s hard to offer any suggestions.
Hi Paul,
We are in the process of migrating our Lotus notes Setup to Exchange Online. As a part of Mail flow coexistence we are setting up Email Forwarding in Lotus notes environment for the Migrated user to alias@domain.omicrosoft.com . We see all Emails are seen as Junk for my EXO mailbox with the Error mentioned in this article.
Currently my MX is pointed to Symantec gateway and we don’t have SPF setup for our Domain.
My query is if I setup SPF pointing to Online server my other Emails which will be sent from my On premise mailbox are going to fail.
Can I add my Symantec and EXO spf record for the domain in Public DNS.
My SCL value is set to 5 when I see the header !
I suspect EOP is treating them as spam because you don’t have an SPF record that validates that your on-premises Notes server is a legitimate sender for your domains. So yes, you need to configure an SPF record.
As of 12-12-16 I have not been able to receive any email from American Express on my Hotmail account @msn.com Is there any way to fix the situation? Also, I am ignorant of any other email I might not be getting.
Thank you for this!
We have users that receive email from a listserv that arrives clean. When our users reply to that email O365 tags the message with “This sender failed our fraud detection checks and may not be who they appear to be”.
Yes, that is expected with externally hosted distribution lists because the listserv is not authorized to send as your address/domain. You’d likely need to add the listserv server IP/s to your SPF records, which is not ideal.
Paul,
Scenario, customer is an Office365 tenant with Hosted Exchange. Their website sends out an email on completion of an order in the form of sales@ which is an address they have and use.
I have taken the address of their website and added to the SPF record at the host, so the SPF is v=spf1 ip4:xxx.xxx.xxx.xxx include:spf.protection.outlook.com -all
but the issue persists, emails from the site have the ‘ This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing ‘ message.
It’s been a week or so since I did this so propagation isn’t an issue, any ideas?
Thanks
I’m still getting a few random instances as well. I suspect their algorithm is making decisions based on multiple factors (SPF, valid sender address, probably others). If you’ve got specific cases you should open a support ticket to see what Microsoft says about it.
This is becoming extremely frustrating for one of my clients. Whenever he send e-mails from his Mobile phone to another users mailbox within the same domain, the recipient will receive this message.
Why is this? The sender is sending from within the same domain
If the device is set up as an ActiveSync connection, it shouldn’t be doing that. If it’s been set up as a POP/IMAP connection, it could very well cause that problem.
In Received-SPF, it says this:
None (protection.outlook.com: mydomain.com does not designate permitted sender hosts)
What does this mean?
It means mydomain.com doesn’t have an SPF record.
Paul, so in the instance above (where it returns NONE) what do you do?
The issue I am having is that contact form outputs from my website are getting thrown into my junk folder.
The mail appears to come from Joe Public (where the Joe Public bit changes depending upon who filled in the form – the remains the same.
Can I somehow whitelist this or perhaps whitelist my hosting server name/ip?
The
Are you using Office 365/Exchange Online to host your mailbox?
We are getting this message ‘This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing’ when i send a message from my email address via my blackberry phone. I c.c. the message back to myself so that i have a copy on my desk top but this message is at the top of the email. I don’t want my clients to see this. Please tell me what i can do about it. I have turned off junk mail filtering.
Possible that the reason is the SMTP server your Blackberry device is using to send email.
We are getting large amounts of clients getting this error this week.
One of the clients, the SPF record was updated with the server details – still has the same issue from their website contact form.
One of the other ones is Office 365 to Hotmail – the hotmail user gets the fraudulent notification.. the DNS is hosted with Office 365 so I would assume it should be fine..
I wouldn’t assume anything. If the messages are appearing, make sure the SPF is correct, make sure the sender is a valid address, and so on. I can’t see your environments or the email in question, so all I can offer is suggestions and possible causes. If you’re still stuck and you’re an Office 365 customer, raise a support ticket and I’m sure they can help you trace why the warnings are appearing.
Dear Paul!
I’m very happy to found this site, because I have the same issue at my company, and during this time we didn’t found any relative information about the message’s origin.
You told that this message has been added by Office365, am I right?
Reffering this I’d like to ask two other questions:
1. My company uses Office365 as a primary filter. Is this only occurs in case of incoming emails or is this possible somehow in case of outgoing messages, which goes through Office365? (We haven’t got any mailboxes in Office365, only in local Exchange.)
2. One of our partners got the same additional text when received a mail from us. As I saw in their MX record, they don’t uses Office365 (the MX doesn’t contains any MS related entry.) Is there any MS product besides Office365, which uses the same protection method and could generate the same additional text in incoming message’s body?
Thank you very much for your answers in advance!
Best regards:
Istvan
If by “primary filter” you mean you’re using Exchange Online Protection for spam filtering, then yes this feature would be working for you. As far as I know it’s only applied to inbound messages. Your partner might still be using Exchange Online Protection even if you can’t see it in their MX records. You should get a copy of the message headers from them and see what is processing the message.
Dear Paul!
At first… Many thanks for your answer!
Yes, EOP is the primary filter we’re using.
Do you know any possibilities (or do you have any experience) to switch off this message without switching off any filters (by EOP Admin or MS itself)?
Best regards:
Istvan
Turning off protection features isn’t the right approach to take here. You should leave the feature enabled and work on fixing whatever is causing the messages to be flagged. I can’t see your messages and I don’t know your environment, so I can only make suggestions. If you’re unable to work out why they’re getting flagged, open a support case with Microsoft (as you’re entitled to, as a paying customer) and they can look at your specific situation and give advice.
Paul, at what point does this text get added? I just got a report from a Customer of this issue. We are the application host provider for domain cdaa.org.au and SPF records pass fine: https://dmarcian.com/spf-survey/cdaa.org.au
When I did a test which sent the email to a gmail address, I didn’t see the error text. But when the email was sent to the same domain, this error pops up.
The message is added by Office 365, so if you’re sending to Gmail you won’t get the same behavior.
Paul,
This error message is frustrating. We do have appropriate SPF declarations for the sending servers ip-address, yet the email gets this message added on.
As per https://testconnectivity.microsoft.com/ test of the headers, the ‘received-spf’ header is ‘Pass’. The email message is also DKIM signed.
The From address being used for the sending of email is also valid.
I am lost here.
Yes, frustrating when the cause is not obvious. If you believe you’ve got everything set correctly, then a support ticket would be my next step. There may be another factor that needs addressing, or it could be a false positive and Microsoft needs to tune their algorithms.
Hi Paul,
Have a Magento site sending out invoices, shipping, etc emails for the server through my Office 365 account. I have updated the DNS sitting on Godaddy with the v=spf1 ip4:(my ip address) include:spf.protection.outlook.com -all (updated 2 days ago), so old record should be updated.
Office 365 has full exchange rights to the domain, but I still get the “This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing” in my emails.
Anything else you can suggest?
Is Magento sending “through” your account (as in, it has programmatic access to your mailbox), or is just using your email address/domain as the From address?
If it’s just using your email address/domain as the From address, you should make sure that the Magento web server’s IP address is included in your SPF record.
Forgive me if I’m not understanding SPF records clearly as we don’t currently use them…
Our Listserv is setup using mail flow rules as internal to our Organization, so we have no issue with the Listserv that we host. However, being an academic institution, our faculty/staff/students subscribe to many Listservs hosted by other institutions and messages sent to them as subscribers of those Listservs are being marked as junk.
Since the messages are not being sent by users in our email domain, our SPF records cannot be updated to fix this issue, correct? Is Microsoft suggesting that all organizations that host Listservs must use SPF records and that they must contain their Listserv IP?
I don’t understand your scenario because it’s a bit unclear who you mean by “them”.
But if someone else is sending email and it’s being treated as spam/phishing/spoofed etc due to a lack of SPF records in their domain, that’s something that they as the domain owner need to fix.
Paul,
I keep getting this in Apple Mail. Is there any info on this? It all of a sudden started happening and GoDaddy support is useless.
We haven’t changed any settings but all of a sudden started seeing this in our inbox. A client’s online store sends an email from example.com website to info@example.com and that same error message shows.
This is a WordPress Managed website where you can’t change the MX records to reflect the domain or IP though.
Hope I made sense.
The client’s domain should have an SPF record that includes the IP address of their web server, if that web server is sending email. That’s something they as the domain owner needs to fix.
We have also started seeing this just now, on emails received from an Azure service using elasticemail.com to send emails.
SPF passes, and neither Forefront Antispam Report Header nor Microsoft Antispam Header has any complaints. The messages are delivered to the users inbox. The only problem is the message in the body.
If your message content looks like it might be fraud, then that’s something to look at fixing with your message content. There’s services available that will analyze emails for “spaminess” so you can adjust them to be more spam filter friendly.
What could be other reasons for this failure. Just today we started getting that message on our emails we send through another program other than our Office365. When I ran the headers through the Remote Connectivity Analyzer the spf passes……so why if everything passes would they still mark the message as such?? Please help! Thanks
I’ve also seen this occur when the emails are sent from a non-existent email address for the Office 365 tenant. For example, let’s say your application sends from “noreply@contoso.com” to “someone@contoso.com”. If the “noreply@contoso.com” email address doesn’t exist, that’s possibly a signal that the email might be fraudulent, even if SPF passes.
I just had this issue, because a user copied my signature line and erased my email address but the link had stayed and they just typed their email address over it. So it said their email address but the link sent to mine. So when you hoover your mouse over their signature line email it showed mailto: my address down in the left hand corner of my browser.
Hi Paul, where it says “the SPF check passed because the IP address sending the email is not in the SPF record” it should be “the SPF check failed…”.
Fixed, thanks.
Do you mean add the IP address of the exchange premises server which can be controlled into the SPF which it is Authoritative like MX is pointing to premises.
If your Exchange server is authoritative for a domain, and sends outbound email for that domain, then yes you should include the server in the SPF record. You can include it by adding the IP address, hostname, or if it is also the MX for inbound email, by adding the MX mechanism to your SPF record.