On June 23, 2026, several Lettermint transactional sending IPs were listed by Spamhaus. This caused a subset of transactional emails to bounce or be delayed while receiving mail providers consumed the listing.

We know this incident came shortly after other recent reliability issues. That is not the level of service we expect from ourselves, and it is not what customers should expect from Lettermint.

This incident followed last Saturday’s infrastructure migration, where part of our sending infrastructure started identifying itself with updated HELO and reverse DNS values. The affected IPs were not new, and weekend validation did not show delivery anomalies. After working with Spamhaus, we confirmed that this case exposed a bug in their guardrails that should have prevented the listing. During mitigation, more traffic than expected shifted onto another range, which caused additional rate limiting at Microsoft.

Our last Spamhaus-related incident before this week was in November 2025, so this is not a recurring pattern for Lettermint. Still, the responsibility is ours: we should have treated this migration as a reputation-sensitive change, coordinated it in advance with the relevant parties, and limited the impact of traffic shifting during mitigation.

We are deeply sorry for the disruption this caused.

Some transactional emails sent through Lettermint were delayed or failed while the affected IPs were listed. The impact was primarily on transactional outbound delivery.

The listing started at approximately 05:13 UTC. We opened a public incident at 06:01 UTC after confirming that multiple transactional IPs were affected. The incident was resolved at 16:24 UTC, after delisting had propagated and we were no longer seeing bounces related to the Spamhaus listing.

During mitigation, traffic that would normally have been spread across the affected range was shifted away from those IPs. This increased volume on another IP range more than expected, which then caused rate limiting from Microsoft. That contributed to additional delivery delays.

On Saturday, June 20, 2026, we completed an infrastructure migration that included changes to HELO and reverse DNS values for part of our sending infrastructure. The change reflected the new location of the IP announcement after moving infrastructure from France to the Netherlands.

Although the IPs were not new, changing HELO and reverse DNS materially changed how the infrastructure presented itself to mailbox providers and filtering systems. Large, established mail infrastructure rarely changes these identifiers, so the change can be interpreted as suspicious even when the underlying sending behavior is legitimate.

We tested the migration extensively over the weekend and used the lower weekend volume as an observation window before weekday traffic returned. During that period, we did not observe delivery anomalies. The listing appeared later, after the observation window, when traffic increased again on Monday and Tuesday.

On June 22, the same IPs were listed for approximately 45 minutes, starting at 11:10:59 UTC. That was resolved through an automated delisting request.

On June 23, the issue recurred and lasted significantly longer. We suspended affected IPs when Spamhaus-related responses were detected and deployed a mitigation at 06:34 UTC to broaden the detection pattern and suspend affected IPs for two hours.

That mitigation reduced repeated delivery attempts through listed IPs, but it also concentrated more traffic on other ranges. This caused Microsoft to rate limit some traffic from the remaining pool.

During the incident, some customers asked to be moved to another shared pool or to a dedicated IP. We did not do this because it would likely have made the incident worse.

A dedicated IP that has not been warmed up cannot safely absorb production transactional traffic at short notice. Moving sudden volume to another shared pool also risks damaging that pool’s reputation or triggering rate limits at large mailbox providers.

We also avoided aggressive retries while the listing and provider-side cache propagation were still active. Retrying too early can amplify bounces, worsen rate limiting, and make recovery slower. Once delivery had stabilised, we resumed processing affected messages.

This was a difficult tradeoff: delaying mail is painful, but causing broader reputation damage would have increased the number of affected customers and extended recovery.

The root cause was a reputation-sensitive infrastructure identity change: HELO and reverse DNS values changed as part of our June 20 migration.

After working with Spamhaus, we confirmed that this case exposed a bug in their guardrails that should have prevented the listing. This context matters because the listing was not caused by observed spam, malware, or abusive traffic from Lettermint’s network. Our sender approval process remained in place, and we found no evidence that customer abuse caused the incident.

At the same time, we own how we plan reputation-sensitive infrastructure changes, how we coordinate them in advance, and how our systems behave when mitigation shifts traffic across pools.

Contributing factors were:

• We did not notify Spamhaus and relevant mailbox providers before changing HELO and reverse DNS values.

• Our initial blocklist mitigation was too narrow. After we broadened it, suspensions were still response-triggered and path-scoped, so they did not instantly remove every listed IP from all destinations.

• As affected delivery paths were suppressed, traffic shifted to the remaining IPs faster than our safeguards allowed, contributing to Microsoft rate limiting.

• Our support response needed clearer, earlier explanation of why moving mail to other IPs would be unsafe.

All times are UTC.

• June 20: Infrastructure migration completed, including HELO and reverse DNS changes.

• June 22 11:10:59: Similar Spamhaus listing affected the same IPs.

• June 22: Listing resolved after approximately 45 minutes through automated delisting.

• June 23 05:13:04: Multiple IPs from the affected range were listed by Spamhaus.

• June 23 06:01: Public incident opened after confirming affected transactional IPs.

• June 23 06:34: Mitigation deployed to broaden Spamhaus response detection and suspend affected IPs for two hours.

• June 23 08:41: We received an update that delisting was propagating.

• June 23 09:35: After the initial delisting began propagating, the affected IPs were listed again. We kept the IPs suspended and continued escalation with Spamhaus.

• June 23 15:14: Delisting had been applied, and we moved the incident to monitoring while provider caches refreshed.

• June 23 16:24: Incident resolved after Spamhaus-related bounces stopped and affected messages were being resent.

We are making the following changes:

• Treat HELO and reverse DNS changes as reputation-sensitive production changes, even when IPs stay the same.

• Update our migration SOP to require advance notification to Spamhaus and relevant mailbox providers before infrastructure identity changes.

• Add traffic-shift safeguards so blocklist mitigation cannot unexpectedly overload another IP range.

• Improve monitoring around per-provider rate limits during mitigation, especially for Microsoft.

• Update internal support guidance so customers receive a clearer explanation during blocklist incidents, including why moving traffic to other IPs can be harmful.

• Review our retry strategy for blocklist and rate-limit incidents so recovery resumes as soon as it is safe, without amplifying the issue.

We regret the disruption this caused, especially because it followed other recent incidents. This was not expected, and it is not a normal operating pattern for Lettermint. We are taking the operational lessons from this incident seriously and are tightening the procedures around infrastructure changes, provider communication, and traffic mitigation.