Postmortem: How a Botched ESP Migration Got Our Domain Blacklisted

The migration was done. All health checks were green. The first big campaign went out through the new Email Service Provider, and for an hour, the dashboard was a sea of positive metrics. Opens were tracking, clicks were coming in. We celebrated a smooth cutover. Then the alerts started firing. Not from our monitoring, but from the sales team: 'A customer said our invoice just landed in their spam folder.'

What followed was a slow-motion catastrophe. A trickle of spam reports became a flood. Our previously pristine sender reputation was tanking in real-time. But every tool we checked gave us a clean bill of health. Our sending IPs weren't on any blocklists. Our SPF record was correct. The emails were, technically, passing authentication.

This is the story of how we ended up on a domain-based blacklist—a URIBL—and the subtle, critical difference between email authentication and email alignment. It's a postmortem every engineer managing a mail-sending service needs to read.

Incident Timeline: Clean IPs, Dirty Reputation

When deliverability tanks, your first instinct is to check your sending IP reputation. So we did. We ran our new ESP's dedicated IPs through every major IP-based Real-time Blackhole List (RBL) we could find—Spamhaus's SBL, SORBS, Barracuda's BRBL. All of them came back clean. This made sense; the ESP's IP pools are well-maintained. The IPs were warm and had a solid history.

This initial 'all clear' was a dangerous misdirection. It made us look for more complex problems. Was there a content issue? Were we tripping spam filters with certain keywords? We spent hours A/B testing subject lines and body copy, a complete waste of engineering time. The problem wasn't the content of the message, and it wasn't the IP address sending it. The problem was the domain *inside* the message.

The Pivot to Domain-Based Intelligence

After exhausting IP-based and content-based theories, we finally widened our search to domain-based and URI-based blacklists. These are different beasts from IP RBLs. They don't list the IP address of the sender; they list the domains found in the body and headers of spam messages. A message from a clean IP can still get flagged if it contains a link to a blacklisted domain. Or, in our case, if the domain in the `From:` header itself is blacklisted.

We ran our company's domain, the one in our `From:` address, through broad-spectrum checkers that include URIBLs like SURBL and the Spamhaus Domain Block List (DBL). And there it was. A bright red flag. Our primary corporate domain was listed on the Spamhaus DBL. The reason code was vague, pointing to 'abuse,' which could mean anything. But now we had a tangible lead. The 'what' was a domain blacklist. The 'why' was still buried in our email headers.

Unraveling the Root Cause: DKIM Alignment vs. Authentication

Finding the DBL entry was the breakthrough. Now we had to connect it to our ESP migration. When we set up the new provider, we followed their standard instructions. We updated our DNS with a new SPF entry, as defined by RFC 7208, to include the ESP's sending infrastructure. It looked something like `v=spf1 include:spf.esp.net ~all`. It was valid, and SPF checks were passing.

We also enabled DKIM (DomainKeys Identified Mail), as specified in RFC 6376. The ESP generated a selector and a public key, which we published in DNS. Mails were being signed, and receiving mail servers were validating that signature. A look at the `Authentication-Results` header on a delivered email confirmed it: `spf=pass` and `dkim=pass`. So what was the issue? The answer is in the details of that DKIM pass.

Authentication-Results: mta.example.org; dkim=pass header.d=esp-domain.com; spf=pass (sender IP is 192.0.2.1) smtp.mailfrom=bounces.mycompany.com; dmarc=fail action=none header.from=mycompany.com; — Representative Authentication-Results Header

Look closely at that header. Specifically, `dkim=pass header.d=esp-domain.com`. The DKIM signature was valid, but it was signed by the ESP's domain, not ours. Meanwhile, the `header.from` shows `mycompany.com`. This is a classic DKIM alignment failure. The domain that *signed* the message (`esp-domain.com`) does not align with the domain that *appears to have sent* the message (`mycompany.com`).

Why Heuristic Filters Hate Misalignment

For a receiving mail server, this misalignment is a significant, negative signal. While it doesn't automatically mean the email is malicious, it's a characteristic shared by many phishing and spam campaigns. Attackers often use legitimate (but compromised or free) services to send mail, resulting in signatures from domains that don't match the forged `From:` address. Sophisticated anti-spam systems and blacklist operators use this misalignment as a strong input to their heuristic models. Our DMARC record (RFC 7489) was set to `p=none`, so the alignment failure didn't cause an outright rejection. But it was contributing to a high spam score, which, at the volume we were sending, was enough to trip the DBL's automated listing criteria.

The Delisting Playbook: Proving You've Fixed the Problem

Simply finding the blacklist and hitting the 'delist request' button is a rookie mistake. It will almost certainly fail if you haven't fixed the underlying issue. Blacklist operators need to see that the abusive signal has stopped and that you've implemented controls to prevent it from recurring. Your appeal is a technical argument, not a plea for mercy.

Step 1: Correct the Signing Configuration

Our first and most critical action was to dive back into the ESP's settings. We had used the default, shared DKIM configuration. The solution was to configure a custom DKIM signing domain, sometimes called a 'branded' or 'whitelabeled' domain. This involved generating a new public/private keypair specific to our account and publishing the new public key under our own domain's DNS (e.g., at `selector2._domainkey.mycompany.com`).

With this change, our ESP began signing our outgoing mail with a DKIM `d=` tag that matched our `From:` header's domain: `d=mycompany.com`. Now, our mail was not only authenticated, it was *aligned*. This immediately resolves the core negative signal that led to the listing.

Step 2: Submitting the Delisting Request

Only after deploying the new DKIM configuration and verifying the headers on new outbound emails did we proceed with the delisting request on the Spamhaus project website. The form is simple, but the comments section is where you make your case. We were concise and technical.

We stated: 'Our domain, mycompany.com, was recently listed. The root cause was a DKIM alignment failure following a migration to a new ESP on [Date]. We were previously using a shared signing domain from the ESP. We have now configured a custom DKIM signing domain, and all mail sent from mycompany.com is now DKIM-aligned with the From: header domain. This has corrected the signal that led to the listing.' We sent a new test email and confirmed the `Authentication-Results` now showed `dmarc=pass`. Because we demonstrated we understood the fault and had fixed it, the delisting request was processed and approved within a few hours.

Hardening for the Future: From Reactive to Proactive

This incident was a painful lesson in the nuances of email authentication. Getting a `pass` verdict isn't good enough. Alignment is what matters for building and maintaining a strong sender reputation. The best way to police this across your entire sending infrastructure is with DMARC.

Our DMARC policy had been `p=none`, which is 'monitor-only' mode. This was a deliberate choice, but we had been neglecting the most valuable part of DMARC: the aggregate (`rua`) reports. These reports, typically sent daily as XML files from receivers like Google and Microsoft, are a complete census of who is sending mail using your domain.

Had we been properly parsing and monitoring these `rua` reports, we would have seen the DKIM alignment failure from our new ESP on day one. The reports would have clearly shown a high volume of mail from the ESP's IPs passing SPF, but failing DKIM alignment. This data would have been a massive red flag, allowing us to fix the custom signing domain configuration *before* it ever led to a reputation problem or a blacklist entry. Essentially, DMARC reporting is the early-warning system we failed to use.

Going forward, DMARC report monitoring became a non-negotiable part of our security and deliverability workflow. Moving our policy from `p=none` to `p=quarantine` and eventually `p=reject` was our next goal, but that's a project that can only begin once you have 100% visibility into every legitimate service sending on your behalf. These reports gave us that visibility.

Bonus: Don't Forget ARC and MTA-STS

While DMARC is the primary tool for this kind of visibility, two other standards are crucial for a modern email security posture. Authenticated Received Chain (ARC), defined in RFC 8617, helps preserve authentication results across complex mail flows like forwarding, which notoriously break SPF. An ARC-sealed set of headers can help a final recipient trust the original DMARC assessment, even if the direct hop breaks SPF. It's a lifesaver for mailing lists and convoluted inbox setups.

Similarly, MTA-STS (RFC 8461) hardens your inbound mail flow. By publishing an MTA-STS policy, you tell other mail servers that they must use encrypted TLS connections to deliver mail to your MX servers. This prevents downgrade attacks and man-in-the-middle snooping of inbound email, a critical protection against corporate espionage. While it wouldn't have prevented our blacklist issue, it's a key part of a defense-in-depth email strategy.

The takeaway

The biggest takeaway is that DMARC reports are not just for fighting phishing. They are your ground truth for sender visibility. Every marketing platform, every HR system, every cloud service that sends mail using your domain will show up in those reports, along with its SPF and DKIM alignment status. Ignoring this data is like flying an airplane without an instrument panel; you might be fine in clear weather, but you're blind to the dangers lurking in the clouds.

Fixing a domain blacklist requires a technical, evidence-based approach, and preventing one requires proactive monitoring. Parse your DMARC reports. You can't protect what you can't see, and tools like MailSleuth.AI exist precisely to turn that firehose of XML data into actionable intelligence before a small configuration error becomes a full-blown incident.