Outlook.com Rejects Email With 550 5.7.1 as Senders Report Failures Across Multiple Services

Senders are reporting authentication-related rejections for messages to Outlook.com and Hotmail, including mail sent through Microsoft 365, Google, and Zoho. Some messages arrive while others are rejected, leaving recipients with little indication that mail is missing.

Key points

• What happened: Senders have reported authentication rejections such as 550 5.7.1 for mail to Outlook.com and Hotmail.
• Scope: Intermittent delivery failures have been reported for messages sent through Microsoft 365, Google, and Zoho.
• What the evidence shows: Even when a retry through Zoho succeeds, a passing SPF result or similar record for that message cannot establish how the earlier rejected message was authenticated.
• What to check: Investigating authentication rejections for Outlook.com requires the nondelivery report returned to the sender.

One message reached Gmail but was rejected by Hotmail

On November 6, local time, a user posted a nondelivery report for mail to Hotmail on Microsoft's public Q&A site. It showed errors 550 5.7.23 (an SPF validation violation) and 550 5.7.1 (a rejection citing missing SPF, DKIM, and DMARC records).

SPF Validation Error - Microsoft Q&A

Others in the thread said messages from senders whose mail used to arrive were suddenly being rejected. An administrator who manages email for several companies said the outcome varied by user. Another said a message reached Gmail but was rejected by Hotmail. Some reported that resending worked.

Another Outlook.com user reported that two personal accounts intermittently rejected messages from senders using Google or Zoho.

Incoming emails being blocked due to lack of SPF/DKIM/DMARC records on my @outlook.com account - Microsoft Q&A

The rejection notice reportedly also included the identifier AS9031519. A message from Zoho was rejected once and went through on retry.

The headers of the delivered message, which record details such as the delivery route, showed passes for SPF, DKIM, and Microsoft's composite authentication. A moderator identified as external staff on Microsoft's public Q&A pointed out that the successful message's records alone cannot establish the authentication results of the earlier rejected message.

In an independent report dated November 8, Windows Latest said a business email addressed to its reporter had been rejected and that the reporter reproduced the issue that day.

What SPF, DKIM, and DMARC errors can tell you

SPF checks whether a sending server is authorized to send mail for a domain. DKIM uses a digital signature to check whether the message was altered. DMARC also checks whether the sender domain shown to the recipient aligns with a domain authenticated through SPF or DKIM.

Microsoft's technical documentation on email authentication lists missing sender authorization, duplicate SPF records, and temporary DNS response failures among the conditions that can cause SPF to fail. DNS publishes configuration information for domains. Forwarding can also affect authentication results.

Microsoft normally describes 550 5.7.23 as an indication of a possible SPF configuration problem on the sender's side. In these reports, senders said their authentication settings were correct, and some saw different results depending on the recipient or delivery attempt. Determining the cause requires records for the rejected message itself.

Adding DMARC resolved one reported case

On November 7, local time, an administrator sending from Microsoft 365 to Hotmail reported that their custom domain lacked a DMARC record. Mail started arriving after they added it to DNS.

Microsoft 365 does not automatically issue DMARC records for custom domains. The domain administrator publishes the record in DNS. In one reported case, adding the record fixed delivery, while other senders said SPF, DKIM, and DMARC were already configured.

Microsoft has long required domains that send high volumes of email to Outlook.com and other consumer mail services to use SPF, DKIM, and DMARC. Its official documentation says the requirements apply when a single sending domain sends at least 5,000 messages a day and identifies 550 5.7.515 as the error for noncompliance.

The reported 550 5.7.1 and 550 5.7.23 codes differ from the high-volume sender error. Misconfigured sending domains can trigger rejections, and the evidence so far does not tie the intermittent failures across multiple services to any single rule change.

What senders and recipients can check

Senders should save the nondelivery report and give their mail administrator the full error, timestamp, sending IP address, rejecting server, and authentication results. The administrator can compare published SPF, DKIM, and DMARC settings with the actual sending route. If the configuration checks out, Microsoft's sender support can investigate.

Recipients can check with senders about missing messages. Microsoft manages DNS authentication for personal @outlook.com addresses, so recipients have no settings to change themselves.

Messages rejected before delivery never reach the junk folder. Adding the sender to the safe senders list is also unlikely to help. If messages from different sources are repeatedly rejected, users can report the issue to official Outlook.com support and include the nondelivery details.

A moderator on Microsoft's public Q&A also said they had no visibility into the status of any internal investigation. The nondelivery report returned to the sender typically holds more clues to the cause than the recipient's inbox.

Originally published on Joho no Todai. The Japanese original is here.