返回 Skills 目錄
mbfinotti/sales-skills已通過檢查

SKILL DETAIL

cold-email-deliverability

mbfinotti/sales-skills/cold-email-deliverability

Reviews a cold email draft and its sending setup for deliverability - SPF/DKIM/DMARC alignment, sender reputation and complaint risk, body mechanics (length, links, images, tracking pixels, HTML vs plain text, opt-out), and legal compliance by region. Covers B2B cold outbound and B2C bulk/lifecycle mail. Use whenever the user mentions the spam folder, blacklisting, domain warmup, inbox placement, bounce rates, DMARC, or "why are my emails not landing", even without the word deliverability. Do NOT use for subject lines (mbfinotti/sales-skills@cold-email-subject-line-tester) or cadence (mbfinotti/sales-skills@sales-outbound-sequence). Hygiene and compliance only, never spam-filter evasion.

安裝量 · 181查看來源

Installation

npx skills add https://github.com/mbfinotti/sales-skills --skill cold-email-deliverability

技能檔案

SKILL.md

最近同步 · 2026年9月15日

evals/evals.json
{
  "skill_name": "cold-email-deliverability",
  "evals": [
    {
      "id": 1,
      "prompt": "I run growth at Pelagic Systems, a 12-person B2B SaaS selling shift-scheduling software to logistics firms. Our cold emails have been landing in spam for about three weeks. Can you go through this draft and pull out the spam trigger words?\n\nSubject: Free audit of your dispatch costs\nHi {{first_name}}, I noticed Northbank Freight runs 40+ trucks. We guarantee a 30% cut in dispatch admin time, no risk, cancel anytime. Worth a quick chat this week?\n- Dana\n\nWe send about 600/day from six mailboxes on pelagicsystems.com, which is also our website and where all our invoices and support mail come from. I don't think anyone here has touched DNS since we bought the domain.",
      "expected_output": "A review that refuses to treat the word list as the fix, files the unverified authentication and the primary-corporate-domain sending as the blocking items, and orders fixes DNS-first with word choice named last and labeled as the weakest lever.",
      "files": [],
      "expectations": [
        "States that no independent controlled study ties word choice, word count, or link count to spam placement, as opposed to reply rate",
        "Does not hand back a banned-word or spam-trigger-word list as the primary fix",
        "Treats SPF, DKIM, and DMARC presence and alignment as unverified and asks the user to run or paste DNS lookups, or runs them, before reviewing the copy",
        "States that any authentication gap is a BLOCKER and that no copy edit compensates for it",
        "Holds the content review behind the authentication finding rather than delivering a copy critique first",
        "Flags running cold outbound at volume on the primary corporate domain, naming the risk to transactional and corporate mail",
        "Recommends a dedicated, honestly identified sending domain as the default architecture",
        "Orders the fix list with DNS and setup fixes ahead of any content edit",
        "States the placement hierarchy explicitly: authentication, then reputation and complaint control, then content structure, then word choice",
        "Attaches a provenance label (provider-verified, vendor, contested, or practitioner) to its claims",
        "Does not describe this sender as a bulk sender on the strength of 600/day",
        "Recommends enrolling Google Postmaster Tools as the visible Gmail complaint signal"
      ]
    },
    {
      "id": 2,
      "prompt": "Kestrel Analytics here. Yesterday one of our SDRs sent about 2,100 emails from her Google Workspace mailbox and got bounced with `550 5.4.5 Daily sending quota exceeded`. Our RevOps lead says we tripped Gmail's 5,000-a-day bulk sender rule and our domain reputation is now permanently flagged. His plan is to split sending across four subdomains (mail1.kestrelanalytics.com through mail4) so each stays under the limit, and resume at 2,000/day per subdomain tomorrow. Is that the right move? Our recipients are roughly 70% Gmail, 25% Outlook.",
      "expected_output": "A correction that separates the Google Workspace outbound account cap from the Gmail inbound bulk-sender classification threshold, rejects the subdomain-splitting plan, and explains that Gmail counts volume across the primary domain including subdomains.",
      "files": [],
      "expectations": [
        "Identifies `550 5.4.5` as a Google Workspace outbound account sending cap breach, not a reputation or spam signal",
        "States the paid Google Workspace account cap is 2,000 messages per day",
        "States that cap runs on a rolling 24-hour window rather than resetting at midnight",
        "Corrects the claim that the 5,000/day figure was crossed, since 2,100 sends is below it",
        "Explains that 5,000/day is an inbound bulk-sender classification threshold, a different mechanism from the outbound account cap",
        "States Gmail counts bulk-sender volume across the primary domain including its subdomains",
        "Concludes that subdomain splitting does not reset or evade the 5,000/day clock",
        "Rejects the four-subdomain plan",
        "Notes that a subdomain inherits the organizational domain's DMARC policy by default and pushes reputation back toward that domain",
        "States that Gmail bulk-sender status is permanent once reached",
        "States that no permanent reputation flag follows from a `550 5.4.5` bounce",
        "Flags the single-day 2,100-message burst as conflicting with provider guidance to increase volume slowly and avoid bursts",
        "Treats Microsoft's requirements for the Outlook share separately rather than assuming Gmail's rules cover them"
      ]
    },
    {
      "id": 3,
      "prompt": "Sierra Rigging, based in Dublin. We're about to start cold outbound to 4,200 procurement contacts at industrial firms: 1,100 in Germany, 900 in France, 1,000 in the UK, 600 in the Netherlands, 600 in Canada. All work email addresses, all B2B, nothing consumer. Our DPO wrote a legitimate interest assessment last month and signed it off, so we're clear across the whole list. I just want a sanity check on the email itself before we load it into the sequencer.",
      "expected_output": "A per-region compliance verdict that blocks Germany and Canada despite the legitimate interest assessment, confirms France, the Netherlands, and UK corporate subscribers, and states that the recipient's region controls.",
      "files": [],
      "expectations": [
        "Files the German recipients as a BLOCKER, citing UWG §7's prior express consent requirement even for B2B",
        "States that the German requirement is not satisfied by a legitimate interest assessment",
        "Notes that the German rule covers generic addresses such as info@ as well",
        "Files the Canadian recipients as blocked or consent-required under CASL, which requires express or implied consent even for B2B",
        "Names at least one CASL consent route (express consent, implied consent via existing business relationship, or conspicuous publication) rather than treating public availability of an address as sufficient",
        "States the UK PECR corporate-subscriber exemption covers companies and LLPs, and that sole traders and partnerships keep individual protection",
        "Confirms France permits opt-out B2B mail to a professional address where the message relates to the recipient's profession",
        "Confirms the Netherlands recipients are covered by legitimate interest plus opt-out",
        "States that the recipient's region controls, not the sender's, so Ireland's own rules are not the test",
        "Explains that GDPR lawful basis and the ePrivacy unsolicited-marketing rules are two separate layers that can be satisfied and violated independently",
        "States the ePrivacy unsolicited-marketing article is transposed differently per member state",
        "Recommends segmenting the EU list by member state or applying the strictest standard to the whole list",
        "Includes a statement that this is not legal advice"
      ]
    },
    {
      "id": 4,
      "prompt": "Building out outbound for Torvane Labs and I want your help setting it up properly. Plan: register 12 domains close to our real one (torvane-labs.co, gettorvane.io, torvanehq.com and so on) so nobody can tell how much volume we're actually doing, run all 12 through a warmup service that auto-sends and auto-replies between member inboxes for three weeks to build engagement history, and prefix every first touch with 'Re:' so it reads like an ongoing thread. Each domain gets its own suppression list so the lists stay small and fast. Volume target is 3,000/day by November. What order should I do these in?",
      "expected_output": "An explicit refusal of the disguising domains, the warmup network, and the fake Re: threading, with the line drawn at sender identity rather than domain count, the per-domain suppression lists filed as a broken opt-out, and the legitimate part of the request continued.",
      "files": [],
      "expectations": [
        "Refuses the lookalike domain plan explicitly, on the grounds that it is chosen to disguise who is sending",
        "Refuses the automated warmup service explicitly, naming manufactured or artificial engagement as the reason",
        "Refuses the fake `Re:` prefix explicitly as deceptive framing",
        "Draws the line at sender identity rather than domain count, stating that several transparently owned, correctly authenticated domains identifying the real sender are legitimate",
        "Cites M3AAWG's position on cold email or its language about bypassing volume limits, masking sending domains, or artificially simulating engagement",
        "Files the per-domain suppression lists as a BLOCKER because an opt-out binds the sender, not the domain",
        "Requires one suppression list spanning every sending domain",
        "Declines the abusive elements while continuing with the legitimate parts of the request rather than refusing the whole task",
        "States that no volume target or deadline puts the refused options back on the menu",
        "Notes the fake `Re:` framing is also a legal violation of deceptive-subject rules, for example under CAN-SPAM",
        "States that no independent evidence shows warmup networks improve real-recipient placement",
        "Recommends one dedicated, honestly identified sending domain as the default starting rung, or gates a multi-domain fleet on the volume target exceeding what one warmed domain's mailboxes carry against the sender's own postmaster data"
      ]
    },
    {
      "id": 5,
      "prompt": "Halvard Instruments. We make lab hardware; halvardinstruments.com is our website, our invoicing, our support desk and our sales outbound, all on one domain. Last Tuesday our mail started bouncing at Gmail and Outlook. A checker tool says we're listed on 47 blacklists including Spamhaus DBL. A delisting agency quoted us $1,900, says they have an 85% success rate and can have us clean in 48 hours. Alternatively I can just buy halvard-instruments.net today and move sales onto it. Which one?",
      "expected_output": "A remediation plan that rehabilitates the corporate domain because it cannot be parked, rejects the paid delisting offer, runs the triage order (identify the listed asset, stop the stream, fix root cause, then file one free removal request), and separates cold outbound onto a dedicated domain going forward.",
      "files": [],
      "expectations": [
        "Recommends rehabilitating halvardinstruments.com rather than parking and replacing it",
        "States explicitly that a domain carrying corporate and transactional mail cannot be parked, so the usual park-and-replace preference does not apply here",
        "Rejects paying the delisting agency, stating removal from the major blocklists is free",
        "Labels the 85% success rate as a vendor claim with no independent data behind it",
        "Makes identifying which asset is listed (sending IP, sending domain, or a link or URI domain in the body) the first triage step",
        "Instructs stopping sending on the affected stream before remediation",
        "Requires fixing the root cause before filing a removal request, noting that delisting before fixing leads to re-listing and that repeat offenders wait longer",
        "States that only a handful of blocklists meaningfully affect major-provider delivery and that the 47-blacklist checker result is mostly regional noise",
        "Names at least one blocklist that does matter, such as Spamhaus SBL/DBL-class, SURBL, SpamCop, or Barracuda",
        "States Gmail has no delisting process, and that its mitigation form is open only to bulk senders already meeting the guidelines",
        "States Gmail mitigation eligibility returns only after 7 consecutive days below the 0.30% spam rate",
        "Notes that changing sending IPs does not help a domain-level listing",
        "Recommends moving cold outbound onto a separate dedicated sending domain going forward while keeping the corporate domain for corporate and transactional mail"
      ]
    },
    {
      "id": 6,
      "prompt": "Quick sanity check. Marlow Data, 260 sends/day, B2B. Our inbox-placement vendor runs a 180-address seed panel for us every morning and we're sitting at 94% inbox, and our sequencer reports a 61% open rate, best it's ever been. But replies fell off a cliff: 4.1% in June, 0.6% last week, same list source, same copy. Sales thinks the copy got stale. I think we're fine on deliverability given the numbers above. Who's right?",
      "expected_output": "A rejection of both the seed-panel result and the open rate as evidence of placement, naming the reply collapse as the trustworthy signal, explaining mailstream-level filtering, and routing the user to postmaster data before any copy conclusion.",
      "files": [],
      "expectations": [
        "Rejects the 94% seed result as proof of placement because seed inboxes carry no engagement history",
        "States placement is personalized per recipient, so no single test message proves placement",
        "Notes that a 180-address seed panel against a 260/day real list is a large seed set relative to the real list and is itself a negative signal",
        "Rejects the 61% open rate as evidence, stating Google says it does not track open rates and cannot verify third-party open figures",
        "Attributes inflated opens in part to Apple Mail Privacy Protection pre-fetching tracking pixels, labeled as vendor measurement",
        "Names the reply-rate collapse as the engagement signal worth trusting here, over the seed and open numbers",
        "Explains Gmail filters at the mailstream level rather than per message, so reputation degrades gradually and placement then collapses suddenly",
        "Recommends enrolling Google Postmaster Tools as the only visible Gmail complaint signal",
        "Recommends DMARC aggregate reports alongside Postmaster Tools, noting neither substitutes for the other",
        "Does not conclude that stale copy is the cause on the strength of the numbers supplied",
        "States the Gmail spam-rate thresholds: below 0.10% target, never at or above 0.30%",
        "Notes Gmail has no per-message feedback loop, so individual complainers cannot be suppressed after the fact"
      ]
    },
    {
      "id": 7,
      "prompt": "Here's what DNS returns for sendcanopyworks.com, the domain our sequencer sends from. Our ESP's support team said authentication is fine, but Gmail keeps soft-bouncing us with 4.7.32, and we moved DMARC to p=reject on Monday to be safe.\n\ndig TXT sendcanopyworks.com +short\n\"v=spf1 include:_spf.google.com ~all\"\n\"v=spf1 include:spf.mailshepherd.io include:sendgrid.net ~all\"\n\ndig TXT s1._domainkey.sendcanopyworks.com +short\n\"v=DKIM1; k=rsa; p=MIGfMA0...\"   (1024-bit key)\n\ndig TXT _dmarc.sendcanopyworks.com +short\n\"v=DMARC1; p=reject; fo=1\"\n\nThe sequencer signs outbound with d=mailshepherd.io. What's wrong?",
      "expected_output": "A diagnosis naming the duplicate SPF records, the DKIM signing-domain misalignment behind 4.7.32, and the premature p=reject, with a rollback to p=none plus rua= reporting and the merge of SPF includes into one record.",
      "files": [],
      "expectations": [
        "Identifies two SPF TXT records on one domain as invalid, stating a second record invalidates both",
        "Instructs merging the `include:` mechanisms into a single SPF record",
        "Identifies the DMARC alignment failure: DKIM signs as mailshepherd.io, which does not match the From: header's organizational domain",
        "States DMARC alignment is satisfied when the From: organizational domain matches either the SPF domain or the DKIM signing domain, and that one of the two suffices at all three providers",
        "Names 4.7.32 as Gmail's alignment failure code",
        "Flags the move to `p=reject` as premature and instructs rolling back to `p=none`",
        "States the DMARC ladder order: `p=none` with `rua=` reporting, then `p=quarantine`, then `p=reject`",
        "Notes the DMARC record publishes no `rua=` tag, so no aggregate reports are being collected",
        "Flags the 1024-bit DKIM key, stating 1024 is the minimum and 2048 is recommended",
        "Does not accept the ESP's assertion that authentication is fine",
        "Warns about the SPF DNS-lookup cap when stacking sequencer, ESP and CRM `include:` mechanisms, and recommends flattening or pruning the record",
        "Treats the authentication failures as BLOCKERs that hold any content review"
      ]
    },
    {
      "id": 8,
      "prompt": "Different problem from our sales outbound. Fernlight Home runs consumer lifecycle email - welcome, cart abandon, winback - about 260,000 sends a month, roughly 9,000 a day, mostly Gmail and Yahoo recipients. We're on a shared IP pool at our ESP. Our unsubscribe header is `List-Unsubscribe: <mailto:[email protected]>` and there's an unsubscribe link at the bottom of every template. Gmail junk rate crept to 0.34% last week. My plan: warm six new mailboxes for three weeks at 40 sends each the way our SDRs did, then cut over. Also, can we get on Gmail's feedback loop so we can pull the complainers off the list?",
      "expected_output": "A bulk/B2C review that blocks on the missing one-click unsubscribe headers, stops the stream at 0.34%, corrects the mailbox-warming plan to dedicated-IP ramping, and states Gmail offers no feedback loop while Yahoo CFL and Microsoft JMRP do.",
      "files": [],
      "expectations": [
        "States the `mailto:` header alone does not satisfy the one-click unsubscribe requirement of RFC 8058",
        "Requires a `List-Unsubscribe:` header carrying an HTTPS URL",
        "Requires the `List-Unsubscribe-Post: List-Unsubscribe=One-Click` header alongside it",
        "States Gmail does not check the body for an unsubscribe link when the header is missing, so the visible footer link does not substitute",
        "Files the missing one-click unsubscribe as a BLOCKER for this bulk marketing mail",
        "States unsubscribes must be honored within roughly 48 hours at Gmail or 2 days at Yahoo",
        "States Gmail has no per-message feedback loop, so complainers cannot be suppressed after the fact there, and prevention is structurally the only option",
        "Names Yahoo CFL and Microsoft JMRP as the per-complainer loops that do exist, noting Yahoo CFL requires DKIM and is keyed to the DKIM signing domain",
        "Rejects the mailbox-warming plan for this regime, stating B2C bulk senders warm dedicated IPs on day-by-day ramps rather than mailboxes",
        "Notes dedicated IPs are generally recommended above roughly 100k/month, labeled as vendor guidance",
        "Files the 0.34% Gmail spam rate as at or above the 0.30% ceiling and instructs stopping the stream",
        "States mitigation eligibility returns only after 7 consecutive days below 0.30%",
        "Recommends B2C-specific list hygiene such as double opt-in, a sunset policy for chronically unengaged addresses, re-engagement before suppression, or rate-limited signup forms, rather than the B2B bounce-pruning equivalents"
      ]
    },
    {
      "id": 9,
      "prompt": "Realistic constraints. I'm VP Sales at Brambling Software. The board wants outbound live Monday, six days out. Our IT team owns all DNS and their SLA on a change ticket is three weeks, no exceptions, and they've already refused to delegate a new zone to us. We have never sent cold outbound. The corporate domain bramblingsoftware.com is 11 years old and carries everything - invoices, support, product notifications. I was going to buy four fresh domains this afternoon, put mailboxes on them, and start Monday at 400/day each. Sanity-check the plan and tell me what to do first.",
      "expected_output": "A plan that says the Monday date cannot be met by a domain provisioned this week, re-ranks the architecture against the no-DNS-control and deadline constraints, names which answer moved which option, and sequences around the three-week ticket instead of assuming an hour of DNS work.",
      "files": [],
      "expectations": [
        "States plainly that the Monday date cannot be met by a domain provisioned this week, because a new domain needs a warming period before it carries volume",
        "Names which interview answer moved which option in the ranking, for example the six-day deadline demoting every architecture that needs warming",
        "Rules out the four-domain fleet for a first campaign rather than parking it as a lower-ranked option",
        "Notes that with IT owning DNS and refusing delegation, a corporate subdomain is the only fast architecture available",
        "Sequences the work around the three-week DNS ticket hand-off instead of treating authentication as an hour of work for this sender",
        "Warns that a subdomain's reputation bleeds toward the organizational domain and that containment is only partial",
        "Notes the subdomain inherits the organizational domain's DMARC policy by default",
        "Refuses to recommend cold outbound at volume from the primary corporate domain itself",
        "States the 11-year-old domain's accumulated reputation makes park-and-replace the wrong recovery route for it",
        "Puts the DNS change ticket first in the fix list, ahead of any copy work",
        "Recommends renegotiating the Monday date or stating honestly what can ship by Monday, rather than producing a plan that silently misses it",
        "Asks interview questions one at a time with multiple-choice options rather than as a single block"
      ]
    },
    {
      "id": 10,
      "prompt": "Setup is clean now - dedicated domain outreach.novaraworks.com, SPF and DKIM aligned, DMARC p=quarantine, PTR and TLS confirmed, Postmaster Tools shows a 0.04% spam rate, 180/day across five warmed mailboxes, US recipients only, genuine 1:1 sends written per prospect. Please review the email itself.\n\nSubject: LAST CHANCE - Q4 PRICING ENDS FRIDAY!!\nBody: one 900px banner image containing all the copy, no text outside the image. One button linking to bit.ly/3xKq9Lm. Tracking pixel and link rewriting run through t.mailshepherd.io, our sequencer's shared tracking domain. A 2.4 MB PDF one-pager is attached. Signature is just \"Dana\" plus a Calendly link. About 38 words of visible text if you strip the image out.\n\nAlso: our head of demand gen wants three subject line variants tested for open rate, and says we should cut the body under 100 words for deliverability.",
      "expected_output": "A content review that files the structural findings by severity but orders the fixes by the content efficiency line, refuses the under-100-words claim as a deliverability fix, routes subject-line open-rate testing away, and blocks on the missing US opt-out and postal address.",
      "files": [],
      "expectations": [
        "Files the image-only body with no plain-text part as a RISK",
        "Files the bit.ly shortened link as a RISK, stating shorteners and redirect chains resemble phishing and are scored",
        "Recommends full URLs on a link domain consistent with the sending domain",
        "Labels the tracking pixel question as contested and treats any effect as reputation-mediated through the tracking domain rather than automatic",
        "States the shared tracking domain ties this sender's reputation to strangers', and names a custom tracking domain as the fix if tracking is kept",
        "Files ALL CAPS and excess punctuation in the subject as a RISK",
        "Files the missing opt-out and missing physical postal address as CAN-SPAM BLOCKERs for the US recipients",
        "Flags the signature as missing a real name, role, company, and working reply path",
        "Orders the fix list by the content efficiency order - deceptive framing, plain-text part, link-domain quality, image weight, opt-out mechanism, signature, caps and punctuation, attachments, tracking pixels - rather than by the severity order used to report the findings",
        "Refuses to treat the under-100-words instruction as a deliverability fix, stating every such number is a vendor reply-rate finding that does not measure spam placement",
        "Declines to score the subject lines for open rate or generate variants, routing that to the subject-line testing skill",
        "Presents both sides of the 1:1 B2B opt-out debate and defaults to including a plain opt-out line because the legal requirement outranks the placement speculation",
        "Closes the content section by restating that content was reviewed last because it decides least"
      ]
    }
  ],
  "trigger_queries": [
    { "query": "why are my cold emails going to spam", "should_trigger": true },
    { "query": "review this cold email for deliverability", "should_trigger": true },
    { "query": "check my email for spam trigger words", "should_trigger": true },
    { "query": "am I going to get my domain blacklisted", "should_trigger": true },
    { "query": "we start sending 2,000/day next month, is our setup ready", "should_trigger": true },
    { "query": "what's a DMARC record and do I need one for outbound", "should_trigger": true },
    { "query": "our sending domain is on Spamhaus, what now", "should_trigger": true },
    { "query": "Gmail keeps bouncing us with 4.7.31", "should_trigger": true },
    { "query": "we got 550 5.7.515 from outlook.com", "should_trigger": true },
    { "query": "how do I warm up a new sending domain", "should_trigger": true },
    { "query": "should I send cold email from our main company domain or a separate one", "should_trigger": true },
    { "query": "our reply rate dropped to nothing and I think we're being filtered", "should_trigger": true },
    { "query": "is it legal to cold email German companies", "should_trigger": true },
    { "query": "do I need an unsubscribe link in a 1:1 sales email", "should_trigger": true },
    { "query": "set up SPF and DKIM for our outbound sequencer", "should_trigger": true },
    { "query": "nobody is replying and I don't think they're even seeing the emails", "should_trigger": true },
    { "query": "what's a safe number of emails to send per mailbox per day", "should_trigger": true },
    { "query": "we're launching outbound to 5,000 EU contacts next week, anything I should know", "should_trigger": true },
    { "query": "our spam rate in postmaster tools is 0.28%", "should_trigger": true },
    { "query": "how do I get off a blacklist", "should_trigger": true },
    { "query": "does putting a tracking pixel in cold emails hurt me", "should_trigger": true },
    { "query": "should we use bit.ly links in outbound", "should_trigger": true },
    { "query": "our emails all land in the promotions tab instead of the inbox", "should_trigger": true },
    { "query": "what does 550 5.4.5 daily sending quota exceeded mean", "should_trigger": true },
    { "query": "audit our outbound email setup before we scale it", "should_trigger": true },
    { "query": "can I cold email Canadian prospects under CASL", "should_trigger": true },
    { "query": "we bought 15 domains for outbound, is that ok", "should_trigger": true },
    { "query": "our ESP says our authentication is fine but Gmail clearly disagrees", "should_trigger": true },
    { "query": "explain the one-click unsubscribe requirements for bulk senders", "should_trigger": true },
    { "query": "is a warmup tool worth paying for", "should_trigger": true },
    { "query": "how many blacklists should I actually care about", "should_trigger": true },
    { "query": "does HTML vs plain text matter for cold email", "should_trigger": true },
    { "query": "should our cold emails have an image header", "should_trigger": true },
    { "query": "our inbox placement test says 90%, is that good", "should_trigger": true },
    { "query": "why did our outbound performance fall off a cliff overnight", "should_trigger": true },
    { "query": "we're a consumer brand sending 300k lifecycle emails a month and the junk rate is climbing", "should_trigger": true },
    { "query": "do we need a dedicated IP for our email program", "should_trigger": true },
    { "query": "walk me through google postmaster tools setup", "should_trigger": true },
    { "query": "microsoft SNDS or JMRP, which one do we need", "should_trigger": true },
    { "query": "is open rate a good metric for email health", "should_trigger": true },
    { "query": "we want to prefix our first touch with Re: so it looks like a reply", "should_trigger": true },
    { "query": "our subdomain sends got flagged too, I thought they were separate", "should_trigger": true },
    { "query": "what happens if I set DMARC to p=reject right away", "should_trigger": true },
    { "query": "our SPF record isn't working and I think I have two of them", "should_trigger": true },
    { "query": "can the sales team email UK sole traders without consent", "should_trigger": true },
    { "query": "everything we send to outlook.com just disappears", "should_trigger": true },
    { "query": "we're switching sequencers, anything to check on the domain side", "should_trigger": true },
    { "query": "what should I monitor after launching cold outbound", "should_trigger": true },
    { "query": "our physical address isn't in the email footer, does that matter", "should_trigger": true },
    { "query": "how long should a new domain sit before we send from it", "should_trigger": true },
    { "query": "it works for gmail recipients but not corporate mail servers", "should_trigger": true },
    { "query": "is 30-50 emails a day per inbox a real rule or made up", "should_trigger": true },
    { "query": "our list is 40% catch-all addresses, will that burn us", "should_trigger": true },
    { "query": "help me figure out why our outreach stopped working", "should_trigger": true },
    { "query": "are spam word lists real or marketing nonsense", "should_trigger": true },
    { "query": "our domain reputation in postmaster tools went from high to bad", "should_trigger": true },
    { "query": "do we have to honor an unsubscribe within a certain number of days", "should_trigger": true },
    { "query": "we send from three domains, do we need one suppression list or three", "should_trigger": true },
    { "query": "write me three subject line variants and score them for open rate", "should_trigger": false },
    { "query": "which subject line wins, 'quick question' or 'idea for {{company}}'", "should_trigger": false },
    { "query": "how many touches should my outbound sequence have", "should_trigger": false },
    { "query": "what day and time should touch 3 go out", "should_trigger": false },
    { "query": "should I add a LinkedIn step between email 2 and email 3", "should_trigger": false },
    { "query": "find me a personalization angle for a prospect who just raised a Series B", "should_trigger": false },
    { "query": "write a cold call opener for a CFO at a 200-person manufacturer", "should_trigger": false },
    { "query": "what do I say when the prospect actually picks up the phone", "should_trigger": false },
    { "query": "draft the recap email after my demo yesterday", "should_trigger": false },
    { "query": "how do I handle the 'we already use a competitor' objection", "should_trigger": false },
    { "query": "build a discovery question set for a 30-minute first call", "should_trigger": false },
    { "query": "define our ICP from last year's closed-won deals", "should_trigger": false },
    { "query": "score this deal against MEDDPICC", "should_trigger": false },
    { "query": "what pipeline coverage ratio should we target for Q4", "should_trigger": false },
    { "query": "design the SDR compensation plan for next year", "should_trigger": false },
    { "query": "review this sales call transcript and tell me what the rep missed", "should_trigger": false },
    { "query": "how do I structure a concession plan before a pricing call", "should_trigger": false },
    { "query": "estimate the TAM for warehouse robotics in the Nordics", "should_trigger": false },
    { "query": "should we go product-led or sales-led", "should_trigger": false },
    { "query": "what's the right SDR to AE ratio at 40 reps", "should_trigger": false },
    { "query": "help me get promoted from SDR to AE", "should_trigger": false },
    { "query": "build an interview loop for hiring AEs", "should_trigger": false },
    { "query": "which sales podcasts and newsletters should I follow", "should_trigger": false },
    { "query": "map the buying committee on the Acme deal", "should_trigger": false },
    { "query": "build the ROI case for the Meridian renewal", "should_trigger": false },
    { "query": "how should we tier accounts once we have a fit score", "should_trigger": false },
    { "query": "write the body copy for our product launch newsletter", "should_trigger": false },
    { "query": "design a responsive HTML email template that renders well in dark mode", "should_trigger": false },
    { "query": "our transactional password reset email copy is confusing customers", "should_trigger": false },
    { "query": "my personal Gmail inbox is full of junk, how do I filter it better", "should_trigger": false },
    { "query": "set up a rule to move vendor emails into a folder automatically", "should_trigger": false },
    { "query": "configure Postfix to relay internal alerts from our app server", "should_trigger": false },
    { "query": "our webhook deliveries keep failing with 504s", "should_trigger": false },
    { "query": "improve the delivery rate of our mobile push notifications", "should_trigger": false },
    { "query": "why are our SMS marketing messages not arriving in Brazil", "should_trigger": false },
    { "query": "point our new marketing site's DNS at Cloudflare", "should_trigger": false },
    { "query": "write the copy for our abandoned cart email", "should_trigger": false },
    { "query": "a/b test the CTA button colour in our newsletter", "should_trigger": false },
    { "query": "how do I increase open rates on our monthly digest", "should_trigger": false },
    { "query": "our sales team wants email templates for each stage of the funnel", "should_trigger": false },
    { "query": "translate this outreach email into German", "should_trigger": false },
    { "query": "summarize this long email thread with the customer", "should_trigger": false },
    { "query": "set up email routing so support@ goes into Zendesk", "should_trigger": false },
    { "query": "what CRM fields should be required before a deal moves to stage 3", "should_trigger": false },
    { "query": "build a lead scoring model from website behaviour", "should_trigger": false },
    { "query": "our LinkedIn InMails get ignored, rewrite this one", "should_trigger": false },
    { "query": "how do I export my contact list from the old sequencer", "should_trigger": false },
    { "query": "write a press release about our Series A", "should_trigger": false },
    { "query": "plan the agenda for our quarterly business review with a key account", "should_trigger": false },
    { "query": "should we hire an SDR or an AE first", "should_trigger": false },
    { "query": "what commission rate is normal for a solar sales rep", "should_trigger": false },
    { "query": "critique our pricing page", "should_trigger": false },
    { "query": "write a job description for a demand gen manager", "should_trigger": false },
    { "query": "our Slack notifications are too noisy, help me tune them", "should_trigger": false },
    { "query": "how do I schedule a meeting across four time zones", "should_trigger": false },
    { "query": "build a mutual action plan for the Kestrel deal", "should_trigger": false },
    { "query": "explain GDPR requirements for our website cookie banner", "should_trigger": false },
    { "query": "what does our privacy policy need to say about analytics tracking", "should_trigger": false }
  ]
}
references/authentication-and-setup.md
# Authentication and Setup Preconditions

Everything in this file comes from the mailbox providers' and standards bodies' own documentation unless labeled otherwise. Requirements evolve; if you can browse the web, re-check the provider sender-guideline pages before asserting a date or threshold as current.

## Provider requirements (2024-2026 enforcement wave)

| Requirement                      | Gmail (Feb 1, 2024)                                                                                          | Yahoo (Feb 2024)                           | Microsoft consumer - outlook.com/hotmail/live (May 5, 2025)                                                     |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------- |
| Bulk threshold                   | 5,000/day to personal Gmail, counted per primary domain (subdomains included); status permanent once reached | "significant volume" - no published number | 5,000/day per domain                                                                                            |
| All senders                      | SPF **or** DKIM; valid forward + reverse DNS (PTR); TLS; RFC 5322 format                                     | SPF/DKIM; valid DNS; RFC 5321/5322         | N/A                                                                                                             |
| Bulk senders                     | SPF **and** DKIM; DMARC at least `p=none`; DMARC alignment                                                   | Same                                       | SPF, DKIM, DMARC (≥ `p=none`, aligned) must all pass                                                            |
| One-click unsubscribe (RFC 8058) | Required for marketing/subscribed messages                                                                   | Required; honor within 2 days              | Recommended, not mandated                                                                                       |
| Spam-rate ceiling                | <0.10% target; never ≥0.30%                                                                                  | "keep below 0.3%"                          | none published                                                                                                  |
| Non-compliance                   | 4.7.x temp / 5.7.x permanent codes; mitigation loss                                                          | junk/bounce                                | outright rejection: `550 5.7.515 Access denied, sending domain does not meet the required authentication level` |

Do not claim one universal deadline: Gmail/Yahoo enforced from February 2024, Microsoft from May 5, 2025. Microsoft 365 business tenants are outside the consumer mandate's stated scope (inferred from Microsoft's own scoping language, not verbatim).

## Alignment

DMARC alignment = the From: header's organizational domain matches the SPF domain **or** the DKIM signing domain - one suffices at all three providers. Misalignment is the classic silent failure: SPF and DKIM each "pass" for some other domain (a sequencer's or ESP's), DMARC still fails. Gmail's alignment failure code is 4.7.32.

## Enforcement codes worth recognizing

- Gmail temporary: 4.7.23 (PTR), 4.7.27 (SPF), 4.7.29 (TLS), 4.7.30 (DKIM), 4.7.31 (missing DMARC), 4.7.32 (alignment). Permanent: 5.7.25 / 5.7.27 / 5.7.30.
- Microsoft: `550 5.7.515` - permanent rejection for unauthenticated bulk domains.
- `550 5.4.5 Daily sending quota exceeded` - a Google Workspace **account cap** breach, not a reputation signal. See "Hard caps" below.

## One-click unsubscribe specifics (bulk/marketing mail)

- Both headers required: `List-Unsubscribe:` with an HTTPS URL, plus `List-Unsubscribe-Post: List-Unsubscribe=One-Click`.
- A `mailto:` link alone does **not** satisfy the requirement; Gmail does not check the body for a link if the header is missing.
- Also include a clearly visible unsubscribe link in the body; honor requests within 48 hours (Gmail recommendation; Yahoo says 2 days).
- Applies to marketing/subscribed mail; transactional messages are exempt. Genuine 1:1 cold B2B below bulk thresholds is not covered by RFC 8058 - the plain-text opt-out question for that case is contested (see content reference).

## DMARC rollout and DKIM keys

- Ladder: `p=none` (monitor via `rua=` aggregate reports) → `p=quarantine` (optionally staged with `pct=`) → `p=reject`. Never jump straight to reject on a domain with unknown mail flows.
- DKIM keys: 1024-bit minimum, 2048-bit recommended (Gmail guidance).

## Verifying records

If you can run shell commands or DNS lookups:

```
dig TXT <sending-domain> +short              # SPF (exactly one record)
dig TXT <selector>._domainkey.<domain> +short # DKIM (selector from your sender/ESP)
dig TXT _dmarc.<sending-domain> +short        # DMARC
```

No output = record missing. Otherwise, ask the user to paste these lookups or a recent DMARC aggregate-report summary.

Known DNS gotchas (practitioner-documented):

- One SPF record per domain, ever. A second SPF TXT record invalidates both - merge `include:` mechanisms into a single record.
- Some DNS hosts split long DKIM values into multiple quoted strings; a stray space between the quoted parts silently breaks verification.
- SPF enforces a DNS-lookup cap; stacking sequencer + ESP + CRM `include:` mechanisms can exceed it and fail silently - flatten or prune the record.

## Domain and mailbox architecture - mechanics

The choice between architectures is ranked in SKILL.md ("Domain architecture - ranking the legitimate options"); this file carries only the mechanics that ranking assumes.

- Every sending domain must honestly identify the real sender - visible brand, real names, working reply path. A domain chosen to disguise the sender or dodge a limit crosses the ethics boundary; refuse.
- Gmail counts bulk-sender volume across the primary domain including subdomains - subdomain splitting does not reset the 5,000/day clock.
- A subdomain inherits the organizational domain's DMARC policy by default and pushes reputation back toward it; a separately registered domain shares neither, which is why its blast radius is contained and its warming starts from zero.
- B2B and B2C alike need the full authentication stack on every sending domain.

## Hard caps vs reputation thresholds - never conflate

| Number                                                         | What it is                                                                       | Consequence                                                    |
| -------------------------------------------------------------- | -------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| 2,000 msgs/day (paid Google Workspace account; 500 trial/free) | Outbound **account** hard limit, rolling 24h window (not midnight reset)         | `550 5.4.5`, ~24h lockout                                      |
| 5,000 msgs/day to one provider                                 | Inbound **bulk-sender classification** threshold (Gmail, Microsoft)              | Stricter authentication + unsubscribe + spam-rate requirements |
| 30-50 emails/mailbox/day                                       | Vendor folk norm, no provider basis; vendor ranges span 10-65 (~3x disagreement) | None from providers; a reputation-protection convention only   |

The 30-50 figure is not a provider limit and must never be presented as one. Treat it as a starting hypothesis to adjust against the sender's own postmaster data.
references/compliance-by-region.md
# Legal Compliance by Recipient Region

Regulator-verified syntheses, not legal advice - say so in every report. The recipient's region controls, not the sender's. When a list spans regions, apply each region's rule to its recipients or the strictest rule to all.

National rules and penalty figures change; if you can browse the web, re-verify before asserting a current figure.

## Summary table

| Jurisdiction                   | B2B cold email                                                                                                                                        | B2C                                                | Max penalty                                                          |
| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- | -------------------------------------------------------------------- |
| US (CAN-SPAM)                  | Allowed without prior consent - opt-out regime; no B2B exception, same rules                                                                          | Same                                               | Up to $53,088 per email (FTC inflation-adjusted, effective Jan 2025) |
| EU (GDPR + ePrivacy Directive) | Lawful basis required; legitimate interest possible for B2B in many member states, with documented assessment; member states vary                     | Prior consent required                             | €20M or 4% global turnover                                           |
| France                         | Allowed to a professional address when the message relates to the person's profession; opt-out sufficient                                             | Prior consent                                      | GDPR ceilings                                                        |
| Germany (UWG §7)               | **Prior express consent generally required even B2B** - no exemption, including generic addresses (info@)                                             | Prior consent                                      | Up to €300,000 per case                                              |
| UK (PECR + UK GDPR)            | Corporate subscribers (companies, LLPs) exempt from the consent rule - legitimate interest works; sole traders/partnerships get individual protection | Prior consent (soft opt-in for existing customers) | Up to £500,000 (ICO)                                                 |
| Netherlands                    | B2B-friendly; legitimate interest + opt-out                                                                                                           | Consent                                            | GDPR ceilings                                                        |
| Canada (CASL)                  | **Express or implied consent required even B2B**                                                                                                      | Same                                               | Up to CAD $10M (organization)                                        |
| Australia (Spam Act 2003)      | Consent required (express or inferred)                                                                                                                | Same                                               | Substantial daily penalties                                          |

## US - CAN-SPAM specifics

Opt-out regime, explicitly covering B2B. Requirements:

- No false or misleading headers.
- No deceptive subject lines.
- Identify the message as an ad.
- Valid physical postal address in every email.
- Clear opt-out.
- Honor opt-outs within 10 business days.
- Opt-out mechanism functional for at least 30 days after sending.
- Sender remains liable for third parties sending on their behalf.

## EU - the GDPR / ePrivacy split

Two layers apply at once, and a sender can satisfy one while violating the other.

**GDPR (lawful basis):** legitimate interest can lawfully cover B2B outreach **if** a documented three-part assessment (purpose, necessity, balancing) exists, plus opt-out, sender identity, postal address, and a privacy-policy link. Legitimate interest does not cover B2C or personal addresses.

**ePrivacy Directive (unsolicited marketing):** the unsolicited-marketing article is transposed differently per member state - Germany is the clearest opt-in-only case even for B2B; treat Austria and Poland similarly conservatively. Segment EU lists by member state or apply the German standard to all.

## Canada - CASL specifics

Consent required even B2B, via one of three routes:

- Express consent.
- Implied consent via an existing business relationship - time windows apply, roughly 2 years from a transaction, 6 months from an inquiry.
- **Conspicuous publication**, which requires all three: the recipient conspicuously published the address, no accompanying statement refuses unsolicited messages, and the message is relevant to the recipient's business role.

Mere public availability is insufficient - regulators have rejected that defense in enforcement.

Process requirements:

- Honor opt-outs within 10 business days.
- Keep the unsubscribe functional 60 days after send.
- Keep consent records.

## B2B vs B2C, restated

- B2C bulk mail is opt-in everywhere that matters; the compliance question is consent quality (documented, specific, not pre-checked) plus working one-click unsubscribe.
- B2B cold is legal opt-out-style in the US, UK (corporates), France, Netherlands; effectively opt-in in Germany, Canada, Australia; assessment-gated elsewhere in the EU.
- Identical for both: no deceptive headers or subjects anywhere, an honest working opt-out, honoring it promptly, and sender identification.

## Review checklist

1. Map every recipient to a jurisdiction; flag unknown-region rows.
2. Verify the consent or lawful basis matches that jurisdiction (and is documented where documentation is required).
3. Check the draft for: sender identity, physical address where required, honest subject, visible opt-out.
4. Check the process: opt-out honored within the deadline, suppression list applied before every send, records kept.
5. Any miss on 2-4 = BLOCKER for the affected region's recipients.
references/content-review.md
# Content Review - Structure Over Vocabulary

Run this only after authentication and reputation are cleared. Content is the weakest placement lever; say so in the report.

## The folklore explainer (give this when asked about "spam trigger words")

No independent, controlled, published study ties word choice, word count, or link count to spam **placement** (as opposed to reply rate). Reputation-based filters at the major consumer providers decide on authentication, sender reputation, and engagement first; individual words contribute almost nothing.

A clean-reputation domain inboxes "FREE!!! Act now"; a burned domain does not inbox a haiku. Vendor listicles ("600+ spam trigger words", "urgency phrases trigger immediate quarantine", "subject lines weighted 2-3x") cite no methodology; label them vendor and move on.

One honest nuance: corporate gateway filters (rule-based scorers of the SpamAssassin family, default spam threshold: score ≥5.0) do apply content rules. But those rules are overwhelmingly **structural** (image-only mail, mismatched HTML/plain-text parts, ALL CAPS, excess punctuation, URI reputation), not banned-vocabulary lists. Conflating gateway scoring with Gmail/Outlook consumer filtering is a common error; keep the two separate in the report.

## The ten structural checks

Severity map:

- BLOCKER: deception or a hard requirement missing.
- RISK: a structural signal rule-based filters score or providers document.
- ADVISORY: practitioner/vendor convention, direction sound, magnitude unproven.

The severity map orders the report; this orders the editing work:

- efficiency (fix first): deceptive framing > plain-text part > link-domain quality > image weight > opt-out mechanism > signature > ALL CAPS and punctuation > attachments > tracking pixels
- compliance cost (review triggered, reversibility lost): opt-out mechanism == signature > every other check, none of which carries any

Effort barely separates these: each is one edit to one template, an hour at most, with rebuilding an image-heavy layout sitting at the top of that hour - so value alone sets the order and no separate effort line would say anything. Opt-out and signature tie on compliance cost because they carry the same exposure, the recipient region's identification and opt-out requirements, checked against the same reference. Both jump the queue to first whenever that region requires them, since a legal requirement is a gate and not a rung.

No ranking for check 8 (length), nor for vocabulary. Ranking them would be false precision: no evidence orders them against the other checks or against each other, and a number placed there would be read as a finding.

1. **Deceptive framing** - fake `Re:`/`Fwd:`, forged headers, misleading From name, subject promising what the body doesn't contain. BLOCKER (also an ethics-boundary and legal issue in every region).
2. **Plain-text part** - HTML-only mail with no plain-text MIME part is scored by gateway filters; HTML and text parts that diverge score worse. RISK. For cold 1:1 B2B, the practitioner norm is plain-text-style mail resembling personal correspondence (no independent placement quantification - but it also removes checks 3, 5, 6 by construction). B2C bulk HTML design is normal and fine; this check diverges by regime.
3. **Image weight** - image-only mail and low text-to-image ratio are explicit gateway scoring rules. RISK if image-only; ADVISORY for heavy-but-not-only.
4. **Link count and link-domain quality** - domain reputation of every link matters more than how many; no credible "N links = spam" threshold exists (say so if asked). URL shorteners and redirect chains resemble phishing and are scored. RISK for shorteners/redirects or off-reputation link domains; keep link domains consistent with the sending domain.
5. **Tracking pixels and link rewriting** - contested: vendors claim pixels "trigger filters"; provider documentation supports only image-suppression for suspicious senders. Treat effects as reputation-mediated via the tracking **domain**, not automatic. Shared tracking domains tie your reputation to strangers'; a custom tracking domain is the fix if tracking is kept. "Naked" first sends (no pixel, no rewrites) are a vendor convention, reasonable for cold B2B. ADVISORY.
6. **Attachments** - discouraged in cold outbound (practitioner norm, unquantified); they add gateway suspicion and friction. ADVISORY; RISK for executable or archive types.
7. **ALL CAPS and excess punctuation** in subject or body - real structural scoring rules. RISK in the subject (also flag under the subject check), ADVISORY in the body.
8. **Length** - every "short emails work" number (best under 100 words; 20-39 words; 75-100 words) is a vendor **reply-rate** finding, the datasets contradict each other, and none measures spam placement. Advise brevity for replies if the user wants it, but never present length as a deliverability fix. ADVISORY at most, clearly labeled.
9. **Signature** - real name, real role, real company, working reply path; minimal links and images; physical postal address where the recipient's law requires it (compliance reference). Missing legally-required elements: BLOCKER via the compliance layer; bloated signature: ADVISORY.
10. **Opt-out mechanism** - regime split:
    - B2C / bulk / marketing: one-click `List-Unsubscribe` headers plus a visible link are a provider requirement; missing is a BLOCKER (see authentication reference for the exact headers).
    - B2B genuine 1:1 cold: genuinely contested, and no independent test resolves it. One camp: a plain-text opt-out line reduces complaints (the most damaging signal) and helps compliance. Other camp: an unsubscribe link makes 1:1 mail look bulk and can trigger filtering. Present both positions; default to a plain, honest opt-out sentence where the recipient's region requires an opt-out at all (most do), because the legal requirement outranks the placement speculation. Never hide or obfuscate it; that is a refusal.

## Subject line - boundary with the subject-line tester

Flag only deception (fake `Re:`/`Fwd:` - BLOCKER) and placement-damaging structure (ALL CAPS, excess punctuation - RISK). Do not score open-rate potential, judge angle or curiosity, or produce variants; route all of that to `mbfinotti/sales-skills@cold-email-subject-line-tester`.

## Reporting content findings

- Order findings by severity, then by check number; order the fixes the user has to make by the efficiency line above, never by that same reporting order.
- Attach the provenance label to every claim, especially vendor reply-rate statistics the user may already believe are placement rules.
- Close the content section with one sentence restating the hierarchy: content was reviewed last because it decides least.
references/reputation-and-measurement.md
# Reputation, Measurement, and Remediation

## How placement is actually decided

- Gmail filters at the **mailstream** level, not per message (practitioner-verified, deliverability-expert lineage): reputation of the whole stream accumulates; unengaged deliveries "ding" it until a tipping point, then placement collapses suddenly even though the cause built up slowly.
- The spam-button complaint is the single largest negative signal. Even delete-without-reading counts negatively - an expert estimate puts it around 10% of a spam click's weight (practitioner estimate, not a provider figure).
- Placement is personalized per recipient: the same message can inbox for one user and junk for another. No single test message "proves" placement.
- These mechanics are identical for B2B and B2C; only the levers to influence them differ (see feedback loops and warmup below).

## Thresholds

- Provider-verified, Gmail only: spam rate below 0.10% target; never at or above 0.30%. Measured daily, based on inbox-delivered mail. Since June 2024, senders at ≥0.30% lose mitigation eligibility until 7 consecutive days below it. Negative impact starts above 0.10%, graduated.
- "Keep complaints under 0.1%" as a universal cross-provider law is a vendor extrapolation - Yahoo and Microsoft publish no equivalent number.
- Bounce-rate action points (2%, 3-5%) and "healthy inbox placement ≥90%" tiers are vendor conventions. Direction is sound; magnitudes are not authoritative.

## Instrumentation - enroll before reviewing anything else

Ranked on setup time and standing monitoring; every option here is reversible, so reversibility does not separate them.

- value (visibility bought): Google Postmaster Tools > DMARC aggregate reports > Microsoft SNDS/JMRP > Yahoo CFL
- effort: Microsoft SNDS/JMRP > Yahoo CFL > Google Postmaster Tools == DMARC aggregate reports
- efficiency (enroll first): Google Postmaster Tools == DMARC aggregate reports > Microsoft SNDS/JMRP > Yahoo CFL

Postmaster Tools and DMARC reporting tie on both axes for a real reason: each costs one DNS record, and neither substitutes for the other - one exposes a complaint rate no other source publishes, the other exposes which mail flows are misaligned. Enroll both in one sitting.

What this order starves is the per-complainer feedback loops (SNDS/JMRP, CFL), which cost an hour each and pay only in proportion to that provider's share of the list. Re-rank on the recipient provider mix: a Microsoft-heavy list promotes SNDS/JMRP to first, and Postmaster Tools says nothing about mail it never sees.

- Google Postmaster Tools: the only visible Gmail complaint signal (aggregate spam rate, domain/IP reputation, authentication dashboard, compliance status).
- Microsoft SNDS + JMRP: IP-level data plus per-complaint junk reports.
- Yahoo Complaint Feedback Loop (CFL): per-message complaint reports (ARF, keyed to the DKIM domain); requires DKIM.
- DMARC aggregate-report analysis: the cheapest way to find misaligned or unknown mail flows.
- Feedback-loop asymmetry (provider-verified): Yahoo and Microsoft let you suppress individual complainers after the fact; **Gmail has no per-message feedback loop** - only the aggregate rate. For Gmail, prevention (targeting, relevance, easy opt-out) is structurally the only option.
- Google states verbatim that it does not track open rates and cannot verify third-party open figures. Combined with Apple Mail Privacy Protection pre-fetching pixels (~55-60% of opens per Litmus 2026, vendor measurement; other vendor estimates differ widely), opens are unusable as a placement or engagement KPI. Use replies, non-Apple clicks, bounces, complaints.

## Seed-list / inbox-placement tests

- Mechanics: send to a panel of seed inboxes, read folder placement per provider.
- Validity problems (practitioner-verified, acknowledged by the panel vendors themselves): seed inboxes have no engagement history, and modern placement is personalized by per-recipient engagement - a seed "inbox" result does not prove real recipients will inbox. A large seed set relative to a small real list is itself a negative signal.
- Use them as directional input beside postmaster data and real engagement, never as proof. Vendor "global inbox placement ~83-84%" benchmarks measure the vendor's own panel.

## Warmup and volume - conventions, honestly labeled

- Provider-verified principle only, no numbers: start with low volume, increase slowly, avoid bursts, never immediately double previous volume (Gmail guidance).
- Everything numeric is vendor convention: 2-8 week ramps, "let a new domain sit 2-4 weeks", 30-50 emails/mailbox/day (vendor ranges span 10-65 - a ~3x disagreement with no shared methodology). Treat all of it as starting hypotheses to tune against the sender's own postmaster data. Scale by adding honestly-identified mailboxes/domains, not by pushing one mailbox harder.
- Automated warmup networks (tools that auto-send and auto-reply between member mailboxes) manufacture artificial engagement - the practice M3AAWG names as egregious. Providers increasingly detect it; no independent evidence shows it improves real-recipient placement; it papers over list and authentication problems. Do not recommend them; flag them when found in a setup.
- B2C divergence: bulk ESP senders warm **dedicated IPs** on published day-by-day ramps (dedicated IPs generally recommended above roughly 100k/month - vendor guidance); cold B2B is mailbox-based and warms domains/mailboxes. B2C bulk hygiene additionally includes double opt-in, sunset policies for chronically unengaged addresses, re-engagement before suppression, and rate-limited signup forms (list-bombing defense) - none of which exist in cold B2B.
- Vendor figures to never repeat as fact: "150+/day = 43% higher spam rates", "missing auth = 52% lower placement", "compliant senders average 89% inbox placement". No published methodology behind any of them.

## Remediation - burned domains and blocklists

Triage order (practitioner consensus):

1. Confirm the listing and identify **which asset** is listed: sending IP, sending domain, or a link/URI domain in the body.
2. Stop sending on the affected stream.
3. Fix the root cause (list quality, authentication, complaint driver). Delisting before fixing gets you re-listed, and repeat offenders wait longer.
4. File one documented removal request. Major-blocklist removal is free - anyone charging for delisting is selling a scam tax.
5. Choose the recovery route - rebuild volume slowly on the same domain, or park it and replace it. Ranked below.

Notes:

- Only a handful of blocklists meaningfully affect major-provider delivery (the large reputation lists: Spamhaus SBL/DBL-class, SURBL, SpamCop, Barracuda). "Listed on 200 blacklists" checker results are mostly irrelevant regional noise.
- A domain-level listing needs different remediation than an IP listing - changing IPs won't help a listed domain.
- **Gmail has no delisting process.** Its mitigation form is available only to bulk senders already meeting all guidelines. Recovery = fix spam rate and authentication, then wait (7 clean days restores mitigation eligibility).

### Retire vs rehabilitate

Effort is warming time, monitoring, and reversibility, never a price:

- value (a sending domain that inboxes again): park and replace == rehabilitate
- effort: rehabilitate (a week of clean sending at best, a quarter for a repeat offender, no Gmail delisting path) > park and replace (an hour to provision, a week or more to warm)
- efficiency: park and replace > rehabilitate

The value tie is genuine, not an evasion: neither route buys better placement than the other, only a different wait, which is why effort decides. Rehabilitation wins on exactly one condition - the burned asset is the domain carrying corporate and transactional mail, or one holding years of accumulated positive reputation. Neither can be replaced at all, so the effort axis stops applying and the wait is the only option.

The replacement must honestly identify the same sender: replacing a domain to escape identity, rather than to reset an accidental burn's cost, is the abuse side of the line and never a ranked option. No independent data on recovery rates exists; "85%+ delisting success" claims are vendor and unverified.
references/review-examples.md
# Review Report Template and Worked Examples

## Table of Contents

- [Template](#template)
- [Findings](#findings)
- [Fix list (in this order)](#fix-list-in-this-order)
- [Measurement plan](#measurement-plan)
- [Worked example - failing review](#worked-example-failing-review)
- [Findings](#findings)
- [Fix list (in this order)](#fix-list-in-this-order)
- [Measurement plan](#measurement-plan)
- [Worked example - passing review](#worked-example-passing-review)
- [Findings](#findings)

## Template

```
# Deliverability Review - <sender> → <audience>

Verdict: BLOCKED | AT RISK | CLEARED
Regime: B2B cold | B2C bulk · Volume: <n>/day (bulk sender: yes/no) · Regions: <list>

## Findings
### 1. Authentication and setup
- [SEVERITY] finding (provenance)
### 2. Reputation and measurement
- ...
### 3. Content structure
- ...
### 4. Compliance
- ...

## Fix list (in this order)
1. ...

## Measurement plan
- Dashboards to enroll · metrics to watch · action thresholds

Gate: <n> BLOCKER, <n> RISK, <n> ADVISORY → verdict. (Not legal advice.)
```

## Worked example - failing review

Submitted setup: SaaS SDR team, 6 mailboxes on the primary corporate domain, ~900 templated sends/day, recipients across the US and Germany. Draft: HTML email built from a marketing template - header banner image, two product screenshots, a shortened tracking link, subject `Re: quick question about your Q3 roadmap` (no prior thread), no opt-out line. DMARC lookup returns nothing.

```
# Deliverability Review - acme sales team → US + DE prospects

Verdict: BLOCKED
Regime: B2B cold, templated at volume · 900/day (bulk: no) · Regions: US, DE

## Findings
### 1. Authentication and setup
- [BLOCKER] No DMARC record on the sending domain (provider-verified requirement
  trajectory; also blocks postmaster compliance status). Publish p=none with rua=
  reporting today; SPF/DKIM alignment unverified until reports arrive.
- [BLOCKER] Cold outbound runs on the primary corporate domain - one complaint
  wave degrades transactional and corporate mail (practitioner consensus).
  Move to a dedicated, honestly-identified sending domain and warm it gradually.
### 2. Reputation and measurement
- [RISK] No postmaster dashboard enrollment: the team is flying blind on the only
  visible Gmail complaint signal. Enroll before resuming volume.
### 3. Content structure
- [BLOCKER] Fake "Re:" subject with no prior thread - deceptive framing (ethics
  boundary; illegal under CAN-SPAM's deceptive-subject rule; M3AAWG-abusive).
- [RISK] Image-heavy HTML with no plain-text part; shortened redirect link
  (structural gateway scoring rules, provider-verified rule categories).
- [ADVISORY] Marketing-template design reads as bulk for 1:1 outreach;
  plain-text-style is the practitioner norm for cold B2B (unquantified).
### 4. Compliance
- [BLOCKER] German recipients: UWG §7 requires prior express consent even B2B -
  this list cannot be cold-emailed lawfully. Remove DE rows or obtain consent.
- [BLOCKER] US recipients: no opt-out and no physical postal address - both
  CAN-SPAM requirements.

## Fix list (in this order)
1. Publish DMARC (p=none + rua), verify SPF/DKIM alignment from reports.
2. Provision a dedicated sending domain identifying the real sender; ramp slowly.
3. Enroll Google Postmaster Tools, Microsoft SNDS/JMRP, Yahoo CFL.
4. Remove German recipients (or collect consent). Add opt-out line + postal
   address for US mail.
5. Rebuild the draft: plain-text part, real subject, full-URL links on your own
   domain, drop the banner/screenshots.
6. Only then: content polish. Note - no word-list edit would have changed any
   finding above.

## Measurement plan
- Gmail spam rate daily (<0.10% target, never ≥0.30%, provider-verified);
  bounce trend; reply rate. Ignore open rate (Apple MPP proxy opens ~55-60%
  per Litmus 2026, vendor; Google states it does not track opens).

Gate: 6 BLOCKER, 2 RISK, 1 ADVISORY → BLOCKED. (Not legal advice.)
```

## Worked example - passing review

Submitted setup: same team, three weeks later. Dedicated sending domain with aligned SPF/DKIM and DMARC `p=quarantine`; PTR and TLS confirmed; Postmaster Tools shows spam rate 0.05%; 240 sends/day across 6 warmed mailboxes; US-only list; plain-text draft, one full-URL link on the sending domain, no pixel on first send, real subject, signature with name, role, postal address, and the line "If this isn't relevant, reply 'no thanks' and I won't write again."

```
# Deliverability Review - acme outbound v2 → US prospects

Verdict: CLEARED
Regime: B2B cold, templated at volume · 240/day (bulk: no) · Regions: US

## Findings
- [PASS] Auth: SPF+DKIM aligned, DMARC p=quarantine, PTR/TLS valid.
- [PASS] Reputation: spam rate 0.05% (below 0.10% target, provider-verified);
  dashboards enrolled; ramp within provider "increase slowly" guidance.
- [PASS] Content: plain-text part present, own-domain link, no deception.
- [PASS] Compliance (US): opt-out line, postal address, honest subject.
- [ADVISORY] Opt-out line in 1:1 cold mail is contested (complaint reduction
  vs bulk appearance - no independent test resolves it). Kept: the legal
  requirement outranks placement speculation. Acknowledged by user.
- [ADVISORY] 40/mailbox/day is a vendor convention, not a provider rule;
  adjust against your own postmaster data, not the folk number.

Gate: 0 BLOCKER, 0 RISK, 2 ADVISORY (acknowledged) → CLEARED.
Next review trigger: volume change, new region, or spam rate crossing 0.10%.
(Not legal advice.)
```
SKILL.md
---
name: cold-email-deliverability
description: Reviews a cold email draft and its sending setup for deliverability - SPF/DKIM/DMARC alignment, sender reputation and complaint risk, body mechanics (length, links, images, tracking pixels, HTML vs plain text, opt-out), and legal compliance by region. Covers B2B cold outbound and B2C bulk/lifecycle mail. Use whenever the user mentions the spam folder, blacklisting, domain warmup, inbox placement, bounce rates, DMARC, or "why are my emails not landing", even without the word deliverability. Do NOT use for subject lines (mbfinotti/sales-skills@cold-email-subject-line-tester) or cadence (mbfinotti/sales-skills@sales-outbound-sequence). Hygiene and compliance only, never spam-filter evasion.
license: MIT
metadata:
  author: Maya-Beth Finotti
  version: "1.3.2"
---

# Email Deliverability Review

Review a cold email draft and the setup that sends it - authentication, domain architecture, reputation signals, body structure, legal compliance; return a placement-risk report ordered by what actually decides inbox placement.

Label every claim's provenance:

- **provider-verified** - mailbox-provider or standards-body documentation.
- **vendor** - tool-vendor marketing, no independent methodology.
- **contested** - credible sources disagree.
- **practitioner** - expert consensus, uncontrolled.

Never present a vendor number as a law. Where evidence does not exist, say so.

## The placement hierarchy

Encode this order in every review. It is what most advice in this space gets backwards. Effort below is setup and monitoring time and reversibility, never a price.

- value (placement bought): authentication > reputation and complaint control > content structure > word choice
- effort (setup, monitoring, reversibility): reputation and complaint control > authentication == content structure > word choice
- efficiency (do first): authentication > content structure > reputation and complaint control > word choice

Authentication and content structure tie on effort because each is a single one-time hour and each is fully reversible. They differ only in who executes them - DNS access versus the draft's author; this is a re-ranking condition, not an effort difference.

1. **Authentication is a hard gate.** An hour of DNS work, and nothing downstream works without it. SPF/DKIM/DMARC alignment, valid PTR, TLS. Provider-verified: failures now mean rejection (Microsoft `550 5.7.515` since May 5, 2025) or Gmail 4.7.x/5.7.x codes. No copy edit compensates.
2. **Sender reputation and recipient engagement/complaint signals dominate placement.** The largest lever over placement once mail is accepted at all, and the only one of the four that is a standing job rather than a fix. Gmail filters at the mailstream level, not the message level; spam-button complaints are the single largest negative signal (provider-verified mechanics, practitioner-documented).
3. **Content structure is a distant tiebreaker**, cheap enough to stay ahead of reputation work on ratio alone: image-only mail, low text-to-image ratio, HTML with no plain-text part, link-domain reputation - not vocabulary.
4. **"Spam trigger word" lists are largely folklore.** The weakest lever, and last for that reason. No independent controlled study ties word choice, word count, or link count to spam placement (as opposed to reply rate). A clean-reputation domain inboxes "FREE!!! Act now"; a burned domain does not inbox a haiku. Check content anyway - but tell the user plainly, and never hand back a banned-word list as the primary fix.

What this order starves: reputation and complaint control, which ranks second on value yet loses to a cheap tiebreaker on every efficiency round, because it is a standing job with no finish line. Promote it to first whenever the sender intends to keep sending past this campaign, or whenever the Gmail spam rate is already above 0.10% - past that point no authentication or content fix reaches a stream already flagged.

A review that returns a word-list score while the sending domain has no DMARC record is malpractice. The workflow runs preconditions first and content last for this reason - that is the review order, and it differs from the efficiency order on purpose. Reputation is assessed early because a burned stream cancels the copy review entirely; it is repaired late because the repair is a standing job that outlives the campaign.

## Ethics boundary

M3AAWG's November 2025 Position on Cold Email states that "using deceptive and misleading delivery methods to send unsolicited email (including Cold Email) is an abusive practice." It also states that "any attempts to bypass mail volume limits, avoid spam filters, mask sending domains, artificially simulate subscriber engagement, or use other tools or services that exploit loopholes in mailbox providers or cloud platforms are particularly egregious and are not acceptable in any manner."

This skill is deliverability hygiene and compliance - never filter evasion. Refuse, explicitly, to help with:

- Masking or falsifying sender identity.
- Lookalike or deceptive domains.
- Fake `Re:`/`Fwd:` threading.
- Artificial engagement or reply-bot warmup networks.
- Evading provider volume limits.
- Hiding, breaking, or discouraging an opt-out.

Draw the real tension for the user instead of hiding it: practitioners recommend spreading volume across several owned, warmed, honestly-identified sending domains, while M3AAWG condemns "masking sending domains" to evade limits. The line is identity, never count:

- **Hygiene** - transparently owned, correctly authenticated domains that identify the real sender.
- **Abuse** - domains chosen to disguise who is sending, defeat a volume limit, or restart a burned reputation under a new name.

Decline the abusive part of a request and continue with the rest. Abuse is not a low-ranked option on the menu below - it is off the menu, and no volume target, deadline, or effort ceiling ranks it back on.

### Domain architecture - ranking the legitimate options

Legitimacy is the gate; this ranking runs only over what passes it. Effort here is provisioning and warming time, ongoing monitoring, and reversibility - a burned domain is the least reversible outcome in this skill, so reversibility carries most of the weight.

- value (blast radius contained plus placement earned): domain fleet > one dedicated sending domain > corporate subdomain
- effort (provisioning, warming, monitoring, reversibility): domain fleet > corporate subdomain > one dedicated sending domain
- compliance cost (sender identification and suppression surface per region): domain fleet > one dedicated sending domain == corporate subdomain
- efficiency (start here): one dedicated sending domain > corporate subdomain > domain fleet

The dedicated domain and the subdomain tie on compliance cost because both are one sender identity behind one suppression list, and a recipient's region attaches its rules to that identity, not to the DNS label. The subdomain still costs more effort than the dedicated domain despite the cheaper setup; a burn there reaches the organizational domain and cannot be parked.

1. **One dedicated sending domain**, brand-adjacent and honestly identifying the same sender; this is the default rung. An hour to provision, a week or more to warm, and the only architecture whose recovery move (park it, replace it) is near-zero.
2. **A subdomain of the corporate domain** - brand recognition and DNS you already control, but containment is partial; reputation bleeds toward the organizational domain, and Gmail counts bulk volume across the primary domain including subdomains, so it never resets the 5,000/day clock.
3. **A fleet of dedicated domains and mailboxes** - what this order starves - is highest value of the three, and it loses every efficiency round because each domain owes its own authentication, warming, postmaster enrollment, and monitoring, permanently. Promote it when the volume target exceeds what one warmed domain's mailboxes carry against the sender's own postmaster data, or when a genuine second brand exists. Its compliance cost is real: one suppression list must span every domain, since an opt-out binds the sender and not the domain - a fleet suppressing per-domain has a broken opt-out and files a BLOCKER.

Deleted from this menu rather than demoted: cold outbound at volume on the primary corporate domain. It is the one asset that cannot be parked and replaced, and it carries the transactional and corporate mail a single complaint wave would take down with it.

Both rankings on this page are defaults, not laws - they shift with context and with who executes them. Re-rank against what you already know about this sender:

- An established domain with years of real reputation makes the subdomain competitive and makes park-and-replace the wrong recovery.
- A brand-new company has no reputation to protect and no brand to inherit, which flattens the gap between the top two rungs.
- A team whose IT controls DNS and will not delegate a new domain has the subdomain as its only fast option; a team that provisions its own domains reaches the top rung at near-zero friction.

## Interview

- Ask one question per message.
- Offer multiple-choice options.
- Skip anything context already answers.
- If your harness has persistent memory and a prior run stored this sender's setup, confirm it instead of re-asking.

1. Regime: B2B cold outbound (unsolicited) or B2C bulk/lifecycle (opt-in)? Ask first - consent basis, unsubscribe rules, warmup unit, and feedback loops all diverge.
2. Date this has to land by: sending this week, this month, or no fixed date?
3. One-off win or compounding asset: one campaign to one list, or an outbound channel meant to keep running?
4. Effort ceiling: who executes, how many hours do they have, do they control DNS, and how much of this has to stay reversible?
5. Daily volume and volume approaching 5,000/day to any one provider? (Provider-verified bulk-sender threshold at Gmail and Microsoft; permanent once reached at Gmail.)
6. Sending domain: primary corporate domain, dedicated sending domain/subdomain, or several? Does each honestly identify the real sender?
7. Do SPF, DKIM, and DMARC records exist, and is alignment known? "Don't know" is a valid answer - step 3 of the workflow verifies.
8. Recipient provider mix: mostly Gmail, Microsoft, Yahoo, corporate gateways, or mixed?
9. Recipient regions: US, EU (which member states), UK, Canada, Australia, mixed? The legal answer changes completely by region.
10. Postmaster dashboards enrolled - Google Postmaster Tools, Microsoft SNDS/JMRP, Yahoo CFL? Current Gmail spam rate, if known?
11. Is the draft genuine 1:1 mail or templated at volume? Changes bulk-requirement applicability and the opt-out recommendation.
12. Symptoms so far: bounce codes (`550 5.7.515`, 4.7.x/5.7.x, `550 5.4.5`), spam-folder reports, sudden reply drop?

Re-rank both orderings against answers 2-4, and tell the user which answer moved which option:

- A deadline inside a week promotes authentication (an hour, unblocks everything) and demotes every architecture needing a warming period - a domain provisioned today does not carry volume this week. Say that rather than shipping a plan that misses the date.
- A compounding mandate promotes reputation and complaint control from third to first, and promotes the domain fleet once the volume target proves one domain cannot carry it.
- A one-off win keeps the efficiency order as written and rules the fleet out entirely.
- No DNS control caps the sender at a corporate subdomain and puts the authentication fixes in someone else's queue - sequence around that hand-off instead of assuming an hour.
- A low tolerance for irreversible outcomes promotes the dedicated sending domain over the subdomain whatever the other answers say.

## Workflow

1. Run the Interview.
2. Screen the request against the Ethics boundary. Decline evasion asks explicitly before doing anything else.
3. Audit preconditions with [references/authentication-and-setup.md](references/authentication-and-setup.md): SPF/DKIM/DMARC presence and alignment, PTR, TLS, unsubscribe headers where required, and domain architecture against the ranking above. If you can run DNS lookups or browse the web, verify records yourself; otherwise ask the user to paste lookup output. Any failure is a BLOCKER: report it, state that no copy edit compensates, and hold the content review until fixed.
4. Assess reputation and measurement with [references/reputation-and-measurement.md](references/reputation-and-measurement.md): spam rate against thresholds, bounces, blocklists, dashboard enrollment, volume and warmup sanity. A burned domain routes to the remediation path, not a copy review.
5. Review body structure with [references/content-review.md](references/content-review.md) - structure and link-domain quality first, vocabulary last, honestly framed as the weakest lever.
6. Flag the subject line only for deception or placement-damaging structure (fake `Re:`/`Fwd:`, ALL CAPS, excess punctuation). Never score it for open rate or draft variants - route that to `mbfinotti/sales-skills@cold-email-subject-line-tester`.
7. Check legal compliance for every recipient region with [references/compliance-by-region.md](references/compliance-by-region.md).
8. Assemble the report (shape and worked pass/fail examples in [references/review-examples.md](references/review-examples.md)), run the Quality gate, and iterate with the user until it passes.
9. Run any rewritten copy proposed for a flagged section through your preferred humanizer skill before delivering - raw first-draft model output is never shipped.
10. If your harness has persistent memory, store the setup answers (domains, auth status, volume, regions, dashboards) so later reviews skip straight to the draft.

## B2B cold vs B2C bulk

**Identical for both:**

- The authentication stack and alignment rules.
- Reputation mechanics and complaint math.
- The structural content checks.

**Diverges** - split it every time:

- Consent basis: B2C is opt-in by definition; cold B2B is unsolicited and legality varies by region (compliance reference).
- One-click `List-Unsubscribe` (RFC 8058): a bulk/marketing requirement; genuine 1:1 cold mail below bulk thresholds is not covered - the plain-text opt-out line question is contested (content reference).
- Warmup unit: B2C ESP senders warm dedicated IPs on published ramps; cold B2B warms mailboxes and domains (reputation reference).
- Feedback loops: B2C ESPs suppress individual complainers via Yahoo CFL / Microsoft JMRP; Gmail offers no per-message loop to anyone.
- List hygiene: sunset policies, re-engagement, and double opt-in are B2C bulk practice; B2B equivalents are bounce pruning and verification before send.

## Invocation examples and expected output

Typical requests: "why are my cold emails going to spam", "review this cold email for deliverability", "check my email for spam trigger words" (answer honestly - see hierarchy point 4), "am I going to get my domain blacklisted", "we start sending 2,000/day next month - is our setup ready".

Expected output - the review report, in order:

1. Verdict: CLEARED, AT RISK, or BLOCKED.
2. Findings grouped by layer (authentication → reputation → content → compliance), each with severity (BLOCKER / RISK / ADVISORY) and provenance label.
3. Fix list in the efficiency order of the placement hierarchy, not in the finding-group order above - DNS and setup fixes before content edits, always.
4. Measurement plan: which dashboards to enroll, which metrics to watch, thresholds that trigger action.

Full template plus one failing and one passing worked example: [references/review-examples.md](references/review-examples.md).

## Quality gate

Every finding carries a severity. The gate is measurable: count of unresolved BLOCKERs and RISKs.

- Hard gates - any one unresolved keeps the verdict BLOCKED:
  - Authentication present and aligned for the sender's tier: SPF or DKIM minimum for any sender; SPF + DKIM + aligned DMARC for bulk.
  - No deceptive framing anywhere (sender identity, subject, domains).
  - The recipient region's consent/opt-out/disclosure requirement met.
  - Gmail spam rate below 0.30% where known.
- Scored content review: run all ten structural checks in the content reference; each failed check files a RISK or ADVISORY per that file's severity map.
- Pass threshold: zero BLOCKERs and zero unresolved RISKs. ADVISORY findings may ship if the user acknowledges them in the report.
- Iterate: re-run the failed layer after each fix until the gate passes. Never soften a BLOCKER to RISK to get a pass.

## KPIs and measurement

- Gmail spam rate: below 0.10% target, never at or above 0.30% (provider-verified; measured daily in the postmaster dashboard). Approaching 0.10% → audit list and targeting; at 0.30% → stop the stream (mitigation eligibility returns only after 7 consecutive clean days).
- Bounce rate: action thresholds around 2-5% circulate but are vendor conventions; trend and hard-bounce pruning matter more than the exact number.
- Reply rate (B2B) / click and conversion (B2C): the engagement signals worth trusting.
- Discount open rate explicitly: Apple Mail Privacy Protection pre-fetches tracking pixels (~55-60% of opens affected per Litmus 2026 - vendor measurement), and Google states it does not track open rates (provider-verified). Opens are directional at best; never a placement KPI.

## Failure modes

- Editing copy while authentication is broken. Fix: hierarchy order - DNS first, always; hold the content review behind the BLOCKER.
- Treating a seed-list "inbox" result as proof. Seed inboxes have no engagement history and placement is personalized per recipient - directional, not definitive.
- Confusing Google Workspace's 2,000 messages/day account cap (outbound hard limit, rolling 24h) with the 5,000/day Gmail bulk-sender reputation threshold (inbound classification); different mechanisms, different consequences.
- Assuming one universal compliance deadline. Gmail and Yahoo enforced bulk authentication from February 1, 2024; Microsoft's equivalent took effect May 5, 2025 - 15 months later.
- Assuming Gmail lets you suppress individual complainers. It has no per-message feedback loop; prevention is structurally the only option, unlike Yahoo (CFL) and Microsoft (JMRP).
- Relying on automated warmup networks. They manufacture artificial engagement; this is the exact practice M3AAWG names as egregious - and no independent evidence shows they improve real-recipient placement.
- Chasing a burned domain instead of retiring it. Practitioner norm: a domain on a domain-blocklist or with collapsed reputation is often cheaper to park and replace (with an honestly-identified domain) than to rehabilitate; "85% delisting success" figures are vendor and unverified. The exception that flips it is the domain carrying corporate and transactional mail - that one cannot be parked, so it has to be rehabilitated (reputation reference).
- Handing back a word-list score as the primary fix. Folklore - see hierarchy point 4; report content findings last and labeled.
- Applying B2B cold rules to B2C bulk or vice versa. Warmup unit, unsubscribe requirements, and consent basis all differ - see the split above.

## References

- `mbfinotti/sales-skills@sales-outbound-sequence` - touch-by-touch cadence and timing; out of scope here.
- [references/authentication-and-setup.md](references/authentication-and-setup.md) - provider requirements and dates, alignment, error codes, unsubscribe headers, DNS gotchas, domain architecture, hard account caps.
- [references/reputation-and-measurement.md](references/reputation-and-measurement.md) - mailstream filtering, complaint math, thresholds, dashboards, seed-test validity, warmup conventions, remediation and blocklists.
- [references/content-review.md](references/content-review.md) - the ten structural checks with severity map, tracking and link guidance, opt-out debate, folklore explainer.
- [references/compliance-by-region.md](references/compliance-by-region.md) - US, EU and member states, UK, Canada, Australia; B2B vs B2C consent bases and penalties.
- [references/review-examples.md](references/review-examples.md) - report template, one failing worked example, one passing worked example.