An update on the forwarding email problem in Office 365


Well over a year ago, I wrote the following blog post: Why does my email from Facebook, that I forward from my outlook.com account, get rejected?

It's a very popular blog post, it gets more comment than almost any other post that I have written. The overwhelming majority of comments asks the question: "When will this be fixed?"

Now, I can't comment on these types of things for two reasons:

  1. We have hit problems many times when deploying this fix, so any time I would have announced something on this blog would have required a subsequent update
    .
  2. I am not allowed to make public comments re: timelines for features and fixes that haven't been announced publicly on a feature roadmap that Microsoft has officially announced

We have had an internal timeline, however, and I've been tracking it closely.

But now, I have an update:

  1. In Office 365, we've deployed a fix such that if you use Exchange Transport Rules (ETRs) to forward or redirect a message to another destination mailbox, the original message format will be retained. This means that a forwarded or redirected message will retain its original DKIM signature and pass DKIM at the forwarded-to destination.I have personally tested this and can confirm that it works.
    .
    The more geeky explanation is that as long as the message has not yet undergone MIME-to-MAPI conversion, it will not have the message format modified such that DKIM breaks. So, there are other code paths that this works such as distribution lists (I've tested that, too). But I haven't tested everything, so I can't say what all works and what doesn't. I just know that ETRs that forward and redirect are the most common features where this breaks, and those seem to work okay at least when I try it.
    .
    .
  2. However, mailbox forwarding does not work - neither in Office 365 nor in Outlook.com. This means that if you have a mailbox rule that redirects to another mailbox, or you use the Mail settings > Options > Mail > Accounts > Forwarding, the original DKIM signature will be broken.
    .
    A workaround for this is to use mailbox rules to forward (I know, it's kind of confusing... sorry). Go into Mail settings (gear icon at the top right corner of Outlook.com web interface) > Options > Mail > Automatic processing > Inbox and sweep rules. Once there, create a rule to forward (not redirect) a message to another destination.

    Per the geeky explanation above, what's happening here is that the message hits the mailbox and therefore has undergone MIME-to-MAPI conversion, and then when forwarded it does MAPI-to-MIME. But this reconstructed message is not the same as the original.We still have to fix this part.

That's all for now.


Comments (8)

  1. Pretty interesting update on that particular subject. Thanks for sharing.

  2. Well, that’s very good news!

  3. Rick says:

    So I guess that might explain a problem that inexplicably developed sometime last year (though it wasn’t a problem more than a year or so ago). I have O365 sending its reports (MailTraffic, SpamDetections, etc) to my O365 account, but I have that account forwarding to Hotmail. *That arrangement works for all mail*, it seems, except O365’s reports, ironically enough. One would think that Microsoft->Microsoft would be a slam-dunk, but no.

    What happens instead is that I receive an “Undeliverable” report:

    SNT004-MC9F17.hotmail.com rejected your message to the following email addresses:
    xxxxxxx@hotmail.com
    Your message wasn’t delivered because the recipient’s email provider rejected it.
    SNT004-MC9F17.hotmail.com gave this error:
    (SNT004-MC9F17) Unfortunately, messages from (104.47.37.115) on behalf of (microsoft.com) could not be delivered due to domain owner policy restrictions.

    This is followed by the complete header. And the actual email is attached, at least allowing me to read it.

    The domain name (e.g. SNT004-MC5F10) and IP (e.g. 104.47.33.130) vary from message to message.

  4. Sebastian Young says:

    Hi Terry

    Firstly, the update is very much appreciated. I think there’s a reason why your original post has received more comments than any other. This is a MASSIVE problem for DMARC p=reject senders and a MASSIVE problems for your (probably largely unaware) customers. It is troubling that a company with the resources of Microsoft can’t fix this in well over a year. To me, that says it’s not considered important internally, because to me it’s a serious enough problem that it’s got to the point where it seems unreasonable now be saying there have been issues with all fixes to date. But of course this is just the feeling I get, and I hope I am wrong.

    Anyhow, I for one am grateful for the update and partial fix, and will continue to hope for the remainder to be fixed.

  5. Mapi Dude says:

    Do you know when this change was made? Starting June 1st, we started seeing a increase of SMTP errors on our list server: 552: 5.6.0 Headers too large (32768 max)

    Our list server is a connector in Office 365. Would this change, or any other change by MS caused additional headers?

  6. Garry Martin says:

    So is there not a “use ETRs to forward all email for this account to this mailbox, but keep a copy in Hotmail too” option we can select in Hotmail? So the messages get forwarded before hitting the mailbox? Or can one not be provided whilst you spend more time working on a fix for us?

    1. tzink says:

      The closest is to use mailbox forwarding rules, Options > Mail > Automatic processing > Inbox and sweep rules.

      This acts more like a “classic Forward”, that is, hitting “Forward” in your email client and attaching the message to a new one. The forwarding option that doesn’t yet work is more like a redirect. So, the terms “forward” and “redirect” are overloaded:

      – ETRs that forward or redirect behave as a redirect -> This should work
      – The mailbox setting that forwards behaves as a redirect -> This does not work
      – Mailbox inbox rules that forward or redirect behave as a forward -> This should work but looks like a forwarded message at the final destination

  7. Nick says:

    We’ve got an issue with relaying outbound mail through Exchange Online Protection as it is modifying the body of all emails sent with attachments and therefore breaking DKIM. Would it be possible to send you details of this T Zink?

Skip to main content