Outlook and Hotmail bounced your email? What happened and what to do

From about 5 November 2026, some businesses found that their email to customers with @outlook.com, @hotmail.com and @live.com addresses came straight back. The bounces read like this:

550 5.7.23 The message was rejected because of Sender Policy Framework violation

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

These weren't bulk senders. The reports on Microsoft's own Q&A forum came from businesses sending a handful of messages a day, and plenty of them had their email records set up correctly.

Microsoft has since explained it. A Microsoft moderator on that forum, citing Microsoft's service health incident EX1545193, says a recent update to spam enforcement rules wrongly identified some legitimate email as failing SPF. Microsoft rolled the change back, marked the incident "Service Restored", and says messages that failed during that time may need to be resent.

So this wasn't a new rule, and most senders didn't need to change anything to get their mail moving again. There are still two jobs worth doing this week: resend what bounced, and check the records that decide whether your mail is trusted, because plenty of business domains still have gaps there.

First, resend what bounced

• Find what bounced. Look for non-delivery reports from early November to outlook.com, hotmail.com and live.com addresses, in Outlook and in any system that sends email as you: the accounting package that emails invoices, the CRM, the booking system.
• Resend it. Microsoft's own advice is that failed messages may need to be resent. Don't assume your customer will chase a missing invoice or appointment reminder.
• If a new message still bounces, keep the whole bounce message (Outlook calls it a non-delivery report) and the time it happened, check your records against the steps below, and if they're right, ask your Microsoft 365 admin to raise it with Microsoft support. If your email runs on another provider, such as Google Workspace or Zoho, raise it with that provider instead, with the bounce attached.

If you're the person with the Hotmail or Outlook.com address and expected emails never arrived, there's no setting on your side that fixes this. Ask the sender to send them again.

What Microsoft actually requires

The published rule dates from April 2025. Microsoft announced that domains sending more than 5,000 messages a day to its consumer service (outlook.com, hotmail.com and live.com addresses) must pass SPF and DKIM, and publish a DMARC record of at least p=none that aligns with SPF or DKIM. Enforcement began on 5 May 2025, and mail that fails is rejected with the error 550 5.7.515.

The November bounces weren't that rule: they carried different codes, hit senders far below the threshold, and Microsoft has put them down to a faulty spam rule. But the 2025 announcement also said enforcement "first targets large senders" and that all senders benefit from the same practices. It's a fair bet the bar comes down over time, and a domain that already meets it has nothing to worry about when it does.

Is your domain set up properly?

Two things decide it: whether you send email from your own domain, and whether that domain has SPF, DKIM and a DMARC record. Microsoft 365 doesn't create a DMARC record for your custom domain. Someone has to add it at your DNS host, and many small businesses never did.

To check, open Command Prompt on a Windows PC and run:

nslookup -type=txt _dmarc.yourdomain.com.au

If the answer includes a line starting v=DMARC1, you have a record. If it comes back empty, you don't.

Then think about everything else that sends email as your domain: the accounting package, the booking system, the website contact form, the newsletter tool. DMARC passes only when a message passes SPF or DKIM for a domain that matches the From address. A record on its own doesn't help a service that isn't set up to sign as you.

How to set it up

Do these in order. The first two matter because DMARC builds on them.

1. Check SPF. Your domain should have exactly one TXT record starting v=spf1. For Microsoft 365 it includes spf.protection.outlook.com; another email provider gives you its own entry to include. Add every other service that sends as you too. Two SPF records, or more than 10 DNS lookups, make SPF fail.
2. Turn on DKIM for your own domain. On Microsoft 365: in the Microsoft Defender portal, go to Email authentication settings and the DKIM tab, select your domain, and follow the prompts to publish the two CNAME records at your DNS host before switching signing on. Mail sent as your custom domain needs this. The built-in onmicrosoft.com signing doesn't align with your domain. On another provider, such as Google Workspace or Zoho, turn DKIM on in its admin settings and publish the records it gives you.
3. Publish a DMARC record, or keep the one you have. A domain must have only one DMARC record, so if the check above found one, leave it in place, and never swap a p=quarantine or p=reject policy back to p=none. If there was none, at your DNS host add a TXT record with the host name _dmarc and a value like v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com.au. The rua address receives daily reports from the big mail providers about who is sending as you, so it must be a mailbox someone actually reads, or the address a DMARC reporting service gives you. If that service's address is on another domain, check the service is set up to accept reports for yours, or the reports won't arrive.
4. Read the reports, then enforce. Give it a few weeks, fix any genuine service that fails, then move to p=quarantine and finally p=reject. Microsoft recommends exactly this gradual path, and ASD's ACSC treats quarantine or reject as the goal. Our guide to SPF, DKIM and DMARC walks through each stage, including the forwarding and mailing-list problems to check before you enforce.
5. Lock down the domains you don't use for email. For a domain that never sends mail, Microsoft's guidance is an SPF record of v=spf1 -all and a DMARC record of v=DMARC1; p=reject;. It costs nothing and tells mail servers to refuse anything sent in that domain's name.

Be clear on what step 3 does and doesn't do. A p=none record doesn't stop anyone pretending to be you: it only asks for reports. Criminals sending fake invoices from your exact address, a common business email compromise trick, are only dealt with by DMARC once you reach quarantine, where the receiving server sends failing mail to junk or quarantine, or reject, where it refuses it outright. Even then it depends on the receiving server applying your policy, which it may choose not to. It does nothing about mail sent from a genuine account that has been broken into, because that mail passes.

Where Geidi fits

Our cloud and business systems service sets up and manages the Microsoft 365 platforms your people work in every day, including the SPF, DKIM and DMARC records behind your email, alongside our 24/7 security operations centre. If you'd like us to check your domain and plan the move to enforcement, talk to us.

Sources

• Microsoft Q&A: SPF Validation Error, with Microsoft's update on incident EX1545193 (November 2026) (opens in a new tab)
• Microsoft Q&A: Incoming emails being blocked due to lack of SPF/DKIM/DMARC records on my @outlook.com account (November 2026) (opens in a new tab)
• Microsoft Defender for Office 365 blog: Outlook's new requirements for high-volume senders (April 2025, updated 29 April 2025) (opens in a new tab)
• Microsoft Learn: Set up DMARC to validate the From address domain for cloud senders (opens in a new tab)
• Microsoft Learn: How to use DKIM for email in your custom domain (opens in a new tab)
• Microsoft Learn: Set up SPF to identify valid email sources for your Microsoft 365 domain (opens in a new tab)
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (opens in a new tab)
• ASD's ACSC: How to combat fake emails (opens in a new tab)