What Are Outlook's Bulk Sender Requirements for Cold Email?

Domains that send more than 5,000 messages per day to Outlook.com, Hotmail, and Live addresses must pass SPF, pass DKIM, and publish a DMARC record of at least p=none that aligns with one of them. Microsoft set this out in its requirements for high-volume senders. An April 29, 2025 update says mail that fails is rejected with a 550; 5.7.515 error, starting May 5, 2025. If your sequences touch those inboxes and your authentication records are incomplete, you have a concrete deliverability problem to fix.

What Microsoft Actually Announced

The requirements mirror what Google and Yahoo rolled out in early 2024. Domains crossing the 5,000 emails/day threshold to Outlook.com and Hotmail recipients must have:

1. A valid SPF record that passes for the sending domain
2. DKIM that passes for the sending domain
3. A DMARC record with at minimum p=none, aligned with SPF or DKIM

The announcement, dated April 2, 2025, first described two phases: Junk-folder routing, then rejection at a later date. An April 29 update changed the plan. Microsoft says it decided to reject messages that fail the requirements, returning 550; 5.7.515 Access denied, sending domain does not meet the required authentication level, with the change taking effect on May 5, 2025.

The rules cover Microsoft's consumer mail service: outlook.com, hotmail.com, and live.com addresses.

The 5,000 Threshold Is Easier to Cross Than It Looks

Five thousand emails per day sounds like a lot. It isn't, for most active cold email operators.

Consider a typical setup: three sending domains, each running 10 to 15 mailboxes, each mailbox sending 40 to 50 emails per day. That's 1,200 to 2,250 messages per domain, or 3,600 to 6,750 across the full rotation. You can hit the threshold with a single well-warmed sending infrastructure.

The count is per sending domain, not per campaign or per tool account. If you run separate domains for different clients or verticals and any single domain clears 5,000 daily sends to Outlook addresses, that domain falls under the requirement. Your other domains do too, because the safest assumption is that your volume patterns put you in scope for all of them.

The Three Requirements, Broken Down

SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers are authorized to send on behalf of your domain. A basic SPF record for a domain using Google Workspace looks like v=spf1 include:_spf.google.com ~all. The ~all softfail is acceptable for compliance, but -all hardfail is better hygiene. Check that every sending IP or mail service your domain uses is included. Forgotten includes from legacy tools are a common failure point.

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing messages. The receiving server verifies the signature against a public key in your DNS. Microsoft's requirement is that DKIM passes; it does not set a key size. 2048-bit keys are the common recommendation, and many default setups from older ESP configurations still use 1024-bit keys. If your DNS host or sending tool generated a DKIM key more than two or three years ago, check it.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and tells receiving servers what to do when checks fail. At minimum, a p=none record satisfies the requirement and starts generating forensic and aggregate reports. A record like v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com covers baseline compliance. Moving to p=quarantine or p=reject over time gives you more protection if your domain is spoofed.

What Happens If You're Non-Compliant

Mail that fails is rejected. The receiving server returns the 550; 5.7.515 bounce, and your campaigns stop delivering to those addresses entirely.

Scope matters here. The requirements are written for Microsoft's consumer domains, not for corporate Microsoft 365 mailboxes. In B2B outreach, the direct exposure is the share of your list on personal outlook.com, hotmail.com, and live.com addresses.

How This Compares to Google and Yahoo

Google's bulk sender requirements have been enforced since February 2024. They cover the same three authentication standards with a nearly identical 5,000/day threshold. Yahoo aligned requirements launched at the same time.

The broader pattern across providers is clear: authentication is becoming a baseline table-stakes requirement, not a nice-to-have. Microsoft is the last major provider to formalize these rules. There is no realistic expectation that non-compliant sending will remain viable anywhere in the medium term.

Compliance Checklist for Cold Email Operators

Go through this for every sending domain you own or manage:

Check	Tool / Method	Pass Criteria
SPF record exists	MXToolbox SPF lookup	Record found, all sending IPs/includes covered
SPF result	Send test, check headers	spf=pass
DKIM record exists	MXToolbox DKIM lookup	Record found for selector
DKIM key size	DKIM record inspection	2048-bit recommended
DKIM result	Send test, check headers	dkim=pass
DMARC record exists	MXToolbox DMARC lookup	Record found
DMARC policy	Record inspection	p=none minimum
DMARC alignment	Headers on received mail	SPF or DKIM aligned with From domain

For each domain, run the check before assuming it's clean. Inherited domains from acquisitions or agency setups frequently have gaps.

How Cold Email Tools Handle This

Instantly and Smartlead both support multi-domain inbox rotation heavily. Neither tool automatically configures your DNS records, but both provide documentation and some UI prompts for DKIM and DMARC during domain setup. The actual DNS changes still happen at your registrar or DNS host.

Quickmail and Woodpecker are more typically used with Google Workspace or Microsoft 365 SMTP connections. If you're sending through those providers, DKIM is handled at the provider level, but you still need to publish SPF and DMARC on your sending domain.

Lemlist has a domain health checker built into the onboarding flow that flags missing authentication records. It doesn't fix them for you, but the visibility helps.

None of these tools can publish DNS records on your behalf. The authentication setup is infrastructure work that lives outside any sending platform.

What This Means for Your Operation

If you run any volume against Outlook or Hotmail addresses, check your DNS records this week. The work is not complicated. For most domains, it's 30 minutes of DNS edits and a few test sends to verify headers. The risk of skipping it is real: non-compliant mail is rejected, and a steady stream of bounces hurts domain reputation further.

Authentication records are infrastructure. Set them once, verify them on a schedule, and move on. The industry has consolidated around these standards. There is no path forward that doesn't require them.