If your app's password reset emails to Hotmail users started bouncing last week with 550 5.7.1 Message lacks SPF/DKIM/DMARC Auth Records, it probably wasn't your code. Since around November 5, 2026, Outlook.com has been rejecting mail from sending domains that have no DMARC record. That covers outlook.com, hotmail.com, live.com and msn.com. Low-volume senders are included, and having SPF and DKIM set up doesn't save you if DMARC is missing.
Microsoft didn't announce it. MailRoute first saw the bounces in its own outbound logs on November 5 and wrote it up the next day. They found no postmaster notice, no blog post and no service-health entry. The Hacker News thread filled up with people who found out the same way, from a bounce.
The fix is one DNS record, plus checking that the records you think you have actually line up. Below are the bounce to look for, the dig commands to confirm it, and the records for the common providers.
What the Outlook DMARC bounce looks like
The rejection is a hard 5xx:
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)
On the first day some bounces came without the (AS9031519) tag. The bracketed server name and ID differ from message to message, so don't write an exact-match filter for it. Grep your MTA logs or your provider's bounce webhook for Message lacks SPF/DKIM/DMARC.
It's easy to miss for two reasons. First, only some messages bounce. MailRoute says a domain with no DMARC record can have some mail delivered and some rejected, so one successful send to your own Hotmail test account proves nothing.
Second, this isn't the 5.7.515 error you may have read about. That one is 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level, and it comes from Microsoft's high-volume sender rules, which apply to domains sending more than 5,000 messages a day. The new 5.7.1 rejection hits everyone and doesn't tell you which check failed.
On HN, jared_stewart said the AS9031519 code "indicates that the domain lacks a DMARC record." The reports in the thread fit that. xmddmx had domains with SPF and DKIM but no DMARC that worked fine until that weekend, "and now only with Outlook". Mail to Gmail kept going through. Tomte got a bounce sending from their own domain on Fastmail with SPF and DKIM set up, "just not DMARC".
"But Microsoft announced this in 2025"
That came up quickly in the thread. ranger_danger linked earlier Microsoft posts and said "They did." donmcronald answered: "That's an old announcement about a different change." donmcronald is right.
The April 2025 Tech Community post covered domains sending over 5,000 messages a day. Those senders needed SPF to pass, DKIM to pass, and DMARC at p=none or stricter, aligned with SPF or DKIM. Non-compliant mail went to Junk after May 5, 2025, and rejection was "date to be announced". Nothing in that post says a side project sending 40 emails a day would start getting hard bounces.
My take: requiring DMARC is fine. The spec is from 2015 (RFC 7489), it costs a TXT record, and as esikich put it in the thread, "You should have done this 5 years ago. Takes like 10 minutes." Bouncing with an error is also better than what several commenters say Microsoft does in other cases. daneel_w described weeks of Hotmail mail where "All envelopes were OKd by Outlook servers, nothing bounced, e-mails just gone." drdaeman said Outlook "blackholed everything I tried to send while 250 OKing me." A 550 at least shows up in your logs.
What isn't fine is changing who the rule applies to without saying anything, and letting thousands of small senders find out from their users' support tickets. Small senders can't call anyone at Microsoft.
Check your domain with dig
Use the domain in your From: header, not your envelope sender or your provider's domain.
# DMARC: no output means no record, which means you're affected
dig +short TXT _dmarc.example.com
# SPF: should return exactly one "v=spf1 ..." string
dig +short TXT example.com
# DKIM: you need your selector; it's in the DKIM-Signature header (s=...)
dig +short TXT s1._domainkey.example.com
dig +short CNAME s1._domainkey.example.com
If your app sends from a subdomain like notify.example.com and there's no _dmarc.notify.example.com, receivers fall back to the organizational domain's record at _dmarc.example.com. So one record at the root covers your subdomains too.
After that, check a real delivered message. Send to a Gmail address, click "Show original", and look for dmarc=pass and which domain passed (header.d= for DKIM, smtp.mailfrom= for SPF). DMARC needs at least one of them to align with the From domain; SPF can pass for amazonses.com and still do nothing for you.
DMARC, SPF and DKIM records for Postmark, SES, SendGrid and Microsoft 365
Publish a DMARC record whatever you send through. Start here:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
p=none tells receivers to take no action when checks fail. That's enough for both the new Outlook rule and the 5,000-a-day rule. The rua address gets daily aggregate reports, which are the only way you'll find that forgotten CRM or that cron box sending as your domain. Keep the report mailbox on the same domain, unless you want to set up the extra authorization record that external report addresses need.
DMARC only passes if SPF or DKIM aligns, so set up the other half too:
| Provider | DKIM | SPF alignment | Gotcha |
|---|---|---|---|
| Postmark | TXT record from the Postmark dashboard |
Custom Return-Path: CNAME pm-bounces.example.com → pm.mtasv.net
|
Without the custom Return-Path, SPF passes for pm.mtasv.net and doesn't align. DKIM alone still gets you a DMARC pass. |
| Amazon SES | Easy DKIM: three CNAMEs | Custom MAIL FROM subdomain (MX + SPF TXT on the subdomain) | Without custom MAIL FROM, SPF authenticates as amazonses.com (AWS re:Post) |
| SendGrid | CNAMEs s1._domainkey and s2._domainkey (Twilio docs) |
em#### CNAME from Domain Authentication |
Single Sender Verification is not domain authentication |
| Microsoft 365 | Enable DKIM for your own domain | SPF include from your tenant setup | Signatures from onmicrosoft.com don't count toward DMARC (MailRoute) |
| Self-hosted | Generate a key in OpenDKIM/rspamd, publish TXT at selector._domainkey
|
v=spf1 ip4:<your IP> -all on the From domain |
Check your PTR record, and run one test through mail-tester.com |
Copy the values from your provider's dashboard, not from my table. Hostnames in the examples above are placeholders, and providers do change their targets.
Keep one SPF record per name. Two v=spf1 TXT records make SPF fail with a permerror, so merge them. If you're on Cloudflare, set the DKIM and return-path CNAMEs to DNS-only instead of proxied. And if you expect to need a few attempts, lower your TTL before you start.
From p=none to quarantine without breaking your own mail
p=none gets you past Outlook. It doesn't stop anyone from spoofing your domain. Once you have the reports:
- Run
p=nonefor two to four weeks and read the aggregate reports. A free parser is fine; the raw XML is unpleasant to read. - Every legitimate source should show DKIM or SPF aligned. Fix the ones that don't: the support desk, the newsletter tool, the invoicing SaaS someone in finance signed up for.
- Move to quarantine gradually:
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com
- Raise
pctto 100, then considerp=reject.
Don't go straight to p=reject just to feel safe. One misconfigured sender will silently lose mail at every receiver that honors your policy, and that includes Gmail and Yahoo as well as Outlook.
The 10-minute checklist
- [ ]
grep -r "Message lacks SPF/DKIM/DMARC"your mail logs or bounce webhooks for the last week - [ ]
dig +short TXT _dmarc.yourdomain.comreturns something - [ ] DKIM is signed with
d=yourdomain.com, not your provider's domain - [ ] Exactly one SPF record
- [ ] A Gmail "Show original" on a real message says
dmarc=pass - [ ] Re-send the password resets and invoices that bounced since November 5
Did any of your domains bounce at Outlook this week, and which provider were you sending through? I'm also curious whether anyone thinks Microsoft was right to skip the announcement. "Everyone should have had DMARC by now" is a fair point, and I still think it's a bad way to roll out a change like this.
Top comments (0)