
If emails to clients with Outlook.com, Hotmail.com or Live.com addresses bounced between November 6 and November 9, 2026, a Microsoft spam rule update was likely the cause, and Microsoft lists the problem as fixed. In its incident notice, as published on the University of Pennsylvania's Microsoft 365 status page, Microsoft says "a recent update to the spam enforcement rules caused email messages to be incorrectly marked and blocked."
You may have seen the bounce yourself, or a client may have told you an invoice, proposal or booking confirmation never arrived. The Register reported that affected senders got a bounce reading "550 5.7.1 ... message lacks SPF/DKIM/DMARC auth records," with the code AS9031519. SPF, DKIM and DMARC are three DNS records that let a receiving server confirm a message really came from your domain.
Mail that bounced never arrives on its own, so anything important has to be sent again. Then it is worth looking up whether your domain publishes a DMARC record, because senders reported that domains without one were among those rejected, and a basic record takes minutes to add.
Key Takeaways
Its incident notice EX1545193 says a spam enforcement rule update wrongly blocked mail to Outlook.com, Hotmail.com and Live.com from November 6 to November 9, 2026, and lists the service as restored.
A 550 rejection is a permanent failure that is not retried, so re-send every message that mattered.
Microsoft's notice never mentions DMARC; that detail comes from affected senders, and some domains with all three records bounced too.
A TXT entry at _dmarc with v=DMARC1; p=none, plus an rua address you actually read, is the monitoring step Microsoft's FAQ and DMARC.org point to.
It covers senders of more than 5,000 emails a day to Outlook.com addresses and uses a different bounce code, 550 5.7.515.
Find out in ten minutes whether the block touched your mail
Start with what Microsoft published, because it tells you which messages to look for. The notice, numbered EX1545193, covers the Exchange Online service and the sentence "Some users may be intermittently unable to send email messages to Outlook.com, Hotmail.com, or Live.com email addresses." The page marks the status as service restored and was last updated November 10, 2026. The page lists no time zone, so the dates below leave out hours.
How the dates line up
- 1
April 2, 2025
Microsoft publishes its sender requirements for high-volume senders to Outlook.com addresses, updated April 30, 2025.
- 2
November 5, 2026
Born's IT blog reports a separate issue, SPF validation errors, under the code EX1540236.
- 3
November 6 to November 9, 2026
The window Microsoft's notice gives for EX1545193.
- 4
November 9, 2026
The Register reports Outlook.com bouncing legitimate email, and the window in Microsoft's notice ends.
- 5
November 10, 2026
The notice is last updated.
Now check your own mail. The bounce lands in the inbox of whoever sent the message, or in a shared mailbox, so look there first and copy the whole message, including the 550 code, AS9031519, the time and the recipient's domain.

Then search Sent Items, your inbox and any bounce folder from November 5 to November 10, 2026. Look for Outlook.com, Hotmail.com and Live.com addresses and for the text "550 5.7.1".
Microsoft 365 owners can run Message trace in the Exchange admin center under Mail flow to see what happened to a specific message. Google Workspace owners can use Email Log Search in the Admin console.
A bounce that reads 550 5.7.515 is a different rejection. That code belongs to Microsoft's high-volume sender rule, covered further down.
Get the messages that mattered back in front of customers
A 550 rejection is a permanent failure, and the sending server stops trying. As far as the customer is concerned, the invoice or confirmation was never sent. Go through the list of bounces from the ten-minute check and re-send the ones that carried money, dates or a decision.
For a customer who already told you nothing arrived, a short note on the re-send saves a second round of confusion. Something as simple as "This is the message from last week, sent again" is enough.
Before you re-send, make sure your own records are in order. If the DMARC record is missing, add it first using the steps in the next section, then send a test to an Outlook.com address you control once the change has spread. If the test arrives, re-send the real messages.

Add the one DNS record that closes the gap
DMARC is a TXT record that tells receiving servers what to do with mail that claims to come from your domain. Affected senders reported that domains without a DMARC record were among those rejected, and adding a basic record was reported as a workaround. Microsoft's notice itself never mentions DMARC, so treat the record as a sensible step and the notice as the explanation of the incident.
On November 10, 2026, a public DNS lookup on a recently added domain of one of our clients, used as an email alias on Microsoft 365, showed SPF and DKIM set up and no DMARC record. That is the kind of domain the reports describe, and the fix is short.
| Field | Value |
|---|---|
| Type | TXT |
| Host | _dmarc |
| Value | v=DMARC1; p=none; rua=mailto:an-address-you-read@yourdomain.com |
| What p=none means | Collect reports and take no action on mail that fails |
| What rua does | Sends aggregate reports to the address you list |
Log in to wherever your DNS lives, usually your domain registrar or your web host, and add the entry. The DMARC.org FAQ recommends beginning with p=none, collecting the aggregate reports and fixing any legitimate senders before moving to enforcement. RFC 7489 is the standard that defines the record. Point the rua address at a mailbox somebody checks, since reports sent to an address nobody opens help no one.
SPF and DKIM need to be passing for the service that actually sends your mail. DMARC passes when SPF or DKIM passes and lines up with the domain in your From address, so a domain with a DMARC record and a broken SPF or DKIM setup still fails. Microsoft's email authentication troubleshooting page explains what the 550 5.7.1 code means and how the three records relate.
If someone else manages your DNS, send them the record exactly as written in the table and ask them to add it. An email provider, a web host or an IT contractor can do it, and the same person can confirm that SPF and DKIM are passing.

See what Microsoft's 2025 sender rule actually covers
Microsoft's published Outlook.com sender rule is a different event from the November incident. In April 2025, Microsoft published "Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders" on its Tech Community blog, dated April 2, 2025 and updated April 30, 2025. It applies to domains sending more than 5,000 emails per day to Outlook.com consumer addresses, which include hotmail.com and live.com.
Those senders must use SPF, DKIM and DMARC, with DMARC at least p=none and aligned with either SPF or DKIM, preferably both. Microsoft's FAQ adds that while enforcement first targets large senders, "all senders benefit from these best practices." A small business sending a few messages a day sits below that line, and adding DMARC is still a good habit.
| November 2026 incident | April 2025 sender rule | |
|---|---|---|
| Where Microsoft describes it | Incident notice EX1545193 | Tech Community blog post |
| Who it covered | Some users sending to Outlook.com, Hotmail.com and Live.com | Domains sending more than 5,000 emails a day to Outlook.com addresses |
| Cause or requirement | A spam enforcement rule update that wrongly blocked mail | SPF, DKIM and DMARC at p=none or stricter, aligned |
| Bounce code reported | 550 5.7.1, AS9031519 | 550 5.7.515 |
| Status | Service restored | A published requirement for high-volume senders |
When you are ready to go beyond monitoring, Microsoft's FAQ describes moving gradually from none to quarantine to reject. Read the rua reports first, so you know every service that sends as your domain passes before you tighten anything.

Know what a p=none record covers and what stays on your list
A p=none record is a monitoring step. DMARC sits on top of SPF and DKIM and does the checking and reporting around them, so it works only when those two are in place. A valid record does not guarantee inbox placement; it gives you reports and a base to build on.
Some senders reported bounces on domains whose SPF, DKIM and DMARC were already set up, so a missing record is not the whole story of the November window. If that matches you, keep the full bounce, note the time and recipient domain, and report it to Microsoft's Outlook.com sender support. Tenant owners on Microsoft 365 can also read the Service Health history for the incident.
For a separate question, mail that reaches the junk folder instead of bouncing, our guide on why your emails go to spam covers the usual causes. Website forms that send through your domain have their own checks in contact form spam and contact form not sending emails.
Bring in help when several services send as your domain
The first check is yours to run: look up the record, copy the bounce and re-send. Help is worth paying for when several services send as the same domain, such as a CRM, a newsletter tool and a website form, when the SPF record is already long, when you are unsure whether DKIM lines up with your From address, when several domains are involved, or when customers need a record of what arrived.
Those are the cases where one careless DNS change can stop invoices, leads and campaigns at once. A website security audit reviews your authentication records and finds services sending as your domain that you forgot about, and our email marketing work sets up newsletter senders so they pass SPF, DKIM and DMARC from the first campaign.
Check what you took from the Outlook bounces
Pick an answer to begin.
1. What does Microsoft's incident notice EX1545193 give as the cause of the blocked mail?
2. A message you sent bounced with 550 5.7.1 on November 7, 2026. What should you do with it?
3. Which record is the smallest sensible step if your domain has no DMARC record?
Frequently Asked Questions About Outlook Rejecting Emails Without DMARC
Is DMARC now required for every sender to Outlook.com?
Microsoft's published rule covers domains sending more than 5,000 emails a day to Outlook.com addresses, and its FAQ says all senders benefit from the practices. The November 2026 incident notice names a spam enforcement rule update as the cause.
What does AS9031519 mean?
It is the code in the bounce senders reported: "550 5.7.1 ... message lacks SPF/DKIM/DMARC auth records." Copy the full bounce, with the time and recipient domain, before you change anything.
Will Microsoft deliver a bounced message later?
No. A 550 bounce is a permanent failure that your mail system stops retrying, so send the message again once your records are right.
What DMARC record should I add?
A TXT entry at the host _dmarc with the value v=DMARC1; p=none; rua=mailto:an address you read. Start there and move toward quarantine and reject only after reading the reports.
Will a DMARC record put my email in the inbox?
A valid record does not guarantee inbox placement. A p=none record is a monitoring step that shows you who sends as your domain and whether their mail passes.
What if SPF, DKIM and DMARC already pass and my mail still bounced?
Keep the full bounce with the code, time and recipient domain. Run Message trace or Email Log Search for the message, and report it to Microsoft's Outlook.com sender support with those details.
Wrapping Up
The block between November 6 and November 9, 2026, came from a Microsoft spam rule update that Microsoft says it rolled back. The practical steps are short: find the bounces from November 5 to November 10, re-send what mattered, and check whether your domain has a DMARC record, adding the minimum one if it does not. Microsoft's 2025 rule is a separate matter that applies to senders of more than 5,000 emails a day.
A p=none record with an rua address you read gives you a view of every service sending as your domain. It will not put a message in the inbox by itself, and it is a sensible baseline that lets you tighten the policy slowly.
If a mix of senders, domains or DNS hosts makes this feel risky, Web Leveling can look at your records with you. Our website maintenance work keeps DNS entries and third-party senders current as they change, and we tell you plainly when a one-line record is all you need. We work with small and medium businesses across the country and overseas. Tell us what your bounces say, and we will help you read them.
Terms
Email words in this post
Tap a term to see what it means.
SPF. A DNS record listing the servers allowed to send mail for your domain.
DKIM. A digital signature added to outgoing mail that a receiving server checks against a public key in your DNS.
DMARC. A DNS record that tells receiving servers what to do with mail that fails SPF and DKIM checks that line up with your From address, and where to send reports.
p=none. The DMARC policy that monitors and reports without asking receivers to block or quarantine failing mail.
rua. The part of a DMARC record that names the mailbox for aggregate reports.
Bounce. A message from the receiving server saying your email was refused, often with a code such as 550 5.7.1.




