Not sure why this is happening but we need to fix it because it is adding friction to people setting up their accounts. Need to investigate why this happens and add some mitigations
some things I want to look into:
- are we following general best practices/law for format/content of transactional email
- https://react.email/templates could be a good reference for what copy to include - a lot of the email templates have company name and address in the footer
- does mailtrap surface any info on this in the admin dashboard
- is dns set right
I vaguely recall whenever we sent transactional emails as the clubs @utdallas.edu email we made i straight into inboxes, I'm pretty sure, which I feel weird about because Mailtrap is obviously not sending email internally. That could be a temporary solution, but I don't want it to remain a permanent one. I feel a bit uncomfortable with impersonating sending emails from UTD servers...
Activity
4
jasonappah23d agoStill seeing emails to UTD emails land in spam. Don't know why. I genuinely thought that I was seeing our emails land in the inbox for a little bit, so not quite sure what's going on. Still need to do some more investigation here ig
kabeer71214d agoLooking at core/emails.py and templates/email/base.html, the HTML now looks well formed (proper doctype, text part derived from the HTML, Auto-Submitted header), so I doubt content is the main problem anymore. With UTD on Office 365, I'd look at authentication and reputation first.
Open one of the spam-foldered messages in Outlook and view the source. Check:
Authentication-Results: spf, dkim and dmarc should all pass, andheader.d=for DKIM should be your EMAIL_FROM domain, not a Mailtrap domain. If DKIM is signed by Mailtrap's domain, DMARC alignment fails, and M365 weighs that heavily.X-Forefront-Antispam-Report: theSCLvalue andCAT(e.g. SPM, BULK, PHSH) tell you exactly why it was filtered.
Also turn off Mailtrap click and open tracking for these sending streams. Link rewriting to a tracking domain plus a tracking pixel in a login/registration email is a common trigger. And if there's no DMARC record yet, even v=DMARC1; p=none helps.
If everything passes and it's still SCL 5+, it's probably UTD's tenant policy, and asking UTD IT to allowlist the sending domain might be the practical fix.
mailtrap is (probably) not the issue. We probably just need to change what our emails look like
I'm realizing our current HTML emails aren't even properly formed HTML, I wonder if that is a red flag to UTD/Office 365 spam filters?
I will look through this at some point: https://mailtrap.io/blog/why-are-my-emails-going-to-spam/