Since November 5, Microsoft's consumer mail service has been rejecting some legitimate email sent to Outlook, Hotmail, Live, and MSN addresses. Most of the bounced messages come from domains that do not publish a DMARC record (domain-based message authentication, reporting, and conformance, a DNS entry that tells receiving servers how to treat mail that fails sender checks). The problem sits in Microsoft's filtering. Nothing in the reporting points to an attack or to a compromise of the sending domains. The activity described here was documented by CSO Online.

Microsoft has required DMARC since May 2025, but only from domains that send more than 5,000 messages a day to consumer mailboxes. The current rejections are hitting small, ordinary senders well below that threshold. If your firm runs a modest domain that someone configured years ago, it falls into the group seeing these bounces.

Senders receive Non-Delivery Reports (NDRs) citing 550 5.7.1 or 550 5.7.23 errors, with wording such as "hotmail.com couldn't confirm that your message was sent from a trusted location." The behavior is inconsistent. One user on Microsoft's community forum said some emails go through while others return SPF failures, and some domains with working SPF, DKIM, and DMARC records have also been bounced.

Microsoft has not announced a policy change. It has not published a postmaster notice, a Service Health entry, or an incident ID. A Microsoft external staff moderator described the issue as a "service degradation" under active investigation. The root cause and expected duration remain unconfirmed, and Frank Dickson of Dickson Research said a policy change and a bug may both be in play.

The failure is easy to miss. Your staff see a bounce full of acronyms and may write it off as a glitch, while the recipient never learns a message was sent. Customers, patients, and job applicants use these Microsoft consumer accounts, and when your invoices, password resets, appointment confirmations, or offer letters fail to arrive, they tend to assume they are being ignored. For a business that relies on email to bill, schedule, and hire, those missing messages can stay unnoticed until someone calls to ask why they never heard back.

Business Consequences of Missed and Quarantined Email

The rejected messages bounce back to the sender, so the first cost lands on your business. When an invoice, payment reminder, or account statement fails to reach a customer who uses a Microsoft consumer address, that customer has no prompt to pay. Your receivables slow down, and your staff spend time chasing balances on bills the customer never saw.

The same applies to anything your team sends in response to a customer. Order confirmations, replies to support requests, and price quotes can fail for one customer and arrive for the next. Dickson notes that the recipient reads the silence as being ignored. A patient waiting on an appointment confirmation, or a job applicant waiting on an offer letter, may decide your organization is unresponsive and go elsewhere.

Time-sensitive correspondence carries the highest cost. Law firms, accounting practices, and medical offices send notices that start or close a deadline: engagement letters, filing reminders, document requests, and signature requests. If one of those bounces and nobody acts on the bounce, a deadline can pass while both parties believe the message went out. For a professional practice, that can mean a missed filing, a lapsed offer, or a dispute over whether notice was ever given.

Automated workflows are especially exposed because no person reads their bounces. Your ticketing system's reply emails, your e-signature service's signing notices, your billing platform's receipts, and your website's password reset messages all send without anyone watching the results. Dickson points out that larger organizations often run these from subdomains or third-party platforms that never received a DMARC record. A customer whose password reset never arrives is locked out and calls your help desk, adding support load you may not connect to a mail problem.

The intermittent pattern makes all of this harder to spot. Some messages get through while others fail, and some domains with correctly configured records were reportedly rejected too. MailRoute observed that a sender who receives a bounce "full of acronyms" usually assumes a glitch and moves on. The error text can also name the wrong cause, so even staff who read it closely may draw the wrong conclusion about what failed.

There is also a longer-term security cost. Employees who see a run of authentication errors on ordinary business mail start to treat those warnings as noise. That habit can carry over to quarantine folders and filter warnings on incoming mail, where staff who have watched legitimate messages get blocked may release flagged items without checking them. The habit outlasts the filtering problem, and it makes phishing and business email compromise easier for attackers to land, which are the very attacks email authentication is meant to stop.

Compliance obligations add another layer. Many contracts and regulatory processes treat email as an accepted way to deliver notice, and your sent folder will show a message as sent even when the receiving server rejected it. If a dispute or audit arises, you may need to show which communications actually reached customers during this period, and the bounce records become part of that evidence. Organizations required to confirm account changes or keep customers informed about services also have to account for messages that never arrived. Microsoft has described the issue only as a "service degradation" under investigation, so you have no formal notice from the provider to cite when explaining gaps in your own communications.

How Exchange Online Protection and Defender for Office 365 Misclassify Mail

The bounces reported since November 5 are SMTP-level rejections. Microsoft's receiving servers refuse the message during the delivery conversation and return a Non-Delivery Report citing 550 5.7.1 or 550 5.7.23, so the message never reaches a mailbox or a junk folder. Exchange Online uses 5.7.1 as a general "delivery not authorized" response and 5.7.23 for Sender Policy Framework violations. That second code matches one forum user's report of "SPF failed" errors on some messages and clean delivery on others. The sender holds the only record of the failure, and the recipient's mailbox shows nothing.

Microsoft's filtering stack can stop or remove a message at several points. The source does not say which stage is producing the current rejections, and Outlook.com consumer mailboxes run on Microsoft's own service configuration, separate from the tenant policies that Microsoft 365 business customers manage. The general pipeline looks like this:

• Connection filtering checks the sending IP address against reputation data and allow or block lists before any content is examined.
• Sender authentication evaluates SPF, DKIM, and DMARC alignment. Microsoft folds these results into a composite authentication verdict used to catch domain spoofing, the technique behind much of the phishing tracked under MITRE ATT&CK T1566.
• Anti-spam scoring assigns a Spam Confidence Level (SCL) and a Bulk Complaint Level (BCL), which decide whether a message goes to the inbox, junk, or quarantine.
• Anti-phishing and impersonation detection flags senders that resemble protected users or domains, along with spoofed senders that fail authentication.
• Safe Links and Safe Attachments (Defender for Office 365) rewrite URLs and detonate attachments in a sandbox, which can delay or block delivery.
• Zero-hour Auto Purge (ZAP) removes messages already delivered when a later verdict reclassifies them.

All of these stages run on shared infrastructure. A changed detection rule, a revised authentication threshold, or a retrained classification model takes effect for every mailbox the service filters, so a single faulty change produces false positives across many unrelated senders at once. For a business sending to customers at Microsoft consumer addresses, the effect looks like scattered delivery problems with no change on its own side.

The cause has not been confirmed. A Microsoft external staff moderator described the problem as a "service degradation" under active investigation, and Frank Dickson of Dickson Research suggested that a policy change and a bug may both be involved. The following is speculation. The inconsistent results, where identical senders see some messages accepted and others refused, fit a change being rolled out unevenly across Microsoft's front-end servers. Reports of bounces from domains with working SPF, DKIM, and DMARC point toward a defect in how authentication results are evaluated, beyond a simple tightening of the requirement.

For messages that do get delivered or quarantined, Microsoft records its filtering decision in the message headers. The X-Forefront-Antispam-Report header carries several values that show why a message was classified the way it was:

• SFV is the spam filtering verdict, showing whether the message was scored as spam, not spam, or skipped filtering because of an allow rule.
• SCL is the numeric spam confidence score behind that verdict.
• CAT names the protection category that applied, such as spam, bulk, phishing, high-confidence phishing, or spoofing.

The X-Microsoft-Antispam header records the BCL value, and the Authentication-Results header lists the SPF, DKIM, and DMARC outcomes along with Microsoft's composite authentication result. A message with valid authentication results paired with a spoof or phishing CAT value indicates the filter misread a legitimate sender. Messages rejected at the SMTP stage never generate these headers, so in the current incident the bounce text and its status code are the only diagnostic data available to the sending organization.

Identifying, Releasing, and Preventing Blocked Legitimate Email in Microsoft 365

Your first action is to confirm whether each domain that sends mail as your organization publishes a DMARC record. MailRoute recommends running dig +short TXT _dmarc.example.com from any terminal, replacing example.com with your domain. A reply beginning with v=DMARC1 means a record exists. An empty reply means it does not, and mail from that domain is exposed to these rejections.

Run the check against secondary domains, regional domains, and the subdomains your marketing and billing platforms send from. Dickson notes these are the records larger organizations most often miss, usually because no one owns DNS and staff fear breaking third-party mail.

Next, find the messages that already failed. Every rejection produced a bounce, so the evidence sits with you as the sender. Search mail logs, your email platform's bounce reports, and help desk tickets for entries citing "Message lacks SPF/DKIM/DMARC" since November 5. In Microsoft 365, Message Trace in the Exchange admin center lets you search outbound mail addressed to outlook.com, hotmail.com, live.com, and msn.com recipients and list the failed deliveries. Resend time-sensitive transactional mail first, such as invoices, password resets, and appointment confirmations.

Check Service Health in the Microsoft 365 admin center for updates. As of the source's reporting, Microsoft had posted no service-health entry or postmaster notice, so an empty dashboard does not mean you are unaffected.

The inbound tools in the Microsoft Defender portal (the quarantine at security.microsoft.com/quarantine, the Submissions page, zero-hour auto purge, and the Tenant Allow/Block List) govern mail arriving at your tenant. They cannot deliver a message that Microsoft's consumer servers refused. Review quarantine if users report missing inbound mail over the same period, and have an administrator confirm each message before release. Tell users that missing mail may be held there and that they should not release unfamiliar messages themselves. Avoid broad transport-rule bypasses or blanket domain allows. They do nothing for outbound delivery and they remove the filtering that stops spoofed and phishing mail aimed at your staff.

Once you have triaged the backlog, fix the cause with these steps:

• Publish a monitoring record where one is missing: v=DMARC1; p=none. This declares DMARC use and requests reports while telling receivers to take no action on failures. Dickson says it stops these bounces as long as SPF or DKIM aligns with the From domain.
• Turn on DKIM for your own domains in Microsoft 365 if you never enabled it. This gives DMARC a signed, aligned result to check.
• Leave SPF alone unless you find an actual error. Dickson advises against rewriting SPF just because the bounce blames it.
• Escalate clean failures. If your records check out and mail still bounces, send the full bounce to Microsoft so it becomes part of the investigation.

Document which business processes were affected and contact customers, partners, and applicants who may have received nothing from you since November 5. They will not know a message was attempted unless someone tells them.

For the longer term, build a list of every service that sends email as you, including the CRM, billing system, HR platform, and marketing tools. Dickson observes that most organizations cannot produce this list. With it in hand, you can move from p=none to p=reject, which tells receivers to refuse anyone forging your domain.

Set an alert for unusual spikes in outbound non-delivery reports, and review quarantine notification policies so users learn when inbound mail is held. Write a short runbook for vendor-side filtering incidents that names who checks DNS records, who searches bounce logs, who contacts the provider, and who notifies affected customers.

Balancing Email Filtering Accuracy Against Phishing Risk

The bounces that began on November 5 trace back to Microsoft's own filtering, which a Microsoft external staff moderator described as a "service degradation" under active investigation. No attacker took over your domain, and no message content was altered in transit. Your sending systems behaved as configured, and the rejections came from the receiving side.

The risk you carry forward comes from the workarounds. When staff are pressed to get invoices, password resets, and offer letters delivered, they tend to add allow entries, create mail flow rules that skip authentication checks, or release quarantined messages in bulk without reviewing each one. Those changes stay in place after Microsoft corrects the filtering. An allow entry for a sender domain also trusts anyone who spoofs that domain, which is the impersonation pattern Dickson links to phishing and business email compromise. A loosened SPF record, edited because a bounce message blamed SPF, can authorize sending servers your organization does not control.

The single most important action, once Microsoft confirms the fix, is to review and remove every temporary allow entry or bypass rule your team created during the incident. That returns your filtering to the state you had tested and approved before November 5.

The longer-term direction is clear. Google and Yahoo began requiring DMARC from bulk senders in February 2024, Microsoft followed in May 2025, and Dickson expects enforcement to extend to every sender. Your domains will eventually need to move from p=none to p=reject, which instructs receivers to refuse mail that forges your name.

If you are unsure which of your domains and third-party senders meet these requirements, or which exceptions were added while mail was bouncing, ask whoever manages your email to check both against the steps above before stricter enforcement takes effect. Our security assessment is a 15-minute call, then written findings on five areas: dark web exposure, phishing risk, security controls, remote access and employee training readiness.