MailRoute says Outlook.com is rejecting mail from domains without DMARC

MailRoute, a vendor of outbound email relay services, reports that since November 5, 2026 Microsoft's consumer mail service has been turning away some of the email from domains that do not publish a DMARC record. The service covers outlook.com, hotmail.com, live.com and msn.com addresses. A company that mails customers, vendors or applicants at those addresses may therefore have messages bouncing right now. According to the post, nobody announced the change.

The sender sees an SMTP bounce reading "550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records", followed by a bracketed server name and ID that differ per message, for example (AS9031519). On the first day, MailRoute says, the same rejection came back without the bracketed code. The wording suggests something is badly broken, but MailRoute says that usually it is not: the bounced domains it has seen mostly had working SPF, and many had DKIM too. What they lacked was the DMARC record that ties the two to the From address.

Microsoft does have published sender rules. Since May 2025, domains that send more than 5,000 messages a day to Outlook.com have had to pass SPF, DKIM and DMARC, or get "550 5.7.515 Access denied". That rule targets marketers and bulk senders. MailRoute argues the new rejection differs in three ways. It reaches small senders, so even a one-line reply from a small office can bounce. It was not announced: as of November 6, the post says, Microsoft has published no postmaster notice, no blog post and no service-health entry. And it does not say what failed, whereas a 5.7.515 bounce lists the SPF, DKIM and DMARC results, this one only says records are missing. MailRoute says it first saw the bounces in its own outbound logs on November 5, and that public reports from other administrators began appearing the same day.

The pattern is easy to miss because Microsoft refuses only part of the mail from an affected domain. One message to a Hotmail address goes through, the next bounces, and a resend may succeed. The sender sees a bounce full of acronyms, assumes a glitch and moves on, while the recipient never learns a message was sent. MailRoute says the cost is quiet for businesses that depend on reaching people at personal addresses (patients, homeowners, applicants, parents, members): invoices that do not arrive, appointment confirmations that never land, replies that look like an ignored message.

To check a domain, run dig +short TXT _dmarc.example.com with your own domain. A line starting with "v=DMARC1" means a record exists; no output means none, which is the case this rejection targets. The fix MailRoute proposes is a TXT record named _dmarc with the value v=DMARC1; p=none. That value declares that the domain uses DMARC and asks receivers to send reports, but tells them to take no action on failures, so nothing changes in how Gmail, Yahoo or anyone else treats the mail.

There is one condition. DMARC passes only when SPF or DKIM passes for the domain in the From address; if neither lines up, a DMARC record alone will not help. The post gives an example: Microsoft 365 signs with its own onmicrosoft.com domain until DKIM is turned on for the customer's own domain, and that signature does not count toward DMARC. For customers sending through MailRoute's relay, the company says SPF and DKIM already pass, so the DMARC record is the whole fix. It also points to a guide and domain checker from its sister company mxio for senders using other services.

Looking ahead, the author predicts that every major mailbox provider follows the same pattern: requirements start with bulk senders, get announced with a deadline, then quietly become the baseline for everyone. In its words, DMARC at p=none is now the floor, not a best practice. It adds that p=none is also the first step toward p=reject, which tells receivers to refuse mail that forges the domain.

Key facts

  • MailRoute reports that since November 5, 2026 Outlook.com, Hotmail, Live and MSN have rejected some mail from domains with no DMARC record, with bounce code 550 5.7.1 ("Message lacks SPF/DKIM/DMARC Auth Records").
  • As of November 6, Microsoft had published no postmaster notice, blog post or service-health entry about the change, per MailRoute.
  • Unlike Microsoft's published rule in force since May 2025 (senders of more than 5,000 messages a day, bounce 550 5.7.515), the new rejection reportedly hits small, low-volume senders.
  • Only part of the mail from an affected domain bounces, so a resend may succeed and delivery that sometimes works does not prove the domain is safe.
  • The proposed fix is a DNS TXT record at _dmarc with the value v=DMARC1; p=none, which works only if SPF or DKIM passes for the From domain.

Why it matters

Microsoft's published rule since May 2025 covers only domains that send more than 5,000 messages a day to Outlook.com. MailRoute says the new rejection reaches ordinary small senders, with no announcement and with a bounce that says only that records are missing. Because the bounces are intermittent, senders may blame a glitch and the recipient never sees the message. The author's forecast is that DMARC at p=none is becoming the baseline for everyone, as bulk-sender requirements have spread before.

Who it affects

Any domain that has no DMARC record and sends mail to outlook.com, hotmail.com, live.com or msn.com addresses, including small businesses and offices sending a single reply. MailRoute names organisations that depend on personal addresses: patients, homeowners, applicants, parents and members. Senders on Microsoft 365 need DKIM enabled for their own domain, since the default onmicrosoft.com signature does not count toward DMARC.

How to use it

Check with dig +short TXT _dmarc.example.com, replacing example.com with your domain. A line starting with "v=DMARC1" means you have a record; no output means you do not. To fix it, add a TXT record named _dmarc with the value v=DMARC1; p=none at your DNS host. Make sure the service sending your mail passes SPF or DKIM for the domain in your From address, because DMARC passes only on one of those. MailRoute says its own relay customers already pass both checks and only need the record. Its sister company mxio offers a guide and a domain checker for other senders.

How solid is it

The evidence is MailRoute's own outbound logs from November 5 plus its statement that other administrators posted public reports the same day; no names, links or counts of affected domains or messages are given. Microsoft had published nothing as of November 6, so there is no official confirmation. The bounce text and the p=none behaviour are described in detail, but the post does not say why Microsoft made the change or whether it is intentional policy, a test or a bug. The author is a relay vendor that sells a service and a trial, and the post names no individual author.

Risks and caveats

Without a Microsoft statement, the scope and duration of the rejections are unknown; the source gives no timescale. Intermittent bounces make a working test send unreliable as proof. A p=none record asks for reports but tells receivers to take no action on failures, so it satisfies the apparent requirement without blocking forged mail; MailRoute presents p=reject as a later step. A DMARC record alone will not help if neither SPF nor DKIM aligns with the From domain. The vendor's advice also promotes its own relay and trial, so treat the sales pitch separately from the technical fix.

“Nobody announced it. The fix is one DNS record.”

— MailRoute