Your Domain Is Blacklisted. Now What? An IR Playbook.

The alert hits your SOC channel on a Tuesday morning. It's not another commodity malware detection or a phishing report from a user. It’s a threat intelligence feed update, and the indicator is one of your own corporate domains. `yourcompany.com` has just been added to the Spamhaus Domain Block List (DBL).

Immediately, the operational clock is ticking. Every outbound email is now suspect. Sales teams can't reach prospects. Automated system notifications are getting bounced. Customer support replies are vanishing into the void. This isn't just an email deliverability headache; it's a direct hit to business operations and brand reputation. The blacklist is telling the world your domain is associated with malicious activity.

Panic is a valid reaction, but it's not a strategy. A domain blacklisting is a symptom of a deeper security failure. This playbook provides a structured incident response plan to move from alert to root cause, transforming a crisis into a methodical hunt for the underlying compromise.

Stop the Bleeding: Triage the Alert

Before you start tearing apart servers, your first job is to validate the alert and understand its scope. Threat feeds can have false positives, and not all blacklists are created equal. Your immediate goal is to confirm the what, where, and why of the listing.

Validate the Listing and Context

First, verify the listing directly with the blacklist operator. Go to their public lookup tool—for example, the Spamhaus Project's domain checker—and query your domain. Never trust a link in an alert email itself; that's just asking for a follow-up phishing incident. Differentiate between an IP-based block (SBL) and a domain-based block (DBL). An SBL targets the sending IP of a mail server, often due to spam volume. A DBL, which is our focus here, targets the domain name itself because it was found within the body of malicious messages, typically in a URL.

Host `yourcompany.com` is listed in the DBL. For more information, please see `http://www.spamhaus.org/query/domain/yourcompany.com`.

The listing page is your first piece of intelligence. It will often include a sample of the malicious URL that triggered the listing and a rough timestamp. This is your starting point for the entire investigation. That URL is your patient zero.

Assess the Blast Radius

How bad is this? The impact depends entirely on the blacklist's influence. A listing on a major, reputable blocklist like the Spamhaus DBL, SURBL, or URIBL is a critical event. The vast majority of email security gateways and internet service providers subscribe to these feeds. For practical purposes, you can assume your ability to send email to anyone is severely degraded. A listing on a smaller, private, or more niche list might have limited impact but still signals an underlying problem that cannot be ignored.

Hypothesis One: The Website Is Infected

A domain is more than just the part of an email address after the '@'. It resolves to web servers, and those servers are a prime target. One of the most common reasons for a DBL listing is a compromised website that is unknowingly hosting a phishing kit, malware, or a malicious redirector.

Hunt for Malicious Files

Get a shell on your web server. Your first task is a file system sweep. Look for files modified around the time of the blacklist event. A simple `find /var/www/ -mtime -2 -ls` can be surprisingly effective. Attackers often drop PHP files with random names (e.g., `wp-content/uploads/192hfg.php`) or modify core application files and `.htaccess` files to create backdoors or redirects. These files are almost always obfuscated to evade simple signature-based scanners.

If you run a file integrity monitoring (FIM) solution, your job is easier. Check for any unauthorized file change alerts that correlate with the incident timeline. If not, you're relying on manual inspection and `stat` commands. Pay obsessive attention to directories related to content management systems like WordPress or Joomla, especially their plugin and theme folders. This is the soft underbelly of many web infrastructures.

Scour the Web Logs

Your web server's access and error logs are the ground truth. Start by searching for the malicious URL path provided by the blacklist. Who requested it? More importantly, how was it created? Look for HTTP POST requests to unexpected endpoints right before the file's creation timestamp. A POST to an image file path or a GET request with a long, Base64-encoded query string are classic signs of a web shell being used to upload malicious content. Also, check for unexpected outbound connections originating *from* the web server; a compromised box can be used as a pivot point or proxy.

Hypothesis Two: A Mailbox Is Hijacked

If the web server investigation comes up empty, your next prime suspect is a compromised employee account. An attacker with valid credentials can authenticate to your mail server and send thousands of malicious emails that will pass SPF (RFC 7208) and DKIM (RFC 6376) checks with flying colors. The emails might contain links to an external phishing site, but the sending reputation of `yourcompany.com` still gets burned in the process.

In some cases, the attacker combines attack vectors. They might use the compromised mailbox to send emails with links pointing to a benign-looking but attacker-controlled page on your *own* website, which then performs a redirect. This makes the email look even more legitimate.

Analyze Mail Server Logs

Time to dig into your mail transfer agent (MTA) logs. You're hunting for behavioral anomalies. The most obvious indicator is sending volume. Is a single user account, which normally sends 50 emails a day, suddenly sending 5,000 in an hour? That's a five-alarm fire. Correlate this with authentication logs. Did the high-volume sending start shortly after a login from an unfamiliar ASN or a country where you don't do business? This is the classic 'impossible travel' scenario.

Mar 15 03:22:15 mail postfix/qmgr[4510]: 8B1C3A0F45: from=<compromised.user@yourcompany.com>, size=2112, nrcpt=500 (queue active) — Example Postfix log line

That `nrcpt=500` is the smoking gun. No legitimate user action generates a single message destined for 500 individual recipients simultaneously. This is the hallmark of a spam script abusing an authenticated session. Finally, use your administrative tools (e.g., PowerShell for Microsoft 365, GAM for Google Workspace) to inspect the user's mailbox for suspicious inbox rules. Attackers frequently create rules to auto-forward sensitive emails to an external address or delete messages that might reveal their presence.

Clean Up and Get Delisted

Finding the point of entry is a victory, but the incident isn't over. You must now methodically eradicate the attacker's foothold, recover your systems, and harden your defenses to prevent a recurrence.

Eradicate, Recover, and Harden

Follow a strict sequence. First, contain the threat: take the compromised server offline, force-expire the password for the hijacked account, and kill all its active sessions. Second, eradicate the artifacts: delete the malicious web files and scan the system for other backdoors. If you suspect a rootkit, the only safe path is to rebuild from a known-good backup. Third, recover services by bringing the clean, patched system back online.

Finally, and most critically, harden your systems. This is your post-incident review. Why did this happen? Was a web application plugin out of date? Patch it. Was the user account not protected by MFA? Enforce it. Was the web server allowed to make arbitrary outbound connections? Implement egress filtering. A failure to harden your environment is an open invitation for the attacker to return, and blacklist operators have long memories.

Requesting Delisting

Only after you are confident that the underlying issue has been resolved should you request removal from the blacklist. Each list has its own process, usually accessible from the lookup page you used during triage. Be prepared to provide a concise, honest account of the compromise and the specific steps you took to remediate it. Vague assurances won't work; they've heard it all before.

Delisting is not instantaneous. It can take hours or even a couple of days. During this time, continue to monitor your logs and mail flow. Any sign of re-infection will likely land you back on the list, this time with a much longer and more difficult path to removal.

The takeaway

A domain blacklisting feels like a public shaming, but it's more accurately described as a free, high-fidelity security audit. It's an external, unbiased signal that something inside your perimeter is broken. That forgotten marketing site, the executive who refused to use MFA, the unpatched server in a dev environment—the blacklist doesn't create these problems, it simply holds a mirror up to them.

Treat every blacklist alert as a confirmed indicator of compromise until proven otherwise. By applying a methodical incident response process, you can move past the initial panic and conduct a productive investigation. Ultimately, the best defense is a proactive one. Continuously monitoring the email authentication and traffic patterns that are the precursors to these events is the only way to spot an account takeover or infrastructure abuse before it damages your reputation.