Small senders report Outlook.com email rejections

Small senders are reporting rejected messages to Outlook.com and Hotmail, with missing DMARC records emerging as one cause. Email-security provider MailRoute says it began seeing the bounces on 5 November, including from domains sending far less mail than the threshold in Microsoft’s published bulk-sender rules.

Adding the record has restored delivery for some administrators. Others say their messages are being refused despite passing authentication. The public evidence therefore leaves two questions open: whether Microsoft has expanded its checks, and whether every reported failure has the same cause.

A rejection before the inbox

MailRoute’s 6 November account identifies this response from Microsoft’s consumer mail servers:

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

The failure concerns delivery to addresses such as outlook.com, hotmail.com, live.com and msn.com. An organisation sending from Microsoft 365 can encounter it when writing to those consumer addresses. The reports do not establish a matching new rule for delivery to business Microsoft 365 tenants, and changing the Outlook desktop app would not change a sender’s DNS records.

Some non-delivery reports put a 550 5.7.23 SPF error above that more specific response. In a Microsoft Q&A thread, administrator David Carver described one message sent to two recipients: Gmail accepted its copy while Hotmail rejected the other. Other contributors reported intermittent failures.

These are delivery rejections reported back to senders, rather than messages simply appearing in a recipient’s Junk folder. The person waiting for the email may have no message to recover.

Microsoft’s published rule still targets bulk senders

Microsoft announced stricter Outlook.com authentication requirements in April 2025, with enforcement starting on 5 May. Its policy describes domains sending more than 5,000 emails a day to Outlook.com. A separate support article describes the threshold as 5,000 or more messages using the same visible From domain.

For those senders, SPF and DKIM must both pass. The domain must also publish a DMARC policy, with p=none sufficient, and the message must pass DMARC through an aligned SPF or DKIM result. Microsoft documents 550 5.7.515 as the rejection code for failing that required authentication level.

The official postmaster policy recommends SPF, DKIM and DMARC for all senders, but its mandatory section retains the high-volume threshold. Its rollout wording also differs from the April blog update: the policy describes Junk placement followed by possible rejection, while the blog says Microsoft chose rejection from 5 May. Neither page explains the November AS9031519 reports.

Missing DMARC explains some failures

MailRoute says many affected domains already had working SPF and, in some cases, DKIM. What they lacked was a published DMARC record. In a separate Q&A discussion, David Goodloe reported that adding one allowed previously rejected messages through. He said the affected clients were nowhere near Microsoft’s published volume threshold.

That account has limits. In the larger SPF-error thread, contributors including David Wood and Austin W reported failures despite what they described as valid records or passing authentication results. Authentication results recorded earlier in a message’s journey do not necessarily establish what Outlook.com checked at delivery. Sulat has not independently inspected those organisations’ DNS configurations, message headers or delivery logs.

Windows Latest reported on 8 November that it had reproduced the delivery problem that day. It also said Microsoft had not publicly confirmed the cause. Replies from independent advisers and volunteers on Microsoft’s forums should not be read as a company announcement.

What the DNS record does

DMARC connects authentication to the domain a reader sees in the message’s From address. SPF checks whether a sending server is authorised for the envelope-sender domain. DKIM verifies a cryptographic signature associated with a signing domain. For DMARC to pass, at least one passing result must align with the visible From domain.

A domain can therefore have valid SPF and DKIM records yet fail DMARC alignment. A delivery service signing mail under its own unrelated domain, for example, does not authenticate the customer’s visible From domain through that signature.

Microsoft’s DMARC documentation describes a monitoring-stage policy such as v=DMARC1; p=none, published as a TXT record at _dmarc.example.com. That policy does not ask receivers to quarantine or reject mail solely because it fails DMARC. Receivers can still block it under their own filtering rules.

The record alone does not repair SPF, add a DKIM signature or fix alignment. It also does not request aggregate reports unless an appropriate rua=mailto: destination is included. Those details qualify the one-record fix in MailRoute’s account.

The checks belong to the sending domain

Microsoft’s troubleshooting guidance starts with the full non-delivery report and message headers, then checks SPF, DKIM, DMARC and any third-party sending services. Looking only for a TXT record is incomplete: the policy must be valid and the message must authenticate against the right domain.

A subdomain may inherit its parent’s DMARC policy, so an empty lookup at one name does not by itself prove that no policy applies. Existing quarantine or reject policies also should not be weakened simply to copy a minimal example. Microsoft recommends a gradual move towards enforcement after legitimate senders are aligned.

People receiving mail at a personal Hotmail or Outlook.com address cannot add DNS records for someone else’s sending domain. The sender’s administrator or provider can investigate the failure and, where authentication is correctly configured, submit the complete bounce details to Outlook.com deliverability support.

Microsoft’s November behaviour remains unexplained. The reports do not yet establish that every small sender without one will be blocked, or that adding one will resolve every AS9031519 rejection.