# The Do-Not-Contact Registry Standard: One Suppression List Every Tool Honors

*You will stand up one suppression registry, wire capture and pre-send scrub into every outreach tool, set the re-sync cadence, and prove no suppressed record can send.*

- Canonical URL: https://www.refolk.ai/guides/do-not-contact-registry-standard
- Pillar: Process, data, and compliance
- Format: Playbook
- Published: 2026-08-10
- Last reviewed: 2026-08-10
- Reading time: 18 min
- Keywords: build a do not contact list, suppression list across tools, opt-out sync crm sequencer, pre-send suppression scrub, do not contact registry setup

## Key takeaways

- A suppression list is a first-party do-not-send database that blocks specific identifiers before delivery, not a CRM status field or a third-party blacklist.
- The tightest constraint is not the 31-day DNC scrub interval but the mailbox-provider honor window: Gmail and Yahoo demand unsubscribes be processed within 48 hours.
- The internal opt-out layer is the one that gets you sued, and TCPA's private right of action attaches there at $500 to $1,500 per call.
- Deleting a suppressed record erases its opt-out memory, so the next import re-creates a clean contact and re-arms outreach; suppress, never delete.
- Soft-bounce thresholds vary roughly 20x across platforms, from 5 errors to 20, so trusting native defaults produces inconsistent suppression states across a stack.
- In Refolk's index of professional profiles, 726 people in the US hold Revenue or Marketing Operations titles versus 56 in the UK, a roughly 13x gap that shapes who gets assigned this build.

A do-not-contact registry is one first-party database that blocks communication to specific identifiers before any tool delivers a message, call, or audience sync. This guide is for the RevOps, MktOps, and compliance owner who is answerable for how outreach data is handled and who has to prove, on demand, that a suppressed person or account cannot slip through any channel. It gives you the build order, the field schema, the sync cadence, and a repeatable seed test that proves enforcement holds.

The public answers stop at "centralize and automate" and then pitch a product. None of them give you the order to build in, the fields a record needs, or a test that proves a suppressed record cannot send. This is that procedure, and it is tool-agnostic on purpose, because the whole point of the registry is that no single tool owns the truth.

## What a suppression registry is, and what it is not

A suppression list is a first-party do-not-send database that blocks communication to specific identifiers before delivery. That definition is the whole discipline: it separates the registry from a contact list, from a CRM status field, and from a third-party blacklist. It tells your systems who you must not reach through a specific channel, and it operates at the identifier level rather than the person level.

The distinction matters because a CRM status field is descriptive and a suppression record is enforcing. "Churned" in a status column is a note; a suppression record for that account's domain is a gate. If your stack treats a field as a gate without a system that reads it before every send, you have a note pretending to be a gate. That is the gap this guide closes.

> **Rule:** The registry is infrastructure, not a list
>
> Build it the same way you build access control, audit logs, or fraud checks: one queryable store that every tool reads before it sends. If any tool can send without consulting it, it is not a registry.

Scope has two grains, and both must be explicit. At the contact grain you suppress an identifier: an email, a phone number, a person. At the account grain you decide which record statuses suppress outreach, paid syncs, AI suggestions, lifecycle messages, and health alerts. Churned, refunded, inactive, suspended, payment-failed, migrated, merged, and duplicate records may all need different handling, and a registry that only thinks in emails will let a suppressed contact's parent account walk straight into a paid audience or a winback.

## The record schema: what one suppression entry carries

A suppression record is channel-aware and carries enough to be defended in an audit. No public source publishes a canonical field schema, so treat the schema below as a build target rather than a cited standard, and adapt the field names to your store.

The load-bearing fields are the identifier, the channel it suppresses, the source that captured it, the timestamp, and the grain. For bounce-driven suppressions specifically, a defensible record adds four more: a count, a time window, a failure reason, and a reset rule. Those four turn a raw bounce into an auditable decision instead of a guess.

**Suppression record schema**

```
identifier          # email, phone, or domain
identifier_type     # email | phone | domain
channel             # email | call | all
grain               # contact | account
source              # one-click | footer | reply-stop | fbl-arf | bounce | legacy-import
suppressed_at       # ISO timestamp, when it entered the registry
reason_code         # opt_out | complaint | hard_bounce | soft_bounce_threshold | status_suppress
bounce_count        # bounce records only
bounce_window       # e.g. 14d, the span the count is measured over
reset_rule          # e.g. reset counter after a successful delivery
durable             # true = reinstated if the record is deleted and reimported
```

*Adapt field names to your store; keep every field, especially the bounce four.*

The `durable` field is not decoration. It is the flag that stops the single most common silent failure in this whole job, and the section on migration explains why.

## The compliance clocks that set your cadence

Three clocks govern how often you scrub and how fast you must act, and they do not agree. The strictest one wins, and it is usually not the one operators watch.

For calls, every seller initiating outbound telemarketing calls to residential or wireless numbers must scrub against the registry at least every 31 days. That 31-day window is the maximum allowable staleness, not a target. For email, any opt-out mechanism must stay live for at least 30 days after you send, and you must honor an opt-out request within 10 business days. Then the mailbox providers tighten it: senders have 48 hours to honor unsubscribe requests, true for both Gmail and Yahoo.

**48 hours - The real honor window for email opt-outs**

Regulators allow 10 business days, but Gmail and Yahoo demand 48 hours, so mailbox rules set your true re-sync SLA.

That is the insight most cadence plans miss. CAN-SPAM's 10 business days is not your constraint; the 48-hour mailbox rule is. Design your re-sync SLA against the tightest clock, then the looser ones satisfy themselves.

The penalties tell you why this is worth engineering. TSR civil penalties reach up to $51,744 per violation, adjusted annually. The TCPA creates a private right of action with statutory damages of $500 to $1,500 per call. Each separate email in violation of CAN-SPAM is subject to penalties of up to $53,088. And enforcement is real: the FTC received 2.6 million DNC complaints in fiscal year 2025, and since 2003 has filed 173 enforcement actions and collected nearly $400 million in penalties.

| Channel | Cadence / honor window | Max penalty (per unit) |
|---|---|---|
| Telemarketing (TSR) | Scrub every 31 days | $51,744 / violation |
| Telemarketing (TCPA) | Honor internal DNC | $500-$1,500 / call |
| Email (CAN-SPAM) | 10 business days | $53,088 / email |
| Email (Gmail/Yahoo) | 48 hours | Blocking / deliverability loss |

Note where the private right of action lives. TCPA damages attach to the internal opt-out list, and that is the layer operators most often leave manual. DNC is three stacked layers: the federal registry, state registries, and the internal company-specific opt-out list. Teams automate the federal scrub and leave the internal layer as a spreadsheet someone updates by hand. That internal layer is the most commonly broken in agency operations, and it is precisely where a person can sue you per call.

## The capture points that feed the registry

Five feeds write into the registry, and each one has a way of failing quietly. The registry is only as complete as its weakest capture point, so treat each as a wired input, not a hope.

- **One-click List-Unsubscribe headers.** RFC 8058 requires an HTTPS URI plus the exact header `List-Unsubscribe-Post: List-Unsubscribe=One-Click`. The endpoint must return a 2xx code and handle POST, not GET, or the unsubscribe silently fails.
- **Footer unsubscribe links.** The visible link a recipient clicks, which must stay live for at least 30 days after send.
- **Reply and STOP parsing.** Inbound replies and STOP keywords, parsed and written to the registry.
- **Spam-complaint feedback loops.** Once an ARF report is parsed, the complaining address is added to suppression so no further emails send from any campaign.
- **Bounces.** Hard bounces suppress immediately; soft bounces suppress on a consecutive threshold.

#### From opt-out event to enforced suppression

1. **Capture** - One-click, footer, reply/STOP, ARF, or bounce fires
2. **Normalize** - Resolve to an identifier and channel, attach source and timestamp
3. **Write** - Insert a durable suppression record within 48h for email
4. **Enforce** - Every tool scrubs against the record at send-time

*Every capture point must write back to one registry inside the honor window before the next send.*

The feedback-loop feed has a structural hole worth naming now. Gmail publishes only an aggregate spam rate through Postmaster Tools and gives no per-address reports. Yahoo's complaint feedback loop only supports DKIM-signed email, and Microsoft's JMRP is tied to the sending IP. So any registry relying on ARF completeness has a permanent blind spot for the largest mailbox provider. You cannot auto-suppress individual Gmail complainers; you can only watch the aggregate rate and rely on engagement-based sending. Gmail defines a bulk sender as 5,000 or more messages a day and flags a spam complaint rate above 0.3 percent, so that aggregate is the number to guard.

## The bounce rule: one threshold, not each tool's default

Suppress hard bounces immediately and promote soft bounces on a consecutive-failure threshold, and set that threshold once for the whole stack rather than trusting each tool's native default. A defensible baseline is three consecutive countable soft bounces across at least 14 days, with immediate suppression for hard bounces.

The reason you must standardize is that platform defaults diverge wildly. Trusting each tool's own rule is a direct route to the "correct in one system, stale in another" failure, because the same address will be suppressed in one tool and live in another.

| Platform | Hard bounce | Soft-bounce threshold |
|---|---|---|
| Klaviyo | Immediate | 7 consecutive (2-yr window) |
| Dotdigital | Immediate | Configurable 1-20, default 20 |
| Adobe Journey Optimizer | Immediate | Default 5 errors |
| Practitioner baseline | Immediate | 3 consecutive over 14+ days |

That is roughly a 20x spread, from 5 errors to 20, before you even count Klaviyo's 7. The counting is as important as the number. Separate your counters by reason code, because a sender-side reputation block or a DNS timeout is not a recipient failure. If a broad, domain-wide spike gets counted as per-recipient hygiene, you will over-suppress valid contacts and blame the wrong thing.

## Build the registry in order

Here is the full procedure, start to finish, with owners and rough durations. Do not reorder it: capture points that write to a registry that does not yet enforce are just data, and a seed test before durable unsubscribe is wired will pass and then lie.

#### Standing up the registry

1. **Define the schema and scope** - Decide identifier types, channel scope, source, timestamp, and contact-vs-account grain. Done = a documented record spec carrying count, window, reason, and reset for bounces. (RevOps/MktOps lead, 1-2 days)
2. **Stand up the central registry** - Build it the way you build access control or audit logs: one queryable store every tool reads before send. Done = a single system of record no tool can bypass. (ops engineer, 3-5 days)
3. **Wire capture points in** - Connect one-click headers, footer links, reply/STOP parsing, ARF parsers, and bounce webhooks. Done = each channel writes back within the honor window, 48h for email. (ops engineer, 3-5 days)
4. **Set the bounce promotion rule** - Hard = immediate; soft = 3 consecutive over 14+ days, tuned per platform. Done = one documented, auditable rule across the stack. (deliverability owner, 1 day)
5. **Insert pre-send scrub in every tool** - Scrub at send-time, not build-time; for dialers, layer federal, state, and internal. Done = no tool can send without a fresh registry check. (ops engineer, 2-4 days)
6. **Set the re-sync and scrub cadence** - Calls every 31 days max; email opt-outs within 48h; scrub before every campaign as best practice. Done = scheduled jobs plus logs. (ops lead, ongoing)
7. **Migrate legacy opt-outs as durable suppressions** - Import old lists as unsubscribe records, never deletions, and enable durable unsubscribe. Done = a re-import cannot re-expose. (ops engineer, 1-2 days)
8. **Run the seed test and retain the audit trail** - Plant seeded suppressed identities across people and accounts, launch a live send in each tool, confirm zero delivery, archive scrub logs. Done = documented proof of due diligence. (compliance owner, quarterly)

> **Rule:** Scrub at send-time, never build-time
>
> The system has to check every outbound event against current suppression rules before a message, call, or audience sync goes out. If your platform checks suppression only after the campaign is built, you are already too late.

Before you assign this, know who actually builds it. In Refolk's index of professional profiles, 726 people in the US hold Revenue or Marketing Operations titles versus 56 in the UK, roughly a 13x gap. Inside the US pool, 35 Marketing Operations profiles list Marketo skills against 28 listing HubSpot, so Marketo runs about 1.25x HubSpot among that group. The practical consequence: UK and EU teams standing up a registry will more often hand it to a Marketo- or HubSpot-skilled generalist than to a dedicated hire, so write the schema and cadence down as a document the generalist can execute, not as tribal knowledge.

| Segment | Count | Derived |
|---|---|---|
| US Rev/Mktg Ops titles | 726 | baseline |
| UK Rev/Mktg Ops titles | 56 | ~7.7% of US pool |
| US MktOps with Marketo | 35 | 1.25x HubSpot |
| US MktOps with HubSpot | 28 | baseline |

When you need to find the person who has actually wired a suppression list across a CRM, a sequencer, and a dialer, describing the exact workflow beats title-searching. [Refolk](/) resolves a plain-English description of that build to reachable people across the public web.

I ran this search: `RevOps engineers who built a centralized suppression list syncing Salesforce with a sequencer and a dialer` - [see the full result list](https://www.refolk.ai/s/fyepesqbwg).

*Returns people whose public footprint shows they have wired suppression across multiple outreach tools, not just held the title.*

## Migrate legacy opt-outs as durable suppressions, never deletions

Import every legacy opt-out as a durable suppression record and never delete a suppressed record to clean your data. Deleting a record erases the opt-out flag, and the next import re-creates a clean contact with no suppression memory. This is a mechanism, not a mistake, which is why it keeps happening.

The documented fix is a durable, persistent unsubscribe. If you delete a person with Unsubscribed = TRUE, that flag is reinstated should the person be inserted again. And the tool will not send where there is a matching Unsubscribe record whether or not it is linked to a contact or lead, so creating Unsubscribe records for preexisting suppression-list members ensures those recipients do not erroneously receive email. Migrate by writing suppression records, not by cleaning.

> Deletion is not hygiene. It is a re-exposure vector that re-arms outreach on the next import.

## How this goes wrong: the failure modes

The value of a suppression registry is not that it exists but that it cannot be quietly bypassed. Below are the documented ways it looks compliant while leaking, with the check that catches each one. Every one of these passes a casual glance, which is the whole problem.

- **Build-time scrub instead of send-time.** Looks green because the campaign was scrubbed at creation, but an opt-out arriving after build still sends. Check: compare the timestamp of the last scrub against the actual send time.
- **Delete-not-suppress.** A cleaned delete looks compliant until the next import re-creates the contact with no opt-out memory. Check: seed a deleted opt-out, re-import, confirm it is still suppressed.
- **Sibling-tool drift.** The sequencer suppresses, the dialer does not; the account looks quiet on one channel while another fires. Check: query the same identifier across every tool.
- **Gmail complaint blind spot.** Assuming the feedback loop catches all complaints, when Gmail gives only aggregate rates. Check: watch the Postmaster spam rate, not just the ARF feed.
- **Soft-bounce over-suppression.** A sender-side reputation block or DNS timeout counted as a recipient failure suppresses valid contacts. Check: separate counters by reason code; a broad domain-wide spike is not a hygiene problem.
- **Unmonitored mailto: unsubscribe.** A mailto in the header with no one reading the inbox is a silent compliance failure. Check: send a live unsubscribe and confirm it lands and processes.
- **Expiring one-click token.** A signed URL expires before the user clicks weeks later; the unsubscribe silently fails and may trigger a spam report. Check: test an old message's header endpoint.
- **Account-level gaps.** A contact opts out but the parent account still enters a paid audience or winback. Check: query suppression at both the contact and account grain.

> **Watch out:** The internal list is the one that gets you sued
>
> Operators automate the federal scrub and leave the internal opt-out layer manual. It is the most commonly broken layer, and TCPA's $500 to $1,500 per-call private right of action attaches exactly there.

The matrix below is the triage. Two variables decide how much a given failure should scare you: how easily it hides, and how expensive it is if it fires.

#### Triaging suppression failures

Horizontal axis runs from Cheap if it fires to Expensive if it fires. Vertical axis runs from Easy to spot to Hides well.

| Quadrant | What it means |
| --- | --- |
| Loud and cheap | Fix in the normal cadence, e.g. a visible footer link outage |
| Loud and costly | Fix now; you will see it but it hurts, e.g. a domain-wide bounce spike |
| Quiet and cheap | Add a check so it stops hiding, e.g. an unmonitored mailto |
| Quiet and costly | Top priority; build the seed test around it, e.g. delete-not-suppress and internal-list drift |

*Prioritize the failures that hide well and cost a lot; they are the ones that reach litigation.*

## The seed test: proving enforcement holds

The seed test is the only thing that turns "we suppress" into "we can prove suppression cannot be bypassed." No public source publishes a named seed-test spec, so treat this as the original procedure it is, and run it quarterly.

Plant a set of seeded suppressed identities you control across both grains: seeded people (mailboxes and phone numbers you own, entered as suppressed) and a seeded account (a domain you control, entered as an account-level suppression). Then launch a real, live send from every tool in the stack against a list that includes the seeds. A live send is essential; a preview or a dry run does not exercise the send-time scrub. Confirm zero delivery to every seed in every tool, and archive the scrub logs alongside the send records.

The audit trail is not optional paperwork; it is the legal product of the whole exercise. The scrubbing process must be documented, creating an audit trail that demonstrates due diligence in the event of litigation or regulatory inquiry. Safe harbor requires written procedures, trained personnel, registry access scrubbed against current data within the past 31 days, and recording and honoring all DNC requests received. Your seed-test archive plus your scrub logs are what satisfy that.

#### What the seed test filters out

| Stage | Figure | Note |
| --- | --- | --- |
| Seeds planted | all | people and account grain |
| Survive build-time scrub | fewer | catches stale post-build opt-outs |
| Survive send-time scrub | fewer | catches tools that skip the registry |
| Actually delivered | zero | any non-zero here is a failure to fix before the next campaign |

*Each stage removes a class of leak; a seed that survives to delivery is a live compliance failure.*

#### Before you call the registry done

- [ ] One central registry exists and every outreach tool reads it before send
- [ ] The record schema carries identifier, channel, source, timestamp, grain, and the bounce four (count, window, reason, reset)
- [ ] One standardized bounce rule is applied across the stack, not each tool's native default
- [ ] Every capture point (one-click, footer, reply/STOP, ARF, bounce) writes back within 48 hours for email
- [ ] Dialers scrub federal, state, and internal layers, and the internal layer is automated not manual
- [ ] Legacy opt-outs were imported as durable suppression records, and a delete-then-reimport test still suppresses
- [ ] A live seed test across people and account grain returned zero delivery in every tool
- [ ] Scrub logs and the seed-test result are archived as an audit trail

## Keeping the registry current

A suppression registry is not a project you finish; it is a control you maintain, and the two things that drift are the cadence jobs and the mailbox-provider rules. Re-run the seed test quarterly and after any change to a capture point, a bounce threshold, or the tool stack, because a new sequencer added without a send-time scrub is a fresh hole that no old test result covers.

Watch the mechanisms, not the current numbers, because the numbers move. Penalty amounts are adjusted annually, mailbox-provider requirements tighten, and complaint-rate thresholds change. Re-check the FTC's CAN-SPAM guidance for the current per-email figure, re-check the telemarketer registry portal for the current scrub obligation, and re-check Google Postmaster Tools and the Yahoo and Microsoft feedback-loop programs for their current sender requirements. The mechanism is stable even when the value is not: capture at the identifier level, write durable records, scrub at send-time, prove it with seeds.

> **Tip:** Tie the seed test to a calendar, not a person
>
> Schedule the quarterly seed test and the post-change re-run as owned, dated jobs. The failure mode is not that the test is hard; it is that nobody owns re-running it after the stack changes.

When the person who built the registry leaves, the document is what survives. That is why every part of this guide is written down rather than configured and forgotten: the schema, the one standardized bounce rule, the cadence, the migration approach, and the seed test. Hand a new owner those five things and they can re-prove enforcement without reverse-engineering your stack.

## Frequently asked questions

### How often do I have to scrub against the do not call registry?

At least every 31 days for outbound telemarketing calls to residential or wireless numbers. Treat that as the maximum allowable staleness, not a target. Most operators scrub more often because email opt-outs must be honored within 48 hours by Gmail and Yahoo, and the honest practice is to scrub before every campaign. The 31-day floor is a legal minimum; your real service level is set by the tightest channel you run.

### What is the difference between suppressing and deleting a contact?

Suppressing keeps a durable do-not-send record so the identifier stays blocked; deleting erases the opt-out flag entirely. Deletion is the silent re-exposure vector: the next import re-creates a clean contact with no suppression memory and outreach re-arms. The documented fix is durable unsubscribe, which reinstates an Unsubscribed flag if a deleted record is inserted again. Never delete a suppressed record to save storage or clean data.

### Should suppression run at build-time or send-time?

Send-time, always. If your outreach platform checks suppression only when the campaign is built, an opt-out that arrives after the build still sends. The system must check every outbound event against current suppression rules before a message, call, or audience sync goes out. A build-time scrub looks green because the campaign was scrubbed at creation, which is exactly why it hides the failure.

### Why does the same person get contacted through one tool but suppressed in another?

Because the suppression state is correct in one system and stale in another, the documented cross-tool failure mode. A sequencer suppresses while a dialer does not, so the account looks quiet on one channel while another still fires. The fix is a single central registry every tool reads at send-time, plus a seed test that queries the same identifier across every tool to confirm consistency.

### Does a feedback loop catch every spam complaint?

No. Gmail publishes only an aggregate spam rate through Postmaster Tools and gives no per-address reports, so individual Gmail complainers are never auto-suppressed. Any registry relying on ARF feedback loops for completeness has a permanent blind spot for the largest mailbox provider. Watch your Postmaster spam rate as a signal and lean on engagement-based sending, because per-person suppression from Gmail complaints is structurally unavailable.

---

*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/do-not-contact-registry-standard*