Calling a business a reseller does not decide its regulatory obligations. What the business actually does, how it participates in the call path and which services it supplies matter more than the label on its website. Resolve that role before launching a US voice offering or accepting outbound traffic from customers.
This chapter is an orientation, not legal advice or a complete compliance checklist. An inbound-number retailer, an originating voice service provider, a gateway provider and an intermediate provider can have different functions and requirements. Have qualified counsel review the actual model and the current rules rather than copying another supplier’s filing.
What STIR/SHAKEN addresses
STIR/SHAKEN is a caller ID authentication framework for IP voice networks. It allows participating providers to sign and verify information about calling numbers as calls pass through supported networks. It is intended to help address spoofing and support call-labeling and blocking decisions.
The FCC’s caller ID authentication overview describes its implementation requirements and the related robocall mitigation framework. Use that source as the starting point for the current scope, rather than relying on an old article that describes an expired extension or transition deadline.
Authentication is not a guarantee that a call is wanted, lawful or safe. It does not establish the truth of what a person says. A signed call can still involve unwanted conduct, while a call’s handling may depend on network support and other context. Do not advertise a reseller service as “spam-proof” because an upstream supplier uses STIR/SHAKEN.
The Robocall Mitigation Database is a separate duty
The FCC states that all providers must file in the Robocall Mitigation Database regarding their efforts to fight illegal robocalls, regardless of whether they have a STIR/SHAKEN implementation obligation. That includes a distinction between authenticating calls and documenting a mitigation program; one is not a substitute for the other.
Start with the FCC’s Robocall Mitigation Database information. Determine which entity must file, which provider category applies and what certifications and plan information the current rules require. A supplier’s presence in the database does not automatically cover every downstream business operating under its own name.
A database entry is not a general license to operate every communications service, an endorsement of the company or a promise that its traffic will never be blocked. Other obligations may apply to the business model. Treat the filing as part of compliance, not as a badge that replaces due diligence.
Upstream contracts cannot answer every legal question
Ask the upstream supplier to identify its role, its responsibilities for authentication and mitigation, and what it requires from you. Then distinguish those contractual promises from your own legal obligations. “Our carrier handles compliance” is too broad to be a useful answer.
Document who originates calls, who has the customer relationship, who verifies authority to use calling numbers and who responds to abuse reports. If a white-label platform provides technical functions, identify which legal entity remains responsible for filings and operational decisions.
Do not assume that being small, using hosted infrastructure or selling only to businesses creates a blanket exemption. Conversely, do not assume every ordinary business that purchases a phone number is itself a voice service provider required to make the same filings. Classification needs to follow the facts.
Build a real mitigation process
A mitigation plan should describe operations the business can actually perform. Establish customer onboarding, account review, approved use, escalation contacts and a process for investigating suspicious traffic. Make sure support staff know how to preserve relevant records and escalate an urgent complaint.
For outbound service, verify the customer’s authorization to use the calling numbers it supplies. Review requests to change that identity or greatly increase traffic. Use controls appropriate to the service and risk, and document decisions so they can be explained later.
A copied document describing tools you do not operate is not an operational program. Align the written plan with the actual platform, staffing and upstream cooperation. Review it when the service model changes, not only when a filing reminder arrives.
Questions to resolve before launch
- What functions does our entity perform in the call path?
- Which current FCC rules and other obligations apply to those functions?
- Which filings and certifications must our entity maintain itself?
- Who signs calls, who verifies number authorization and who handles exceptions?
- How do we review suppliers and respond to traceback or abuse requests?
- Who can suspend suspicious service, preserve records and contact counsel?
Keep a dated record of the answers and the sources used. This page was reviewed in October 2026, but rules, filing procedures and enforcement actions can change. Check the FCC materials again before making a filing or changing an operational control. Continue with documents and KYC for the separate question of who is entitled to use a particular number.