PowerMTA Microsoft SNDS and JMRP Setup

SNDS and JMRP: Microsoft's Sender Monitoring Programs

Microsoft operates two sender monitoring programs that together provide the data needed to manage Outlook.com and Hotmail delivery effectively. SNDS (Smart Network Data Services) provides IP-level sending statistics and reputation status. JMRP (Junk Mail Reporting Program) provides individual complaint reports for messages delivered to Outlook/Hotmail users who mark them as junk.

Both programs require enrollment — they are not automatic. Enrollment without integration into your monitoring and suppression workflow provides no operational value. This note covers enrollment, data interpretation, and integration with PowerMTA operations.

SNDS Enrollment and Data Access

# SNDS enrollment:
# URL: https://sendersupport.olc.protection.outlook.com/snds/

# Requirements for enrollment:
# 1. Valid Microsoft account
# 2. List of sending IP addresses to register
# 3. Domain that matches your sending infrastructure

# SNDS data available after enrollment:
# - Sending statistics per IP (daily)
# - Complaint rate (% of delivered messages marked as junk)
# - Spam trap hit count per IP
# - Traffic light status: GREEN / YELLOW / RED

# Automated data access (SNDS API):
curl "https://sendersupport.olc.protection.outlook.com/snds/data.aspx?ip=185.x.x.10" \
  --cookie "snds_session=YOUR_SESSION_COOKIE"
# Returns: CSV with date, rcpts, complaints, status

Interpreting SNDS Traffic Light Status

JMRP Enrollment and ARF Processing

# JMRP enrollment:
# URL: https://sendersupport.olc.protection.outlook.com/snds/JMRP.aspx

# Requirements:
# 1. Your sending IP addresses registered in SNDS
# 2. FBL report destination email address (must be at domain you control)
# 3. DKIM signing active (required for JMRP enrollment in some cases)

# Each JMRP report is an ARF (Abuse Reporting Format) email containing:
# - Original message headers (not body — recipient privacy)
# - Source-IP of the sending connection
# - Feedback-Type: abuse
# The original Message-ID allows you to identify the recipient in your database

# Process JMRP reports:
cat > /usr/local/bin/process_jmrp.py << 'SCRIPT'
import sys, email, re

def process_jmrp():
    raw = sys.stdin.buffer.read()
    msg = email.message_from_bytes(raw)
    
    message_id = None
    source_ip = None
    
    for part in msg.walk():
        content_type = part.get_content_type()
        
        if content_type == 'message/rfc822-headers':
            headers = part.get_payload(decode=True).decode('utf-8', errors='replace')
            match = re.search(r'Message-ID:\s*<([^>]+)>', headers, re.I)
            if match:
                message_id = match.group(1)
        
        elif content_type == 'message/feedback-report':
            report = part.get_payload(decode=True).decode('utf-8', errors='replace')
            match = re.search(r'Source-IP:\s*(\S+)', report)
            if match:
                source_ip = match.group(1)
    
    if message_id:
        print(f"Complaint: Message-ID={message_id}, Source-IP={source_ip}")
        # Add to suppression list using Message-ID lookup
        suppress_by_message_id(message_id)

process_jmrp()
SCRIPT

SNDS Data Integration with PowerMTA Operations

# Daily SNDS check workflow (automate via cron):

#!/bin/bash
# /usr/local/bin/check_snds.sh
SNDS_IPS="185.x.x.10 185.x.x.11 185.x.x.12"

for IP in $SNDS_IPS; do
    # Query SNDS API for this IP
    STATUS=$(curl -s "https://sendersupport.olc.protection.outlook.com/snds/data.aspx?ip=$IP" \
             --cookie "snds_session=$SNDS_SESSION" | \
             awk -F, 'END {print $4}')   # Status in column 4
    
    case $STATUS in
        "GREEN")  echo "$IP: GREEN — normal" ;;
        "YELLOW") echo "$IP: YELLOW — investigate" | mail -s "SNDS Yellow: $IP" ops@yourdomain.com ;;
        "RED")    echo "$IP: RED — stop sending" | mail -s "SNDS RED ALERT: $IP" ops@yourdomain.com ;;
    esac
done

# If IP shows RED:
# 1. Remove from active PowerMTA pool immediately:
# sed -i "s/virtual-mta $RED_VMTA/#virtual-mta $RED_VMTA/" /etc/pmta/config
# pmta reload
# 2. Investigate complaint source in JMRP reports
# 3. Remediate before returning IP to pool

SNDS Data Correlation with PowerMTA Logs

SNDS data reflects a 24-48 hour rolling view. An IP moving from GREEN to YELLOW in SNDS confirms what your PowerMTA accounting log was showing 24-48 hours earlier. Build a correlation discipline: when SNDS changes, look at the accounting log for the corresponding period to identify which sending activity caused the reputation change. This pattern-matching builds the operational memory that prevents recurrence.

Accounting Log Analysis for This Configuration

Monitor this configuration area through the PowerMTA accounting log's dsnDiag field. Filter accounting records for the specific ISP domains affected by this configuration and group dsnDiag responses by first 60 characters to identify the dominant error patterns. A deferral rate above 5% at any single ISP warrants investigation; above 15% requires immediate volume reduction and configuration review.

The dlvSourceIp field in the accounting log enables per-IP analysis within this configuration context. Comparing per-IP deferral rates identifies whether a configuration issue affects all IPs in a pool uniformly (configuration problem) or just specific IPs (reputation or IP-specific problem). This distinction determines the correct remediation path.

Calibrating to Your Current Environment

The parameter values documented in this reference are appropriate for established, warmed IPs with HIGH reputation at the target ISP. New or warming IPs, and IPs with MEDIUM or LOW reputation, require more conservative values. Move up incrementally as reputation signals confirm the infrastructure can sustain additional throughput. Review ISP-specific configuration monthly — Postmaster Tools reputation tier changes and SNDS status changes are the primary triggers.

Production Deployment Summary

Implementing this PowerMTA configuration correctly in production requires testing the specific parameter values against your actual IP reputation history, ISP distribution, and sending volume. The values documented here represent proven starting points, not fixed constants — your optimal configuration may differ based on your infrastructure's operational history.

After applying any configuration change, monitor the accounting log for the first 2-4 hours to verify the change produced the expected effect on deferral rates. A configuration change that was expected to reduce deferrals but shows no change (or increased deferrals) indicates either: the change addressed the wrong variable, or there is a confounding factor that needs investigation before continuing.

The Cloud Server for Email infrastructure team manages PowerMTA environments daily, applying the configuration principles documented in this reference series across clients with varied volume levels, ISP distributions, and reputation histories. Contact us at infrastructure@cloudserverforemail.com for a technical assessment of your specific PowerMTA configuration requirements.