PowerMTA Outlook and Hotmail Delivery Configuration: Complete 2026 Operator Guide

Why Microsoft delivery needs attention

Microsoft's consumer mail, Outlook, Hotmail, and the rest of the family, is a major destination for most senders, and Microsoft has historically had a reputation for being a demanding receiver, more prone to filtering and throttling than some others. Microsoft's establishment of bulk sender requirements, with comparatively abrupt enforcement, has raised the stakes further. Getting Microsoft delivery right is a distinct piece of work, with its own tools, SNDS and JMRP, its own enforcement specifics, and its own configuration considerations.

This guide exists to bring together what a PowerMTA operator needs for reliable Microsoft delivery in 2026. The structure of this guide: why Microsoft delivery needs attention, the Microsoft mail family and collapsing it with queue-to, Microsoft's bulk sender enforcement and the 550 5.7.515 error, SNDS as the primary reputation window, JMRP as the complaint feedback loop, configuring the Microsoft domain block, the authentication Microsoft requires, the Microsoft deliverability support process for blocked IPs, and the diagnostic workflow when Microsoft delivery degrades.

The Microsoft mail family

Microsoft's consumer mail is spread across several domains that are all the same service:

Domain	Part of
hotmail.com	Microsoft consumer mail
outlook.com	Microsoft consumer mail
live.com	Microsoft consumer mail
msn.com	Microsoft consumer mail
Country variants (hotmail.co.uk, outlook.de, etc.)	Microsoft consumer mail

These domains are all handled by the same Microsoft mail infrastructure, and Microsoft evaluates the sender's mail to the whole family as one combined stream.

The PowerMTA consequence: the Microsoft-family domains should be throttled together, not separately. The correct configuration is one domain block for the Microsoft family, with the appropriate throttling, and queue-to directives routing the other family domains into it:

<domain hotmail.com>
    max-msg-rate 8000/h
    max-smtp-out 8
    virtual-mta microsoft-pool
</domain>

<domain outlook.com>  { queue-to hotmail.com }
<domain live.com>     { queue-to hotmail.com }
<domain msn.com>      { queue-to hotmail.com }

With queue-to, mail to all the Microsoft-family domains shares the single block's throttling, so PowerMTA's pace to Microsoft reflects the combined stream Microsoft actually sees. Skipping this, leaving each Microsoft domain with its own separate block, lets the combined rate exceed Microsoft's tolerance even when each block looks conservative, and is a common reason Microsoft throttles a sender whose configuration appears reasonable.

Microsoft bulk sender enforcement and 550 5.7.515

Microsoft followed Gmail and Yahoo in establishing bulk sender requirements, and its enforcement deserves specific attention because it was comparatively abrupt.

Microsoft's bulk sender requirements are the familiar set: authentication with SPF, DKIM, and DMARC; valid one-click unsubscribe for marketing mail; acceptable sending practices. Where Gmail ramped its enforcement gradually, Microsoft's enforcement, which began in May 2025, moved comparatively directly to rejecting non-compliant bulk-sender mail.

The specific error is 550 5.7.515. This is the rejection code Microsoft returns for bulk-sender mail to the Microsoft consumer family that does not meet the sender requirements.

The practical takeaway for a PowerMTA operator: Microsoft's bulk sender requirements are not optional, and the cost of not meeting them is permanently rejected mail. An operator sending bulk mail to the Microsoft family must meet the authentication and one-click requirements and maintain acceptable practices, and must monitor the accounting log for 550 5.7.515 as the signal that something is wrong.

SNDS as the reputation window

SNDS, Smart Network Data Services, is Microsoft's free program that gives senders data about their sending IPs as Microsoft sees them, and it is the primary window into Microsoft reputation.

SNDS shows, for the registered sending IPs:

• A reputation indication. Frequently expressed as a filter result or a color, green for good standing, yellow for caution, red for poor.
• The complaint rate Microsoft observes for the IP.
• Volume data about the mail Microsoft received from the IP.
• Trap-hit information where Microsoft has it.

SNDS is the single most important tool for understanding how Microsoft regards a sender. Any operator sending meaningful volume to the Microsoft family should register their sending IPs in SNDS and monitor the SNDS reading regularly.

SNDS has a volume threshold, an IP needs to send enough mail to Microsoft, on the order of 100 messages a day, for SNDS to have meaningful data. Below that, the SNDS data is sparse. For a real bulk sender, the volume is well past the threshold and SNDS provides a continuous picture.

The practical use of SNDS: a green SNDS reading means Microsoft regards the IP well; a yellow or red reading is a warning that the IP's reputation with Microsoft has slipped, and it points at a problem to address before it becomes a delivery failure. When Microsoft delivery degrades, SNDS is the first place to look, it frequently shows the reputation problem directly.

JMRP, the complaint feedback loop

JMRP, the Junk Mail Reporting Program, is Microsoft's complaint feedback loop, and it complements SNDS.

Through JMRP, when an Outlook or Hotmail recipient marks the sender's mail as junk, Microsoft sends the operator a report of that complaint. This lets the operator learn which specific recipients complained and suppress them, which both respects the recipient's wish and protects the sender's reputation, because a recipient who complained and keeps receiving mail will keep complaining.

The relationship between SNDS and JMRP: SNDS gives the aggregate reputation picture, the complaint rate, the standing; JMRP gives the individual complaints, the specific addresses. Microsoft modernized both systems, and in the current arrangement the JMRP complaint feeds are linked to SNDS accounts rather than being standalone, so the two are administered together.

For a PowerMTA operator, JMRP is a feedback-loop input that should flow into the suppression pipeline: a JMRP complaint about a recipient should result in that recipient being suppressed, the same way a hard bounce drives suppression. Processing JMRP complaints into suppression keeps the complaint rate down, which keeps the SNDS reputation healthy, which keeps Microsoft delivery working.

Together, SNDS and JMRP are the Microsoft equivalent of the monitoring an operator does for Gmail with Postmaster Tools, the reputation window and the complaint stream, and an operator serious about Microsoft delivery uses both.

Configuring the Microsoft domain block

The PowerMTA-side configuration for Microsoft is the Microsoft family domain block, the single block the whole family is collapsed onto with queue-to.

The block sets the throttling, the message rate and connection limits, and the VMTA or pool assignment. Microsoft has historically warranted somewhat conservative throttling, it is a receiver that responds to aggressive sending with filtering and throttling, and its connection tolerance in particular is not generous. So the Microsoft block typically carries conservative connection limits, a modest max-smtp-out and max-conn-rate, alongside a message rate tuned to the sender's reputation.

As with all domain blocks, the right numbers are reputation-dependent and tuned from observation: start conservative, watch the accounting log for 421 deferrals and throttle responses from Microsoft, and adjust. If Microsoft is throttling, lower the rate; if Microsoft is accepting smoothly, the rate can rise gradually.

And as with Gmail, the domain block is necessary but not sufficient: it keeps PowerMTA's pace within Microsoft's acceptance, but Microsoft's acceptance is governed by the sender's reputation, the SNDS standing, the complaint rate, the authentication, not by the domain block's numbers. A well-tuned Microsoft block paired with a poor SNDS reputation still delivers poorly. The block is one part of Microsoft delivery; the reputation and the bulk sender compliance are the larger part.

The authentication Microsoft requires

Microsoft's bulk sender requirements include authentication, and the 550 5.7.515 enforcement applies to authentication failures, so the authentication PowerMTA contributes to must be correct.

The authentication Microsoft requires is the standard set:

• SPF. The sending IPs must be authorized by the domain's SPF record. PowerMTA must send from SPF-authorized IPs.
• DKIM. PowerMTA must DKIM-sign the mail, through the domain-key directive, with a valid key whose public counterpart is published in DNS.
• DMARC. A DMARC record must be published, and the mail must pass with alignment, DKIM or SPF passing in a way that aligns with the From domain.

The PowerMTA-side authentication tasks are the same as for any receiver: send from SPF-authorized IPs, DKIM-sign with a valid key, and DKIM-sign with the sender's own domain so the signature aligns for DMARC. The DNS records, SPF, the DKIM public key, DMARC, are the operator's to publish.

Because Microsoft's enforcement rejects authentication failures with the permanent 550 5.7.515, the authentication must be solid, not a partial setup. An operator seeing 550 5.7.515 should check the authentication first, verify with a test message that SPF, DKIM, and DMARC all pass and align for the Microsoft mail, because an authentication gap is a leading cause of the rejection.

The Microsoft deliverability support process

When a sender's IPs are blocked by Microsoft or delivery to the Microsoft family is significantly impaired, Microsoft provides a deliverability support process.

Microsoft operates a sender support and deliverability support process through which a sender can raise a delivery problem, a blocked IP, persistent filtering, with Microsoft. The process typically involves submitting the relevant details, the affected IPs, the nature of the problem, through Microsoft's support form.

The deliverability support process is the route for a problem that the sender cannot resolve through their own configuration and reputation work, specifically a block. But it is not a substitute for the underlying work: Microsoft's support process expects the sender to be addressing the root cause, the reputation issue, the sending practice, the authentication, and a support request is more likely to help when the sender has fixed the cause and needs the block reviewed, rather than when the underlying problem is still active.

So the deliverability support process fits into the recovery this way: the operator diagnoses and fixes the cause, monitors SNDS for the reputation to recover, and uses the support process for a residual block that needs Microsoft's manual review once the cause is resolved. It is a tool for the recovery, not a shortcut around the reputation work.

When Microsoft delivery degrades

When Microsoft delivery degrades, the diagnostic workflow:

Step 1: check SNDS. SNDS is the first place to look. The SNDS reputation reading, and the complaint rate it shows, frequently reveals the problem directly, a yellow or red reading, an elevated complaint rate.

Step 2: read the accounting log for Microsoft. Check the deferrals and rejections from the Microsoft family. 421 deferrals indicate throttling; 550 5.7.515 rejections indicate a bulk-sender-requirement failure.

Step 3: for 550 5.7.515, check the requirements. A 550 5.7.515 pattern means a bulk sender requirement is unmet. Check authentication, SPF, DKIM, DMARC all passing and aligning, and check one-click unsubscribe on marketing mail.

Step 4: for throttling, check reputation and volume. 421 deferrals from Microsoft point at a reputation or volume issue. SNDS shows the reputation; the accounting log shows whether volume spiked.

Step 5: process the JMRP complaints. Confirm JMRP complaints are being processed into suppression. An accumulation of unprocessed complaints, recipients who complained still being mailed, drives the complaint rate up and the reputation down.

Step 6: address the cause. For an authentication failure, fix the SPF, DKIM, or DMARC setup. For a reputation problem, the fix is list quality and engagement, and reducing complaints, with JMRP feeding suppression. For a one-click gap, implement one-click correctly.

Step 7: reduce volume while recovering. While addressing a reputation problem, reduce the Microsoft volume so the sender is not pushing into the degraded state.

Step 8: use the support process if needed. If the IPs are blocked and the cause is resolved, use Microsoft's deliverability support process to have the block reviewed.

Reliable delivery to Outlook, Hotmail, and the Microsoft consumer family rests on several pieces working together. On the configuration side, the Microsoft-family domains must be collapsed onto one domain block with queue-to so the throttling reflects the combined stream Microsoft evaluates, and that block should carry conservative connection limits given Microsoft's character as a receiver. The authentication, SPF-authorized IPs, valid DKIM, DMARC alignment, must be solid, because Microsoft's bulk sender enforcement, in force since May 2025, rejects non-compliant mail with the permanent 550 5.7.515 error. SNDS is the primary reputation window and JMRP the complaint feedback loop, and an operator serious about Microsoft delivery monitors SNDS and processes JMRP complaints into suppression. When delivery degrades, SNDS and the accounting log localize the cause, a 550 5.7.515 pattern pointing at an unmet bulk sender requirement, a 421 pattern at throttling, and Microsoft's deliverability support process is available for a residual block once the cause is fixed. Operators who collapse the family, get the authentication right, and use SNDS and JMRP, get reliable Microsoft delivery; operators who treat the Microsoft family as separate domains or leave an authentication gap find Microsoft's strict, abrupt enforcement rejecting their mail.