An email sent to an Outlook.com account may bounce even if the sending domain has SPF and DKIM configured. Since November 5, administrators and email providers have reported rejections on Outlook.com, Hotmail, Live, and MSN when a DMARC record is missing, even for low-volume sending. The error shown is 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records, sometimes followed by AS9031519.
Reports describe irregular behavior: some messages from the same domain arrive while others are rejected; sometimes, resending works. MailRoute and Teneo say they have observed the pattern in their own systems. Microsoft, by contrast, has not published a notice confirming a new general requirement or explained the AS9031519 identifier. That lack of confirmation matters: some users also say they receive the rejection despite having all three mechanisms configured.
A rejection that does not affect every message
MailRoute dates its first bounces to November 5 in its outgoing mail logs. According to the company, public reports from other administrators began appearing that same day. Teneo describes rejections starting on that date and documents one received on Saturday, November 7, at 18:00 UTC, when sending a message to an outlook.be address.
In Teneo's case, the message had a DKIM signature for the sending domain, and the sending server was authorized by SPF; both checks passed. What was missing was the DMARC record at _dmarc. Two seconds later, another message from the same domain received the same response from another Outlook server, according to the company.
The error also appeared in user questions posted on Microsoft Q&A. One customer said that around 50% of their customers who had written to them since the previous day were receiving the bounce. Another explained that several regular customers could no longer send them messages, although messages from other senders still reached their inbox. That difference is consistent with the partial nature described by MailRoute and Teneo, but does not allow us to conclude that all cases have the same cause.
Windows Latest reported that it was able to reproduce the problem on November 8 and collected complaints from Outlook.com and Hotmail users. One sender said that a message sent from Zoho to an Outlook.com account was rejected at 15:50 and arrived when they tried again at 16:09; the delivered message indicated that SPF and DKIM had passed. The result of the second attempt alone does not reveal what happened with the first.
“Domains with valid SPF, DMARC and DKIM are being rejected. It only happens for a small percentage of the emails (probably depends on which Microsoft server your message gets routed to),”
— one user wrote
The quote comes from a comment cited by Windows Latest in a Microsoft forum. The publication also reported the case of someone who said that approximately half of the customers who had written to them since November 5 received a rejection. In another case described on Microsoft Q&A, a user said their messages to Gmail and another Exchange account were accepted, while Outlook.com rejected the message.
The new code is not the high-volume error
Microsoft does document an authentication policy for high-volume senders, but its support page refers to code 550 5.7.515, not 550 5.7.1 with AS9031519. The official rule applies to domains that send 5,000 messages or more to Microsoft's consumer email services and use the same domain in the From address. For those senders, Microsoft requires SPF and DKIM to pass, a DMARC record to exist, and at least SPF or DKIM to align with the From domain.
Microsoft's support page explains that DMARC can pass through SPF, DKIM, or both, as long as at least one aligns with the sender's visible domain. It also recommends checking the return path, DKIM signature, and settings for external services that send email on behalf of the domain. If a billing platform, email system, or relay uses a signature or domain that does not align, SPF or DKIM showing “pass” is not necessarily enough for DMARC to pass.
MailRoute and Teneo maintain that the new rejections go beyond that rule: they would affect domains of any volume that do not publish DMARC. Teneo distinguishes the two errors by the code and returned text, and says its tests with the recent rejection did not affect Microsoft 365 business mailboxes. Its observations concern the cases it has seen; Microsoft has not confirmed that it has rolled out a universal requirement.
The difference also appears in responses on Microsoft Q&A. An independent advisor noted that the requirements for high-volume senders began the previous year and that the volume threshold was relevant. Other participants said that domains well below 5,000 messages per day had stopped delivering email. Forum responses are not a Microsoft announcement and do not resolve whether the new code corresponds to an intentional change, a partial rollout, or a failure.
The fix some senders have already tried
In several cases, adding a DMARC TXT record with the value v=DMARC1; p=none allowed messages to be delivered again. Frank Lawler, on Microsoft Q&A, said his email from Microsoft 365 to Hotmail was bouncing even though SPF and DKIM were correct. After checking that the domain had no DMARC record in public DNS, he published the record and reported that Hotmail accepted a new message. David R. described a similar test: his headers indicated that the checks were passing, but the public record was missing; after adding it, the test message reached the same Live account.
A user cited by Windows Latest also said they found their organization's DMARC entry missing, configured it with p=none, and got successful results in subsequent tests. These are specific experiences, not a guarantee for every bounce: Microsoft Q&A itself warns that the absence of DMARC alone does not prove the cause in every case, and Windows Latest collected complaints from senders who said they had valid records.
The p=none policy declares the use of DMARC but asks receivers not to take action against messages that fail validation. MailRoute and Teneo present it as the starting point that is resolving the cases they have observed. Adding that record also does not fix a misalignment: if neither SPF nor DKIM passes for the domain shown in From, DMARC will not validate simply because the record has been published.
To check whether the record exists, MailRoute suggests querying the domain's _dmarc TXT record. From a terminal, its example is dig +short TXT _dmarc.example.com, replacing example.com with the sending domain. The company says that a response beginning with v=DMARC1 confirms that a record exists; no results means that none was found in that query. Microsoft Q&A users also recommended checking the sender's public domain with MXToolbox.
The record is published with the domain's DNS provider, not in the settings of the personal inbox receiving the email. A Microsoft Q&A participant explained that Microsoft 365 does not automatically create a DMARC record for every domain. In the same discussion, a user also found duplicate DMARC records and a syntax error in SPF on another domain; for that reason, it is worth checking each sending domain rather than assuming that a single account or service covers every case.
What senders and recipients can do
If a message bounces, senders can keep the complete non-delivery report and check SPF, DKIM, DMARC, and alignment with the From domain. Microsoft recommends using the message headers to review authentication results and also checking third-party services. Teneo advises searching the logs for the rejection text and the AS9031519 identifier; if the problem continues after publishing DMARC, it recommends saving the full response, including the server name and timestamp.
The Outlook.com recipient cannot fix the DNS records of the sending domain. In a Microsoft Q&A response, a user who asked whether they could change anything in their account to receive these emails was told that the rejection occurs before the message reaches the inbox. The suggestion was to ask the sender or their IT team to check DMARC; changing inbox rules or the safe senders list does not fix the configuration of the domain originating the message.
If the sender confirms that SPF, DKIM, and DMARC pass and are aligned, Microsoft Q&A suggests escalating the case with the complete non-delivery report and message details. Windows Latest also recommends sharing the bounce with the email provider or Microsoft support. Resending the message may work in some cases, but it does not identify the cause or ensure that the next attempt will arrive.
The question that remains open is whether Microsoft is deliberately applying a DMARC check to senders of every size or whether some of the rejections are due to a service issue. MailRoute says that, as of November 6, it had not found a postmaster notice, a blog post, or a status entry about the change. As of November 8, Teneo had also found no statement from Microsoft about AS9031519. Until there is an official explanation, the available reports continue to show two situations: domains without DMARC that restored delivery after publishing it, and senders who say they are receiving the same error despite having authentication configured.
Sources: MailRoute, Microsoft Q&A, Microsoft Q&A, Microsoft Support, Windows Latest, Teneo SMTP Relay
