Microsoft 365 Outage EX1550543: What Deferred Email Means for Senders

From about 17:30 UTC on November 12, 2026, sending services saw mail to Outlook.com and Microsoft 365 addresses pile up in their queues. Microsoft’s servers were not rejecting it. They were answering with temporary replies, and we found no Microsoft documentation that explains those replies for this case.

A deferred message is not a lost one: the sending server holds it and tries again. The exceptions are a queue that gives up before Microsoft recovers, and mail that expires on its own, such as a one-time passcode. How soon a queue gives up depends on what sends your mail. Among the systems that document a default, the retry windows run from 8 hours to 5 days.

It is the opposite failure from the AS9031519 bounces a week earlier, and the advice is the opposite too.

Is the Microsoft outage over?

Not at Microsoft’s most recent update. Posted under MO1550821 on November 13, 2026, 09:57 UTC, it keeps the status at “Service degradation” and reports “incremental improvement in several workloads”, while “service health remains variable and capacity has not yet fully returned to baseline”. It gives no time for full recovery.

Its updates on November 13 say Microsoft is “not aware of any malicious activity that is causing this incident”, and promise a Post-Incident Report with the root cause.

Microsoft posts a public summary on its service health status page. Microsoft 365 admins get every update in the admin center under Health > Service health: EX1550543 covers Exchange Online, and MO1550821 the other services that depend on it. We quote the updates from the Cloud Admin Hub mirror of that feed, which is readable without an admin account.

What did Microsoft’s servers tell senders?

SparkPost, an email delivery service, published three of the replies its systems were getting from Microsoft on November 12, 2026, 20:01 UTC. Its post says “The errors include” these, so the list may not be complete. It dated the start to “about 17:30 UTC on November 12” and named the affected destinations: Outlook.com, Hotmail, Live, MSN and Office 365.

451 4.7.0 Temporary server error
421 4.3.2 The maximum number of concurrent server connections has exceeded a limit
451 4.7.700 PFA agent busy

All three start with a 4, and that digit is the part that matters. Under RFC 5321 §4.2.1, a 4yz reply means “the error condition is temporary, and the action may be requested again”, and the sending server “SHOULD try again”. None of the five sending services whose status pages we read reported a permanent 5xx rejection from this incident.

The rest of each reply says less than you would hope:

• 451 4.7.0 Temporary server error. RFC 3463 §3.8 defines X.7.0 as “Other or undefined security status”, a catch-all. We found this text once in Microsoft’s documentation, with a PRX5 suffix, in an article about hybrid mail flow. That article does not explain the reply for this incident.
• 421 4.3.2 The maximum number of concurrent server connections has exceeded a limit. RFC 3463 §3.4 defines X.3.2 as “System not accepting network messages” and gives “excessive load” as an example. That fits Microsoft’s own account: at 19:18 UTC on November 12 it reported “a large number of servers being unexpectedly unavailable, which is shifting load onto the remaining infrastructure”. A 421 also closes the connection (RFC 5321 §4.2.3), so the sender has to reconnect before it retries.
• 451 4.7.700 PFA agent busy. We found neither the 4.7.700 code nor the term “PFA” in Microsoft’s documentation, and we will not guess at either. Read the reply by its first digit: temporary.

SparkPost quoted the reply text without host names or trailing detail, so the same reply in your own log may be longer.

Is email sent during the outage lost?

Email sent to Microsoft during the outage is not lost while it is deferred. A deferred message stays in the sender’s queue, and the sender keeps retrying until Microsoft accepts it or the sender’s own time limit runs out. Only the second outcome loses mail. If your sending dashboard shows an email as queued, delayed or deferred, this is the state it is in.

The sending services said so while it was happening:

• SparkPost: “Affected messages are not lost.”
• Mailgun, at 22:38 UTC: “Messages are deferred and there is no mail loss at this time.”
• beehiiv, at 21:51 UTC: “No mail has been lost but delivery may be delayed”.

By 04:45 UTC on November 13, SparkPost still saw “about three in four delivery attempts to Microsoft” deferred, and added that “Most mail is still getting through, but more slowly than usual.” That is one provider’s traffic, not a global rate. Those statements describe mail that was still queued when they were written, and Microsoft has not said whether any mail was lost.

Microsoft’s first statement on the backlog came in its update of November 13, 09:03 UTC: “we are extending the email timeout window to 48 hours to help protect delayed messages while service recovery continues”. Microsoft does not define that window. Our reading is that it covers mail held inside Exchange Online, whose documented retry period is 24 hours. It cannot lengthen a queue on someone else’s sending system.

Delay becomes loss when the retry window closes. RFC 5321 §4.5.4.1 says a sender’s give-up time “generally needs to be at least 4-5 days”. Many sending systems stop sooner. By Microsoft’s update of November 13, 09:57 UTC, the default windows for Mailgun, Postmark and Resend had already ended for mail first deferred at 17:30 UTC on November 12, so a message still undelivered through one of them comes back as a bounce or a failure event.

Read the table with its limits in mind. It lists only systems whose documentation states a figure; we found none for Google Workspace or Amazon SES. The figures are defaults, and several can be changed. Exim counts continuous failure for the recipient address, not the age of one message, and Postmark says some domains differ. A window matters only for a message that failed every retry in it.

Mail with a short life of its own is useless long before any window closes. SparkPost told customers that messages with a short expiration, such as one-time passcodes, “may expire before Microsoft recovers”, and Resend said some mail may bounce if the outage outlasts its retry window.

What should senders do now?

Six steps, in order.

1. Do not resend mail that has not bounced. If your sending system queues and retries, as every system in the table above does, the message is still in its queue. SparkPost’s warning to its customers holds for any of them: “Resending creates duplicates once the queued mail goes through.”

2. Find what expired. A message that outlived its retry window comes back as a bounce or an “expired” event. On a sending platform, filter events for bounces to Microsoft-hosted recipients since 17:30 UTC on November 12. Not sure whether a recipient is on Microsoft? Look at the domain’s MX record: a host under mail.protection.outlook.com or mx.microsoft is Microsoft 365, one under olc.protection.outlook.com is Outlook.com, Hotmail, Live or MSN, and the MX lookup shows either. On Postfix, the logs hold both sides:

   Find deferred and expired mail in Postfix logs bash

   # Postfix: mail that Microsoft's servers deferred, from current and rotated
   # logs. Debian/Ubuntu log to /var/log/mail.log; RHEL-family to /var/log/maillog.
   
   # 1. Recipients a Microsoft host deferred, with the reply and how many times.
   zgrep -hE 'status=deferred .*(protection\.outlook\.com|mx\.microsoft)' /var/log/mail.log* \
     | sed -E 's/.*to=<([^>]+)>.*said: ([0-9]{3} [0-9.]+ [^(]*[^( ]) *\(.*/\1  \2/' \
     | sort | uniq -c | sort -rn
   
   # 2. Messages that outlived the queue lifetime and went back to the sender.
   #    No output means nothing has expired.
   zgrep -hE 'status=expired, returned to sender' /var/log/mail.log*

   With Postfix’s default queue lifetime of 5 days, the second command should print nothing unless that default was lowered.

3. Resend only expired messages that still matter, and only once Microsoft is accepting mail again. Invoices and replies people are waiting for come first.

4. Reissue anything time-bound instead of resending it. A passcode or a password-reset link sent during the outage has expired by the time it lands. Send a fresh one.

5. Check your suppression list. Some sending platforms stop mailing an address after a bounce. If yours does, look for Microsoft-hosted addresses added since November 12 and remove the ones that are there only because a message expired. No provider has said it suppressed addresses over this incident, so treat it as a check, not a finding.

6. Leave SPF, DKIM and DMARC alone. Microsoft’s updates describe lost server capacity and a patch to one of its own authentication/routing components. They never mention SPF (RFC 7208), DKIM (RFC 6376) or DMARC (RFC 9989), and no DNS change would have delivered a deferred message. Nothing in the updates touches Microsoft’s bulk-sender rule either. If you edited a record in a hurry, the domain health check shows whether everything still validates.

What should Microsoft 365 admins check after recovery?

Start from one rule: a mailbox that opens again does not prove that queued mail arrived. Access and delivery recover separately.

• Inbound mail. Senders’ queues drain over hours, each on its own retry schedule. In the Exchange admin center, Mail flow > Message trace shows what arrived and what is still pending, and it reaches back 90 days. Microsoft listed message traces among the Defender for Office 365 features that may be delayed, so run the trace again later if the first result looks thin.
• Quarantine. Microsoft’s notice said attempts to view Quarantine could fail, and that users who did reach the portal “may encounter failures when attempting to release items from quarantine”. Recheck anything you tried to release.
• Safe Links. From the same notice: “Users clicking on wrapped/rewritten URLs typically processed by Safe Links will result in a failure to navigate”. A link that failed to open during the outage is not evidence of a bad link. Tell users to try it again.
• Outbound and hybrid mail. At 06:16 UTC on November 13, Microsoft added that “on-prem mail flow may be affected if it goes to or from Exchange Online”. Exchange Online retries a deferred outbound message for 24 hours before it returns a non-delivery report, and Exchange Server for 2 days by default. Microsoft’s update of November 13, 09:03 UTC says it is extending an “email timeout window” to 48 hours, without saying whether that is the same window. Microsoft has not said whether Exchange Online’s own outbound mail queued.
• Apps that send through Microsoft Graph. Microsoft’s notice says Graph requests that access Exchange Online data, “such as mail, calendar, and contacts, may time out”. An application that sends mail through Graph may have failed with nothing left in a queue: that is our inference, so check the application’s own error log.

When did Microsoft’s bulletins first mention email delivery?

Microsoft’s bulletins first mentioned email delivery on November 13, 2026, 00:00 UTC, when an update to MO1550821 added “email delivery may be delayed”. That is 6 hours 30 minutes after the time SparkPost gives for the first deferrals, and 3 hours 59 minutes after SparkPost published the replies.

EX1550543‘s own list of affected “connection methods” names Outlook on the web, MAPI, Exchange ActiveSync and REST. It never names SMTP.

Read the comparison with care. The 17:30 UTC start is SparkPost’s estimate from its own traffic. We read Microsoft’s Service Health bulletins, not every post on its status account on X, and Microsoft may have told tenants more through channels we cannot read. The cause is not final either: Microsoft’s explanation moved from elevated load, to failed health checks, to an overwhelmed secure-connection process, to a network change it tried to revert and found “not taking as expected”.

What happened to DMARC aggregate reports from Microsoft?

The first DMARC aggregate report from Microsoft 365 on November 13 reached DMARCguard 5 hours 58 minutes late. The rest of that day’s run had not arrived when our data ended.

DMARCguard receives DMARC aggregate reports (RFC 9990) for the domains it monitors, and Microsoft’s arrive on a regular schedule. On each of the 12 days from November 1 to 12, the day’s first report from Microsoft 365 arrived between 01:03 and 01:11 UTC. On November 13 it arrived at 07:09 UTC. Outlook.com’s first report, which arrived between 01:12 and 02:17 UTC on those same days, came at 08:31 UTC, 6 hours 14 minutes late.

The last Microsoft report before that had arrived on November 12, 18:00 UTC. Microsoft’s daily run is normally over by the evening and silent until the next one starts, so the late start is the finding, not the length of the silence. Where the data we read ends, at November 13, 08:57 UTC, only the first report from each of Microsoft’s two reporters had arrived.

Reports from other mailbox providers kept arriving through those hours. The address our customers publish in rua= is served by our own mail servers, not Microsoft’s, so we see no sign of a fault at our end. We can say what we received. We cannot say what Microsoft sent, and we cannot show that EX1550543 caused the delay: the timing is what we have. Microsoft’s bulletins do not mention DMARC reports.

One detail matters for reading it. A Microsoft report arrives on the second UTC day after the day it covers, so the run due on November 13 covers November 11, and the reports that have arrived do cover that day. That mail was sent before EX1550543 began. The first report about it is what arrived late.

For your own domain, expect Microsoft’s part of your DMARC data to lag or thin out around these days, and read it in two parts. For November 11, a missing report may be late, not lost: the first ones have arrived, and the rest had not when our data ended. For November 12 and 13, a report may also show less mail than usual, because part of that mail was deferred. Check your own sending logs before you treat either as a change in your pass rate. Microsoft’s documentation says its aggregate reports are “typically sent once per day”, and only about mail to recipient domains whose MX record “points directly to Microsoft 365”.

The standard does not oblige a late report. RFC 9990 §3.1 describes aggregate reports as “daily (or more frequent)”. §3.5, written for a destination that cannot accept reports, lets the report generator “cache that data and try again later” or “discard data that could not be sent”. So far we have received only the first report from each of Microsoft’s two reporters, both late. We do not know yet whether the rest will come, and we will update this section when we do.

For the format, see what a DMARC aggregate report contains. For gaps that are your own, see whether your reports are reaching you.

How is this different from the AS9031519 Outlook bounces?

Both were Microsoft mail incidents, in consecutive weeks. They call for opposite responses:

The lesson that carries over: read the first digit of the reply before you act. Our post on the 550s covers that case.

Frequently asked questions

What does 451 4.7.0 Temporary server error mean?

A 451 4.7.0 Temporary server error is a temporary refusal: the receiving server did not accept the message now, and the sending server should keep it queued and try again. RFC 3463 defines 4.7.0 as an undefined security status, so the code says little about the cause. We found no Microsoft documentation that explains the reply for the EX1550543 outage.

What does 421 4.3.2 The maximum number of concurrent server connections has exceeded a limit mean?

A 421 4.3.2 reply with this text means the receiving server is at a connection limit, so it refuses the session and closes it. The reply is temporary: the sender reconnects later and retries. RFC 3463 defines 4.3.2 as a system not accepting network messages, with excessive load as an example. SparkPost recorded it from Microsoft during incident EX1550543.

What is 451 4.7.700 PFA agent busy?

451 4.7.700 PFA agent busy is a temporary SMTP reply that SparkPost recorded from Microsoft’s mail servers during the EX1550543 outage in November 2026. We found neither the 4.7.700 code nor the term PFA in Microsoft’s documentation. The leading 4 marks the reply as temporary, so the sending server keeps the message queued and retries.

Should I resend an email that has not reached an Outlook or Microsoft 365 address?

No, unless it bounced. If your sending system queues and retries, a message answered with a 4xx reply is still in its queue and is retried automatically; sending it again produces a duplicate when the original is delivered. Resend only a message that expired and came back as a bounce, once Microsoft is accepting mail.

Why is my email to Microsoft 365 queued?

Email to Microsoft 365 is queued when the receiving server answers with a temporary 4xx reply instead of accepting the message. The sending server then holds the email and retries at intervals until it is accepted or its retry window ends. During Microsoft’s EX1550543 outage, sending services reported this for Outlook.com and Microsoft 365 recipients.

Did Microsoft’s DMARC reports go missing during the outage?

We do not know yet. The first Microsoft DMARC aggregate report of November 13 reached DMARCguard hours later than usual, and the rest of that day’s run had not arrived when our data ended. Microsoft’s incident bulletins do not mention DMARC reports, and RFC 9990 does not require a late report. Check your own sending logs before reading a gap as a change in your mail.

What should you take away from EX1550543?

• Mail to Microsoft during the outage EX1550543 was deferred with 4xx replies, not rejected. In a system that queues, a deferred email is still waiting.
• The retry window decides whether a deferred message is lost. Among documented defaults it runs from 8 hours to 5 days. Know yours.
• Do not resend unless a message expired and bounced. Reissue passcodes and links.
• The first Microsoft DMARC report of November 13 reached us 5 hours 58 minutes late, and the rest had not arrived when our data ended. Expect a gap or thinner numbers from Microsoft in your DMARC data for November 11 to 13, and check your sending logs before you read it as a change in your pass rate.

Nothing in EX1550543 calls for a DNS change. To see each DMARC report as it arrives, and each gap, start monitoring your DMARC reports: free plan, no credit card.

Updates

• November 13, 2026. First published while EX1550543 was open. Microsoft’s latest update at publication was posted at 09:57 UTC under MO1550821.