Outlook.com High-Volume Sender Requirements: What to Do Now

If your mail keeps landing in the Junk folder on Outlook.com, the Outlook.com high-volume sender requirements are the most likely reason. In 2025 Microsoft began enforcing a rule that any domain sending more than 5,000 messages a day to Outlook.com, Hotmail and Live addresses must authenticate that mail with SPF, DKIM and DMARC. Enforcement started on 5 May 2025.

Almost every article about the 2024 bulk-sender rules covers Google and Yahoo and stops there. Microsoft runs its own, separate regime, and it is the one that catches senders out — your Gmail deliverability can look fine while your Outlook.com delivery quietly collapses. This guide is the Microsoft side of that story.

Below is the short answer, the exact records to publish, how Outlook's rules differ from Google's and Yahoo's, and what to do when your mail still goes to Junk after everything is set up.

The short answer: what Outlook requires#

Microsoft's requirement kicks in once your domain crosses roughly 5,000 messages in a day to Microsoft consumer inboxes — Outlook.com, Hotmail, Live and MSN. The count is measured by the domain in your From address, so spreading sends across servers or IPs does not split it.

Above that threshold, three things are mandatory.

• SPF: publish an SPF record and send only from sources it authorizes.
• DKIM: sign your mail with DKIM so receivers can verify it was not altered in transit.
• DMARC: publish a DMARC record with a policy of at least p=none, and make sure your From domain aligns with your SPF or DKIM domain.

Before you start#

Setting this up takes about half an hour of DNS work, plus propagation time. Gather these first so you are not switching tabs mid-record.

• Access to your domain's DNS zone, at your registrar or DNS host.
• A list of every service that sends mail using your domain — ESP, CRM, help desk and transactional provider.
• The DKIM setup instructions or keys from each of those services.
• A mailbox or shared group to receive DMARC reports (the rua address).

How to set up SPF, DKIM and DMARC for Outlook#

Do these in order. SPF and DKIM come first because DMARC depends on them, and alignment is the step people most often skip.

1. 1

   Publish or fix your SPF record

   In DNS, add one TXT record that starts with v=spf1 and lists every service allowed to send for your domain, ending in -all or ~all. You may only have one SPF record per domain, and it must resolve in under 10 DNS lookups, so consolidate includes rather than adding a second record.

2. 2

   Turn on DKIM signing for every sending source

   Enable DKIM in each service that sends mail for you — ESP, CRM, help desk and Microsoft 365 — and publish the CNAME or TXT keys each one gives you. Every source needs its own DKIM setup; one unsigned source can fail authentication for the whole domain.

3. 3

   Publish a DMARC record with at least p=none

   Add a TXT record at the _dmarc host for your domain. A minimal compliant value is v=DMARC1; p=none; rua=mailto:[email protected]. The p=none policy asks receivers to take no action yet but to send you reports, which meets Microsoft's requirement while you confirm nothing legitimate breaks.

4. 4

   Confirm SPF or DKIM aligns with your From domain

   DMARC only passes if the domain in your visible From address matches the domain that SPF or DKIM authenticated. Send a test to an Outlook.com address and open the message headers: look for dmarc=pass. If SPF and DKIM pass but DMARC fails, you have an alignment problem, not an authentication one.

5. 5

   Register for Microsoft SNDS and watch your reputation

   Smart Network Data Services (SNDS) is Microsoft's free tool showing how Outlook.com sees your sending IPs, including complaint rates and filtering. Pair it with your DMARC aggregate (rua) reports to spot problems before they bury your delivery.

6. 6

   Tighten your DMARC policy over time

   Once your reports show only legitimate mail passing, move the policy from p=none to p=quarantine, then p=reject. Microsoft recommends this gradual rollout. A stricter policy is not required to meet the 5,000-a-day rule, but it is what actually stops others from spoofing your domain.

Your records at a glance#

Here is what a minimal compliant set looks like. Replace the placeholders with the include, selector and report address for your own sending services.

Outlook vs Gmail and Yahoo: how the rules differ#

Google and Yahoo announced their joint bulk-sender rules in February 2024, and most coverage stopped there. Microsoft's regime is separate, arrived later and is easy to miss — your Gmail delivery can look healthy while Outlook.com quietly buries the same campaign. Here is how the three compare.

Where authenticated and unauthenticated mail ends up#

Authentication decides the path. When SPF, DKIM and DMARC line up, Outlook evaluates your mail on its merits and it can reach the inbox. When they do not, the message is diverted to Junk regardless of what it says.

Thresholds and enforcement dates shift, so confirm each on the provider's own postmaster page before you rely on it. Apple's iCloud Mail applies the same SPF, DKIM, DMARC and one-click-unsubscribe expectations to bulk mail.

What to do when it still doesn't work#

You published all three records and mail still lands in Junk. That is common, and it usually traces back to one of a few causes.

• DNS has not propagated. New records can take up to 48 hours to be visible everywhere; re-test after a day.
• One sending source isn't signed. If your ESP is DKIM-signed but your CRM isn't, mail from the CRM fails — check every source, not just the main one.
• SPF or DKIM passes but doesn't align. Alignment, not raw authentication, is what DMARC checks; the From domain has to match. Look for dmarc=fail while spf=pass in the headers.
• Your reputation is the problem, not your records. Authentication gets you a fair evaluation; high complaint rates and spam-like content can still send you to Junk. SNDS shows how Outlook.com rates you.

The 550 5.7.515 rejection#

If Outlook is refusing your mail outright rather than junking it, the bounce carries a specific code. The full text is: 550 5.7.515 Access denied, sending domain <yourdomain> does not meet the required authentication level.

That is Microsoft telling you a high-volume domain has not cleared the SPF, DKIM and DMARC bar. The fix is the same steps above: publish or correct the records, wait for DNS to propagate, then re-send.

A faster way — for the inbox on the other side#

Everything above is sender-side work: DNS records, authentication and watching your deliverability. AI Emaily does none of it. It is a mail client, not an email service provider, a DMARC monitor or a deliverability tester — if your job is to send compliant bulk mail, your DNS host, Microsoft SNDS and a DMARC reporting service are the right tools, not us.

Where we fit is the other end of the pipe. The whole point of these rules is to keep unauthenticated bulk mail out of people's inboxes, and AI Emaily does that job on your side: its spam protection and cold-email filter triage inbound mail across Gmail, Outlook and IMAP, sorting newsletters, cold outreach and phishing before you open your inbox. It does not send mail, authenticate your domain or change how Outlook rates you. We build AI Emaily.