This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(256, 51%, 34%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EFV%3C/text%3E%3C/svg%3E)
Hi there,
one of our customers is complaining he can't forward meeting requests to several of his private domains.
I think this is occurring since the emergency patches on Exchange 2016 CU19, have updated to CU20 now but the issue persists.
To be clear, if he forwards e-mails there are no issues. Everything is nicely rewritten to his address as sender.
However, if he forwards a meeting, most headers are rewritten, but the 'From' header still lists the original sender. This happens both from Outlook & OWA.
If the original sender has a strict DMARC policy (reject) and the address forwarded to adheres to it, it will reject the forwarded meeting request because of this.
Return-Path, Sender headers point to the address it was forwarded from.
From header is still set to original sender.
DKIM will pass, DMARC will fail.
Authentication-Results: xyz, dmarc=fail (p=reject dis=none) header.from=original-sender-domain.tld
Authentication-Results: mail.receiving-the-forward-message.tld;
dkim=pass (2048-bit key) header.d=forwarded-by-domain.tld header.i=@forwarded-by-domain.tld header.b=IDxyzzzz;
dkim-atps=neutral
Any ideas what might be causing this?
Hi,
thanks for the reply.
1) Well yes, but no as well. It's related to DMARC/DKIM. So if user@external.com sends an e-mail or meeting to user@rayn .com and user@rayn .com clicks forward and sends it to user@Stuff .com what happens for e-mail is that the from from is rewritten to user@rayn .com and the outgoing server should obviously adhere to DKIM/DMARC. For meeting however the from is not rewritten and remains on user@external.com. If DMARC for external.com then has a reject policy and forwarded-to-receiver (like gmail.com) checks DMARC the message will be refused as local.com can't DKIM sign for external.com nor will it be listed in SPF for external.com.
So yes, it's specific as in not all domains have DMARC reject policy and not all receivers check it, but if both are true it will happen for all of them.
2) Yes you will receive NDR if the receiver sends reject messages for DMARC. This is where it gets really annoying, gmail for example will nicely send a reject message for this. A lot of mail servers however accept the message, but then quarantaine or discard the message silently. This is very receiver configuration specific of course.
The NDR gmail returns:
user@Stuff .com
[IPv6]
Remote Server returned '554 5.0.0 <[IPv6] #5.0.0 smtp; 550-5.7.26 Unauthenticated email from original-sender.com is not accepted due to 550-5.7.26 domain's DMARC policy. Please contact the administrator of 550-5.7.26 original-sender.com domain if this was a legitimate mail. Please visit 550-5.7.26 https://support.google.com/mail/answer/2451690 to learn about the 550 5.7.26 DMARC initiative. SOME-ID.269 - gsmtp>'
Note this also tells you to talk to the administrator of original-sender.com, but they can't do much about a user on another domain forwarding the meeting (works fine for e-mail thus as from is correctly rewritten).
To be more precise, gmail doesn't really send NDR, they refuse the message in transit.
So the sending server actually sends it, not being able to deliver. Many spamfilters seem to check later on or accept first and then handle it silently later on.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(284.8, 17%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EYS%3C/text%3E%3C/svg%3E)
Hi @Ferry van Steen ,
Thanks for the clarification! I tried to test in my lab and can also got the NDR when forwarding a meeting request to gmail:
To the best of my knowledge, this is an expected behaior when the recirpient domains have a strict DMARC policy. And based on my research, I am afraid there is no solution in these situations. Given this, as an alternative, you could educate the users to send the meeting request as an attachment instead when trying to forword it to these particular external domains.
If an Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Hi Yuki,
thanks for confirming.
If this is the default behavior however I think Microsoft should change the code so it rewrites from properly on meetings as well.
Considering this is error prone, breaks DKIM and it doesn't do it on e-mails, for obvious reasons, why do it on meetings? Doesn't make much sense to me.
Have no clue where to request that however, do you?
In any case, much obliged :)
Hi @Ferry van Steen ,
Per my understanding, unlike forwarded emails, forwarded meeting request shows "send on behalf of <original meeting organizer>" and thus the From header still shows the original sender might due to the consideration that in this way, the meeting organier can receive a meeting forward notification and in the meantime be able to track the additional recipients at his end.
For instance, in my test mentioned above, Administrator(the original meeting organier) sends a meeting request to User1, User1 forwards the meeting to User2 and two external users(one outlook.com account and a gmail account), then Administrator will receive a notification that User1 has forwarded the meeting to the additonal recipients, these recipients will be automatically added to the attendees list:
Well, maybe at some point in time it had good reasons.
These days you are not allowed to send mail under domains you don't own/granted access for - and for good reason. That is if the admins set up DKIM/SPF/DMARC properly anyways.
If that means it breaks other stuff that will need to be fixed by adding an additional header with the original meeting sender name for example, but it can't remain to be as it is and be compliant with current anti-spam technology.
Thanks for your research, it's much appreciated.
Hi @Ferry van Steen ,
Personally I do agree with you on that ideally the normally forwarded meeting requests or messages sent using "send on behalf" permission should automatically bypass the DKIM/SPF/DMARC policy, but I am assuming that it might be difficult to figure out a perfect way on the technical level.
So currently, to some extent, we may have to balance between email security and false positive. In your case, I'd recommend telling your customers to use the "Forward as attachment" option instead when they find a centain domain cannot receive a normally forwarded meeting request.
Hi @Ferry van Steen ,
However, if he forwards a meeting, most headers are rewritten, but the 'From' header still lists the original sender.
I tried to test in several different versions of Exchange(Exchange 2016, Exchange 2019 and Exchange Online), it seems to me that it's an expected behavior that the From field remains as the original sender when a meeting request is forwarded.
Let's say a meeting was sent from Administrator to User1, then User1 forwarded the meeting request to User2(in the same domain) and an external user. When I checked the message headers of the meeting request received by User2 and the external user, the From field still shows as Administrator who is the original sender, the return-path and the sender field is shown as User1:
As per your concern about this doesn't occur when a normal message is forwarded, based on my test, this could be related to the difference that when we receive a forwarded meeting request, it displays as "<actual sender> on behalf of <original sender>", but in a forwarded mail, it only shows the actual sender.
That being said, regarding the issue described in the original post, could you help collect the information below for further troubleshooting:
If an Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.