• Status: Solved
  • Priority: Low
  • Security: Public
  • Views: 67
  • Last Modified:

Local security group with e-mail used with Office 365 triggers the fraud detection

As we're currently in an Office 365 environment where we used to have Cloud distribution groups. Because we're looking to move back to our local Exchange server again I made some preparations already in case we switch back. This might save my some work in the future!

Since we moved from the cloud 'created' security group to the Active Directory Synced Security group with e-mail people are flagged as 'fraudulent' whenever they send an e-mail to the distribution group. I didn't change a thing on my SPF records or mailserver itself, so I am not really sure what's causing the trigger.

We're using the exact same distribution group e-mail address. The only difference is that it's created and synced from our local Active Directory instead of an Office 365 created distribution group.

Could anyone tell me what the possible cause is of this issue and if there is a way to fix this without reverting back to the cloud created distribution group?

Thanks a lot in advance!
0
Rick S
Asked:
Rick S
  • 3
  • 3
1 Solution
 
Vasil Michev (MVP)Commented:
Well, what exactly does it trigger? SPF fail, DKIM fail, generic "marked as spam"? Which service triggers the detection, EOP or external party? And what server are you sending them from, does the mail flow trough any connectors? Post the sanitized headers of one such message if possible.
0
 
Rick SAuthor Commented:
Hello,

You're right, some more information can be useful:

When retrieving the message details from the e-mail and pasting them to https://testconnectivity.microsoft.com/ it tells me the following:

Forefront Antispam Report Header– 
Language	en
Spam Confidence Level	-1
Spam Filtering Verdict	SKA
IP Filter Verdict	NLI
HELO/EHLO String	EUR01-HE1-obe.outbound.protection.outlook.com
Connecting IP Address	<IP>
Microsoft Antispam Header– 
Bulk Complaint Level	0
Phishing Confidence Level	0

Open in new window


Other headers– 
#↓	Header	Value
1	Authentication-Results	spf=pass (sender IP is 104.40.229.156) smtp.helo=smtp.eu1.exclaimer.net; <ourdomain>; dkim=none (message not signed) header.d=none;<ourdomain>; dmarc=none action=none header.from=<ourdomain>;
2	Received-SPF	Pass (protection.outlook.com: domain of smtp.eu1.exclaimer.net designates 104.40.229.156 as permitted sender) receiver=protection.outlook.com; client-ip=104.40.229.156; helo=smtp.eu1.exclaimer.net;
3	Authentication-Results-Original	spf=pass (sender IP is 104.40.229.156) smtp.helo=smtp.eu1.exclaimer.net; <ourdomain>; dkim=none (message not signed) header.d=none;<ourdomain>; dmarc=none action=none header.from=<ourdomain>;
4	Received-SPF	Pass (protection.outlook.com: domain of smtp.eu1.exclaimer.net designates 104.40.229.156 as permitted sender) receiver=protection.outlook.com; client-ip=104.40.229.156; helo=smtp.eu1.exclaimer.net; 

Open in new window


We're using Exclaimer for our signatures. SPF seems to be okay, spam level is marked as -1 which seems to be okay. dkim is noted as none, we're using one but even disabling the dkim signing is not solving the issue. The only connector we're using are for the signatures. Mails are sent from either the OWA (portal.office.com) or Mail clients.

It only happens whenever we're sending to security or distribution groups who are synchronised with the Active Directory. When creating a cloud based group everything is okay!

Thanks for your reply!
0
 
Vasil Michev (MVP)Commented:
Well I'm not seeing anything wrong with that message, moreover it seems to be treated as internal email and has bypassed additional scanning (the SKA verdict). So I have to ask again, which "fraud detection" does it trigger? Do you mean the mail tips in Outlook/OWA?
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

 
Rick SAuthor Commented:
To answer your last question: it literally tells you:
This sender failed our fraud detection checks and may not be who they appear to be.
This is also shown in other mail clients like Outlook or Mail for iOS.
0
 
Vasil Michev (MVP)Commented:
OK, so this is simply a because of the logic they use in order to surface those tips. Read here: https://blogs.msdn.microsoft.com/tzink/2016/02/23/how-antispoofing-protection-works-in-office-365/
And here for more details and you exact scenario: https://blogs.msdn.microsoft.com/tzink/2016/11/02/troubleshooting-the-red-suspicious-safety-tip-for-fraud-detection-checks/
0
 
Rick SAuthor Commented:
Thanks a lot, I'm going to try this and will try to report back!
0
 
PberSolutions ArchitectCommented:
No comment has been added to this question in more than 21 days, so it is now classified as abandoned.

I have recommended this question be closed as follows:

Accept: Vasil Michev (MVP) (https:#a42361739)

If you feel this question should be closed differently, post an objection and the moderators will review all objections and close it as they feel fit. If no one objects, this question will be closed automatically the way described above.

Pber
Experts-Exchange Cleanup Volunteer
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now