Hotmail and Outlook.com may be bouncing your email. Check for one DNS record
If your business sends email from its own domain, and some of your customers use Hotmail, Outlook.com or Live addresses, check one thing today: does your domain have a DMARC record?
Since 5 November, email services have been reporting that Microsoft's consumer mail is turning away some messages from domains without one. Microsoft hasn't announced it. But the fix is a single line of DNS, it's good practice anyway, and it takes ten minutes.
What's been reported
The email security firm MailRoute reported it first, from bounces in its own logs. It says Microsoft's consumer service has been turning away "some of the email from domains that don't publish a DMARC record". The bounce looks like this:
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)The addresses affected are the consumer ones: outlook.com, hotmail.com, live.com and msn.com. A write-up from mxio, another email service, gives the same error and the same start date, and points out it's a permanent rejection. Outlook won't try again later. The email just doesn't arrive, and the sender gets a bounce they may never read.
Two things make this one easy to miss. It hits ordinary small senders, not just the big mailing list companies. And only some messages bounce, so a test email to your own Hotmail account might go through fine.
Why this is new
Microsoft did publish rules for this, back in April 2025. Its post on the Microsoft Tech Community blog said domains sending more than 5,000 emails a day to Outlook.com, Hotmail and Live addresses need SPF, DKIM and DMARC, with DMARC "at least p=none". Most small businesses send nowhere near 5,000 a day, so most of us quite reasonably ignored it.
What's being reported now goes further than that published rule. As far as I can find, Microsoft still hasn't said anything about it. So I can't tell you exactly what its systems check, or whether it's deliberate and here to stay. Treat the detail as reported, not confirmed. The fix below is sensible whatever the answer turns out to be.
Business mailboxes on Microsoft 365 don't appear to be affected so far. That's the receiving end, though. If your business sends from Microsoft 365 to customers on Hotmail, you're on the sending end, and that's the bit that matters.
Does it affect you?
You need a DMARC record if you send email from your own domain. That's your normal mailboxes, and it's also the email your website sends: contact form replies, order confirmations, password resets, invoices from your accounts software. Those last ones are the quiet worry, because nobody's watching for the bounce.
To check, open a terminal and run this, with your own domain:
dig +short TXT _dmarc.yourdomain.co.ukIf you get back something starting v=DMARC1, you have one. If you get nothing, you don't. If you don't have a terminal handy, any online DMARC checker will tell you the same thing.
What to do this week
1. Add a DMARC record if you haven't got one. In your DNS, add a TXT record with the name _dmarc and this value:
v=DMARC1; p=nonep=none means "don't block anything, just tell me what's happening". It's the safe place to start. Don't jump straight to p=reject. If something legitimate isn't set up properly, that setting tells everyone to throw its mail away.
2. Make sure SPF and DKIM actually pass. A DMARC record on its own isn't enough. It only passes when SPF or DKIM passes for the same domain as the From address. If you're on Microsoft 365, check DKIM is actually switched on for your domain, not just SPF. Google Workspace has a similar setting.
3. Find everything that sends as you. Your website, your shop, your newsletter tool, your accounts package. Each one needs to be covered by your SPF record or be signing with DKIM for your domain. This is the step that usually turns up a surprise.
4. Look for bounces. If your website or app sends email, check its mail log or the bounce mailbox for that 5.7.1 error since 5 November. Then let anyone who missed an order confirmation or password reset know.
The emails your website sends
I wrote recently about moving your website without breaking your email, and the same lesson applies. Email setup tends to get done once, by whoever built the site, and then nobody looks at it again until something stops arriving.
If your app sends its own email and the developer who built it has moved on, it's worth getting someone to check how it sends and who it sends as. The team at Dev Partners support and maintain existing software, and that sort of check is part of looking after it properly.
If you'd like a second pair of eyes on your DNS, I can go through your domain, tell you what's there, and tell you in plain English what to add.
Liked that? Get the next one by email
When a security flaw lands that could affect your server, I'll email you what it means and what to do. Plus the odd opinion piece. Not often, no spam.