Microsoft has rolled back a spam-filter update that incorrectly rejected legitimate messages sent to some Outlook consumer accounts, according to Windows Latest. Mail flow has reportedly been restored, but there is an important catch: messages rejected during the incident will not simply appear in your inbox now that the fix is in place.

For anyone waiting on an invoice, account verification email, or reply from a customer, the practical next step is to identify missing correspondence and arrange a fresh send. Changing Outlook settings or rebuilding your Windows mail profile is not the remedy for this particular incident.

What Microsoft confirmed

In a November 12, 2026 report, Windows Latest journalist Mayank Parmar says Microsoft confirmed that an update to its spam rules had blocked legitimate email. Microsoft told the publication it had rolled back that update and restored mail flow, while continuing to monitor delivery.

The report identifies rejected messages involving Outlook.com, Hotmail.com, Live.com, and MSN.com addresses. Microsoft's quoted statement specifically mentions Outlook.com, Hotmail, and Live. The article also references incident EX1545193 in the admin center.

Windows Latest observed failures dating back to at least November 5 and says readers reported earlier problems. Parmar reports that mail flow was restored on November 9 at 12:02 CET. Those observations should not be treated as a definitive outage window for every affected account: the article does not establish how many users were impacted or exactly when each mailbox started experiencing failures.

This is a report about delivery to Microsoft's consumer email services, not evidence that every installation of the Outlook desktop application or every Microsoft 365 business mailbox was affected.

Why the authentication error was misleading

Some senders received this rejection:

550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)
That wording naturally directs attention toward the sender's email authentication configuration. SPF identifies authorized sending systems, DKIM provides a cryptographic signature for messages, and DMARC uses authentication and domain alignment to guide handling of mail claiming to come from a domain.

However, Windows Latest reports that some senders with valid authentication records were affected too. Microsoft told the publication that senders do not need to change SPF, DKIM, or DMARC records because of this incident.

The distinction matters for administrators. An error message is a diagnostic clue, not conclusive proof that DNS needs changing. Keep legitimate authentication protections in place and investigate current failures using fresh evidence rather than weakening domain security to work around a resolved filtering mistake.

Why missing messages will not return automatically

A rejected message is different from a delivered message that was filed into Junk. According to the report, the affected rejected messages never reached the recipient's mailbox, so Microsoft cannot restore those copies for the recipient.

Searching additional folders, switching between new and classic Outlook, or rebuilding the local search index cannot retrieve a message the service never accepted. The sender may still have the original in Sent Items or in the application that generated it, but a new delivery attempt is needed.

This does not mean every email you cannot find was rejected by this incident. Normal filtering, inbox rules, addressing mistakes, and unrelated delivery problems remain possible. Checking Junk and other folders is still useful when diagnosing an individual missing message; it just cannot recover a confirmed rejection.

What Outlook users should do now

Start with correspondence that has a deadline or financial consequence, rather than asking every contact to resend everything.

- Review expected messages. Check pending purchases, appointments, invoices, support cases, and conversations that unexpectedly went quiet.
- Contact the sender through a known channel. Ask whether they received a delivery failure and request a resend of the specific message.
- Generate fresh verification emails. For account activation or password-reset messages, use the service's official website to request a new link rather than relying on an older, potentially expired one.
- Confirm the replacement arrived. For important exchanges, acknowledge receipt so both sides know communication is working again.

Be cautious about unsolicited messages claiming to recover blocked email. This incident does not require handing over your password, installing remote-access software, or paying someone to restore rejected messages.

A focused checklist for IT and support teams

If your organization sends mail to affected consumer addresses, review delivery failures from the suspected period. Look for the reported rejection code, retain timestamps and recipient information, and distinguish permanently rejected messages from mail that your platform still has queued for retry.

Before resending business notifications in bulk, check whether a later attempt already succeeded. Duplicate invoices, order confirmations, or account alerts can create their own support workload. Where an application has marked an address as undeliverable, follow that platform's normal review process before retrying a legitimate recipient.

For delivery problems that continue after the reported restoration, collect a fresh non-delivery report and relevant sending-system logs or message traces, where available. Windows Latest advises reporting continuing problems to Microsoft with trace information. Consumer recipients may need the sender's administrator or email provider to supply that evidence.

The priority is straightforward: restore the conversation, not the Outlook installation. Microsoft's rollback addresses the filtering fault described in the report; recovering the missed exchange still depends on identifying the message and getting it sent again.

Source: Windows Latest reporting by Mayank Parmar, published November 12, 2026.