Outlook Is Rejecting Email Without DMARC: What the 550 5.7.1 Bounce Means, and the One-Record Fix

Illustration of an email with a red warning triangle above a laptop inbox and a security shield with a checkmark

AI-generated illustration of an email blocked by a warning symbol above a laptop inbox, with a security shield beside it.

Since 5 November 2026, email sent to Outlook.com, Hotmail, Live and MSN addresses has started bouncing for some senders — and those senders had changed nothing that week. The bounce reads "550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)". It is a permanent rejection, so the message is not retried, and the person on the other end never knows it was sent. What makes this one worth your attention is who it hits: not just bulk marketers, but ordinary low-volume senders — a small business replying to a customer, a school emailing parents, a recruiter answering an applicant — whose domains publish no DMARC record, even when their SPF and DKIM records pass. There is a second twist, too: on 9 November, a Microsoft moderator confirmed an ongoing Exchange service issue affecting the same mailboxes, so two things are happening at once. This guide separates them, shows you how to check your domain in a minute, and walks through the one-record fix that is fully in your hands.

The short version is this: if your domain has no DMARC record, publish one at p=none. It is a single TXT record in your DNS, it takes a few minutes to add, and it changes nothing about how Gmail, Yahoo or anyone else treats your mail. The rest of this article explains what the error actually means, why SPF and DKIM alone no longer save you, how to check and fix your setup step by step, and what to do if your mail still bounces after the fix — because for some senders the problem is on Microsoft's side, and no DNS change will fix that.

As an Amazon Associate, we earn from qualifying purchases.

8-COREAMD Ryzen 7 9800X3D8 cores / 16 threads, up to 5.2 GHz, AM5, 96MB L3View deal at Amazon >32GB DDR5CORSAIR Vengeance DDR5 32GB (2x16GB) 6000MHz32GB (2x16GB) DDR5-6000, CL38, AMD EXPO + Intel XMP 3.0View deal at Amazon >AMAZON'S CHOICEASUS Prime GeForce RTX 5060 8GB GDDR7 OC EditionVRAM: 8GB GDDR7, Amazon's Choice, 50+ bought in past monthView deal at Amazon >

Prices and savings can change. Check the retailer for the current price.

What the bounce looks like, and why it is easy to miss

The rejection arrives during the SMTP session, before the message is accepted, and it looks like this:

550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)

Two details matter. First, 550 means permanent failure: a standards-compliant sending server bounces the message back to the sender and does not retry. There is no queue, no second attempt, and no copy sitting in the recipient's junk folder. Second, the rejection is intermittent. Microsoft refuses only part of the mail from an affected domain — one message to a Hotmail address goes through, the next one bounces, and a resend a few minutes later may succeed. Neowin reported a sender whose mail through Zoho was rejected and then delivered when resent about 19 minutes later. That inconsistency is what makes this dangerous: the sender sees a bounce full of acronyms, assumes a glitch, and moves on, while the customer on the other end never knows a message was sent. Invoices that do not arrive, appointment confirmations that never land, and replies that look like you ignored someone are the quiet cost.

The timeline is short and well documented by the people who run mail servers. Email security vendor MailRoute first saw the rejections in its own outbound logs on 5 November 2026, and public reports from other administrators started appearing the same day. On the first day the rejection came back without the "(AS9031519)" suffix; the suffix appeared from 6 November. Email diagnostics site mxio traced the same pattern, and DMARC vendor dmarkoff reproduced it on 7 and 8 November: with SPF and DKIM set up to pass and align, 16 out of 16 Outlook.com and Hotmail seed mailboxes refused a message from a domain with no DMARC record anywhere, while the same message was accepted everywhere else. The rejecting servers sit behind Microsoft's consumer mail infrastructure (*.olc.protection.outlook.com), in North America, Europe and Asia-Pacific alike, so this is a global change, not a regional one.

What the bounce does not tell you is which record is actually missing. The wording suggests something is badly broken. Usually it is not: in the cases MailRoute examined, the bounced domains mostly had working SPF, and many had DKIM too. What they were missing was the DMARC record that ties the two to the From address. Without a DMARC record, those passes have no policy to count toward, and Outlook.com now appears to treat the message as unauthenticated.

What SPF, DKIM and DMARC actually do

These three records work as a team, and the confusion around this bounce comes from treating any one of them as enough on its own. SPF (Sender Policy Framework) is a TXT record that lists which servers are allowed to send mail for your domain. When a receiving server gets your message, it checks whether the sending server is on your list. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message, using a private key held by your mail service and a public key published in your DNS. The receiver verifies the signature to confirm the message was not altered in transit and really came from your domain. DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer that sits on top of both: it tells receivers what to do when a message fails SPF or DKIM checks, and it asks them to send you reports about mail claiming to be from your domain.

The key concept is alignment. DMARC only passes when SPF or DKIM passes for the domain in the From address — the domain your recipients actually see — not for some other domain in the background. This is where most setups go wrong. Microsoft 365, for example, signs your mail with its own onmicrosoft.com domain until you turn on DKIM for your own domain, and that signature does not count toward your DMARC. Google Workspace and Zoho have their own versions of the same setup step. A DMARC record alone will not help if neither SPF nor DKIM lines up with your From domain, so the fix below has two parts: the record itself, and confirming alignment.

DMARC policies come in three strengths. p=none means monitor only: receivers take no action on mail that fails, but they send you aggregate reports. p=quarantine asks receivers to put failing mail in the junk folder. p=reject asks them to refuse it outright. For the fix in this article, p=none is the right starting point — it is enough to satisfy the new Outlook.com behaviour, and it carries no risk of blocking legitimate mail while you check your setup.

How this differs from Microsoft's May 2025 bulk-sender rule

Microsoft does have published sender requirements, and it is important not to confuse them with this new rejection. In April 2025, Microsoft announced new requirements for high-volume senders to Outlook.com, Hotmail and Live: domains sending more than 5,000 messages a day had to pass SPF and DKIM and publish DMARC at p=none or stronger, aligned with SPF or DKIM. Enforcement started on 5 May 2025, and senders who failed got a different error: "550 5.7.515 Access denied, sending domain ... doesn't meet the required authentication level". That error lists the SPF, DKIM and DMARC results, so you can see what failed.

The November 2026 rejection breaks from that rule in every way that matters. It reaches small senders: a one-line reply from a small office can bounce, and the affected domains send nowhere near 5,000 messages a day. It was not announced: as of 8 November, Microsoft had published nothing about it — no postmaster notice, no blog post, no service-health entry — and the AS9031519 code is not defined in any Microsoft documentation. And it does not say what failed: the bounce only says records are missing, with no per-check results. The May 2025 rule is still in force for bulk senders on top of this; the new behaviour appears to extend a DMARC requirement to everyone, quietly.

This is also part of a wider pattern. Gmail and Yahoo began enforcing SPF, DKIM and DMARC for bulk senders in 2024, and the requirements have been tightening since. What usually starts as a rule for bulk senders, announced with a deadline, eventually becomes the baseline for everyone. A DMARC record at p=none is the floor now, not a best practice.

Who is affected — and who is not

On the receiving side, the rejection comes from Microsoft's consumer mail platform only: outlook.com, hotmail.com, live.com and msn.com addresses, including their country variants such as outlook.be. Microsoft 365 business mailboxes with custom domains do not appear to be affected as recipients — dmarkoff's tests found Microsoft 365 mailboxes accepted the same message that Outlook.com refused, and the sending side is not limited to Microsoft 365 either. Neowin reported senders on Google and Zoho getting rejected, and administrators on Reddit reported the same from on-premises Exchange servers.

On the sending side, any domain without a DMARC record is exposed, regardless of volume. That includes small businesses, schools, clinics, clubs and anyone sending from a custom domain through a website contact form, an invoicing tool or a newsletter service. If you only ever send from a free outlook.com or gmail.com address, this does not affect you — those providers publish their own records. But if your email address ends in a domain you own, and you have never deliberately added a DMARC record, you are very likely in the exposed group. Microsoft 365 does not automatically create or publish DMARC records for custom domains, so many tenants never had one.

Check your domain in 60 seconds

Before changing anything, check whether your domain already has a DMARC record. From any terminal, replace example.com with your own domain:

dig +short TXT _dmarc.example.com

A line starting with "v=DMARC1 means you have a record. No output means you do not — and that is the case this rejection targets. On Windows, the equivalent is nslookup -type=TXT _dmarc.example.com. If you prefer a web page, the free checkers from mxio and EasyDMARC test your domain from the browser and report on all three records at once, including whether SPF and DKIM align with your From domain.

Check the domain in your From address, not the envelope sender or the bounce address, because DMARC is published for the domain your recipients see. And check for exactly one record: publishing two _dmarc TXT records on the same name makes the result undefined, and receivers ignore both. If your DNS host shows two, remove one before doing anything else.

The fix: publish a DMARC record at p=none

If the check above returned nothing, this is the whole fix. At your DNS host — your domain registrar, Cloudflare, or wherever your DNS lives — add a TXT record with these values:

Name / host: _dmarc
Type: TXT
Value: v=DMARC1; p=none

That is all. p=none declares that your domain uses DMARC and asks receivers to send you reports, but tells them to take no action on failures, so nothing about how Gmail, Yahoo or anyone else treats your mail changes. DNS changes take a few minutes to a few hours to propagate depending on your TTL, so wait at least an hour, re-run the dig check, and then send a test message to an Outlook.com or Hotmail address you control. If it arrives, the fix worked.

One condition applies, and it is the step people skip. DMARC passes only when SPF or DKIM passes for the domain in your From address. If you use Microsoft 365, go into the Microsoft Defender portal and turn on DKIM signing for your own domain — until you do, Microsoft signs with onmicrosoft.com and the signature does not count. Google Workspace and Zoho each have their own DKIM setup in their admin consoles, and most newsletter and transactional-mail services publish step-by-step DKIM instructions for your domain. If your mail goes through a relay or a website plugin, confirm with that service which domain it signs as. A DMARC record plus aligned SPF or DKIM is the complete fix; a DMARC record on its own is not.

If the bounce message you received was the 550 5.7.23 variant instead, that one points specifically at an SPF validation failure rather than a missing record. Check your SPF record first in that case: it may have more than the 10 DNS-lookup limit, a typo, or a missing include for your sending service. Do not start changing SPF because of the 5.7.1 message, though — in most of the cases reported so far, there was nothing wrong with SPF.

If you already have DMARC and your mail still bounces

This is where the second half of the story matters. Several administrators have reported bounces even though their SPF, DKIM and DMARC records are all correctly configured, and the failures are intermittent — some messages go through while others from the same domain are rejected. On 9 November, a Microsoft moderator confirmed in a Microsoft Q&A thread that there is an ongoing Exchange service issue affecting messages to Outlook.com, Hotmail and Live addresses. The advisory is classified as a service degradation, Microsoft is still investigating the root cause, and a Reddit user cited the advisory ID EX1540236. As of this writing, that advisory does not appear in the Service Health dashboard of every tenant, which is consistent with a consumer-platform issue rather than a tenant one.

If that is your situation, adding a DMARC record is still worth doing — it is the documented baseline and it fixes the cases where a missing record is the cause — but it may not stop every bounce until Microsoft resolves the service issue. What helps in the meantime: resend the message after a few minutes, since many reports show the same message going through on a second attempt; keep the full non-delivery report, including timestamps, sending IP addresses and authentication details, and submit it to Microsoft through the sender support form or the Q&A thread so the issue can be investigated; and do not tear down a working SPF record chasing the bounce text. The error message points at SPF first, but the evidence so far says the record is usually fine.

Going further: from p=none to p=reject

Once your p=none record has been in place for a few weeks and you have looked at the aggregate reports it generates, you can tighten the policy. The usual path is p=none, then p=quarantine, then p=reject, checking the reports at each step for legitimate mail that would be affected. The reports show you who is sending mail as your domain — including anyone who is not you.

That is the real reason this change is worth making rather than resenting. Spoofing is how much of today's phishing and business email compromise starts, and a domain that authenticates is much harder to impersonate. The p=none record that gets your mail delivered to Outlook.com today is also the first step to p=reject, which tells receivers to refuse mail that forges your domain. Do not jump straight to p=reject, though: without a monitoring period, you risk blocking legitimate mail from a service you forgot about, such as an old invoicing tool or a website form that sends as your domain.

Checklist: fix Outlook DMARC bounces

Check your domain: dig +short TXT _dmarc.yourdomain.com — no output means no DMARC record.
Confirm you have exactly one _dmarc TXT record, not two.
Add the record: name _dmarc, type TXT, value v=DMARC1; p=none.
Confirm SPF or DKIM passes and aligns with your From domain — turn on DKIM for your own domain in Microsoft 365, Google Workspace or Zoho if it is not on.
Wait for DNS propagation, re-check, then send a test message to an Outlook.com or Hotmail address.
If mail still bounces intermittently with all three records correct, resend after a few minutes and report the full bounce to Microsoft — a service issue (EX1540236) is also in play.
After a few weeks of reports, consider moving from p=none to p=quarantine, then p=reject.

Bottom line

Since 5 November 2026, Outlook.com has been bouncing some mail from domains with no DMARC record — quietly, intermittently, and without an announcement — and even domains with working SPF and DKIM are affected. The fix that is in your hands is one DNS record, v=DMARC1; p=none at _dmarc, plus confirming that SPF or DKIM aligns with your From domain. If your mail still bounces after that, you are likely hitting the separate Exchange service issue Microsoft confirmed on 9 November, and the right move is to resend, keep the bounce report, and let Microsoft investigate. Either way, check your domain today: the record takes minutes to add, costs nothing, and it is the same first step toward stopping anyone from sending phishing mail in your name.