SendGrid, forwarding and DMARC policy

We have recently deployed a strict DMARC policy (p=reject; sp=reject) on our domains. While this adds greater security while sending e-mail and prevents spoofing, we noticed that certain mails forwarded within our organization stopped coming in.

The scenario is, that we quite heavily use Microsoft Teams along with its e-mail to channel feature. How it works in Exchange Online is quite simple - we have a Mail Contact (originating from the address generated in Teams - xxxx.test.groups.thenetw.org@emea.teams.ms) created for the Teams address, then a Distribution Group on our domain (say sendgrid@thenetw.org). The contact is then added as a member of the distribution group and everything is nice.

After we tested the policy - no bad unexpected reports came in, we decided to tighten up the policy to quarantine the message. Almost instantly, the messages which were being forwarded this way stopped coming to Teams. From the message trace in our EXO, the messages were coming in correctly and being forwarded, but they didn’t appear in Teams.

We later identified, that the issue is affecting e-mails sent from SendGrid by our own domain which are being forwarded by Office 365 (eg. we send invoices from SendGrid and a copy goes to Microsoft Teams channel).

As a security precaution, we decided to prevent any sort of automated system, except Office 365 to send e-mails from our primary domain thenetw.org, and to have all transactional e-mails sent from a subdomain - e-mail.thenetw.org.

When we setted up the domain SendGrid - we also setted up Sender Authentication for domain e-mail.thenetw.org. It probably should’ve occured to us back then, because SendGrid pregenerated a prefix for the domain - em2509.e-mail.thenetw.org. What we did was setup SPF for domain e-mail.thenetw.org along with DKIM and all was good - except, when a message is sent, the smtp.mailfrom isn’t e-mail.thenetw.org but em2509.e-mail.thenetw.org. When being sent directly by SendGrid, everything was working fine, because SendGrid makes you create a CNAME record em2509.e-mail.thenetw.org which points to u9317285.wl036.sendgrid.net which actually has correct SPF set - for SendGrid only however. Now thanks to this, I haven’t immediately noticed the fact that the SPF check would fail when the message was being forwarded directly.

The simple solution was to create an SPF record for em2509.e-mail.thenetw.org which contains v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:u9317285.wl036.sendgrid.net -all Office 365 and SendGrid IPs.

Right after setting this up, the e-mails started coming to Microsoft Teams correctly.

We already had a similar SPF record inplace for e-mail.thenetw.org domain, but I was unaware that SendGrid was setting a different Return-Path. While it can be configured while setting up the domain, you are not able to make it the same as the sender domain - so e-mail.thenetw.org as well.

The future and correct solution - the general issue is e-mail forwarding. Forwarding e-mails is pain and generally bad practice. Honestly, I don’t understand why Microsoft Teams channels can’t have addresses in their tenants - testgroup+channelid@groups.thenetw.org which would prevent this happening in first place. Now the proper solution would be for the Sender Rewriting Scheme to be work with EXO. Actually, the SRS in EXO is being worked on and per the roadmap is being rolled out. Funny thing is, that the rollout was scheduled for Q2 CY2018, and as of now, it is Q1 CY2019 and the status is rolling out still, without any further information. I don’t see SRS working in our tenant yet at the time of writing.

Honestly, I hope that Microsoft can finish the SRS deploy soon enough, so that we can revert back to the default SendGrid’s configuration.