Deliverability Case Study: "Born Under A Bad IP"
This song carries the weight of a sender who's read too many bounce logs and watched too many campaigns disappear into the void. The narrator isn't angry at the mailbox providers — he's accepted that authentication is the price of admission, and SPF (Sender Policy Framework, RFC 7208) is the first line of any sender's testimony. There's no bravado here, just the quiet wisdom of someone who's learned that the protocol doesn't care about your intentions, only your records.
Here is the technical breakdown of the lessons buried in this weary blues:
Verses 1 & 2: The Missing Record and the Borrowed Muscle
"I see no SPF there, boy, that sender didn't write / ... / Envelope-from say one thing, server say another name / You borrowed somebody's muscle, now you're playin' a risky game"
- The Deliverability Context: The narrator is reading SMTP headers and seeing the absence that defines so many failed campaigns — no SPF record at all, or a record that doesn't authorize the sending IP. SPF authenticates the envelope-from (the Return-Path / MAIL FROM domain), not the visible "From" header. When a marketer fires up a new ESP (Email Service Provider) without updating their DNS, the receiving server sees an unauthorized server claiming to send for a domain it has no permission to represent.
The Hard Truth: "You borrowed somebody's muscle"* is the perfect description of using a third-party sender — your ESP, your CRM, your transactional service. Each one needs to be explicitly authorized in your SPF record via an
include: mechanism. Without it, the check fails, and
DMARC alignment">DMARC alignment collapses with it.
The Ten-Lookup Wall: "One record, ten lookups, you crossed that dotted line"* refers to the SPF DNS lookup limit. SPF permits a maximum of 10 DNS lookups during evaluation; exceed that and the entire record returns
PermError, which most receivers treat as authentication failure. Stacking
include: after
include: for every vendor is the fastest way to break your own authentication.
Verse 3 & Chorus: The Qualifiers and the Baseline
"Softfail ain't forgiveness, neutral don't earn trust / Fail just says 'not invited,' rest is judgment, dust to dust / ... / It don't promise you the inbox, but it gets you past the door"
- The Lesson on Qualifiers: SPF mechanisms carry qualifiers that determine the result of a match. The narrator names them with the gravity they deserve:
-all (Fail / Hardfail):* The explicit "not invited" — anyone not listed is unauthorized.
~all (SoftFail):* A suggestion, not a verdict. Many receivers accept
softfail messages but mark them suspicious. The narrator is right: it isn't forgiveness.
?all (Neutral):* No assertion at all. As useful as no record, and just as untrusted.
The Reality: SPF passing doesn't guarantee inbox placement — it gets you "past the door." Reputation, engagement, and content filtering decide what happens after. But failing SPF means you start every race behind, because DMARC alignment requires either SPF or DKIM (DomainKeys Identified Mail) to pass and* align with the From domain.
Bridge: The Trinity and the Audit
"SPF checks the path it came from, not the name you sign / That's why DKIM holds the letter, DMARC draws the line"
The Deliverability Context: This is the cleanest two-line summary of email authentication ever set to a 12-bar progression. SPF authenticates the path
(which IP sent it). DKIM cryptographically signs the content* (proving the message wasn't altered and originated from the signing domain). DMARC ties them together by requiring
identifier alignment between the visible From domain and the authenticated domain.
The Fix: "Better audit what you have"* is the working sender's discipline. Vendors come and go — a deprecated marketing platform still listed in your
include: chain is a silent liability. Quarterly SPF audits, DMARC aggregate report (rua) review, and removing unused includes keep the record short, clean, and under the ten-lookup ceiling.
The narrator closes with the truth every weary sender eventually learns: the protocol doesn't read your heart, it reads your headers. You can write the most beautiful campaign ever drafted, but if the record at the edge of your domain doesn't tell a coherent story, the inbox will turn its face away. Authentication isn't the song — it's the tuning of the instrument before the first note ever plays.
You been watching the logs at midnight long enough, you start to see the pattern. Most mail that goes missing didn't get lost — it got refused at the door because the paperwork didn't match.
SPF won't carry you to the inbox, and it won't sweet-talk a spam filter into loving you. But without it, every other piece of your deliverability story falls apart before the first verse. Here's the hard-won wisdom from senders who learned the slow way.
Get Your SPF Record Honest
Sender Policy Framework (SPF, defined in RFC 7208) is a TXT record at your sending domain that lists the IP addresses and hosts authorized to send mail on your behalf. It's the first thing receiving servers check, and a vague record is worse than no record at all.
- Inventory every sender before you publish: Walk through your stack — marketing platform, transactional service, CRM, support desk, billing system, internal MTAs. Every vendor that sends as your domain needs to be in the record, and every retired vendor needs to come out. An old
include: for a platform you stopped using two years ago is a quiet liability.
- Mind the ten-lookup limit: SPF allows a maximum of ten DNS lookups during evaluation. Each
include:, a, mx, exists, and redirect mechanism counts, and nested includes count too. Cross that line and receivers return a permerror — your SPF doesn't soft-fail, it fails to evaluate at all, and DMARC alignment">DMARC alignment collapses with it.
- Choose your qualifier deliberately: End your record with
-all (hardfail) once you're confident in your sender inventory. ~all (softfail) tells receivers "probably not us, but accept anyway," which is a halfway house that buys you little protection. ?all (neutral) tells them nothing — don't bother.
Don't Let SPF Stand Alone
The bridge says it plain: SPF checks the path, DKIM holds the letter, DMARC draws the line. One without the others leaves a hole receivers can see through.
- Sign with DKIM at 2048 bits: DomainKeys Identified Mail (RFC 6376) attaches a cryptographic signature tied to your domain via a published public key. Use 2048-bit keys — 1024 is considered weak by modern standards — and rotate keys at least annually using distinct selectors so you can roll without downtime.
- Publish DMARC and read the reports: Domain-based Message Authentication, Reporting, and Conformance (RFC 7489) tells receivers what to do when SPF or DKIM fails alignment. Start at
p=none with a rua= aggregate reporting address, use a parser like Postmark's DMARC monitor or Dmarcian to read the XML, then move to p=quarantine and eventually p=reject once your legitimate streams are clean.
- Understand alignment, not just authentication: SPF can pass on the envelope-from (Return-Path) while your visible From: header points somewhere else entirely. DMARC requires the authenticated domain to align with the From: domain — that's the check that actually protects your brand from spoofing.
Audit Like the Infrastructure Will Change (Because It Will)
Vendors get acquired. Sending IPs get reassigned. A new team spins up a transactional service nobody told you about. SPF records rot quietly until the day volume spikes and a receiver finally looks hard.
- Schedule a quarterly SPF review: Pull your record, resolve every include, count the lookups, and verify each authorized sender is still in use. Tools like dmarcian's SPF Surveyor or MXToolbox's SPF check will flatten the tree and surface the lookup count.
- Use subdomains to isolate reputation: Send marketing from
mail.brand.com and transactional from t.brand.com, each with its own SPF, DKIM, and DMARC posture. When one stream stumbles, the other keeps its standing — and your audits get easier because each subdomain has a smaller, cleaner sender list.
- Watch for permerror in DMARC aggregate reports: If your
rua reports show SPF results of permerror or temperror, your record is broken in production even if it looks fine in a browser check. Treat these as outages, not curiosities.
Conclusion
Authentication won't earn you love or opens — reputation does that work, slowly, over time. But a sender with broken SPF starts every race behind, and no amount of clever subject lines closes that gap. Get the record right, then go earn the inbox.
Your SPF Sanity Checklist:
- Confirm your SPF record stays under the 10-DNS-lookup limit.
- End the record with
-all once your sender inventory is verified.
- Pair SPF with 2048-bit DKIM signing and a published DMARC policy.
- Monitor DMARC aggregate (
rua) reports for alignment failures and permerrors.
- Audit authorized senders quarterly — remove vendors you no longer use.
- Separate marketing and transactional mail onto distinct subdomains for reputation isolation.
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 