Deliverability Case Study: "Doing Something Unholy"
"Unholy" by Sam Smith and Kim Petras is a dark, glittering pop song about secrets, forbidden behavior, and the consequences of getting caught. The parody maps almost too cleanly onto email deliverability: a sender making all the wrong choices behind the scenes — bought lists, missing authentication, zero consent — right up until Spamhaus catches him and the inbox collapses. What follows is a technical autopsy of every failure mode named in the song.
Intro and Chorus: The Spamhaus Block
The song opens on the moment of discovery: the sender is listed on Spamhaus ZEN, and delivery has stopped.
Spamhaus ZEN is a composite DNS blocklist that consolidates four separate datasets into a single query point. The SBL (Spamhaus Block List) lists IP addresses directly tied to spam operations. The XBL (Exploits Block List) covers compromised machines — infected hosts, botnets, and proxies used to relay spam without the owner's knowledge. The PBL (Policy Block List) targets IP ranges that should never originate outbound email, typically residential or dynamic addresses that belong to end users rather than mail servers. The DBL (Domain Block List) operates at the domain layer, flagging domains found in the body or headers of spam.
A ZEN listing does not slow delivery — it stops it. Receiving mail servers that query Spamhaus ZEN at the connection level will drop the SMTP session before a single byte of message content is transmitted. Because thousands of ISPs, corporate mail gateways, and hosting providers use ZEN as a first-line filter, a listing causes inbox placement to collapse globally and simultaneously. There is no workaround, no alternative routing path, and no way to gradually recover while listed.
Manual delisting requires submitting a removal request through the Spamhaus website, demonstrating that the underlying cause has been fully remediated. For SBL listings tied to deliberate spam behavior — including purchased list campaigns — Spamhaus may decline the request or require evidence of substantive program changes before processing it. The review is not automated and is not fast. Every hour on the blocklist is revenue lost and reputation degraded further.
Verse 1: Purchased and Scraped Lists
The first verse identifies the root cause: the sender did not build his list — he bought it.
Purchased and scraped lists introduce two categories of addresses that inflict maximum reputational damage. Pristine spam traps are email addresses that have never belonged to a real person. They are seeded by ISPs and anti-spam organizations into locations where only automated harvesting tools would find them — hidden in website source code, embedded in pages scraped for bulk address collection. There is no legitimate opt-in path to a pristine trap. Sending to one is unambiguous evidence of scraping or list purchasing, and the hit registers immediately against your IP and domain.
Scraped lists compound the problem with high hard bounce rates. Email addresses harvested from the open web are frequently old, abandoned, or deliberately malformed. Sending to a large volume of invalid addresses generates 5xx SMTP errors at a rate that signals systemic negligence to every major mailbox provider. Gmail, Yahoo, and Microsoft all monitor hard bounce rates closely; sustained rates above 2% are sufficient to trigger bulk filtering or temporary blocks.
ESP terms of service uniformly prohibit sending to purchased, rented, or scraped lists. Violations result in immediate account suspension with no warning period — leaving the sender without a platform at the worst possible moment.
The only fix is confirmed opt-in, also called double opt-in. A subscriber submits their address, receives a confirmation email, and clicks to verify. The confirmation click is the only proof of a valid address, a functioning inbox, and genuine intent. It eliminates invalid addresses before they enter the list, filters out typos, and produces an engagement baseline that supports long-term deliverability.
Verse 2: Missing Authentication — DKIM, DMARC, and CAN-SPAM
The second verse turns to the sender's authentication failures and his violations of consent law.
DKIM (DomainKeys Identified Mail, RFC 6376) adds a cryptographic signature to outgoing mail. The sending domain publishes a public key in DNS; the sending mail server signs each message with the corresponding private key. Receiving servers verify the signature on arrival, confirming that the message originated from an authorized source and was not modified in transit. As of February 2024, both Gmail and Yahoo require DKIM authentication for senders exceeding 5,000 messages per day. Failure to pass DKIM causes messages to be rejected or bulk-foldered regardless of content quality.
DMARC (Domain-based Message Authentication, Reporting, and Conformance, RFC 7489) ties
SPF and DKIM together under a policy published in DNS. A
p=none record is the minimum entry point — it enables aggregate reporting (
rua) without enforcing rejection, allowing the sender to observe alignment failures before tightening policy. Without a DMARC record, mailbox providers have no instruction for handling messages that fail authentication, and there is no reporting channel to expose spoofing or misconfigured sending infrastructure. The DMARC
rua tag delivers XML reports showing which IPs are sending on behalf of the domain, which messages pass or fail SPF and DKIM, and where alignment breaks down.
CAN-SPAM establishes the minimum federal requirements for commercial email in the United States. Every bulk message must include a physical postal address, a functional unsubscribe mechanism, and must honor opt-out requests within 10 business days. The penalty is $51,744 per individual email in violation — not per campaign, per message. Alongside CAN-SPAM, Gmail and Yahoo's February 2024 requirements mandate
one-click unsubscribe (RFC 8058) for bulk senders. RFC 8058 requires a
List-Unsubscribe-Post header that processes removal via a single POST request without requiring the subscriber to log in, navigate a preferences page, or re-enter their address.
The Inbox Does Not Forgive
Spamhaus ZEN is not an arbitrary obstacle. It is a composite record of every failure mode named in this song — purchased lists generating spam trap hits, missing authentication failing ZEN's SBL and DBL checks, complaint volumes from non-consenting recipients registering across the network. The blocklist is the outcome, not the cause. The inbox is a privilege earned through explicit consent, clean data, and working authentication. The sender in this song did none of those things, and the blocklist is the ledger.
Getting blocked by Spamhaus is not bad luck — it is the predictable outcome of purchasing lists, skipping authentication, and ignoring consent. Every failure mode described in this song has a direct fix, and none of them are complicated. They simply require doing the work before the first send, not after the block.
1. Never Purchase or Scrape Lists
Purchased and scraped addresses do not represent subscribers. They represent liability. Pristine spam traps seeded by ISPs carry no prior relationship and no opt-in path — hitting them proves automated harvesting, and the damage registers immediately.
Build exclusively through confirmed opt-in (double opt-in). The confirmation click validates the address, verifies intent, and creates a record of consent that protects you legally and technically. Monitor your complaint rate closely: Gmail's threshold for action is 0.10% (warning level) and 0.30% (bulk filtering begins). A purchased list will breach both thresholds within the first campaign.
Before importing any list — even an internally collected one that has been dormant — validate it with an address verification tool such as ZeroBounce, NeverBounce, or Kickbox. These services identify invalid addresses, spam traps, role accounts, and high-risk addresses before they hit your sender reputation.
2. Deploy DKIM and Enforce DMARC
DKIM is not optional. Since February 2024, Gmail and Yahoo require passing DKIM authentication for bulk senders. Use a 2048-bit key — 1024-bit keys are no longer considered adequate. Rotate keys annually and confirm that every sending IP and subdomain is covered.
Publish a DMARC record starting at p=none with an rua reporting address. The aggregate reports will show you which sending sources are passing or failing SPF and DKIM alignment before you move to enforcement. Progress the policy through p=quarantine to p=reject as alignment issues are resolved. Confirm that SPF and DKIM are both aligned to the same domain displayed in the From header — DMARC requires at least one to align, but aligning both is the stronger posture.
3. Comply with CAN-SPAM and Global Consent Laws
CAN-SPAM sets the floor: every bulk message requires a physical postal address, a functioning unsubscribe link, and processing of opt-out requests within 10 business days. The penalty for each non-compliant message is $51,744. This is the minimum — not the standard to aim for.
Implement one-click unsubscribe (RFC 8058) on every bulk campaign. The List-Unsubscribe-Post header must be present and must process removals via a single POST request. Gmail and Yahoo enforced this requirement starting February 2024 for senders above the 5,000/day threshold.
If you send to recipients in the EU, UK, or Canada, CAN-SPAM compliance is insufficient. GDPR requires a lawful basis for processing (typically explicit consent for marketing) and data subject rights including erasure. CASL requires express consent before sending to Canadian addresses and prohibits the use of pre-checked opt-in boxes. PECR in the UK requires prior consent for electronic marketing to individuals. Map your list geography and apply the strictest applicable standard.
4. Understand Spamhaus and Monitor Your Listings
Spamhaus ZEN consolidates four blocklists into a single query:
- SBL — IP addresses operated by or associated with known spam sources, including purchased-list senders.
- XBL — Compromised infrastructure: infected hosts, open proxies, and botnet-controlled IPs.
- PBL — Dynamic and residential IP ranges that should not send outbound mail directly.
- DBL — Domains found in spam message bodies or headers; relevant even if your sending IP is clean.
The DBL matters to senders who believe their IP is safe: if a domain linked in your message body appears on the DBL — a tracking domain, a redirect domain, or a landing page URL — your email will be blocked regardless of your
IP reputation. Audit every domain that appears in your email templates and confirm none are listed before sending.
Check your sending IPs and domains against Spamhaus ZEN at lookup.mxtoolbox.com or directly via the Spamhaus website before every major campaign.
5. Monitor Reputation Continuously
Blocklist hits and complaint spikes do not come without warning signals. Build a monitoring routine that surfaces problems before they become Spamhaus listings.
- Gmail Postmaster Tools — provides domain reputation, IP reputation, spam complaint rate, and authentication pass rates directly from Google's perspective. If domain reputation shows "Bad" in Postmaster Tools, bulk filtering is already happening. Check weekly.
- Microsoft SNDS (Smart Network Data Services) — provides complaint rates and filtering status for traffic delivered to Outlook, Hotmail, and Microsoft 365. Register your sending IPs and review the dashboard weekly.
- DMARC aggregate reports — your
rua reporting address receives XML digests of every authentication event. Parse them with a tool like Valimail, DMARC Analyzer, or dmarcian to identify unauthorized senders and alignment failures before they compound.
Your Blocklist Avoidance Checklist
- Build lists exclusively via confirmed opt-in — never purchase, rent, or scrape.
- Deploy DKIM (2048-bit) and publish a DMARC record with aggregate reporting (
rua).
- Implement one-click unsubscribe (RFC 8058) on every bulk campaign.
- Monitor Gmail Postmaster Tools and Microsoft SNDS weekly.
- Check sending IPs and domains against Spamhaus ZEN before every major campaign.
Educational content. Email deliverability evolves rapidly. Platform rules (Gmail, Yahoo, etc.), engagement signals, and ESP behaviours change frequently, and real-world issues often involve conflicting signals, data quality problems, and failure modes that general best practices can’t anticipate. Content on this site is provided for informational purposes only and does not replace a thorough analysis by a qualified deliverability professional.
Terms of Use