One of our cloud customers recently implemented spam and phishing controls and since then emails notifications and particularly assignment alerts no longer get delivered.
Their IT indicates that the issue is due to M-Files Cloud using SendGrid.net to Impersonate a user. It is this impersonation that is the security concern for the client as SendGrid is known to be used in phishing attempts, and therefor our customer is viewing the impersonation as a phishing attempt and blocking the emails.
Reminders are working because they come from noreply@m-files.com , which is not impersonated, however the assignments looks like they are coming from someone in the organization, however are being blocked due to something in in background identifying it was impersonated via SendGrid.net.
I am sure our customer cannot be the only one's being affected by this, and therefor curious how others are getting around the issue of emails from M-Files Cloud Alerts and Notifications being blocked.
The below more detailed explanation was provided by the customer
Impersonation is when a service sends or tries to send as a user of an organization, so e.g. M-Files/SendGrid are sending AS a futuremetals.com user SMTP address.
This makes our anti-spoofing policy put that check as a failure in verification and classifies as spoofing. Many scamming organizations use the same methods to send as a specific internal user, which this current setup protects us from that. You typically see it come out as something like “Arnie Cilliers Arnie.cilliers@fakedomain.com”.
The type of protocol and check that is used for this is the standard DMARC/DKIM/SPF record checks, which sign our domains on the internet for not only vendors but also partners to know our domain is not capable of being compromised, while also protecting our domain and users from these types of attacks.
When a domain is signed and protected in this manner, a third-party service like SendGrid will not be able to copy the private key we use to sign our domain, and therefore will fail in spoofing us. We also cannot place the whole SendGrid domain as an exception because it is one of the most widely used services by scammers to conduct phishing attacks and general social engineering campaigns.
An example of how M-Files is currently sending through SendGrid and falling into impersonation is as seen below:
Envelope <bounce+53487-a5dc-
Sender: {user}={domain.com@sendgrid.net>
From Header: {User2 Name}<user2@domain.com>
You’ll see there that the actual sending email is bounces+53487-a5dc-{user}={domain.com}@sendgrid.net but the From header will read From an organization employee. This type of usage will fall under impersonation.
If possible customer would like to know if sendgrid can send as itself, instead of trying to send as a organization employee. That way the only thing we would need to do is whitelist the actual SendGrid account email and call it a day.
