Why Hotmail and Outlook.com are rejecting some business emails

What's happening

Since the first week of November 2026, people sending email to Microsoft's personal addresses, such as those ending in @hotmail.com, @outlook.com and @live.com, have been getting bounces, and the people they were writing to have been reporting them on Microsoft's support forum. The error reads:

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

One of our clients forwarded us one on 8th November. Their email runs on Microsoft 365 and their SPF record was set up correctly, but their domain had no DMARC record, and DKIM hadn't been set up for it.

At the time of writing, on 9th November 2026, Microsoft hasn't announced a change. On its own support forum, a moderator has said contributors there can't confirm whether the reports have reached the Outlook.com team. What Microsoft has published is a set of requirements from April 2025 for domains sending more than 5,000 emails a day to its personal addresses: SPF and DKIM must pass, and the domain needs a DMARC record set to at least p=none that passes using SPF or DKIM.

The bounces being reported now include small businesses that send nowhere near that many, and in some of the reported cases, adding a DMARC record to the sending domain stopped them. The rejections also seem to be intermittent, and some people have reported bounces from senders whose records look correct, so a missing DMARC record may not be the only cause. All the reports we've seen involve email sent to Microsoft's personal addresses, and we haven't seen the same bounce from business mailboxes, including those on Microsoft 365.

What SPF, DKIM and DMARC do

All three are records in your domain's DNS, the settings that tell the rest of the internet where your website and email live. None of them is new, and Gmail has had requirements for them since 1st February 2024.

SPF lists the mail servers that are allowed to send email as your domain. When a message arrives, the receiving server checks whether it came from one of them.

Once it's set up, DKIM adds a digital signature to the emails you send, and the receiving server checks it against a key published in your DNS. If the signature checks out, it knows the message was signed by your domain and wasn't changed on the way.

DMARC tells receiving servers what you'd like them to do with an email that claims to be from you but fails those checks, and where to send reports about the email they've seen. A message passes DMARC if either SPF or DKIM passes for the domain in its From address, so under the DMARC standard it only needs one of the two.

Why a DMARC record on its own has stopped some of the bounces

If your SPF record is set up properly, emails sent through your main mail service, such as Microsoft 365, already pass SPF for your own domain. Once a DMARC record is published, those emails pass DMARC as well, which seems to be what has cleared the bounce in the cases where adding one worked.

A DMARC record set to p=none asks receiving servers to take no specific action, so it doesn't ask anyone to reject or junk your email, which makes it a safe first step. If the record includes a reporting address, receiving servers such as Microsoft and Google send reports showing which servers are sending email as your domain. That helps you spot other services using your domain, such as a newsletter tool, a booking system or your website's contact form, and whether each one is passing.

Why DKIM is still worth setting up

SPF checks the server that hands the message over. When an email is forwarded, say from someone's work address to their Hotmail, it arrives from the forwarding server instead, which isn't in your SPF record, so the SPF check no longer passes for your domain. A DKIM signature travels with the message, so it can still pass, and that can keep the email passing DMARC.

It's also worth having DKIM in place before moving DMARC on from p=none to a stricter setting. That's the setting that tells receiving servers to junk or reject email that fails, which is how you stop email pretending to be from you, and without DKIM, genuine email that's been forwarded could be turned away too.

If your email is on Microsoft 365, DKIM isn't switched on for your own domain until someone sets it up. Microsoft's own documentation says that "no DKIM signing occurs for outbound mail from custom domains" until it's configured. Setting it up means adding 2 records to your DNS and turning on signing in Microsoft 365, so it needs someone with access to both.

How to check your own domain

MXToolbox's DMARC Check Tool will tell you whether your domain has a DMARC record, and the same site can look up your SPF record.

DKIM is harder to check from outside, because you need to know the name your provider gives its signature. The quickest way is to send an email to an address on a different service and look at its headers, where you're looking for "dkim=pass" alongside your own domain. If it shows "dkim=none" or a different domain, DKIM isn't set up for yours.

How we can help

If we look after your domain's DNS, we're adding a DMARC record to every domain that doesn't already have one, at no charge, and we'll let you know if yours needs anything else, such as DKIM.

If your domain is managed elsewhere, get in touch and we'll check it and tell you what it needs. We can set up DKIM, make sure the other services that send email as you are covered, and move DMARC on to a stricter setting once the reports show everything is passing. We'll quote for that work before we start.