SendGrid, forwarding and DMARC policy

2 minute read

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 - created for the Teams address, then a Distribution Group on our domain (say 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, and to have all transactional e-mails sent from a subdomain -

When we setted up the domain SendGrid - we also setted up Sender Authentication for domain It probably should’ve occured to us back then, because SendGrid pregenerated a prefix for the domain - What we did was setup SPF for domain along with DKIM and all was good - except, when a message is sent, the smtp.mailfrom isn’t but When being sent directly by SendGrid, everything was working fine, because SendGrid makes you create a CNAME record which points to 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 which contains v=spf1 -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 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 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 - 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.



Nice but where do you create the info “The simple solution was to create an SPF record for which contains v=spf1 -all Office 365 and SendGrid IPs.” Since in the DNS there should already have a entry for em2509 (cname) that SendGrid need to have?

We are using SendGrid but have problem sending to others Microsoft Tenant (as we also have a tenant) Microsoft re-route the mail…first time spf pass with our dedicated IP but the message header change after that and now use the Microsoft IP with our SendGrid emxxxx subdomain…spf then fail.

Leave a Comment

Your email address will not be published. Required fields are marked *