Post-Incident Playbook: Your Mail Server is on a Spamhaus Blacklist

The alert lands at 7 AM. Outbound mail flow has cratered. A quick check of your monitoring dashboard confirms it: one of your primary mail transfer agent (MTA) IPs is listed on a Spamhaus blocklist. Sales can't send quotes. Support can't reply to tickets. The business is grinding to a halt.

The gut reaction is pure adrenaline: get the IP address and smash the 'delist me' button on the Spamhaus website. This is a mistake. A premature removal request without a credible root cause analysis is the fastest way to get ignored, or worse, have your next listing treated with extreme prejudice.

Treating a blacklist event as an incident, not a nuisance, is the only professional path forward. You need to diagnose, contain, and eradicate the source before you ever think about asking for removal. Let's walk through the playbook.

Step 1: Stop Guessing, Start Diagnosing

Your first job is to confirm the reality of the situation. Don't just trust a second-hand alert from a monitoring tool or an angry NDR (Non-Delivery Report) from a user. Go directly to the source and gather facts. Panic is the enemy of precision.

Verify with Authoritative Tools

Use the Spamhaus Project's own IP and Domain Reputation Checker. This is your ground truth. Enter your mail server's IP address and see what it says. It will return one of two results: not listed, or listed on one or more blocklists. Third-party tools like MXToolBox can provide a wider view, checking your IP against dozens of other blocklists at once, but for a Spamhaus issue, their own portal is gospel.

Interpret the Listing Code

Spamhaus won't just say you're 'bad'; it will provide a specific code that tells you *why* you're listed. This is the most critical piece of data in your initial triage. An SBL (Spamhaus Block List) listing indicates your IP has been observed sending spam directly. An XBL (Exploits Block List) listing means you're likely infected with malware or are an open proxy. A PBL (Policy Block List) listing is less severe, often indicating an IP address that shouldn't be sending email directly to the internet, like a dynamic broadband IP. Each code points to a different root cause, and thus a different investigation path.

Step 2: Containment. Find and Isolate the 'Patient Zero'.

Before you can fix the problem, you must stop the bleeding. The malicious email is still flowing out of your server, digging your reputation hole deeper with every connection. Your immediate priority is to identify the source and shut it down. Do not proceed to the delisting step until you have contained the threat.

Hunt for the Compromised User Account

The most common culprit is a legitimate user account whose credentials have been compromised through phishing or password reuse. The attacker logs in via SMTP AUTH and uses your trusted server to blast out spam or phishing emails. These messages will pass SPF (RFC 7208) and probably DKIM (RFC 6376) because, from the server's perspective, they are legitimate authenticated mail. Your job is to find that account.

Look for anomalies. Is one account sending 10,000 emails an hour when it normally sends 20 a day? Are there SMTP authentications coming from unusual countries or IP ranges? Scour your mail logs for high-volume senders. Once identified, the immediate fix is to force a password reset, invalidate all active sessions, and strongly consider enabling multi-factor authentication if it isn't already mandatory.

Investigate the Vulnerable Web Form

The other classic vector is a poorly secured web form. 'Contact Us', 'Newsletter Signup', or 'Recommend a Friend' forms that send email directly from the web server are ripe for abuse. Spambots can automate submissions to these forms, effectively turning your web server into an open relay. Since the mail originates from your trusted web server IP, it looks legitimate.

Check your web server's access logs (e.g., Apache or Nginx logs). Look for a deluge of POST requests to the form's submission endpoint, often from a single IP or a small set of IPs. The immediate containment step is to disable the form or, if you can move quickly, implement a CAPTCHA or a more sophisticated rate-limiting mechanism.

Step 3: Root Cause Analysis in the Mail Logs

Your mail server's logs are the definitive record of what happened. They contain the evidence you need to confirm your hypothesis from the containment step and to build your case for delisting. Whether you run Postfix, Exim, or Exchange, you need to get comfortable with reading these logs.

For Postfix or Sendmail, this is typically `/var/log/maillog` or `/var/log/mail.log`. For Exim, it's often `/var/log/exim4/mainlog`. The key is to look for authenticated submissions that correspond to the timeframe of the spam event. When you suspect a compromised account, you're hunting for the username used in the SMTP AUTH command.

May 28 07:15:12 mail postfix/submission/smtpd[12345]: client=unknown[198.51.100.23], sasl_method=PLAIN, sasl_username=compromised.user@example.com — Example Postfix Log Entry

This log line is the smoking gun. It shows the timestamp, the connecting client IP, and most importantly, the authenticated user (`sasl_username`). A simple command-line query can often pinpoint the abuser a lot faster than manual inspection:

`grep 'sasl_username=' /var/log/maillog | awk -F 'sasl_username=' '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -nr | head`

This chain of commands finds all authenticated sends, extracts just the username, and gives you a sorted list of the top senders by volume. In a compromise scenario, one user will typically be at the top with a count thousands of times higher than anyone else. This is your proof.

Step 4: The Delisting Process Done Right

Only after you have contained the source and performed a root cause analysis should you approach Spamhaus for removal. Their investigators are volunteers, and they are very good at spotting someone trying to get a quick fix without doing the work. You need to present a clear, concise, and credible summary of the incident.

Follow the removal link on the Spamhaus site for your specific listing. You will be presented with a form. This is your one shot to make your case. Do not just write 'We fixed it.' Be specific. State what you found ('We identified a compromised user account, j.doe@example.com'). Explain the actions you took ('The account password has been reset, all sessions were invalidated, and we have enabled MFA for the user'). Describe the preventative measures ('We have also implemented outbound rate limiting of 500 messages per hour per user to prevent future abuse').

This level of detail demonstrates that you are a competent operator who takes network hygiene seriously. It transforms you from part of the problem into part of the solution. A well-documented request is processed far more quickly and favorably than a lazy one. If your IP starts sending spam again right after being delisted, your chances of a quick removal next time are close to zero. Do the work first.

Step 5: Post-Delisting Monitoring to Stay Clean

Getting delisted isn't the end of the incident. It's the beginning of the 'never again' phase. Your goal now is to put alarms in place so you're the first to know if something goes wrong, not the last.

Implement Outbound Queue and Rate Monitoring

You don't need a fancy commercial product for basic protection. A simple cron job that runs a script every 15 minutes can save you. Have it check the size of the outbound mail queue (`mailq | tail -n 1` often works). If the queue length exceeds a certain threshold, send an alert to your operations team. Similarly, you can parse the mail logs on a schedule to count messages per sender over the last hour. If any sender exceeds a high-water mark, that's another critical alert.

Automate Reputation Checks

Relying on users to report delivery problems is not a monitoring strategy. Use a service that automatically checks your mail server IPs against dozens of the most common blacklists every day. An alert from one of these services gives you a precious head start on the incident response process, long before the first support ticket arrives. Knowing is half the battle; knowing first is an unfair advantage.

Bonus: What about Email Authentication?

It’s a common point of confusion. Wouldn’t DMARC, SPF, and DKIM have prevented this? Not in this scenario. These protocols are designed to prevent *others* from impersonating your domain. When a threat actor compromises a legitimate account and sends mail *through your own infrastructure*, that mail is perfectly authentic.

The SPF check (RFC 7208) will pass because the mail is coming from your authorized IP. The DKIM signature (RFC 6376) will be valid because your server is signing it. Therefore, the DMARC alignment check (RFC 7489) will also pass. Email authentication protects your brand from external forgery; it does not protect you from internal compromise. That requires the operational discipline and monitoring we've just covered.

The takeaway

A blacklist notification is a symptom of a deeper problem. Your response should reflect that. The playbook is not complicated, but it demands discipline: Diagnose, Contain, Eradicate, *then* Request Removal. By treating it as a full incident, you not only resolve the immediate issue but also harden your infrastructure against the next attack.

While a Spamhaus listing is about your sending IP, analyzing inbound threats requires a different set of tools. When you're on the receiving end of a phishing campaign or BEC attempt, platforms that help you dissect the headers and authentication chains of suspicious inbound mail are critical. But protecting your outbound reputation starts with the rigorous, log-driven process we've outlined here.