Microsoft's sender requirements (Outlook, Hotmail) in 2025

Shared or dedicated IPs: which reputation actually belongs to the sender?

Where sending goes through a routing platform rather than in-house servers, Microsoft tracks two distinct ledgers: the reputation of the sending IP and the reputation of the domain. On a shared IP pool, the first is collective — the behavior of the platform's other customers is inherited, for better or worse, and SNDS visibility on those IPs usually sits with the platform rather than with its customer. Domain reputation, by contrast, belongs entirely to the sender: it's fed by its authentication results and by how recipients react to mail carrying its name. That's precisely why aligned DKIM matters so much in this setup — it's the lever that remains fully under the sender's control when the IP layer isn't.

Microsoft's filtering: Junk Email Reporting and SCL

Microsoft uses its own scoring system, the SCL (Spam Confidence Level), which determines where a message lands: inbox, junk folder, or outright block. That score draws on authentication (SPF/DKIM/DMARC), IP/domain reputation (partly visible via SNDS), and content analysis — logic close to Gmail's, but with its own internal weightings, not published in detail.

One specific signal worth watching: the Junk Email Reporting Program (JMRP), the program through which Outlook users report a message as junk. As with Gmail, a high complaint rate quickly degrades reputation — but signing up for JMRP (distinct from SNDS) delivers a direct copy of the reports filed against a sender's own emails, an early warning signal few senders take advantage of — most only discover a spike in complaints weeks later, once it has already dragged their reputation down, instead of seeing it happen in near real time.

DMARC alignment: the same rules, sometimes stricter behavior

DMARC works to the same standard at Microsoft as everywhere else — SPF/DKIM alignment with the From: has nothing specific to this ecosystem. What differs, in practice, is that some administrators report slightly stricter handling of alignment failures at Outlook compared to Gmail, particularly on edge cases. The practical lesson: a DMARC setup "that passes at Gmail" can't be assumed automatically sufficient at Microsoft — each source's alignment deserves a specific check in the DMARC aggregate reports, with an eye on outlook.com/hotmail.com recipients in particular.

Microsoft 365 on the business side: another layer

Where part of the recipient base uses Microsoft 365 in a business environment rather than the consumer domains, enterprise administrators have additional filtering layers (Exchange Online Protection, custom transport rules, internal block lists) stacked on top of standard Microsoft filtering. Flawless authentication doesn't guarantee passing an aggressive internal block rule set by a recipient's administrator — a factor outside the sender's control, but useful to know, so that nobody goes hunting for a DMARC bug where none exists — a corporate mail admin's local block list can override every signal carefully built up, and no amount of reporting will surface that override.

Microsoft compliance checklist

• Aligned SPF and DKIM, specifically checked on traffic to outlook.com/hotmail.com in the reports.
• DMARC published, with a goal of ramping to quarantine then reject using the same method as for any other receiver — see getting to p=reject without breaking email.
• SNDS signup for IP reputation visibility, where the sending IPs are under the sender's control.
• JMRP signup to receive direct spam reports on the domain's own sends.
• List hygiene identical to what's recommended for Gmail — Microsoft watches the same behavioral signals (complaints, bounces, engagement).
• A functional, visible unsubscribe, reducing reliance on the "report as junk" button.

The Microsoft hardening timeline

One point worth knowing at roadmap-building time: Microsoft's enforcement pace hasn't always followed Gmail's and Yahoo's. Where Google communicated a precise, dated timeline right from its initial 2024 announcement, Microsoft long proceeded through gradual filtering adjustments without an equally structured public announcement. The practical consequence: "Google's deadline has passed, so everything is settled everywhere" is never a safe assumption. Microsoft's filtering keeps evolving independently, and a domain that sailed through six months ago can see its Outlook deliverability degrade with no change on the sender's side being the cause — simply because Microsoft's tolerance threshold moved.

That's one more argument for treating reputation monitoring (via SNDS) as an ongoing exercise, not a box checked once during initial compliance work — it earns a recurring slot in the calendar exactly like Google Postmaster Tools, rather than being remembered only after deliverability has already dropped.

A practical case: a French B2B sender

Let's take a concrete example to ground these notions. A French SMB sending invoices and reminders by email reaches a mix of business recipients — often on enterprise Microsoft 365 domains — and consumers, more spread across Gmail, Outlook.com/Hotmail, and French ISPs (Orange, Free, SFR). For this SMB, ignoring the Microsoft layer isn't a marginal option: it's potentially half its business traffic running through that ecosystem.

The right reflex is to treat DMARC configuration as universal (one record, valid for all receivers) but reputation monitoring as ecosystem-specific: Postmaster Tools for the Gmail share, SNDS for the Microsoft share, and vigilance on DMARC aggregate reports to spot whether a particular receiver shows an abnormally high failure rate compared to others. This differentiated vigilance costs little time once set up, and it avoids the most common blind spot among senders: excellent Gmail deliverability masking mediocre Outlook deliverability, simply because nobody was watching that side. For a domain sending mostly business invoices and account notifications, that blind spot translates directly into missed payments and confused customers calling support to ask why they never got an email that, from the sender's dashboard, looked perfectly delivered.

Why Gmail compliance alone isn't enough

The most common reasoning error: "I'm already compliant for Gmail, so I'm compliant everywhere." Technically, authentication (SPF/DKIM/DMARC) is indeed the same DNS configuration for all receivers — no duplication needed on the record side. But reputation is specific to each ecosystem: a domain's reputation at Google and its reputation at Microsoft are two independent histories, built on signals observed separately by each. Excellent deliverability at Gmail guarantees nothing at Outlook, and vice versa — the two filters draw their conclusions from their own users, not from a repository shared across providers.

In summary

The DMARC/SPF/DKIM foundations are universal and only need configuring once. What changes at Microsoft is the visibility tooling (SNDS, JMRP) and the fact that reputation builds independently of whatever has been earned at Gmail. A serious DMARC rollout covers both ecosystems from the start, without waiting for a deliverability incident specific to one of them before paying attention.

To confirm authentication is correctly configured — the identical prerequisite regardless of receiver — a domain run through the free DMARC analyzer settles it. It's the common starting point for both ecosystems; reputation monitoring then plays out separately at each, and neither substitutes for the other.