Microsoft's consumer mail platform is bouncing ordinary business mail from domains that publish no DMARC record, and it has said nothing about it. The rejection started on 5 November and is still hitting senders across every mail provider, Microsoft 365 included.
What happened
Senders are receiving a permanent rejection from Microsoft edge servers: 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records, with the reference code AS9031519. Microsoft 365 wraps the same rejection in a second line starting 550 5.7.23 Sender Policy Framework violation, which sends administrators off checking an SPF record that was correct all along.
The pattern operators converged on is consistent. The rejected domains had working SPF, and in most cases valid DKIM aligned with the From domain. What they lacked was any DMARC record at _dmarc on the sending domain. Publishing a minimal record stopped the bounces in every confirmed case reported so far.
The scope is wider than any published rule. Microsoft's documented requirement covers domains sending more than 5,000 messages a day to consumer mailboxes, rejected with a different code, 550 5.7.515. This rejection is hitting low-volume senders and personal domains well below that threshold, it is intermittent rather than deterministic, and as of 9 November Microsoft had published no postmaster notice or service health entry explaining it.
Who is affected
- Any organisation sending mail to outlook.com, hotmail.com, live.com or msn.com addresses from a domain with no DMARC record.
- Microsoft 365 tenants are not exempt: the platform does not create a DMARC record for custom domains, so a tenant with perfect SPF and DKIM can still have no _dmarc entry.
- Domains used only for transactional or system mail, which are the ones nobody remembers when authentication is audited.
- Mail to business tenants on Microsoft 365 with custom domains is not being rejected in the same way, so a successful internal test proves nothing about your customers.
What to do now
Query DNS for _dmarc on every domain you send from, and publish a record where one is missing. Do not trust a dmarc=pass in your own headers; Microsoft records a best-guess pass when no record exists, which looks reassuring and means nothing to anyone else.
- Run a TXT query on _dmarc.yourdomain.com and check for a value starting v=DMARC1 for each sending domain, each subdomain used in a From address, and each secondary domain still emitting mail.
- Publish exactly one record, for example v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com, and publish only one, since duplicate records break DMARC evaluation itself.
- Search your mail logs and helpdesk tickets for AS9031519 or lacks SPF/DKIM/DMARC back to 5 November, then re-send the invoices, statements and password resets that bounced, because a 550 is permanent and nothing is queued.
- Move on from p=none once reports are clean: p=quarantine, then p=reject, is where the record actually starts blocking spoofed mail in your name.
What this means for South African businesses
Most South African SMEs have never published a DMARC record, and many never turned on DKIM for their own domain, so a large share of local senders are exposed to a bounce they cannot see: the customer simply never receives the invoice and nobody gets an error on their side. The nastier detail is that this is silent and permanent, which means the damage shows up as an unpaid account or a missed quote weeks later, not as an outage you can escalate. Assume consumer Outlook addresses on your client list are unreliable until you have checked DNS yourself.
Source: dmarcian analysis of the Outlook.com DMARC rejection.
Also on the blog
Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.