How to sync DNC and opt-out lists between your dialer and CRM

Last updated 2026-07-11

Why does a sync gap between your dialer and CRM create TCPA liability?

A sync gap lets a rep legally dial someone who already opted out, because the opt-out lives in one system and the call queue reads from the other. Nobody flagged the mismatch. The call goes through. That single call is a TCPA violation worth $500 to $1,500.

Most outbound teams run two separate systems: a CRM like Salesforce or HubSpot that stores contact records, and a dialer like Five9, Convoso, or PhoneBurner that powers the calls. Each system often keeps its own internal opt-out or suppression list. When those lists are not synchronized, a rep can pull a contact into a call queue from the CRM after that person already opted out inside the dialer, or the reverse.

Under 47 U.S.C. § 227(c), a person who receives a call in violation of the FCC's do-not-call rules can sue for $500 per call, or up to $1,500 if the violation is willful ^[1]. Courts have treated a demonstrable sync failure, where a company held an opt-out in one system but not another, as evidence of willfulness. That's how you land at the $1,500 end of the range ^[2].

The scale problem is real. A single campaign touching 10,000 contacts where 2% already opted out means 200 potential violations. At $1,500 each, that's $300,000 in exposure from one bad list export. The cash app tcpa class action settlement and the credit one tcpa settlement both grew out of systemic failure to honor opt-outs across large contact databases. The mechanism was the same even if the scale was different.

This is not a theoretical edge case. Plaintiff attorneys look for exactly this gap in discovery.

What does the TCPA actually require for honoring do-not-call requests?

The TCPA and the FCC's rules set a few hard floors: honor an internal opt-out within 30 days, scrub against the federal registry at least every 31 days, stop texting immediately after a STOP reply, and comply with whichever state rule is strictest. Know these before you pick a technical solution.

The FCC's rules under 47 C.F.R. § 64.1200(d) require any company making telephone solicitations to maintain an internal do-not-call list, honor requests within a "reasonable time" not to exceed 30 days, and train personnel on that list's existence ^[3]. Thirty days sounds generous. In practice you want the opt-out honored before the next dial attempt, which could be the same afternoon.

The National Do Not Call Registry (the federal DNC list run by the FTC) requires companies to scrub their calling lists against the registry at least every 31 days ^[4]. A number added to the federal registry today has to be out of your active calling lists within that window. Treat "at least once every 31 days" as the outer limit, not the goal. See our deeper explainer on the do not call list for how registry access works.

For text messages, the TCPA treats an SMS opt-out (a reply of STOP, QUIT, UNSUBSCRIBE, or equivalent) as an immediate revocation of consent ^[1]. "Immediately" is not defined in days. It means you cannot queue another message after receiving STOP and send it anyway.

Several states impose tighter windows than the federal floor. Florida's Mini-TCPA (FTSA, Fla. Stat. § 501.059) and Washington's CEMA carry their own opt-out and timing rules that apply on top of federal law ^[5]. Your sync architecture has to be fast enough to satisfy the strictest jurisdiction your contacts live in.

What are the main technical architectures for syncing suppression lists?

Four architectures cover almost every team: a shared suppression database, API-driven bidirectional webhooks, scheduled batch export/import, and middleware like Zapier. They range from duct tape to real infrastructure. Here's how they compare and which one I'd actually build.

1. Shared database / single suppression table Both the dialer and CRM query the same database table before placing a call or sending a message. An opt-out written anywhere goes to one table and is visible everywhere at once. This is the cleanest approach and the one I'd recommend if you have engineering resources. It kills the sync problem by leaving nothing to sync.

2. API-driven bidirectional sync The dialer and CRM each expose webhooks or REST APIs. When an opt-out fires in either system, it posts to the other via API call. This works well when both platforms support webhooks (most modern ones do) and when the API calls retry on failure. The risk is webhook delivery failures that go unnoticed. You need logging and alerting on failed deliveries, which matters more than the webhook itself.

3. Scheduled batch export/import A script runs on a schedule, hourly or nightly, and exports the opt-out list from one system and imports it to the other. This is cheap and common. The sync window creates the risk. A contact who opts out at 2 PM and gets called again at 2:15 PM is a violation if your batch runs at midnight. For any high-volume operation, a batch schedule longer than a few hours is too slow.

4. Middleware / integration platform Tools like Zapier, Make (formerly Integromat), or dedicated RevOps platforms sit between the dialer and CRM and translate events in real time. An opt-out event in the dialer fires a zap that updates the CRM record, and the reverse. This is accessible to non-engineers and stands up quickly. The reliability ceiling is lower than a native API integration, and you're adding a dependency.

Architecture	Sync speed	Engineering lift	Reliability	Best for
Shared suppression database	Instant	High	Very high	Teams with dev resources
API bidirectional webhooks	Seconds	Medium	High	SaaS stacks with webhook support
Batch export/import	Hours	Low	Medium	Low-volume, low-frequency campaigns
Middleware (Zapier/Make)	Seconds to minutes	Low	Medium	Small teams, modern SaaS tools

How do you set up a bidirectional sync in practice?

The practical path is seven steps: map every opt-out signal, define a suppression record schema, build the dialer webhook, build the CRM receiver, mirror the reverse direction, add a pre-dial check as a backstop, and log everything with timestamps. That covers most teams reading this.

Step 1: Map every opt-out and DNC signal in both systems. List every way a contact can become suppressed: an inbound STOP reply to an SMS, pressing 9 to opt out during an IVR, a rep manually flagging a record, a number matching the federal DNC registry, a state DNC match, a prior litigation flag. Every signal type belongs in scope, including the ones that aren't obvious.

Step 2: Define the suppression record schema. Decide what fields travel with an opt-out: phone number (normalized to E.164 format), opt-out type (federal DNC, internal DNC, SMS stop, voice opt-out), timestamp, source system. Phone number normalization matters more than most teams realize. (555) 867-5309, 5558675309, and +15558675309 are the same number but three different strings. If your suppression check is a string match, format mismatches create false negatives.

Step 3: Build the webhook on the dialer side. Configure the dialer to POST to a webhook endpoint whenever an opt-out event fires. The payload should carry at minimum the phone number and opt-out type. Test it by manually opting out a test number and confirming the POST fires.

Step 4: Build the receiver on the CRM side. The CRM (or a middleware layer) needs to receive that POST and write the suppression flag to the contact record. For CRMs like Salesforce, this usually means updating a custom field (something like "DNC_Flag__c" with a true/false and a timestamp). HubSpot has a native opt-out property for email, but you'll likely need a custom property for call-specific DNC flags.

Step 5: Mirror the reverse direction. When a sales rep manually marks a contact DNC inside the CRM, that write event should also POST to the dialer's suppression list. Most dialers accept an API call to add a number to their internal DNC list.

Step 6: Add a pre-dial check as a backstop. Even with real-time sync, build a pre-dial check: before any number is dialed, query the suppression database. Belt and suspenders. The sync keeps lists current. The pre-dial check catches anything the sync missed.

Step 7: Log everything. Every suppression write, every sync failure, every pre-dial check result should be logged with a timestamp. In litigation, a timestamped audit trail showing when an opt-out arrived and when it propagated to all systems is the difference between a defensible position and a bad settlement.

How should you handle the federal and state DNC registry scrubs?

The federal registry scrub is separate from your internal opt-out sync, but it belongs in the same workflow. Access the National Do Not Call Registry through the FTC's official Telemarketing Sales Rule framework ^[4]. It costs $80 per area code per year as of 2024, with the first five area codes free ^[6]. You download the registry data for the area codes you call and scrub your list against it. Your dialer may do this automatically if you've uploaded the registry data, or you may need to run the scrub before uploading your call list.

The operational point that trips teams up: the registry scrub must happen at least every 31 days, but your list import into the dialer might happen more often. Every time you upload a new list to the dialer, scrub it first. Don't assume a list that was clean three weeks ago is still clean today. The FTC's National Do Not Call Registry Data Book for FY 2023 reports the registry held more than 249 million actively registered phone numbers by the end of that fiscal year ^[6].

For state DNC lists, several states (Indiana, Wyoming, Texas, Tennessee, Louisiana, Kentucky, Colorado, Florida, Mississippi, Missouri, Pennsylvania, and others) maintain their own separate registries ^[5]. If you call into those states, you have to scrub against the state list on top of the federal one. Some third-party data vendors and dialer platforms bundle multi-state scrubbing, so check whether yours does. Our page on how do I get the do not call list walks through the FTC registration process step by step.

On mobile phone do not call list questions: cell numbers on the national registry get the same protection as landlines. There is no separate federal mobile DNC list. It's the same registry. But TCPA adds a layer for cell phones. You generally need prior express written consent to call a cell phone with an autodialer or prerecorded message, regardless of DNC status ^[1].

How do you handle SMS opt-outs specifically?

SMS opt-outs are stricter than voice. When a contact replies STOP (or QUIT, CANCEL, END, UNSUBSCRIBE, the CTIA's standard opt-out keywords), your texting platform has to stop sending to that number immediately and send one confirmation message ^[7]. What most teams miss: the opt-out needs to flow back to the CRM and the dialer too.

Why the dialer? Because some teams use the same contact records for both call and text campaigns. If someone texts STOP but their CRM record isn't updated, a rep might still call them. Depending on the nature of the call, that can implicate the same consent and opt-out issues. The safe move is to treat an SMS opt-out as a suppression signal for all outreach until you have a documented re-consent.

The FCC's 2024 one-to-one consent order (effective January 2025) added more teeth here ^[8]. The FCC required that consent for text messages be "logically and topically associated" with the specific seller, meaning a consent given for one company's texts cannot be recycled to cover another company's texts. That hits lead generation companies that syndicate consent across multiple buyers.

For text message marketing programs specifically: your SMS platform likely captures opt-outs automatically, but confirm it's writing those opt-outs back to your CRM via API or webhook. If you're using Twilio, Klaviyo, or Attentive, each has an opt-out webhook or callback you can configure. Set it up, test it, log the results.

What fields should your suppression record include?

A suppression record that holds up in discovery needs more than a phone number. The minimum viable schema carries the number in E.164 format, the opt-out type and method, the source system, the opt-out timestamp, and a propagation timestamp showing when the suppression reached each downstream system.

• Phone number (E.164 normalized format, e.g., +15558675309)
• Opt-out type (values: FEDERAL_DNC, STATE_DNC, INTERNAL_DNC, SMS_STOP, VOICE_OPT_OUT, LITIGATION_HOLD)
• Opt-out source (which system received the opt-out: dialer name, CRM name, SMS platform)
• Opt-out timestamp (UTC, millisecond precision)
• Propagation timestamp (when the suppression reached each downstream system)
• Agent or system that recorded it (for manual entries, which rep; for automated, which system process)
• Opt-out method (IVR keypress, verbal request, SMS STOP reply, web form, written request)
• Reinstatement record (if the contact later re-consented, the timestamp and method of that re-consent)

The propagation timestamp is the field most teams skip and the one most valuable in litigation. If you received an opt-out at 14:03:22 UTC and your dialer removed the number at 14:03:45 UTC, you have a 23-second propagation time you can prove. That's a defensible position. Without a propagation timestamp, you cannot show when, or whether, the suppression took effect.

Store suppression records indefinitely, or at minimum for four years. The TCPA statute of limitations for a private action is four years ^[9]. Some plaintiff attorneys argue for longer under alternative theories. When in doubt, keep the records.

How do you test that your sync is actually working?

Building the sync is step one. Confirming it works is step two, and most teams skip it. Run four tests: dialer-to-CRM propagation, CRM-to-dialer propagation, SMS STOP propagation, and a pre-dial check that catches anything the sync misses. Each should resolve within 60 seconds.

Test 1: Dialer-to-CRM opt-out propagation. Take a test phone number that exists in both systems. Trigger an opt-out event in the dialer (via IVR press, manual flag, or API call to the dialer's DNC endpoint). Check the CRM record for that number within 60 seconds. Is the DNC flag set? Is the timestamp accurate? If not, the sync is broken.

Test 2: CRM-to-dialer opt-out propagation. Manually mark the same test number as DNC inside the CRM. Within 60 seconds, attempt to dial that number using the dialer. The dialer should block the call. If it doesn't, the reverse sync is broken.

Test 3: SMS STOP propagation. Send a test SMS to a number you control from your SMS platform. Reply STOP from that number. Within 60 seconds, check the CRM record. Is the SMS opt-out flag set? Then check whether your dialer also reflects the suppression, if your workflow calls for that.

Test 4: Pre-dial check validation. Bypass the sync and manually add a number directly to your suppression database. Confirm the pre-dial check blocks that number before a call is attempted, even if neither the dialer nor CRM got updated through the normal sync path.

Run these tests after any system update, integration change, or platform migration. Run them monthly as a routine audit. A 30-minute test costs nothing next to the cost of finding a sync failure through a lawsuit.

For teams that want a starting framework, LeadCompliant offers a free TCPA compliance checklist with a sync audit section you can run through with your ops team.

What are the most common sync failure modes to watch for?

Sync failures cluster around a handful of predictable points: phone number format mismatches, silent webhook delivery failures, list imports that skip the suppression check, botched platform migrations, timestamp confusion, and unlogged manual overrides. Most of these are process problems, not code problems.

Phone number format mismatch. The most common and most invisible problem. Your CRM stores numbers as (555) 867-5309. Your dialer stores them as 5558675309. Your suppression check is a string comparison. It returns no match. The call goes through. Normalize all numbers to E.164 at write time, in every system, every time.

Webhook delivery failures. HTTP webhooks fail. The receiving server times out. The SSL cert expires. The endpoint returns a 500. If your sync depends on webhooks and you have no retry logic and no alerting on delivery failures, you will eventually have a silent sync gap. Add retry with exponential backoff and alert on sustained failure.

List imports that bypass suppression. Someone downloads a contact list from a data vendor, does a quick import to the dialer, and starts calling. The import never ran through the suppression check. This is a process failure, not a technical one, but it's everywhere. The fix is to make the suppression scrub a mandatory gate in your list import workflow, not an optional step.

Platform migrations. When teams switch CRMs or dialers, historical opt-out data often gets lost or partially migrated. Treat historical opt-out lists as migration-critical data, equal in priority to contact records themselves.

Time zone and timestamp confusion. Suppression records written in local time by different systems create ambiguity. Standardize on UTC everywhere.

Manual override culture. Some dialers let reps or admins override a DNC flag to force a dial. The feature exists for legitimate reasons (testing, wrong number corrections), but without logging and approval workflows it becomes a liability. Audit your dialer settings to confirm who can override suppression flags and whether every override is logged.

What do real TCPA cases say about sync failures specifically?

Courts have not been kind to companies that had opt-out mechanisms but failed to make them work across systems. The FCC has held that companies are responsible for maintaining opt-out mechanisms that actually work, not ones that exist only on paper ^[10]. A sync that fails 2% of the time is not effective.

In class action practice, the discovery phase typically includes requests for all suppression list data, system logs showing when numbers were added and removed, and any evidence of calls made to numbers on internal DNC lists. A plaintiff's attorney who finds a number in your dialer's call logs after that same number appears in your CRM's opt-out field at an earlier timestamp has found exactly what they need to argue willfulness.

Several large settlements in recent years trace to this fact pattern. The credit one tcpa settlement involved allegations of repeated calls to consumers who had asked to be placed on an internal DNC list. The cash app tcpa class action settlement raised related questions about how opt-outs were handled at scale. These cases are instructive because the underlying calling programs were not rogue operations. They were large, structured programs with compliance teams that still had systemic gaps.

For teams running cold calling or cold call programs, the tcpa exposure on a per-call basis means even a small sync failure in a high-volume operation creates class action exposure. The math is unforgiving. See our overview of the do not call telemarketer list for how the registry intersects with B2C outbound.

The honest takeaway: no technical architecture makes TCPA liability impossible. But a well-documented, real-time, logged sync system makes willfulness very hard to argue, and that's the goal.

How often should you audit your suppression sync?

Run a functional sync test monthly and a full suppression list reconciliation quarterly. High-volume teams (thousands of dials per day) should reconcile daily with an automated script. Most teams set up the sync once and assume it keeps working. That assumption is wrong often enough to matter.

The quarterly reconciliation is the one that catches drift: export the full suppression list from every system (dialer, CRM, SMS platform, any third-party scrubbing service), merge them, find discrepancies, and resolve them. Any number suppressed in one system but not others should be added everywhere and flagged for review.

For high-volume operations, a daily automated reconciliation makes more sense. Write a script that pulls the previous day's opt-out events from every system, checks for gaps, and sends an alert when the counts don't match. The script is cheap to build. The liability it prevents is not.

Audit your federal DNC registry data currency too. The FTC updates the registry continuously. If your registry data download is 45 days old, you're outside the 31-day scrub window for any numbers added in the last two weeks of that period. Check the download date stamp on your registry data files. Make the refresh automatic.

LeadCompliant's free compliance tools include a DNC checker for spot-checking individual numbers, which is handy for validating a record before a high-stakes outreach.

One more thing worth building into your audit: a review of your consent records for the contacts you're actively calling. Opt-out sync solves the back end. Consent documentation solves the front end. Both need to be in order.

Frequently asked questions

How fast does a DNC opt-out need to take effect under TCPA?

The FCC's rules under 47 C.F.R. § 64.1200(d) require companies to honor internal do-not-call requests within a "reasonable time" not exceeding 30 days. For SMS, the FCC expects immediate effect after a STOP reply. In practice, building for immediate suppression beats relying on the 30-day outer limit. Any call made before the opt-out propagates is a potential violation if you cannot prove it was unintentional.

Does an SMS STOP opt-out also cover voice calls to the same number?

Not automatically under federal law, but treating it as a full suppression signal is the safest approach. An SMS STOP revokes consent for text messages to that number. Whether it also covers voice calls depends on what the original consent covered. If one consent form covered both calling and texting, a STOP reply likely revokes both. When in doubt, suppress across all channels and require fresh consent before resuming any contact.

Can we use a spreadsheet to manage our DNC list?

Technically yes, but it creates real operational risk. A spreadsheet is a static file with no real-time write access, no webhook capability, and no audit log. Every import/export cycle is a window for gaps. Small teams with very low call volume (under 50 dials per day) might manage it carefully, but anyone running an active outbound program needs a system that can be written to in real time from both the dialer and CRM.

What happens if we accidentally call someone who's on the national DNC registry?

Under the Telemarketing Sales Rule, the FTC can assess civil penalties up to $51,744 per violation for calls to numbers on the national registry. Private individuals can sue under TCPA for $500 per call or $1,500 for willful violations. A single accidental call is unlikely to trigger a government enforcement action, but it can anchor a private lawsuit, especially if the caller has a history with your company or reaches a plaintiff's attorney.

How do we handle a contact who opts out and then re-consents later?

Document the re-consent carefully: timestamp, method (web form, verbal on recorded line, signed agreement), and what they consented to. Store the re-consent record alongside the original opt-out record. Update the suppression flag in every system. The re-consent must be as clear and documented as the original opt-out. If you face a dispute, you need to show both the opt-out and the later re-consent with timestamps that make the sequence unambiguous.

Do we need to scrub against state DNC lists in addition to the federal registry?

Yes, if you call into states that maintain their own registries. States including Indiana, Wyoming, Texas, Tennessee, Louisiana, Kentucky, Colorado, Florida, Mississippi, Missouri, and Pennsylvania keep separate state DNC lists. You must comply with whichever standard is stricter, state or federal. Some third-party data providers and dialer platforms bundle multi-state DNC scrubbing, worth confirming with your vendor if you call nationally.

How long should we keep opt-out and suppression records?

At minimum, four years. The TCPA statute of limitations for a private action is four years under 28 U.S.C. § 1658, and some courts have applied different periods under state law. Some legal practitioners recommend keeping records indefinitely for numbers involved in any complaint or dispute. Storage is cheap. Losing a lawsuit because you deleted a record is not.

What's the risk if our webhook-based sync has a few failures per week?

It depends on whether those failures result in calls to suppressed numbers. A webhook failure that gets retried and resolved within seconds carries minimal risk. A failure that goes undetected for hours while the dialer keeps dialing those numbers is a real liability event. The technical fix is retry logic with alerting on sustained failures. If you cannot confirm a webhook delivered, treat the suppression as unconfirmed and do not dial until it is.

Our dialer vendor says their platform handles DNC compliance, do we still need to sync with our CRM?

Yes. A dialer vendor's built-in DNC handling usually means they scrub against the national registry before dialing. It does not mean they know about every internal opt-out recorded in your CRM by your sales reps. Those internal opt-outs are your company's obligation under 47 C.F.R. § 64.1200(d). No vendor handles that for you unless you've explicitly integrated your CRM's opt-out data into their system.

How often does the national DNC registry need to be re-downloaded?

At least every 31 days, per the FTC's Telemarketing Sales Rule. The registry updates continuously, so a download from 32 days ago may miss numbers added in the past week. Access costs $80 per area code per year (first five area codes free). Many teams set an automated monthly download as a recurring task. Any new list imported to the dialer should be scrubbed against the most current registry data, not a stale download.

What's the difference between a federal DNC suppression and an internal do-not-call list?

The federal DNC registry is the FTC's national list of consumers who requested no telemarketing calls. Your internal DNC list is the list you maintain of people who asked your company specifically not to call, regardless of their federal registry status. Both are legally required. A number can be on neither, one, or both lists. Your suppression system needs to block a number if it's on either. They are checked and stored separately.

Can we outsource our DNC sync to a third-party compliance vendor?

You can outsource the technical implementation to a vendor, and several specialize in real-time DNC scrubbing and suppression management. You cannot outsource the legal responsibility. If a call goes to a suppressed number because the vendor's system failed, the TCPA liability is still yours. Vet any vendor carefully: confirm their uptime guarantees, their audit log retention, and whether their indemnification clause means anything. Get it in writing.

How does the FCC's 2024 one-to-one consent rule affect our opt-out sync needs?

The FCC's January 2025 one-to-one consent rule requires that text message consent be tied to a specific seller and topic, not shared across a list of companies. That makes consent tracking more granular and more complex. Your sync architecture needs to carry more than a suppression flag: it needs to record which company's communications the number is opting out of. Generic suppression lists may fall short for multi-brand or lead-generation operations under the new rule.

Is there a safe harbor if we call a DNC number by mistake?

There is a limited safe harbor under the Telemarketing Sales Rule for calls made by error, but it applies only if you have procedures that meet FTC standards and the call resulted from a bona fide error despite those procedures, not from systemic failure. TCPA's text at 47 U.S.C. § 227(c)(5) allows suits for violations, and courts decide willfulness case by case. The safe harbor is narrow and litigated often. Build the sync correctly rather than relying on it.

Sources

1. Cornell LII, 47 U.S.C. § 227 (TCPA full statute text): TCPA provides for $500 per violation or up to $1,500 for willful violations; SMS opt-outs constitute revocation of consent
2. Cornell LII, 47 U.S.C. § 227(c)(5) (private right of action and willful violation treble damages): FCC orders require effective opt-out mechanisms; failure to maintain them can support a finding of willfulness
3. eCFR, 47 C.F.R. § 64.1200(d), Internal Do Not Call requirements: Companies must maintain an internal DNC list, honor requests within 30 days, and train personnel
4. FTC, Complying with the Telemarketing Sales Rule (business guidance): Sellers must scrub calling lists against the national DNC registry at least once every 31 days
5. FTC, National Do Not Call Registry: Multiple states including Florida, Texas, Indiana, and others maintain separate state DNC registries with their own requirements
6. FTC, National Do Not Call Registry Data Book FY 2023: Registry access costs $80 per area code per year (first five free); the registry held more than 249 million actively registered numbers at the end of FY 2023
7. eCFR, 47 C.F.R. § 64.1200(a), consent and revocation for calls and texts: STOP, QUIT, CANCEL, END, and UNSUBSCRIBE function as opt-out keywords requiring cessation of messaging; revocation of consent must be honored
8. eCFR, 47 C.F.R. § 64.1200(f), definition of prior express written consent: FCC rules require text message consent to be logically and topically associated with a specific seller, eliminating shared-consent lists
9. Cornell LII, 28 U.S.C. § 1658, Statute of limitations for federal civil actions: Four-year statute of limitations applies to TCPA private causes of action
10. eCFR, 47 C.F.R. § 64.1200(d), procedures for maintaining a do-not-call list: FCC rules require companies to maintain effective written do-not-call procedures, not merely nominal ones
11. FTC, Telemarketing Sales Rule (TSR), 16 C.F.R. Part 310: FTC can assess civil penalties up to $51,744 per violation for calls to numbers on the national DNC registry
12. FTC, National Do Not Call Registry (consumer and business guidance): Cell phone numbers on the national DNC registry receive the same protection as landlines; TCPA adds consent requirements for autodialed calls to cell phones