Forwarding of calendar appointments from a DMARC projected domain fail when using Office 365
When receiving a calendar appointment from a DMARC protected domain (domain1) and forwarding this appointment to another domain through domain2 this results in an NDR.
550 5.7.23 The message was rejected because of Sender Policy Framework violation -> 550 5.7.1 rejected by DMARC policy for <domain>
The forwarding adds a Sender header so the message is send as <domain2> on behalf of <domain1>.
But uses the authentication (SPF+DKIM) of domain2 to send as domain1.
This violates the DMARC specification as the message now originates from domain2 but the From address (which is used by DMARC) is stil set on domain1.
Rein Heringa commented
This also happens when you have multiple accepted domains in your Office 365 tenant and have a PA with a primary email address of PA@DomainA.com and a Manager with a primary email address of Manager@DomainB.com.
Now, when the PA sends an invite on behalf of the manager to an external recipient, the FROM address will be Manager@DomainB.com, while SPF and DKIM authenticate DomainA.com. The same thing happens with updates to invites etc.
Office 365 does include ARC-Authentication-Results header, but unfortunately it seems not all major ESPs respect these ARC results yet, e.g. Google hosted domains.
Suggested fix: If both domains are in the same tenant, include an additional DKIM signature for the domain in the FROM header field.
Nate Adar commented
Yes we are having the same issue. We documented it as well and it is the same issue but we worded it differently:
Picture a 3-company scenario. Person from company A sends a meeting request to someone at company B. The person at Company B uses Outlook/O365 and ropes in another person at Company C by forwarding the meeting invite. That invite will be sent with the originator's address as the Sender. This hasn’t been an issue in the past 20+ years, but with more and more companies doing anti-spoof enforcement (i.e. Company A sets up DMARC to p=reject), this means the message is going to be blocked due to Sender B spoofing Sender A when forwarding the Invite to person at company C.
1.This bug only happens with calendar invites, not regular emails
2.This bug only happens if the calendar invite is forwarded by an O365/Outlook user
2a.If the original sender of the invite has DMARC protection the forwarded invite will be blocked or rejected with a bounce back by an external recipient – this is when the end user might notice the bug because their email is not being delivered.
3.This bug only happens when O365 uses Outlook desktop client or OWA. It does not happen when user uses Outlook iOS or Android mobile apps.
The default forwarding button in Outlook and in OWA to not send as the Original meeting creator. The forwarded meeting invite should come from the forwarder, just like it is done with regular email forwarding.
Seems like basic functionality...
Andrew Grant commented
Also broken for one of my users. 6/20/2019
Had this occur for a user today. Still broken as of 5/2/2019.