Forum Discussion
Firebase authentication emails are blocked by Office 365
Hi arnotixe,
I just analyzed the new test message that you sent me and it passes the security scans and it's not identified as Bulk. The only problem is the SCL level, (5), and by default EOP will deliver those messages to the Junk email folder. ( Note that this can be modified by the Admins, so it's possible that in some cases it landes in the inbox folder and in other ones it will be quarantined ).
I'll share the message header with you in a private message. Finde here more information about the SCL value:
https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-spam-spam-confidence-level-scl-about?view=o365-worldwide
https://learn.microsoft.com/en-us/exchange/antispam-and-antimalware/antispam-protection/antispam-stamps?view=exchserver-2019
https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/message-headers-eop-mdo?view=o365-worldwide
I have a brand new app, that is also using Firebase and I am experiencing exactly the same issue. The Firebase Authentication service has pre-configured templates that it sends for user email verification and similar interactions. The Authentication product sends these communications by default from Firebase's own email service.
This issue will affect any developer who uses Firebase (of which there are many) and uses Firebase authentication. Seems like this is a new issue though as these emails were all still working at the beginning of Feb.
Given that this is a universal problem experienced by many users of the Firebase Service, how can this be addressed at a large scale, rather than everybody trying to address this individually?
- The delisting service also has no effect. I enter my sender email and IP (now have a dedicated one) into https://sender.office.com/, verify it by clicking the link I get (I don't block THEIR mails "ha ha") and then I get "Delisting was denied, click to escalate". After that I don't hear anything.
The problem is that these auth emails somehow get tagged as spam in ONE Microsoft customer, and then protection.outlook.com blocks them for all.
I'm starting to think a lawsuit may be the way to goUnfortunatley there's no much more I can do here.
I searched around and found other forums with similar issues:
https://issuetracker.google.com/issues/253291461
https://arutkayb.medium.com/firebase-auth-how-to-set-up-a-custom-domain-for-email-templates-1693999224be
https://www.reddit.com/r/Firebase/comments/vib8yy/firebase_confirmation_email/
On the last test message received by arnotixe I see all quite good, only a problem with the returnpath and that SCL score, ( 5 ).
The sender was "mailto:email address removed for privacy reasons and the returnpath was "
bounces-201492346-robot=domainname.no & mailer.domainname.no" EOP is very strict with spammers, so they pay a lot of attention at the returnpath and reputation of the senders servers.
Mark messages as safe ones will help for a single O365 organization, but that doesn't mean that the same messages will go thorugh the other ones. ( And if the messages are considered High confidence SPAM/Phish, that will not help ). In the case of arnotixe I think he's quite close to a solution, as all the other headers and scans are clean. In your case, StefDevs I don't know without analyze a message header, but I'm quite sure that the issue will be the same, ( server/IP reputation, domainname, returnpath... ).
My suggestion will be to refer to the Firebase community and the fixes mentioned there.
Microsoft Defender/EOP adapts the detection engine as per admins feedbacks, but if something seems suspicious, the security of the O365 customers environments will always be the priority, and only tenants admins will be able to "adapt" it to each own environment.
Sorry that I have not better news...
- Just want to thank FcoManigrasso here too, he's been very helpful in finding out what the problem is! Post your donation link here, FcoManigrasso!
Basically, for existing customers we have to tell their IT departments to whitelist our sender. We'll add a notice to the login page about this. This is also the Microsoft way of doing it, according to this link: https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/services-for-non-customers?view=o365-worldwide
In short, customers must whitelist our senders or open a ticket with Microsoft support about it.
The only thing not solveable by this approach is the case of new companies. This adds a LOT of friction to the signup process. Basically it is blocking it altogether.
