What Outlook's High-Volume Sender Rules Mean for Agency Client Domains
Since May 5, 2025, Outlook.com has enforced authentication requirements for domains that send more than 5,000 messages a day to Microsoft consumer mailboxes. Most agency teams read that number and decide it does not apply to them. A single client mailbox doing 30 to 50 cold sends a day is nowhere near 5,000.
That is the wrong unit to measure. Microsoft counts by the domain in the visible From address, not by mailbox, and the cost of getting it wrong lands on the client's domain, not the agency's.
What Microsoft actually requires
Microsoft's support article for the 550 5.7.515 error defines a high-volume sender as one that sends 5,000 or more messages to Microsoft consumer email services where all of those messages use the same domain in the 5322.From address. Once a domain crosses that line, Microsoft expects every message from it to:
- Pass SPF and DKIM for the domain.
- Publish a DMARC record, at minimum
p=none. - Pass DMARC, meaning SPF or DKIM (at least one) aligns with the From domain.
The Outlook.com postmaster policy page says non-compliant mail from these senders goes to Junk first, and that unresolved issues can lead to rejection with 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level. Microsoft recommends p=reject and alignment on both SPF and DKIM, while only requiring the minimum.
"Microsoft consumer email services" means mailboxes like outlook.com, hotmail.com, and live.com. It is a separate question from how a prospect's corporate Microsoft 365 tenant filters mail.
Why the threshold matters more than it looks
Three agency patterns push a client's From domain toward the line without anyone noticing:
- Many mailboxes, one domain. Ten sender mailboxes on the same client domain, each running a modest daily cap, all count toward one total if they share a From domain.
- The client's own marketing. If the client's newsletter platform sends from the same root domain your cold mailboxes use, the client's volume and your volume share a From domain.
- Lists with consumer addresses. B2B lists still carry personal outlook.com and hotmail.com addresses, especially for founders and small-business owners. Those are exactly the mailboxes this rule covers.
The fix is not to calculate how close you are. It is to meet the requirement on every client domain before the first send, so the threshold never becomes the thing that trips a campaign.
A per-client check before sending to Microsoft consumer mailboxes
Run this for each client sending domain during setup, and again whenever the client changes email providers or adds a sending tool.
1. Confirm SPF covers every service that sends as the domain. The client's mailbox provider, any sending platform, and any marketing tool. Microsoft's guidance is that the SPF record must list the IPs or include values the sending service requires.
2. Confirm DKIM signs with the client's domain. Not the vendor's shared domain. DKIM that passes for a vendor domain does not align with the client's From address.
3. Publish DMARC and read the reports. p=none meets the minimum. It also gives you aggregate reports that show which sources are sending as the domain. That is where you find the forgotten tool that will fail alignment.
4. Send a test to a Microsoft consumer mailbox and read the headers. Look for SPF, DKIM, and DMARC results in the authentication headers. A pass on all three is what you want before live volume.
5. Know what the bounce looks like. Add 5.7.515 to your bounce taxonomy as an authentication failure, not a list-quality problem. It means pause sending on that domain and fix DNS, not suppress the prospect.
6. Keep cold and marketing mail on separate domains where you can. This keeps volumes and reputations apart. We have written before about separating agency reputation from client sending domains, and the same logic applies inside a client's own footprint.
What this does not change
Authentication gets mail evaluated fairly. It does not make cold email wanted. Microsoft's sender support page says junk email complaint rate is one of the principal factors that drives down a sender's reputation, along with list accuracy and volume. A fully authenticated domain sending to bad data will still land in Junk.
Microsoft's policies also say senders must not use namespace mining, which it defines as verifying addresses against Outlook.com servers without sending. Ask your verification vendor how they check Microsoft consumer addresses.
Where GTM fits
GTM runs each client in an isolated workspace with its own connected email domains, send windows, daily limits, and a compliance gate that refuses any send without a verdict and an unsubscribe URL. Proving authentication per client domain, as we covered in how agencies prove SPF, DKIM, and DMARC per client before first send, is the groundwork that keeps one client's DNS gap from becoming a pipeline problem.
If you run outbound across several client domains, join the waitlist.
Sources
- Outlook.com Postmaster, announcements: https://postmaster.outlook.com/policies.aspx
- Outlook.com Postmaster, policies: https://substrate.office.com/ip-domain-management-snds/postmaster/Policies
- Microsoft Support, "Fix NDR error 550 5.7.515 in Outlook.com": https://support.microsoft.com/en-au/topic/fix-ndr-error-550-5-7-515-in-outlook-com-34cfe8f8-6fbf-457e-9e8b-9e4dbaf4e0ef
- Microsoft Tech Community, "Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders": https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730
- Microsoft Support, "Sender Support in Outlook.com": https://support.microsoft.com/en-us/office/sender-support-in-outlook-com-05875e8d-1950-4d89-a5c3-adc355d0d652