I’m maintaining 4 tenants, and have setup the E-Mail provider as documented. For all 4 tenants I have tested sending the test email after the configuration. For all of them the test mail has been successfully delivered to my Office 365 managed E-Mail box.
How ever, here it gets strange… For two of the four tenants, the E-Mail sending for password recovery does not work for Office 365 accounts. It works for outlook.com, but not for Office365.
For both tenants, I see in the log, that the E-Mail has been triggered, but still it is not delivered. AWS does not show any abnormalities - which is expected as other E-Mail addresses work.
I read here in the forum that other people had similar issues. For some it got resolved by deleting the tenant, for others, a configuration change was required I suppose.
I have tested various E-Mail from addresses to send E-Mails. There is no restriction on the SMTP server on what to use. Currently the sender E-Mail for both the tests and the actual E-Mail is the same, but no luck.
These are two log ids where it does not work (two different tenants)
From the two log records. One works which is a outlook.com address, the other one does not work which is an Office365 address.
Still on SES, there is no problem, and other applications can successfully send messages to the Office 365 application. Still two other, exactly same configured tenants still work with the exact same Office 365 mailbox.
Is there anyone that can help here? If we cannot get this running in due time, we would have to move to another provider.
A couple of housekeeping items; If you reply to your own thread, it knocks it out of the unanswered queue. Try the edit function if you need to add info to your post.
Additionally, if you need urgent/time-sensitive support, all of our paid plans include dedicated support. No need to @mention our team directly, please be patient while we get to your topic!
As for your issue:
If it is working for one email client, but not another, that would suggest the client is the source of the issue. Are the emails making it to SES? This would confirm that suspicion.
Have you looked to see if the emails are being quarantined?
Thank you very much! I was off for a week, hence the delay.
Apologies for tagging, and completely agreed that the community version has no guaranteed support. I’m helping a startup to launch their product and before we commit to a service, we want to make sure that everything works.
The link you posted was very helpful. Turns out that the mails sent from the production and test instance (as we call it, i.e. tenants) are being blocked by O365.
Interestingly that does not happen with the other two environments (tenants) that we have. So by now i have three tenants (Local, Dev and Test) that all use the same configuration when sending E-Mails, but only two of them work: Local and Dev.
Do you know other cases where someone was able to track down what triggers the mail of becoming Phishing?
Update: I did run some testing with the two tenants that connect to the same AWS Region to send out mails.
Tenant 1 (Dev) works as long as I don’t use any of the following E-Mail addresses info@, account@, support@… If I use any of those, the message is filtered by Office 365.
For Tenant 2 (Test), I’m not able to produce any working configuration. The E-Mail templates, name, URls to S3 resources are all the same.
And for Tenant 3 (Prod). The problem is the same as in Tenant 2
Sometimes the email content can be the issue. (Source).
Just FYI, I am not an email/SPAM expert and can only help so much here. I am pulling directly from Google. Once the email has successfully left Auth0, it’s up to the provider to make the next move.
Seems that the configuration on Office 365 is super sensitive to it. Investigating now, how AWS could be blacklisted sometimes although I’m using the same region for both Dev and Test. Prod is in fact a different region.
Also found links to remove the sender IP from the Office 365 blacklist, let’s see if that helps, although the blacklisting seems to come from SORBS
