How a Misconfigured Newsletter and Email Forwarding Got Our Server Blacklisted

Written by: Tim Davis Created: 05 February 2026

Category: Net Shaker

New!Hits: 194Reading time: 03:16

Last week, several of our clients reported that their emails weren't reaching recipients using Microsoft email services. What followed was an intensive investigation that revealed email security twoseparate issues working together to damage our server's email reputation. We're sharing this story to help others understand and prevent similar problems.

This article is presented in two parts. The first section is written for general readers who want to understand what happened and how to avoid similar issues. The second section provides technical details for system administrators and IT professionals who may need to diagnose similar problems on their own servers.

Part 1: The Non-Technical Overview

The Problem

Microsoft had blocked our server's IP address from sending email to any of their services. When our clients tried to email anyone with an Outlook, Hotmail, or Live.com address, the messages bounced back with an error saying the server was on their block list.

What We Discovered

Our investigation uncovered two separate issues:

1. A Newsletter Configuration Error

One client was using a newsletter plugin to send updates to their subscribers. The software was misconfigured — emails were being sent from one domain, but the "bounce" address (where undeliverable notifications go) was set to a completely different domain.

To Microsoft's security systems, this looked like suspicious activity. Over 3,000 emails were sent this way, which triggered their anti-spoofing protections.

2. Spam Being Forwarded to Microsoft

Another client had email forwarding set up — all emails sent to their domain were automatically forwarded to their Microsoft 365 mailbox.

The problem? Spam emails were also being forwarded. Phishing emails pretending to be from well-known companies were passing through our server and landing at Microsoft. Even though our spam filter was catching these emails (some scored as high as 35 out of 5 on the spam scale), they were still being forwarded.

Microsoft saw our server delivering obvious spam and blocked us.

How We Fixed It

For the newsletter issue, the configuration was corrected so that sending and bounce addresses use the same domain.

For the forwarding issue, we enabled automatic deletion of high-scoring spam before it could be forwarded. Now, only legitimate email passes through.

Lessons for Email Best Practices

Based on this experience, we recommend:

Check your newsletter settings — Make sure your sending address and bounce/reply address use the same domain
Be cautious with email forwarding — If you forward email to an external provider like Microsoft 365 or Gmail, spam can damage your reputation
Consider pointing your email directly to your provider — If you use Microsoft 365 or Gmail, having your domain's email go directly there (rather than forwarding through another server) is safer

If you're experiencing email deliverability issues, contact Cybersalt and we'll help investigate.

Part 2: Technical Details for System Administrators

This section details our investigation into a Microsoft S3150 block affecting a WHM server's primary IP. We're documenting the technical details for other system administrators who may encounter similar issues.

Symptoms

Outbound email to Microsoft domains (outlook.com, hotmail.com, live.com, msn.com) began returning:

550 5.7.1 Unfortunately, messages from [x.x.x.x] weren't sent. Please contact your 
Internet service provider since part of their network is on our block list (S3150).

SNDS showed no data, and JMRP was not reporting complaints. The delisting portal at sender.office.com was not resolving the issue.

Investigation

We used Exim logs to identify which accounts were triggering rejections from Microsoft:

grep -E "(hotmail|outlook|live|msn).*(550|S3150)" /var/log/exim_mainlog | grep -oP '(?<=F=<)[^>]+' | sort | uniq -c | sort -rn

This revealed two distinct issues:

Issue 1: Cross-Domain Envelope Sender Mismatch

An AcyMailing installation was configured to send from This email address is being protected from spambots. You need JavaScript enabled to view it. but with the envelope sender (return-path) set to This email address is being protected from spambots. You need JavaScript enabled to view it.. Over 3,334 emails were sent this way:

Spoofed Senders
  Count   Auth-User                    Envelope-Sender
  3334    This email address is being protected from spambots. You need JavaScript enabled to view it.            This email address is being protected from spambots. You need JavaScript enabled to view it.

Microsoft's anti-spoofing systems flagged this pattern. The mismatch between authenticated user domain and envelope sender domain is a common spam indicator.

Issue 2: High-Scoring Spam Forwarded via valiases

A domain had forwarders configured in /etc/valiases/ pointing to Microsoft 365 addresses. Incoming spam was being delivered to the local spam folder AND forwarded externally — SpamAssassin's spam box feature does not prevent forwarders from firing.

Log analysis showed spam with scores of 20-35 being forwarded:

grep "domain.com" /var/log/exim_mainlog | grep "=>" | awk '{print $4}' | sort -u | while read msgid; do
  grep "$msgid" /var/log/exim_mainlog | grep "SpamAssassin" | head -1
done

Sample output:

Warning: "SpamAssassin as username detected message as spam (35.3)"
Warning: "SpamAssassin as username detected message as spam (22.3)"
Warning: "SpamAssassin as username detected message as spam (20.3)"

Despite high spam scores, messages were forwarded to Microsoft:

=> This email address is being protected from spambots. You need JavaScript enabled to view it. ... H=external-domain-com.mail.protection.outlook.com

Resolution

For the envelope sender mismatch:

The AcyMailing configuration was corrected to use consistent domains. The mailbox was subsequently removed as email for that domain is now hosted externally.

For the forwarded spam:

We enabled SpamAssassin auto-delete for the affected account:

touch /home/username/.spamassassindelete
chown username:username /home/username/.spamassassindelete

This causes messages scoring above the threshold (5) to be deleted before the forwarder can process them.

Additional Fixes

We also enabled SRS (Sender Rewriting Scheme) to prevent SPF failures on legitimately forwarded mail:

sed -i 's/srs=0/srs=1/' /etc/exim.conf.localopts
/scripts/buildeximconf --force && /scripts/restartsrv_exim

Key Commands for Diagnosis

Identify accounts sending to Microsoft:

grep -E "@(hotmail|outlook|live|msn)\." /var/log/exim_mainlog | grep "<=" | awk '{for(i=1;i<=NF;i++) if($i ~ /A=/) print $i}' | cut -d: -f2 | sort | uniq -c | sort -rn

Check rejection counts:

grep -E "(hotmail|outlook|live|msn)" /var/log/exim_mainlog | grep -oP 'S3[0-9]{3}|5[0-9]{2} 5\.[0-9]\.[0-9]+' | sort | uniq -c

Find forwarders pointing to Microsoft:

grep -rE "@(hotmail|outlook|live|msn)\.(com|co\.uk)" /etc/valiases/

Check spam scores for forwarded messages:

grep "domain.com" /var/log/exim_mainlog | grep "=>" | awk '{print $4}' | sort -u | while read msgid; do
  grep "$msgid" /var/log/exim_mainlog | grep "SpamAssassin" | head -1
done

Lessons Learned

SpamAssassin spam box does not prevent forwarding — Only auto-delete stops spam before forwarders fire
Envelope sender mismatches trigger anti-spoofing — Newsletter software must be configured with consistent domains
Email forwarding is inherently risky — Consider having clients point MX directly to their destination provider
Enable SRS — Prevents SPF failures on forwarded mail
Monitor with SNDS and JMRP — Register at https://sendersupport.olc.protection.outlook.com/snds/

Delisting

After resolving the underlying issues, submit delisting requests:

Microsoft: https://sender.office.com
Gmail: https://support.google.com/mail/contact/msgdelivery

Interesting blog? Like it on Facebook, Post it or share this article on other bookmarking websites.