Research · Deliverability · Living page
Newsletter going to Outlook's junk folder? Here's why, and the 2026 fix
The short version: Outlook routes newsletters to junk for three reasons that Gmail often ignores. First, complaint rate: Microsoft treats it as the top signal, stricter than the 0.3% floor that governs Gmail. Second, DMARC in monitoring mode (p=none): in 2026, Microsoft is no longer treating that as sufficient; you need an enforcement policy. Third, the "noisy neighbor" problem on your ESP's shared sending IPs. The fix is the same authentication checklist as Gmail, but with two extras: enroll your sending IPs in Microsoft's Smart Network Data Services (SNDS) to see your complaint data, and move your DMARC policy from monitoring to enforcement once alignment is confirmed.
How Microsoft is different from Gmail and Yahoo
Gmail and Yahoo announced bulk-sender authentication requirements in February 2024, and the email world spent a year focused on them. Microsoft moved later and more quietly. As of 2026, its enforcement of SPF, DKIM, and DMARC alignment has tightened to roughly the same level. Microsoft does add one priority that Gmail treats as secondary.
Where Gmail weighs authentication and content signals roughly equally, Microsoft weights junk-complaint rate above nearly everything else. Palisade Email, which analyzed Microsoft's published sender guidelines, puts it plainly: complaint rate is "one of the principal factors in driving down a sender's reputation" at Microsoft.
The practical difference: a newsletter with clean authentication but a list full of disengaged subscribers will land in Outlook's junk folder before Gmail's. If your open rates are fine on Gmail and your Outlook delivery is failing, complaint rate is the first thing to check.
The other difference is reputation throttling. Microsoft can cap the daily message volume from a sender it views as poor-reputation. Gmail typically downgrades inbox placement. Microsoft can restrict total send volume, which makes diagnosing the problem harder because the failures are silent.
The 2026 DMARC change: p=none is no longer enough
Until recently, adding a DMARC record at p=none (monitoring mode) satisfied Microsoft's requirements. Monitoring mode tells receiving servers to report failures but do nothing about them. It was sufficient to show you had DMARC set up, even if you weren't enforcing it.
That changed in 2026. Microsoft has aligned its enforcement with Google and Yahoo, and monitoring-only DMARC is no longer treated as equivalent to an enforcement policy. Domains without DMARC alignment on both SPF and DKIM are now classified as risky, and "risky" at Microsoft means junk folder placement or rejection.
The fix is to move from p=none to p=quarantine, then to p=reject once you have confirmed that all legitimate mail from your domain is passing authentication. That confirmation step matters: jumping straight to p=reject without verifying alignment can cause legitimate mail to be rejected. The safe path is: set up a Verified Sending Domain in Kit first (which handles SPF and DKIM alignment), then add DMARC at p=none and read reports for two to four weeks, then move to p=quarantine, then p=reject.
Our email newsletter deliverability guide covers the Kit authentication setup in full. That setup is the prerequisite for everything here.
The shared IP problem
Newsletter senders on Kit, MailerLite, beehiiv, or any managed ESP send from shared IP addresses by default. You share that IP pool with every other sender on that platform. Most senders are legitimate. But if someone else on the same IP runs a bad campaign (low engagement, high complaints, spam trap hits), Microsoft can block or throttle the entire IP pool. Your newsletter gets flagged even though you did nothing wrong. This is the "noisy neighbor" problem.
The bounce code that signals a noisy-neighbor IP block looks like this: 550 5.7.1 followed by an IP reputation failure message. At that point, your newsletter platform's deliverability team is your first call. They can move you to a clean IP or work with Microsoft to clear the block on their infrastructure.
If you are on Kit: Kit's deliverability team handles IP reputation management across their infrastructure. A hard block is escalated through their support channel. The delist process described below is for cases where your own domain is blocked. Platform IP blocks go through your ESP's support.
NDR codes: what Microsoft is telling you
Non-Delivery Reports from Microsoft include specific codes that diagnose the reason for a failed or filtered message. These are worth reading before you start troubleshooting, because the fix differs by code.
| Code | What it means | Where to start |
|---|---|---|
550 5.7.515 |
Authentication does not meet requirements; mail placed in junk before rejection | Check SPF, DKIM, DMARC alignment — all three must pass together |
550 5.7.509 |
DMARC verification failed specifically | Verify your From domain matches your DKIM signing domain; check DMARC record syntax |
421 RP-001 to RP-003 |
Reputation-based throttling — not a hard block but a rate limit | Check complaint rate in SNDS; clean your list before the next send |
If you see SFV:SPM in the X-Forefront-Antispam-Report header of a message that did deliver, the spam filter flagged it as likely spam even though it got through. A few of those back to back, combined with recipients marking as junk, pushes your complaint rate up. Checking email headers is a two-minute diagnostic that most senders skip.
The fix: a step-by-step checklist for newsletter senders
Your part: about 30 minutes to set up, then a monthly SNDS review. The AI handles diagnosis, record formatting, and tracking the DMARC progression. You step in for three logins: your Kit account, your DNS host, and a Microsoft account for SNDS.
- AI+HUMAN: account Set up a Verified Sending Domain in Kit. Go to Settings → Email → Verified Sending Domains. Add your sending domain. Kit sets up SPF and DKIM alignment through this step. Without it, your From domain and signing domain will not match, and DMARC alignment will fail. Full setup is in our deliverability guide.
- AI+HUMAN: account Add a DMARC TXT record at your DNS host. Start with
v=DMARC1; p=none; rua=mailto:[email protected]. This starts collecting aggregate reports without affecting delivery. Kit's DMARC guide covers the exact format. - AI-RUN Read DMARC aggregate reports for two to four weeks. The reports show which sources are sending mail from your domain and whether they pass SPF and DKIM. An AI can parse these and flag any failures.
- AI+HUMAN: account Move DMARC to p=quarantine once alignment is confirmed. Once reports show all legitimate mail passing, update the DNS record to
p=quarantine. This puts unauthenticated mail in spam instead of rejecting it outright. A safer transition. - AI+HUMAN: account Enroll your sending IPs in Microsoft SNDS. Go to postmaster.live.com (Smart Network Data Services). Log in with a Microsoft account, request IP authorization, and wait for access (typically 24 hours). SNDS shows your traffic volume, spam filter results, and complaint rate from Microsoft's mail servers.
- AI+HUMAN: account Enroll in JMRP (Junk Mail Reporting Program). JMRP delivers individual complaint reports when recipients on Hotmail or Outlook mark your messages as junk. Without it, you are flying without complaint visibility on Microsoft's user base.
- AI-RUN Review SNDS monthly before each major send. Check complaint rate and spam filter hit percentage. If either climbs, run a list-hygiene pass before the send: suppress subscribers who have not opened in 90 days before you mail them again.
- AI+HUMAN: account If blocked: submit to the Microsoft delist portal. Go to sender.office.com. Enter your domain name, sending IP, and the bounce code from your NDR. Microsoft's team reviews and removes the block if the issue is cleared. This portal handles hard blocks on your own domain; platform IP blocks go through your ESP's support channel.
Two things to keep under control once you're set up
Complaint rate. Microsoft's junk-complaint rate is the number to watch. Keep it below 0.3% per send (aim for under 0.1%, which is Kit's internal threshold). The fastest way to drive it up is mailing people who forgot they signed up. Double opt-in at the form level is the prevention; re-engagement sequences are the cure. Subscribers who have not opened in 90 days are your highest complaint risk — clean that segment before the next send.
Email size. Unspam.email, citing Hotmail's published guidelines, recommends keeping messages under 100KB. Most newsletter platforms produce HTML emails with embedded images that blow past this limit. Check your template's rendered HTML size in your ESP's preview tool. Images should be externally hosted, not base64-encoded inline. A 400KB newsletter HTML is a measurable junk-filter risk at Outlook in a way it is not at Gmail.
What we set up on our account
We run the Field Tested newsletter on Kit, launched in July 2026. Our authentication setup: Verified Sending Domain through Cloudflare (SPF and DKIM live since July 2026), DMARC at p=none since July 2026. We have not yet enrolled in SNDS or JMRP because we have not reached meaningful send volume. At zero subscribers, there is nothing for SNDS to show us.
Our plan for SNDS and JMRP enrollment: before our first broadcast to a list above a few hundred subscribers. At that point, monitoring complaint data from Microsoft's network becomes worthwhile. We will add first-party SNDS data to this page once we have it.
One honest note about DMARC: we are still at p=none, which the 2026 enforcement guidance says is no longer sufficient for reliable Microsoft delivery. Our to-do is to move to p=quarantine once we have two months of aggregate reports showing clean alignment. We are documenting this gap publicly rather than hiding it.