# The Opt-Out Propagation Runbook: From One Reply to Proven Suppression

*Take any opt-out signal, classify it in under a minute, suppress it in every system within the strictest clock, and prove it held with a dated seed test.*

- Canonical URL: https://www.refolk.ai/guides/opt-out-propagation-runbook
- Pillar: Process, data, and compliance
- Format: Playbook
- Published: 2026-10-31
- Last reviewed: 2026-10-31
- Reading time: 21 min
- Keywords: how to sync opt-outs across sales tools, unsubscribed contact re-imported and emailed again, cold email reply opt-out how to handle, suppression list after GDPR erasure hash, global do not contact list recruiting and sales

## Key takeaways

- The 48-hour clock that Gmail and Yahoo set for bulk senders is stricter than every statute in the table (Australia allows 5 working days, CAN-SPAM and CASL 10 business days, CCPA 15 business days), so 48 hours is the right internal deadline for every opt-out.
- A plain reply saying "stop emailing me" is a valid opt-out: the ICO says an objection can be made "in any way" with "no specific words", and the FTC says you cannot require any step beyond a reply email or a single page visit.
- Deleting an opted-out person's record without keeping a minimal suppression entry is the most common way an unsubscribed contact gets re-imported and emailed again, because the next enrichment or CSV upload has nothing to match against.
- The ICO treats a suppression list as not being direct marketing, and says there is no automatic right to be removed from it, so a minimal tombstone can outlive an erasure request.
- In Refolk's index there are 3.2 US Revenue Operations professionals for every US Recruiting Operations professional, and the two functions usually run separate stacks, so an opt-out recorded in sales rarely reaches recruiting unless someone builds the bridge.
- No regulator or mailbox provider publishes a seed-test procedure, so proof that a suppression held has to come from your own dated log: when the request arrived and when each system was confirmed to block it.

This runbook is for the recruiting ops or RevOps owner who has just received a "remove me" from someone the team sourced or prospected, whether it came as a link click, a one-click header, or a plain reply. It takes that one signal all the way to verified suppression across sequencers, mailboxes, CRM, ATS, vendor tools, and every future list upload. You get a reply-classification table, a clock table by regime, a scope rule, a hashed-tombstone pattern, a pre-import guard, and a seed-test log format.

## What counts as an opt-out signal?

An opt-out is any message in which the person asks you to stop, in whatever words they choose and through whatever channel they choose. The ICO says the objection "can be exercised at any time and in any way" and that "there are no specific words that you must use". The FTC says you cannot require "any step other than sending a reply email or visiting a single page".

Most pages that rank for this topic were written by email platforms about marketing lists, and they assume the opt-out arrives as a click. In cold sourcing and prospecting it often doesn't. The signals you need to catch:

- **Unsubscribe link click.** Usually recorded automatically, but only in the tool that sent the message.
- **One-click header.** This is the RFC 8058 mechanism, where the mail client sends the unsubscribe on the recipient's behalf. Gmail requires it of senders sending more than 5,000 messages a day to Gmail accounts, and a mailto link or a normal body link does not meet that requirement on its own.
- **Plain reply.** Anything from "unsubscribe" to "please stop emailing me". ACMA's guidance gives "reply to this email with 'unsubscribe' in the subject line" as a clearly worded mechanism, which tells you regulators expect replies to work.
- **Verbal or off-channel.** The person tells a recruiter on a call, or messages a different rep. The ICO advises you to "keep a log of verbal objections."

### The four labels

Every signal gets exactly one label at intake. The label decides what happens next.

| Label | Typical wording | What it proves | Action |
|---|---|---|---|
| Opt-out | "Remove me", "stop emailing" | Wants no more messages | Global suppress, start clock |
| Objection + erasure | "Delete my data" | Stop, plus a deletion request | Global suppress, open erasure |
| Not interested | "Not right now, thanks" | Declines this offer only | Close sequence, note, no global flag |
| Wrong person | "Wrong John", "I left" | Address isn't your target | Suppress the address, fix the record |

The label that misleads most often is "not interested". A reply like "not interested, please don't contact me again" is an opt-out wearing a polite sentence. My tie-break rule: if a reasonable reader could take the reply as "stop", label it an opt-out. Over-suppressing costs you one prospect. Under-suppressing costs you a complaint, and with it your standing with the mailbox providers.

#### Classifying a reply in under a minute

Horizontal axis runs from Stop language ambiguous to Stop language clear. Vertical axis runs from No data request to Asks for deletion.

| Quadrant | What it means |
| --- | --- |
| Ambiguous stop, asks deletion | Treat as objection plus erasure; deletion implies stop |
| Clear stop, asks deletion | Objection plus erasure; suppress globally and open the one-month erasure clock |
| Ambiguous, no data request | Not interested or wrong person; close the sequence, re-read for any stop wording |
| Clear stop, no data request | Opt-out; suppress globally and start the honor clock |

*Clear stop language or any deletion request moves a reply onto the global suppression list, and only a reply with neither stays out.*

## Which clock applies to an opt-out?

Use the strictest clock that applies to you as the sender and to the recipient. If you send more than 5,000 messages a day to Gmail accounts, that is the 48-hour mailbox-provider clock, which is stricter than every statute below.

| Regime | Max window to honor | Mechanism must stay live |
|---|---|---|
| Gmail bulk | 48h (recommended) | n/a |
| Yahoo bulk | 2 days | n/a |
| Australia Spam Act | 5 working days | 30 days |
| CAN-SPAM | 10 business days | 30 days |
| CASL | 10 business days | 60 days |
| CCPA sale/share | 15 business days | n/a |

Three regimes are missing from that table on purpose:

- **GDPR Article 21 and UK GDPR.** The ICO says individuals have "an absolute right to stop their data being used for direct marketing". None of the sources I reviewed gave a fixed day count. One secondary source describes the clock as "without undue delay (no fixed number)".
- **PECR.** None of the public sources I retrieved give a separate day count.
- **Erasure, when asked for.** This runs on its own clock and must be handled within one month, in parallel with the suppression.

Two other numbers matter later. Under CCPA you must wait at least 12 months before asking the person to re-authorize. The "mechanism must stay live" column matters too: a CASL unsubscribe link has to keep working for 60 days after the send, and that sets your token-expiry policy.

The mailbox clock binds hardest because of what happens if you miss it. Gmail lists requests left unhonored after 48 hours as a sender compliance issue, and only compliant senders "are eligible for mitigation" when deliverability problems hit. For a bulk sender, that makes deliverability the real deadline, ahead of the law.

> **Rule:** One internal deadline: 48 hours
>
> Every opt-out, from every regime and every channel, is propagated within 48 hours of receipt. Record the legal ceiling on the ticket as a backstop, but run the operation to the strictest clock so nobody has to work out which regime applies under pressure.

These values change, so don't treat this table as permanent. At each quarterly review, re-read the FTC CAN-SPAM compliance guide, the ACMA unsubscribe fact sheet, the CPPA FAQ, and Google's sender FAQ, and update the table if any window has moved.

## Which teams and tools does one opt-out bind?

My operating rule: one opt-out binds the whole company. That means every sending domain, every mailbox, every brand, recruiting and sales alike, and every vendor or contractor tool that touches your contacts. The law sets a floor here that is less clear than this rule, so set the rule yourself and write it down.

What the sources do establish:

- CAN-SPAM allows a preference menu, but "you must include the option to stop all commercial messages from you."
- You cannot outsource liability: "even if you hire another company to handle your email marketing, you can't contract away your legal responsibility."
- Once someone opts out, you "can't sell or transfer their addresses, even as a mailing list", with one exception: a company you've hired to help you comply.
- CCPA adds downstream propagation. The business must notify the third parties it sold or shared the information to, telling them to comply and to pass the request on.
- ACMA-oriented checklists ask whether unsubscribes are removed "including from any tool a contractor uses".

What the sources leave open: whether one opt-out legally binds every sending domain, brand, or team of a single company is not spelled out in the FTC guide or in the CASL sources I retrieved. Don't read that silence as permission. The person on the other end sees one company, and a recruiter emailing them a week after they told a sales rep to stop looks like you ignored them.

#### Every layer that can send to or recreate a contact

1. **Future lists and enrichment** - CSV uploads, enrichment runs, and new list pulls that can recreate a deleted contact
2. **Systems of record** - CRM and ATS, where the global do-not-contact flag lives
3. **Sequencers and engagement tools** - Scheduled steps across every sales and recruiting sequence
4. **Mailboxes and sending domains** - Manual sends from reps and recruiters on every domain
5. **Vendors and contractors** - Agency and contractor tools you do not administer but remain liable for

*An opt-out recorded only in the sequencer protects one layer, and the outer layers are where suppressed people come back.*

The recruiting and sales gap is structural. In most companies the two functions run separate stacks, with different CRMs, different sequencers, and different owners, so a suppression set in one never reaches the other.

**3.2x - US Revenue Operations professionals per US Recruiting Operations professional, in Refolk's index**

Sales-side ops capacity heavily outnumbers recruiting-side capacity, so recruiting stacks are often the ones without a propagation owner.

## Who owns opt-out propagation?

Opt-out propagation needs one named owner for the global do-not-contact list and one named owner inside each stack that can send. In most companies that means a RevOps manager for the sales stack and a recruiting operations manager for the talent stack, with a privacy owner handling erasure.

Refolk's index of professional profiles shows how thin that ownership can be:

| Segment | Headcount | Top title share (sample of 25) |
|---|---|---|
| RevOps, US | 1,401 | RevOps Manager 64% |
| RevOps, UK | 239 | RevOps Manager 76% |
| Recruiting Ops, US | 439 | Recruiting Ops Manager 56% |

Headcounts come from Refolk's index, and the title shares come from a sample of 25 profiles per segment. Two derived ratios: US RevOps outnumbers UK RevOps 5.9 to 1, and US RevOps outnumbers US Recruiting Ops 3.2 to 1. In the UK sample, 15 of 25 RevOps profiles are London-based (60%). In the US, no metro has more than 3 of 25 (12%). My reading, and it is inference from a sample rather than a measured fact, is that fewer people in the UK own PECR and GDPR propagation and they sit in a narrow cluster. If your UK owner leaves, the knowledge may leave with them.

### How much triage volume to plan for

No published dataset isolates opt-outs that arrive as plain replies, so the number you actually need is not established publicly. The nearest benchmarks conflict:

| Source | Unsubscribe rate | Reply rate |
|---|---|---|
| thedigitalbloom | 0.17% avg | 3 to 5.1% |
| cleanlist (aggregated) | 2.1% avg | 3.1% |
| Outreach (target) | <1.1% | 12% response |

The methods differ, so these rows are not strictly comparable. The Outreach target is also about five years old. One figure points somewhere useful: aggregated data puts cold recruiting reply rates at 7.2% for non-tech roles and 5.8% for tech roles. Recruiting sends draw more replies than average, so recruiting coordinators triage more replies per send. To get your own figure, count a month of replies by label from your mailboxes. That count is the only volume estimate worth staffing against.

If the recruiting side of the house has nobody who can own the ATS and sequencer side of this, that is the gap to close first, and [Refolk](/) can show you who does this job elsewhere.

I ran this search: `Recruiting operations managers in the US who administer Greenhouse or Lever and run candidate email sequencing` - [see the full result list](https://www.refolk.ai/s/ws1vzkjbk5).

*Returns named recruiting ops owners with their current employer and stack signals, so you can benchmark the role or hire into it.*

## The opt-out propagation procedure

The procedure has seven steps, from intake to logged proof, and it runs to a 48-hour target. I put this order together from the clocks and guidance above. No single source documents it.

#### One opt-out, intake to verified suppression

1. **Intake and classify the signal** - Whoever sees the reply, click, or verbal request labels it as opt-out, objection plus erasure, not interested, or wrong person, in under a minute, and logs the original wording.
2. **Stop in-flight sends** - The rep or sequencer admin cancels every active sequence step and scheduled send for the address the same day.
3. **Set the clock** - Ops records the strictest deadline that applies (48h bulk, 5 working days AU, 10 business days US and CA, 15 business days CCPA), with 48 hours as the internal target.
4. **Propagate to every system that can send** - RevOps sets the global do-not-contact flag in the CRM, ATS, every sequencer, every mailbox and domain, and every vendor or contractor tool, then queries each one for the address.
5. **Erase if asked and keep a tombstone** - The privacy owner erases the data within one month, keeps a minimal hashed suppression record, and writes an audit note of what was deleted, where, and when.
6. **Install the pre-import guard** - RevOps puts a one-off check in front of every CSV upload, enrichment run, and list pull that drops rows matching the tombstone list.
7. **Seed-test and log** - Ops opts out a controlled seed address through each channel, checks every system, attempts a re-import, and records the timestamps.

Timing and ownership, step by step:

1. **Intake (under 1 minute, SDR, recruiter, or reply-triage owner).** The original wording goes in the log verbatim. If someone challenges the label later, the wording is your evidence.
2. **Stop sends (same day, rep or sequencer admin).** Don't assume this happens automatically. A competitor claims that in Outreach and Salesloft a reply opt-out "depends on a rep reading that reply and manually updating the record." I could not verify that claim, so test your own sequencer before you rely on it either way.
3. **Clock (minutes, ops).** Write the deadline as a timestamp, not as a regime name.
4. **Propagate (under 48 hours, RevOps).** This is the step that fails most often, because each system needs its own action. "Done" means you queried each system and saw the flag, not that you sent a request.
5. **Erase (within one month, privacy owner).** Only for objection-plus-erasure signals. The tombstone is created before the deletion, never after.
6. **Guard (one-off, RevOps).** Built once, then it protects every later signal.
7. **Seed test (dated, ops).** Run it on a schedule and after every stack change, not once per opt-out.

## The hashed tombstone and pre-import guard

A tombstone is the minimum record that lets you recognize a suppressed person after you have deleted everything else about them. The pre-import guard is the check that compares every new list against those tombstones before anything is created. Together they stop the most common cold-outreach failure: an unsubscribed contact gets re-imported and emailed again.

### Why the tombstone is allowed

The ICO's position, taken in order:

- "While you must not keep using someone's information for direct marketing when they object, keeping a suppression list isn't for direct marketing purposes."
- Keep "just enough information about them to ensure that their preference not to receive direct marketing is respected," and "only keep the minimum amount of information needed."
- "There is no automatic right for people to have their information on such a list deleted."
- The legal basis: the ICO's draft code says "it is likely that Article 17(3)(b) applies" because processing the suppression list is needed to meet a legal obligation.

### Why hash it

Hashing is my pattern, not a regulator's instruction. No ICO or EDPB text I found names one-way hashing for suppression lists, and I found no EDPB guidance on it at all. I hash because it minimizes what the list holds: the guard can still match an incoming address, but nobody browsing the table sees a list of people who asked you to go away. Treat the hash as personal data unless your privacy counsel tells you otherwise.

Implementation rules that decide whether matching works:

- Normalize before hashing: trim whitespace and lowercase the address. If you skip this, "Jane@" and "jane@" become two different people.
- Use the same hash function and the same key in every system, or the guard will never get a match.
- Hash every address you know for the person (work, personal, old employer), one row each.
- Store no name, no employer, and no message content.

**Tombstone record and pre-import match**

```
-- tombstone table: one row per suppressed address
address_hash      -- HASH(LOWER(TRIM(email)))
signal_label      -- opt-out | objection+erasure | wrong-person
channel           -- link | one-click | reply | verbal
received_at       -- timestamp of the signal
deadline_at       -- strictest applicable clock
blocked_at        -- timestamp confirmed blocked everywhere
scope             -- company-wide (always)
source_system     -- where the signal arrived

-- pre-import guard: run before any CSV, enrichment, or list pull
SELECT incoming.*
FROM incoming
LEFT JOIN tombstone t
  ON HASH(LOWER(TRIM(incoming.email))) = t.address_hash
WHERE t.address_hash IS NULL;   -- only unmatched rows proceed to import
```

*Swap HASH() for your stack's one-way hash function with a fixed key; keep the field list this short.*

### Where the guard sits

The ICO describes the mechanism directly: "check any new marketing lists against it." A new list means any list: a purchased file, an event upload, an enrichment refresh, a recruiter's spreadsheet, or a pull from [Refolk](/) or any other sourcing tool. All of them pass the guard before they reach a sequencer.

#### The pre-import guard

1. **Normalize** - Trim and lowercase every email in the incoming file
2. **Hash** - Apply the same one-way hash and key used for tombstones
3. **Match** - Join against the tombstone table
4. **Drop** - Remove matched rows; they never reach the CRM, ATS, or sequencer
5. **Log** - Record file name, row count, and rows dropped

*Every incoming row is normalized and hashed the same way as the tombstones, so a suppressed person is dropped before any system can recreate them.*

What tools do natively varies, and most of it isn't documented. HubSpot's behavior is public. Contacts added through an opt-out import "will not be added to your billable contact total or created as contacts," and the import sets "Unsubscribed from all email" to true. A HubSpot community expert says suppression "still holds true when you re-import contacts." Import defaults for Salesforce, the major ATSs, and sequencers are not established in the sources I reviewed. Don't assume them. Prove them with the seed re-import in the verification section.

> **Watch out:** Deleting is not suppressing
>
> "If you delete their record, you risk re-adding them to your marketing database later from another source." Create the tombstone first, then erase; a clean delete with no tombstone is how erased people get emailed again.

## How opt-out propagation goes wrong

Most failures are not refusals to honor an opt-out. They are opt-outs honored in one place and nowhere else. Each failure below comes with what it looks like and the check that catches it.

1. **Misclassification.** "Not interested" gets treated as an opt-out, or the reverse. The dangerous direction is the false negative, where "please stop emailing me" stays in the sequence because nobody clicked anything. *Check:* run sampled replies through the ICO's "any words" test. If the person said stop in any phrasing, the label must be opt-out.
2. **Link-only automation.** The sequencer records clicks and nothing else, so the reply opt-out sits in a rep's inbox. *What it looks like:* clean unsubscribe metrics alongside complaints from people who "replied twice". *Check:* send a seed reply with no click and see whether anything changes.
3. **Single-tool suppression.** The opt-out is recorded only where it arrived, for example "that opt-out is recorded in Salesloft" but not in the ATS. This is the recruiting-and-sales collision in its most common form. *Check:* query every system in the stack figure for the address.
4. **Form re-entry.** When an unsubscribed contact fills out a form, HubSpot prompts them to resubscribe. A resubscribe they choose themselves is legitimate. A rep or workflow quietly reversing the flag is not. *Check:* audit resubscribe events monthly and confirm each one was self-initiated.
5. **Weak manual opt-outs.** In HubSpot, a workflow action "cannot resubscribe contacts that have self opted-out," but a manual opt-out can be reversed. A reply-based opt-out entered by a rep is therefore weaker than a link click unless it is recorded as self-initiated. *Check:* confirm how your CRM stores rep-entered opt-outs, and whether automation can undo them.
6. **Delete instead of suppress.** The record is erased, no tombstone is kept, and the next enrichment run recreates the person. *Check:* re-import a test CSV containing an erased seed address.
7. **Token expiry.** "Token expiry must not make the unsubscribe mechanism fail during the required availability period." Under CASL that period is 60 days. *Check:* click a 59-day-old link from a seed send.
8. **Opt-out list transferred to a vendor.** Sharing suppressed addresses with any vendor other than one you hired to help you comply breaches CAN-SPAM's transfer rule. *Check:* list every destination the suppression file is sent to, and the purpose of each.

Regulators have punished broken mechanisms directly. The CRTC fined Compu-Finder $1.1 million on 5 March 2015 over its unsubscribe mechanism. ACMA found that Telstra's unsubscribe "required the recipient to log in to their account, or provide additional personal information." In both cases the problem was friction or failure in the mechanism itself, which is the same family of failure as everything on this list.

> An opt-out is not a checkbox in one tool. It is a promise every system you own has to keep.

> **Tip:** Treat the unverified claims as test cases
>
> Wherever this runbook says a tool's default is not established, turn that into a seed test rather than a debate. One controlled address answers the question for your configuration faster than any vendor documentation.

## How to prove the suppression held

You prove suppression with a seed test. Opt out an address you control through every channel, confirm each system blocks it, try to re-import it, and log every timestamp. No regulator or mailbox provider publishes a seed-test procedure. The nearest published guidance is to "test your unsubscribe route as a recipient would," so this protocol is mine.

### The seed-test protocol

- **Seed addresses.** Keep at least one per channel: link, one-click header, plain reply, and verbal (logged by a rep). Use addresses on a domain you control, so they never collide with a real person.
- **Cross-team pass.** Opt the seed out via a sales sequence, then confirm the recruiting stack blocks it too. Then reverse the direction.
- **Re-import pass.** Put the seed address into a test CSV and an enrichment run, and confirm the guard drops it.
- **Expiry pass.** Click an aged unsubscribe link at 59 days.
- **Target.** Every system confirmed blocked within 48 hours of the request, the window after which Gmail treats an unhonored request as a compliance issue.

**Seed-test log (one row per system per run)**

```
run_id | seed_address | channel | request_at | system | checked_at | result | checker
2 | seed-reply@yourtestdomain | plain reply | (timestamp) | CRM | (timestamp) | blocked | (initials)
2 | seed-reply@yourtestdomain | plain reply | (timestamp) | ATS | (timestamp) | blocked | (initials)
2 | seed-reply@yourtestdomain | plain reply | (timestamp) | Sequencer (sales) | (timestamp) | blocked | (initials)
2 | seed-reply@yourtestdomain | plain reply | (timestamp) | Sequencer (recruiting) | (timestamp) | blocked | (initials)
2 | seed-reply@yourtestdomain | plain reply | (timestamp) | Contractor tool | (timestamp) | blocked | (initials)
2 | seed-reply@yourtestdomain | re-import CSV | (timestamp) | Pre-import guard | (timestamp) | dropped | (initials)
```

*Keep every run; the history is the proof, not the latest row.*

A failed row is the useful result. It tells you exactly which layer leaks. Fix it, re-run that channel, and log both rows.

#### Before you close an opt-out ticket

- [ ] The signal has one label and the original wording is logged verbatim
- [ ] No sequence step or scheduled send remains queued for the address in any sequencer
- [ ] The ticket shows a deadline timestamp, and the block was confirmed within 48 hours
- [ ] The CRM, ATS, every sequencer, and every contractor tool return the address as suppressed when queried
- [ ] A hashed tombstone row exists for every known address of the person
- [ ] If erasure was requested, an audit note lists what was deleted, where, and when, dated within one month
- [ ] Any third party the data was sold or shared to has been told to comply and pass the request on
- [ ] The most recent seed test, including the re-import pass, shows every system blocked

## Keeping the runbook current

This runbook goes stale whenever your stack changes, not on a calendar, so tie each re-check to the event that could break it.

- **New tool, domain, mailbox, or contractor.** Add it to the stack inventory and run a full seed test before it sends anything.
- **New import path.** A new enrichment source or list provider goes behind the pre-import guard before its first upload.
- **Quarterly.** Re-read the FTC guide, the ACMA fact sheet, the CPPA FAQ, the ICO's "Respect people's preferences" page, and Google's sender FAQ, and update the clock table if a window has moved. Re-run every seed channel.
- **Monthly.** Sample 20 replies labelled "not interested" and re-check them against the any-words test. Audit resubscribe events.
- **Owner change.** When the RevOps or recruiting ops owner leaves, the handover includes the stack inventory, the tombstone schema, the guard, and the seed-test log. If the UK pattern in Refolk's index holds for your company, that handover is often the only copy of the knowledge.

The test of the whole system is simple. Pick any opt-out from last quarter and show, from the log alone, when it arrived, when each system blocked it, and that the person has not been recreated since. If you can do that for any address, the runbook is working.

## Frequently asked questions

### Does a plain email reply saying stop count as an unsubscribe?

Yes. The FTC says you cannot require any step other than sending a reply email or visiting a single page, and the ICO says an objection can be made at any time and in any way, with no specific words required. A reply that says "please stop emailing me" is an opt-out even if the person never clicks your link. If your sequencer only records clicks, that reply sits in a rep's inbox until someone acts on it, so reply triage has to be a staffed job.

### How do I stop an unsubscribed contact from being re-imported and emailed again?

Keep a suppression record that survives deletion, and check every new list against it before import. The ICO describes this exact mechanism: check any new marketing lists against your suppression list. If you delete the record outright, the next enrichment run or CSV upload recreates the contact with no flag. HubSpot's opt-out import holds suppression across re-imports. Import defaults for other CRMs, ATSs, and sequencers are not publicly documented, so test yours with a seed address.

### Can I keep someone on a suppression list after they ask for GDPR erasure?

Yes, as long as you keep only the minimum. The ICO says a suppression list isn't for direct marketing purposes, that there is no automatic right to be removed from it, and that you should keep just enough to make sure the person's preference is respected. The ICO's draft code says Article 17(3)(b) likely applies. No ICO or EDPB text I found names hashing specifically, so confirm the hashed format with your privacy counsel.

### Does one opt-out apply to both our recruiting and sales teams?

Treat it that way. CAN-SPAM requires an option to stop all commercial messages from you, and you cannot contract away that responsibility. Whether one opt-out legally binds every team, brand, and domain of one company is not spelled out in the FTC or CASL sources I reviewed. The person cannot tell your teams apart, though, so one company-wide do-not-contact list is the only rule that holds up when they complain.

### How fast do I have to honor an opt-out?

Use the strictest clock that applies. Gmail recommends 48 hours and Yahoo 2 days for bulk senders, Australia allows 5 working days, CAN-SPAM and CASL 10 business days, and CCPA opt-out of sale or sharing 15 business days. GDPR and PECR have no fixed day count in the sources I reviewed. Set 48 hours as your internal target for every opt-out and keep the legal limit as a backstop.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/opt-out-propagation-runbook*