Why Outlook Rejects Your VPS Email When SPF/DKIM/DMARC All Pass

How Microsoft actually filters VPS email

Gmail uses machine learning that weighs recipient engagement: opens, replies, "mark not spam" actions. A new VPS IP with no history can build reputation gradually as recipients interact with your messages. Microsoft does not work this way.

Microsoft's Exchange Online Protection (EOP) runs incoming email through three explicit scoring systems before the message reaches a mailbox:

• Spam Confidence Level (SCL): scores from -1 to 9. Messages scoring 5-6 land in Junk. Scores 7-9 are blocked outright. Score -1 bypasses filtering entirely. Microsoft documentation defines each threshold.
• Bulk Complaint Level (BCL): scores 0-9 measuring how "bulk-like" a sender is. BCL 8-9 goes to Junk regardless of content.
• Sender Reputation Level (SRL): scores 0-9 predicting the probability that the sender is a spammer. Compares your HELO/EHLO domain against reverse DNS. Default block threshold is SRL 7 or higher.

The critical difference: Outlook does not factor in recipient engagement the way Gmail does. Microsoft's filtering documentation confirms that engagement signals (opens, clicks, replies) do not rehabilitate a sender's reputation. The exception is their Sender Reputation Data (SRD) program, a panel of vetted Outlook users across 200+ countries who vote on whether forwarded samples are junk. SRD votes feed into SmartScreen filtering, but individual senders cannot influence or monitor them.

What this means for VPS operators: Gmail gives you a path to build reputation through legitimate sending. Microsoft gives you a wall. If your IP or your provider's ASN is on their blocklist, no amount of clean sending from your individual server will change the score. You need to either get delisted or route around the block.

What S3150 and S3140 mean

Both error codes produce nearly identical bounce messages. The difference is the blocking mechanism:

The S3150 bounce includes a timestamp and correlation ID in brackets at the end. Save this. If you need to escalate with Microsoft support, they can look up the exact filtering decision using that ID.

The phrase "part of their network is on our block list" is the key. It says "their network" (your provider's network), not "your IP." Microsoft is blocking the neighborhood, not the house.

Why Gmail works but Outlook doesn't

This is the question that drives VPS operators to forum posts at 2 AM. The same email, from the same server, with the same authentication, delivers to Gmail and bounces from Outlook. The reason is architectural:

Gmail evaluates senders primarily by engagement. It watches what recipients do with your messages (open, reply, archive, delete, report spam) and adjusts your domain reputation accordingly. A new IP on a clean domain starts neutral and moves up or down based on real recipient behavior. Gmail Postmaster Tools shows your domain-level reputation as High, Medium, Low, or Bad. You can rehabilitate a damaged reputation by sending good mail that people engage with.

Microsoft evaluates senders primarily by infrastructure. It checks your IP against blocklists (including UCEPROTECT, which lists entire ASNs), assigns explicit numerical scores (SCL, BCL, SRL), and makes filtering decisions before examining content or authentication. Engagement does not rehabilitate you. If your IP range is flagged, the block persists until Microsoft manually lifts it, which they may do temporarily, only to re-apply weeks later.

A Virtualmin forum user described the cycle: "Microsoft unblocks temporarily, then re-blocks within days to months. Gmail, Yahoo, Proton all accept the same emails." A DirectAdmin forum thread documented support request IDs incrementing by over 9 million between November and March, suggesting massive volumes of similar complaints from self-hosted mail operators. One user summarized it: "Big companies pay for some kind of whitelisting and then they don't block each other. It's always the small companies who are hit worst."

Which VPS providers are blocked

No VPS provider guarantees clean IPs for Microsoft delivery. But some are consistently worse than others, based on community reports and ASN-level blacklist data:

The pattern: budget providers attract more spammers because of low prices and easy signup. Those spammers poison the ASN reputation for everyone on the same network. Microsoft blocks the entire network segment rather than hunting individual IPs. You inherit the reputation of every tenant who shared your provider's IP range before you.

Checking your reputation with SNDS

Microsoft's Smart Network Data Services (SNDS) is a free portal that shows how Microsoft evaluates your IP's reputation. It's the closest thing to Gmail's Postmaster Tools for the Microsoft ecosystem.

Portal: sendersupport.olc.protection.outlook.com/snds/

Setup takes about 48 hours:

1. Sign in with any Microsoft account.
2. Click "Request Access" and enter your VPS IP addresses (up to 20 IPs per request).
3. Microsoft verifies ownership via automated email to the abuse@ or postmaster@ address listed in your IP's WHOIS record. Click the authorization link.
4. Once approved (24-48 hours), the dashboard shows message volume, spam trap hits, complaint rates, and a color-coded reputation indicator: green (positive), yellow (mixed), red (serious problems).

There's a catch for low-volume VPS senders: SNDS only displays data for IPs sending more than 100 emails per day to Microsoft addresses. If you run a personal mail server handling 10-30 messages daily, SNDS will show "insufficient email seen." That message is not neutral. It means Microsoft has almost no positive reputation data for your IP. You're invisible to their scoring system, which defaults to suspicion rather than trust.

While you're in SNDS, enroll in JMRP (Junk Mail Reporting Program), Microsoft's feedback loop. When an Outlook user clicks "Report spam" on your message, JMRP forwards a copy to an email address you designate. This lets you identify and suppress recipients who mark you as junk before their complaints degrade your SRL score further.

What actually fixes it

Ranked by reliability, from most to least:

1. External SMTP relay (most reliable)

Route outbound email through a dedicated email service on port 587. Your VPS handles receiving; the relay handles sending through IPs that Microsoft already trusts. In Postfix, this is one line: relayhost = [smtp.provider.com]:587 with SASL authentication.

Options by cost:

• Amazon SES: $0.10 per 1,000 emails. Cheapest at scale.
• SendGrid: free tier up to 100 emails/day. Documented working as a Postfix transport_maps relay in the Mail-in-a-Box forum.
• Postmark: ~$15/month for 10,000 emails. Praised in Cloudron forum threads for strong Outlook deliverability specifically.

This solves the problem permanently because you stop sending from your VPS IP entirely. Microsoft never sees your provider's ASN in the connection. The trade-off: you're paying a third party to send mail from a server you control, which defeats part of the self-hosting premise. But it works.

2. Microsoft delisting request

Two portals, depending on the error code:

• Office 365 blocks (error 5.7.606-649): Submit at sender.office.com. Enter the blocked IP and the email address that received the bounce. Confirm via email link. Results within 24 hours.
• Outlook.com/Hotmail blocks (S3150/S3140): Submit at Microsoft's support request form.
• Permanent bans (5.7.511): Forward the full NDR to delist@microsoft.com. Microsoft responds within 48 hours.

Critical tip from andreas.heigl.org: if you receive an automated "not qualified for mitigation" rejection, reply directly to that rejection email with substantive arguments: your authentication setup, your sending volume, how recently you acquired the IP. This escalates to a human reviewer. The author reported resolution within 24-48 hours after the initial automated denial.

Another tip from Tilaa's blog: if the IP was recently assigned to you, send Microsoft an email confirmation or PDF from your VPS provider proving the allocation date. This distinguishes you from the previous tenant who caused the block.

The problem with delisting: it's often temporary. Multiple forum reports describe a cycle of unblock, send clean mail for weeks or months, get re-blocked. The Virtualmin thread documents this pattern explicitly. You're treating the symptom (your specific IP) while the cause (your provider's ASN reputation) persists.

3. IPv6 sending (OVHcloud-specific)

UCEPROTECT does not blacklist IPv6 addresses. For OVHcloud users whose ASN is blocked on IPv4, configuring Postfix to prefer IPv6 (smtp_address_preference = ipv6) bypasses the UCEPROTECT listing entirely. All OVHcloud services include at least one IPv6 address. This workaround is documented in Luc Saffre's blog.

Limitation: not all receiving mail servers support IPv6. Microsoft and Gmail do. Smaller providers may not. You may need to fall back to IPv4 for some recipients, which puts you back in blocked territory.

4. IP change

Request a new IP from your VPS provider and check it against MXToolbox, Spamhaus, UCEPROTECT, and the SNDS portal before installing your mail server. If the new IP is clean, you get a fresh start, until your provider's ASN gets re-flagged. This is a reset button, not a solution.

What does not work

• Better SPF/DKIM/DMARC configuration. Authentication is a prerequisite, not a fix. Microsoft blocks your IP before evaluating your authentication records.
• Submitting the delisting form repeatedly. Temporary relief followed by re-blocking. Forum users report cycles of weeks to months.
• Low-volume warm-up. This works for Gmail because Gmail uses engagement signals. Microsoft does not. Sending 5 clean emails per day from a flagged ASN does not rehabilitate your reputation with Microsoft.
• Asking your VPS provider. Some providers (Contabo, Linode, Netcup) will contact Microsoft on your behalf, and this can work. But most budget providers don't have a direct relationship with Microsoft's abuse team. Hetzner and OVHcloud have not resolved their ASN-level issues despite years of community complaints.

FAQ