If your app sends sign-in codes, receipts, password resets or a newsletter, some of it may have been bouncing at Outlook.com since November 5. According to MailRoute, an email security company that first saw it in its own outbound logs, Microsoft's consumer mail service (outlook.com, hotmail.com, live.com and msn.com) has started refusing part of the mail from domains that publish no DMARC record. It reaches small, low-volume senders, and as of November 6 Microsoft had announced nothing about it.
The good news is that the fix is one DNS record. The bad news is that most builders send from more domains than they think, and the rejection is partial, so it hides. Below: what the bounce looks like, what changed, why it is easy to miss, how to check every domain you send from, the record to add, the alignment trap that can make that record useless, and how to test that it worked.
What the bounce looks like
The sender gets a rejection like this one, followed by a bracketed server name and an ID that differ per message:
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)
On the first day, MailRoute saw the same text without the AS9031519 code. The wording suggests everything about your mail setup is broken. Usually it is not. The domains MailRoute saw bounced mostly had working SPF, and many had DKIM too. What they were missing was the DMARC record that ties those two checks to the address in the From line.
If you have never looked at these three acronyms: SPF lists the servers allowed to send mail for your domain, DKIM signs each message with a key published in your DNS, and DMARC tells receivers what to do when a message claiming to be from your domain fails both, and where to send reports about it.
What changed
Microsoft already had published sender rules. Since May 2025, domains that send more than 5,000 messages a day to Outlook.com have had to pass SPF, DKIM and DMARC, or get a 550 5.7.515 Access denied bounce. That was a bulk-sender rule, and most small senders rightly assumed it did not apply to them.
The new rejection differs in three ways that matter:
- It reaches small senders. A one-line reply from a small team can bounce.
- It was not announced. As of November 6 there was no postmaster notice, blog post or service-health entry from Microsoft.
- It does not say what failed. A 5.7.515 bounce lists the SPF, DKIM and DMARC results. This one only says records are missing.
Why builders miss it
Microsoft refuses only part of the mail from an affected domain. One message to a Hotmail address goes through, the next one bounces, and a resend may succeed. If you glance at your email provider's dashboard, delivery looks mostly fine, and a scattered handful of bounces reads like noise.
Builders are also more exposed than they look, because a small product usually sends mail from several places at once:
- transactional mail from your app (sign-in codes, receipts, password resets) through a provider such as Resend, Postmark, Amazon SES or SendGrid;
- emails from your auth provider, if you gave it a custom sender domain;
- your newsletter platform;
- your support desk or CRM;
- a separate domain you bought for cold outreach;
- and your own founder address on a personal domain, which is the one most likely to have no DMARC record at all.
The cost is quiet. A user on Hotmail who never gets their sign-in code does not file a bug report. They just never finish signing up, and the bounce sits in a log nobody reads.
Step 1: Check every domain you send from
First, list every domain that appears in a From address across all of the services above. Then check each one from any terminal, replacing yourdomain.com with the domain:
dig +short TXT _dmarc.yourdomain.com
A line that starts with "v=DMARC1 means you have a record. No output means you do not, and that is the case this rejection targets. While you are there, check SPF as well:
dig +short TXT yourdomain.com | grep spf
This is a good job to hand to a coding agent. Give it the list of domains, ask it to run both checks for each one, and have it return a table of domain, DMARC record and SPF record. It takes a minute, and it catches the domain you forgot you send from.
Step 2: Add the DMARC record
At your DNS host, add one TXT record:
- Name: _dmarc
- Value: v=DMARC1; p=none
p=none is the safe starting point. It declares that your domain uses DMARC but tells receivers to take no action when a message fails, so nothing changes about how Gmail, Yahoo or anyone else treats your mail.
It is worth adding one more tag. If you set the value to v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com, receivers send aggregate reports to that address. Those reports show which servers send mail as your domain and whether each one passes, which is exactly what you need later when you want to tighten the policy. Use an address you actually read, or a free DMARC report service, because the raw reports are XML.
Step 3: Make sure SPF or DKIM lines up
There is one condition that catches people. DMARC passes only when SPF or DKIM passes for the same domain as your From address. This is called alignment. If neither lines up, a DMARC record on its own will not help, and some mail will keep bouncing.
In practice, alignment usually fails in one of two ways:
- Your provider signs with its own domain. Many services sign mail with their own domain until you set up authentication for yours. MailRoute's example is Microsoft 365, which signs with its onmicrosoft.com domain until you turn on DKIM for your own domain, and that signature does not count toward DMARC.
- You skipped the DKIM records. Most email providers give you a set of DNS records to publish when you add a sending domain. If you got sending working but never published the DKIM records, your mail may go out without an aligned signature.
The fix is the same in both cases. Open each provider's domain settings, publish every DNS record it asks for, and wait until it shows the domain as verified. Do it for every service on your list from Step 1, not just the one that sends the most mail.
Step 4: Test that it worked
Because the rejection is partial, one successful test proves very little. Send several messages from each domain to an outlook.com or hotmail.com address you control. Then open one of the received messages, view its original headers, and find the Authentication-Results line. You want to see dmarc=pass, together with spf=pass or dkim=pass for your own domain.
Check your provider's bounce log for the 550 5.7.1 text too. If those bounces stop after the record goes live, you have found the cause. If they continue, alignment is the next place to look.
One prompt for the whole check
If you would rather not do this by hand, the whole audit fits in one prompt for a coding agent that has shell access:
"Here is every domain I send email from: [list]. For each one, use dig to read the _dmarc TXT record and the SPF record. Return a table with the domain, its DMARC record and its SPF record, and write out the exact TXT record I should add for any domain that has no DMARC. Do not change any DNS records yourself."
The last sentence matters. Reading DNS is safe and fast, so let the agent do all of it. Writing DNS is the kind of change you want to make yourself, at your DNS host, with the record in front of you, because a typo in an SPF or DMARC record can break delivery for every service at once.
Where this is heading
None of this is a surprise in direction, only in timing. Google and Yahoo started requiring DMARC from bulk senders in February 2024, and Microsoft followed for bulk senders in May 2025. The pattern is consistent: requirements start with bulk senders, arrive with a deadline, and then quietly become the baseline for everyone. A DMARC record at p=none is now the floor, not a best practice.
It is also worth doing for its own sake. Spoofing is how a lot of phishing and business email fraud starts, and a domain that authenticates is much harder to impersonate. Once your reports show every legitimate sender passing, you can move from p=none to p=quarantine and then to p=reject, which tells receivers to refuse mail that forges your domain.
Practical takeaways
- Since November 5, Outlook.com, Hotmail, Live and MSN refuse part of the mail from domains with no DMARC record, small senders included.
- The bounce reads: 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records.
- List every domain that appears in a From address: app, auth, newsletter, support, outreach and personal.
- Add a TXT record at _dmarc with v=DMARC1; p=none, plus a rua address for reports. It changes nothing for other receivers.
- DMARC passes only when SPF or DKIM lines up with your From domain, so publish every DNS record your providers ask for.
- Test with several messages, because the rejection is partial, and read the Authentication-Results header.
Conclusion
This takes about ten minutes and prevents the slow, invisible kind of churn: the sign-in code that never arrives and the receipt that looks like you ignored someone. Check every domain you send from today, add the record wherever it is missing, and make sure every provider signs as you.
We found this through the weekly feed in the HelloBuilder newsletter, where it ran under Growth & Money. The original write-up, with the bounce samples, is MailRoute's post.
