Deliverability Case Study: "Block It"
This parody flips the script on the typical sender-versus-filter narrative. Instead of hearing from the frustrated marketer, "Block It" puts us inside the mind of the mailbox provider itself — the gatekeeper standing at the MX record, methodically rejecting every malformed, misaligned, and misbehaving message that dares to knock. It's a rare and refreshing perspective: the receiver as protagonist, the spammer as antagonist, and DMARC as the bouncer at the door.
Here is the technical breakdown of what's actually happening at the SMTP gateway when the filter says "block it":
Verse 1: Policy Enforcement and the 5xx Rejection
"The policy is strict and the rules are really clear / We block it, just block it / ... / Don't be a spoofing man"
- The Deliverability Context: This verse is a near-perfect dramatization of a hard rejection — specifically, a
550 5.7.1 SMTP response, which mailbox providers issue when a message fails policy checks (typically DMARC p=reject enforcement against a spoofed domain). The "policy" being referenced is literally the DMARC policy published in the legitimate domain owner's DNS TXT record.
The Anti-Spoofing Tactic: "Don't be a spoofing man"* points to direct domain spoofing — forging the
From: header to impersonate a trusted brand. Before DMARC was widely adopted, this was trivially easy. With DMARC enforcement (either
p=quarantine or
p=reject) backed by aligned
SPF and
DKIM, spoofed mail gets rejected at the gateway before it ever reaches a user's spam folder.
The Fix: "You better do what you can"* is the receiving server's challenge to the sender — publish proper SPF, sign with DKIM, and align both with a
From: domain that matches your DMARC record.
Chorus: DMARC as the Final Verdict
"Showin' our filters your records are tight / Failing your DMARC will end the night"
- The Deliverability Context: "Records are tight" refers to the three foundational DNS records every legitimate sender must publish: an SPF TXT record listing authorized sending IPs, a DKIM public key at the appropriate selector subdomain (
selector.domainkey.yourdomain.com), and a DMARC policy record at dmarc.yourdomain.com.
The Verdict: "Failing your DMARC will end the night"
is technically precise. DMARC is evaluated after* SPF and DKIM — it's the final adjudication layer. Even if SPF passes, if neither SPF nor DKIM aligns with the
From: domain (matching organizational domains under relaxed alignment, exact match under strict), DMARC fails, and the published policy dictates whether the message is monitored, quarantined, or rejected outright.
Verse 2: Header Alignment and the Bounce-Drop-Notify Sequence
"Your headers don't align, you wanna reach a man / ... / We'll bounce you, then we'll drop you, then we'll tell you it's fair"
The Deliverability Context: "Headers don't align" is the heart of DMARC failure. SPF authenticates the Return-Path (envelope sender), and DKIM authenticates the d= domain in the signature. DMARC requires that at least one* of these aligns with the visible
From: header domain. Misalignment is the #1 cause of legitimate-but-failing DMARC mail.
The Sequence: "Bounce you, then we'll drop you, then we'll tell you it's fair"* describes the receiver's actual workflow:
Bounce:* return a 5xx SMTP rejection during the transaction.
Drop:* silently discard, or route to spam, depending on the
pct= tag and policy.
Tell you it's fair:* deliver an aggregate
rua report (the daily DMARC XML feedback) to the address the sender published — receivers literally document and report every rejection.
The Reputation Reality: "You're playin' with your rep"* underscores that repeated authentication failures don't just kill individual messages — they degrade
domain reputation in systems like Google Postmaster Tools, often dropping a domain from "High" to "Low" within a single bad campaign.
The filter isn't being cruel; it's being consistent. Every block is a small act of trust preserved — for the inbox, for the brand being spoofed, and for the recipient who never asked to be deceived.
Tired of receivers shouting "Block it!" the moment your mail hits their
MTA? When your
DMARC fails, your headers don't align, and your
domain reputation has seen better days, mailbox providers won't just quietly route you to spam — they'll bounce you, drop you, and tell you it's fair. Here's how to make sure the only thing getting blocked is the spammer impersonating
you, not your legitimate campaigns.
Prove You're Not a Spoofing Man (Authentication Foundations)
The song's "spoofing man" gets blocked because his records don't add up. Receiving servers run cryptographic checks on every inbound message, and if you can't prove ownership, you fail before content is ever scored.
- Publish a Tight SPF Record: Sender Policy Framework (RFC 7208) lists the IPs authorized to send for your domain. Use
-all (hardfail) once you're confident in your sources, and stay under the 10-DNS-lookup limit — exceeding it triggers a permerror that fails authentication entirely, regardless of which IP sent the mail.
- Sign Everything with DKIM: DomainKeys Identified Mail (RFC 6376) attaches a cryptographic signature verified against a public key in DNS. Use 2048-bit keys (1024-bit is now considered weak), rotate selectors at least annually, and ensure the
d= domain aligns with your visible From domain.
- Enforce DMARC Beyond p=none: A
p=none policy is monitoring mode — it tells receivers nothing about how to handle failures. Move to p=quarantine (with pct= ramping from 25 to 100) and ultimately p=reject once your rua reports show clean alignment. Gmail and Yahoo's 2024 bulk sender requirements demand at least p=none with proper alignment for senders over 5,000 messages/day.
Showin' Our Filters Your Records Are Tight (Domain Pairing & Alignment)
The lyrics warn, "you have to show us that your domains are paired." That's identifier alignment — and it's where most senders quietly fail without realizing it.
- Achieve SPF Alignment: The domain in the Return-Path (envelope sender) must match (relaxed) or exactly equal (strict) the From domain. ESPs that use their own bounce domains will fail SPF alignment unless you configure a custom Return-Path on your subdomain.
- Achieve DKIM Alignment: The
d= value in the DKIM signature must align with the From domain. This is typically easier to control than SPF alignment, which is why DKIM is the more reliable path to DMARC pass for senders using third-party platforms.
- Isolate Reputation by Subdomain: Send marketing from
mail.brand.com and transactional from tx.brand.com or the root. A complaint storm on promotional mail shouldn't poison your password reset deliverability.
Don't Play With Your Rep (Reputation Management)
"You're playin' with your rep, this ain't no truth or dare." Reputation is the cumulative scorecard mailbox providers keep on your IPs and domains — and it's harder to repair than to maintain.
- Watch Google Postmaster Tools Daily: GPT exposes Google's view of your domain reputation (Bad/Low/Medium/High), spam rate, and authentication pass rates. Keep your spam complaint rate strictly below 0.10% — crossing 0.30% triggers severe filtering and is explicitly called out in Gmail's bulk sender rules.
- Monitor Microsoft SNDS: Smart Network Data Services reports IP status (green/yellow/red), complaint rates, and spam trap hits for Outlook/Hotmail. Yellow is a warning; red means you're already being filtered aggressively.
- Warm Up New IPs and Domains Methodically: Start at 200–500 messages/day to your most engaged subscribers, doubling every 2–3 days over a 4–8 week ramp. New domains require their own warmup independent of IP warmup — sending volume from a cold domain triggers immediate suspicion.
Don't Get Bounced, Dropped, and Told It's Fair (List Hygiene & Filter Survival)
The song's threat — "we'll bounce you, then we'll drop you" — is exactly what happens when you ignore bounce data and complaint signals.
- Suppress Hard Bounces Immediately and Permanently: A 5xx response (especially 550 "no such user") means the mailbox is gone. Repeatedly mailing it signals poor list hygiene and can hit recycled spam traps; keep your bounce rate under 2%.
- Implement RFC 8058 One-Click Unsubscribe: Required by Gmail and Yahoo since February 2024 for bulk senders, the
List-Unsubscribe-Post header lets users opt out without confirmation pages. Ironically, easier unsubscribes lower your complaint rate — frustrated users hit "spam" instead.
- Run a Sunset Policy: Suppress subscribers with no opens or clicks in 90–120 days, ideally after a re-engagement campaign. Apple Mail Privacy Protection inflates open rates, so weight clicks more heavily when defining "engaged."
Conclusion
The chorus is right: no one wants to be rejected. But rejection isn't arbitrary — it's the predictable consequence of unaligned authentication, sloppy reputation management, and ignored bounce signals. Get your records tight, and the filters will let you through every time.
Your Block-Proof Deliverability Checklist:
- Confirm SPF, DKIM, and DMARC are publishing, passing, and aligned with your From domain.
- Move DMARC from
p=none to p=quarantine or p=reject after verifying rua reports are clean.
- Keep Gmail Postmaster spam rate under 0.10% and monitor SNDS for IP status changes.
- Implement RFC 8058 one-click unsubscribe headers on all bulk mail.
- Permanently suppress hard bounces and sunset unengaged subscribers at 90–120 days.
- Warm new IPs and domains over 4–8 weeks, starting with your most engaged segment.
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