Update on Jan 25, 2017 - Still no timeline on a fix for this, we have repeatedly hit issues. 🙁
Update on June 23, 2017 - See An update on the forwarding email problem in Office 365
Update on Nov 3, 2017 - See A second update on the problem of email forwarding in Office 365
Why is my (your) email bouncing when I (you) forward it?
Recently, many people have been asking me why their email from Facebook, that they forward from their outlook.com or Hotmail account to another account, bounces after they forward it? That is:
Facebook -> outlook.com (forward) -> Hotmail/Yahoo/Gmail -> bounces back
Why does this happen? How can you fix it?
It's because of the way we are migrating accounts, plus some older behavior designed to protect the mailbox
A few months ago we announced that Hotmail/outlook.com accounts were being migrated to Exchange Online (EOP). This is not an instantaneous process, it takes a long time to move all of those accounts over and we are not complete. But, this issue of bounced email that is forwarded only happens if your account has been migrated. A migrated account first goes through the old Hotmail infrastructure and then lands in the Exchange Online environment where it re-uses the spam filter verdict that the old Hotmail infrastructure stamped .
Exchange server has a feature wherein it "fixes up" content in a message. This has been around for many years and it's to prevent malformatted data from going into your mailbox where it could cause a corruption problem. So, if messages arrive in a certain way, it converts it to a format it does expect. For example:
Before being fixed: Joe Sender <email@example.com>
After being fixed: "Joe Sender" <firstname.lastname@example.org>
There are good reasons for doing this, especially in enterprise environments, that I won't get into here. To a human, the message looks identical. But the problem with doing this is that if a message has a DKIM signature, then fixing up the message will break the DKIM signature - even doing something as small as adding quotes around the Display Name breaks the existing DKIM-Signature.
Normally this isn't a problem because Exchange Online verifies SPF, DKIM, and DMARC and stamps the results in the Authentication-Results header . But if the message is forwarded to another mailbox who reverifies the message, it won't pass SPF (because the IP address of the forwarder won't be in the original sender's SPF record ), it won't pass DKIM because the message headers and body have changed slightly and the hash doesn't verify, and therefore it can't pass DMARC since the From: domain won't align with either the domain that passed DKIM or SPF.
Non-migrated Hotmail/outlook.com account
Migrated Hotmail/outlook.com account
This wouldn't normally be a problem except when it comes from domains that publish a DMARC record with p=reject or p=quarantine. Most email doesn't but there are a few large senders that do including Facebook (facebookmail.com), LinkedIn, Yahoo, AOL, and soon-to-be Gmail. Since they don't align with SPF/DKIM/DMARC, messages from those domains will bounce if you forward them because they fail DMARC.
So what can I (you) do?
The good news is that we are fixing this - that is, we are fixing the "fixing up of messages." We are introducing a change in Exchange Online that will stop modifying the contents of messages when they are forwarded out of the system. SPF will still fail, but DKIM will pass. This means that you'll be able to forward email to your heart's content and it will pass DMARC just fine.
I don't have a timeline on this because we've tested this before and had to pull it back because we found problems. But hopefully over the next few weeks this fix will go out worldwide and then this will no longer be a problem.
We ask that you sit tight until then.
 For a migrated mailbox, Hotmail/outlook.com does its authentication checks and stamps the result in the Authentication-Results header. When the message is sent to EOP, it does its own authentication checks and stamps the result, but they are not used. Instead, Hotmail/outlook.com pushes its authentication checks into its spam/non-spam verdict which EOP re-uses.
 Some systems rewrite the 5321 MailFrom so that it does pass SPF, e.g.,
Original SMTP MAIL FROM: <email@example.com>
Original SMTP RCPT TO: <firstname.lastname@example.org>
Forwarded SMTP MAIL FROM: <email@example.com>
Forwarded SMTP RCPT TO: <firstname.lastname@example.org>
This does pass SPF at the forwarded-to receiver, but since the domain in the SMTP MAIL FROM does not match the From: address - which is not rewritten - it still fails DMARC.