Office 365
Today, Wednesday, October 11th, many senders are reporting trouble (specifically, delayed mail) when attempting to send email to Microsoft-hosted subscribers. Here’s more on the issue from Steve Atkins from Word to the Wise. I’m keeping a close eye on my Office365 admin dashboard to watch for updates on this issue. Microsoft has logged this as “incident EX680695” and those with O365 admin access can go to Home -> Health -> Exchange Online -> Health to see the current status and click on the incident/advisories there to find the latest details. Here’s a direct link to that incident information, which likely only works if you have appropriate access.Many (but not all) senders were impacted, seeing “451 4.7.500 Server busy” delivery delays when sending to email domains hosted by Office 365 / Exchange Online. Many of the senders reporting trouble were located in the EU; suggesting that the issue may be EU-specific, or specific
Florent Destors, Deliverability Manager at Marigold, recently found and shared some very good and timely information related to an increase of mailbox full (over quota) bounces that folks are seeing when sending to Microsoft domains. With his permission (thank you!), I’m sharing his info here:Florent writes:In case you noticed a drop these last weeks on your delivery rates towards Microsoft domains and see an increase in mailbox full bounces received, you should be aware that Microsoft recently changed their cloud storage calculation method.Starting February 1, 2023, cloud storage used across Microsoft 365 apps and services will now include Outlook.com attachments data and OneDrive data. This update may reduce how much cloud storage users have available to use with their OneDrive. If they reach their cloud storage quota, their ability to send and receive emails in Outlook.com will be disrupted.According to Microsoft, the new quota bar should have been gradually rolled
Microsoft recently posted that their Exchange Online servers (which I think also includes Microsoft 365/Office 365, basically any business email cloud-hosted by Microsoft) will soon block mail from old, unpatched Microsoft Exchange servers.Unlike the recent DMARC changes for Microsoft OLC, this likely has no impact to email marketing senders. Few email marketers are using years-old versions of self-hosted Microsoft Exchange for sending email messages.This does likely have a positive impact on the email ecosystem as a whole, though. Setting aside the snark of Microsoft (new, cloud) blocking Microsoft (old, on premise) servers, rejecting mail from servers that are (or could be) engaging in potentially bad acts is a good way to protect users from malware, phishing and spam, and hopefully will also nudge admins of those outdated servers to either upgrade them or shut them down, which will eliminate them as spam and phish vectors, making all of our inboxes
By default, Microsoft 365 handles inbound emails failing DMARC for domains with a DMARC policy of reject the same way as if they had a policy of quarantine. Read more here about how Microsoft 365 handles inbound email that fails DMARC. Administrators can specify an action to be taken on emails classified as “spoof” through configuring an anti-phishing policy; however, none of these actions include rejecting the email with an error code. After all, a domain owner who has gone through the process of deploying a DMARC policy of reject would want to be alerted of emails being rejected. You may also wish to reject emails failing DMARC where your own domain is being spoofed. This can be achieved through the use of an Exchange mail flow rule. An email that failed DMARC where the domain has a reject policy published will be marked in the Authentication-Results headers by Microsoft