Security Advisory: Microsoft Now Rejects Email to Outlook.com, Hotmail & Live from Domains Without DMARC — Virtue IT Hosted Customers Verified Covered

1. Executive Summary

From approximately Friday 6 November 2026, Microsoft quietly tightened sender-authentication checks on its consumer email services (Outlook.com, Hotmail, Live and MSN). Mail is now rejected outright at the SMTP connection when the sending domain has no DMARC record in DNS — regardless of how small the sender is.

Since yesterday (Monday 9 November) Virtue IT has fielded multiple calls from local business customers whose suppliers, accountants and contacts suddenly could not email them — the messages bounced back to the sender. The receiving mailbox is not broken: the problem is on the sender's side. We have audited and test-sent mail from every Virtue IT hosted customer domain, and all hosted domains already have valid DMARC records in place — hosted customers require no action.

2. Technical Breakdown: What's Actually Happening

This change is separate from Microsoft's May 2025 rule that targeted bulk senders (5,000+ messages/day, error 550 5.7.515). The new rejection ignores sending volume — it only checks whether a DMARC record exists for the From domain:

• The bounce senders see: 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (identifier AS9031519). Some senders instead get a misleading 550 5.7.23 SPF failure, which points admins at the wrong fix — SPF passing does not help if the DMARC record is missing.
• Rejection happens before the mailbox: the message never reaches Outlook.com's servers as accepted mail, so the recipient sees nothing — no Junk entry, no warning. To the recipient it looks like the email simply vanished.
• What Microsoft requires: SPF must pass for the sending domain, DKIM must pass, and a DMARC record must exist at _dmarc.yourdomain and align with SPF or DKIM. A record as simple as v=DMARC1; p=none — which changes nothing about delivery elsewhere — is enough to pass the new check.
• Consumer mail only (so far): the same senders' mail to Microsoft 365 business mailboxes is still accepted. Google's Gmail introduced equivalent sender rules for bulk senders in 2024, so the direction is clear industry-wide.

3. What Virtue IT Checked on Behalf of Hosted Customers

Following the first reports on Monday morning we ran a fleet-wide email-authentication audit across every customer domain hosted on our cPanel / CloudLinux and TTVPS platforms:

1. DNS record audit: verified each hosted domain's SPF record syntax and coverage, DKIM selector signing, and — critically — the presence of a valid DMARC record at _dmarc.
2. Live test sends: sent test messages from hosted domains to Microsoft consumer addresses (outlook.com) and confirmed delivery acceptance rather than the 550 5.7.1 rejection.
3. Result: every Virtue IT hosted customer domain passed all checks and is already covered. If you are a hosted customer and someone tells you email to you is bouncing, it is their domain that needs the fix — not yours.

4. Recommended Actions for Businesses Hosted Elsewhere

If your domain is not hosted with Virtue IT, or a supplier's messages to you are bouncing with the errors above, verify the following today:

1. Check for a DMARC record: run dig txt _dmarc.yourdomain.com.au (or use a free online DMARC checker). If nothing comes back, that is the cause.
2. Publish a basic record: add a DNS TXT record — host _dmarc, value v=DMARC1; p=none; — then upgrade later to include a reporting address (rua=mailto:dmarc@yourdomain) so you can monitor failures.
3. Confirm SPF and DKIM pass: SPF must list your actual sending servers; DKIM signing must be enabled (Microsoft 365: enable in the Defender portal; Google Workspace: enable in Admin console → Gmail → Authenticate email).
4. If people can't email YOU: forward the bounce message to your supplier or IT provider — the fix belongs to their domain's DNS, not your mailbox. Ask them to publish DMARC and resend.