STIR/SHAKEN: Why Your Clients' Calls Are Getting Flagged

The MSP's Guide to VoIP: Part 18 of 20

Disclaimer: This post is educational content about the STIR/SHAKEN call authentication framework and its implications for voice service providers. It is not legal advice. Regulations change, interpretations vary, and your specific situation may differ from the general scenarios described here. Consult with a telecom attorney to determine how these regulations apply to your business.

Your client calls you on a Tuesday morning. Their sales team has noticed that prospects are not answering the phone. When prospects do answer, some of them mention that the call showed up as "Spam Likely" on their phone. The client's outbound calling numbers are legitimate, their business is legitimate, and they are not making robocalls. But the phone network does not know that, because the calls are not being properly authenticated.

This is a STIR/SHAKEN problem, and it is one of the most common voice issues MSPs encounter today that has nothing to do with network quality, codec configuration, or SIP signaling errors. It is an identity and trust problem, and understanding how it works is essential for anyone managing voice services.

The problem STIR/SHAKEN was created to solve

To understand STIR/SHAKEN, you need to understand the problem it was designed to address. The traditional telephone network had a fundamental trust weakness: caller ID was asserted by the originating party and accepted at face value by the rest of the network. There was no mechanism to verify that the entity placing the call was authorized to use the displayed caller ID number.

This was fine when the telephone network was a closed system operated by a handful of carriers with physical interconnection points. It became a catastrophic vulnerability when VoIP made it trivially cheap to originate millions of calls with arbitrary caller ID values. Robocallers exploited this by spoofing caller IDs, displaying numbers they did not own to make their calls appear local, appear to come from legitimate businesses, or appear to come from government agencies.

The scale of the problem became staggering. At peak, American consumers were receiving an estimated 4 to 5 billion robocalls per month. The calls were not just annoying. They were vehicles for fraud. Spoofed caller IDs made it nearly impossible for consumers to distinguish legitimate calls from scam calls, and the erosion of trust in the telephone system became a policy priority.

The TRACED Act of 2019 directed the FCC to mandate implementation of a call authentication framework for providers of interconnected VoIP, meaning any VoIP service that connects to the PSTN. That framework is STIR/SHAKEN. It has not eliminated robocalls — the reasons caller ID still lies in 2026 are worth understanding on their own — but it has fundamentally changed how carriers evaluate every call, including your clients' legitimate ones.

What STIR/SHAKEN actually is

STIR/SHAKEN is a pair of related standards. STIR (Secure Telephone Identity Revisited) defines the mechanism for creating and verifying digital signatures on calls. SHAKEN (Signature-based Handling of Asserted information using toKENs) defines how STIR is implemented in telephone networks using SIP signaling.

The core concept is straightforward. When a call is originated, the originating service provider creates a digital signature (a cryptographic token) that attests to the relationship between the calling party and the caller ID number being displayed. This token is attached to the SIP INVITE as an Identity header. As the call traverses the network, downstream carriers can verify the signature using the originating provider's public certificate, confirming that the call was signed by a legitimate provider and that the caller ID has not been tampered with in transit.

It works on the same basic principle as HTTPS certificates on the web. A certificate authority issues a digital certificate to the voice service provider. The provider uses that certificate to sign calls. The receiving carrier verifies the signature against the certificate authority's trust chain. If the signature is valid, the receiving carrier knows that a legitimate, identified provider originated the call and attested to the caller ID.

The three attestation levels

Not all STIR/SHAKEN signatures are equal. The originating provider assigns one of three attestation levels to each call, and the level chosen has real-world consequences for how the call is treated downstream.

Full attestation (A)

Full attestation means the originating provider has verified that the calling party is authorized to use the specific phone number displayed as the caller ID. The provider knows who the customer is, the customer has an established relationship with the provider, and the number being displayed belongs to that customer or is assigned to them by the provider.

This is the gold standard. Calls with full attestation are the most trusted by downstream carriers and analytics engines. They are the least likely to be flagged as spam or blocked. For your clients' outbound business calls, full attestation is what you want.

Full attestation is achievable when the numbers being used as caller ID are assigned to the customer by the same trunk provider that is signing the calls. If a client has ten DIDs assigned to their trunk, and they place calls displaying one of those ten DIDs, the trunk provider can verify that the number belongs to the customer and sign with full attestation.

Partial attestation (B)

Partial attestation means the originating provider has verified the customer's identity and has an established relationship with them, but cannot confirm that the customer is authorized to use the specific number displayed. The provider knows who is making the call, but the number shown might not be one the provider assigned.

This commonly occurs when a customer sends a caller ID number that is valid and belongs to them but is assigned through a different provider. For example, a business might have phone numbers from a previous carrier that they are displaying through a new trunk provider. The new provider can verify the customer's identity but cannot verify ownership of numbers they did not assign.

Partial attestation is a step down from full. Calls with partial attestation are not automatically flagged, but they receive less trust from analytics engines than fully attested calls. In an environment where carriers are aggressively filtering, partial attestation calls have a higher probability of being flagged or receiving reduced caller ID treatment.

Gateway attestation (C)

Gateway attestation means the originating provider can identify the source of the call (it came from a specific gateway or interconnection point) but cannot verify the caller's identity or their authorization to use the displayed number. This is the lowest attestation level.

Gateway attestation is common for calls entering a provider's network from international gateways, from legacy TDM interconnections, or from sources where the provider has limited visibility into the originating party. It is essentially a statement of "this call came from a known point, but we cannot vouch for anything else about it."

Calls with gateway attestation are the most likely to be flagged by analytics engines and blocked by carrier spam filters. If your clients' calls are consistently receiving gateway attestation when they should be getting full or partial, that is a problem that needs to be addressed with the trunk provider.

How attestation affects call completion

The practical impact of attestation is significant and measurable. Carriers and mobile handset manufacturers use attestation level as one of several inputs to their call scoring algorithms. These algorithms determine what the recipient sees when the phone rings: the caller's name and number, a "Verified" badge, a "Spam Likely" label, or nothing at all because the call was silently blocked.

The downstream effects cascade. When calls are flagged as spam, answer rates drop. Industry data suggests that calls flagged as spam are answered at rates 50 to 80 percent lower than verified calls. For a business that depends on outbound calling (sales teams, appointment reminders, follow-up calls), this directly affects revenue and operations.

When calls are blocked entirely, the caller may not even know. Some carriers silently block suspected spam calls rather than routing them to voicemail. The call appears to complete normally from the originator's perspective (they might hear ringback tone or get voicemail), but the recipient's phone never rings. This is particularly insidious because the business believes they are reaching people when they are not.

The attestation level is not the only factor in call scoring. Analytics companies like TNS, Transaction Network Services, Hiya, and First Orion also consider calling patterns, call volume, complaint history, number registration status, and other signals. But attestation is a foundational input, and getting it wrong undermines everything else.

Where signing happens in the network

Understanding where STIR/SHAKEN signing occurs helps you figure out who is responsible for your clients' attestation level and where to go when there is a problem.

STIR/SHAKEN signing happens at the originating service provider's network edge, typically at a Session Border Controller (SBC) or equivalent element that processes outbound calls before they leave the provider's network. The provider's SBC has access to the provider's STIR/SHAKEN certificate and the private key used for signing. When an outbound call passes through the SBC, the SBC evaluates the call, determines the appropriate attestation level, creates the cryptographic token, and attaches it to the SIP INVITE as an Identity header.

For an MSP in a white-label resale arrangement, signing typically happens at the wholesale provider's infrastructure. Your client's PBX (or the hosted platform) sends the call to the wholesale provider's SBC, and the SBC signs it. The attestation level depends on whether the wholesale provider recognizes the caller ID number as belonging to the customer.

For an MSP with their own trunking, signing typically happens at the trunk provider's SBC. Your PBX sends the INVITE through the SIP trunk, and the trunk provider's SBC signs it before routing it toward the destination. Again, the attestation level depends on the trunk provider's ability to verify the caller ID.

In either case, the entity doing the signing needs accurate information about which numbers belong to which customer. If your client's numbers are not properly registered in the signing provider's system, the provider cannot verify ownership and will default to partial or gateway attestation.

The certificate authority chain

STIR/SHAKEN certificates are issued by certificate authorities that are authorized by the STI Policy Administrator, which in the United States is the STI Governance Authority (STI-GA), managed by the industry. To obtain a certificate, a voice service provider must demonstrate that it is a legitimate provider and must maintain its certification through the STI-PA (Policy Administrator).

This is relevant to MSPs because obtaining your own STIR/SHAKEN certificate requires that you be recognized as a voice service provider, which circles back to the regulatory classification discussion from the previous post. If you are operating as a reseller under a wholesale provider's authority, you typically rely on the wholesale provider's certificate for signing. If you are operating as an independent voice service provider with your own trunking, you may need your own certificate, which means going through the certification process.

What happens when calls are not properly attested

When your clients' calls leave the network without STIR/SHAKEN signing, or with a lower attestation level than they should have, the consequences show up in several ways.

Spam labels. The recipient's phone displays "Spam Likely," "Scam Likely," "Potential Spam," or similar labels alongside or instead of the caller ID. The specific label varies by carrier and handset, but the effect is the same: the recipient does not trust the call.

Reduced answer rates. Even without an explicit spam label, calls without verification badges are answered less frequently than verified calls. As consumers become conditioned to screening calls, the absence of verification is itself a negative signal.

Outright blocking. Some carriers and call-blocking apps block unverified calls or calls with poor attestation without delivering them to the recipient. The call may go to voicemail or may receive no treatment at all.

Client frustration. Your client does not understand or care about STIR/SHAKEN. They know that their calls used to get answered and now they don't. They know their caller ID says "Spam Likely" when their customer looks at their phone. And they expect you to fix it, because you are managing their phone system.

The MSP's responsibilities depending on role in the call chain

Where your obligations sit depends on the service model you are operating under, as discussed in the previous post and in Post 2.

Referral model

If you referred the client to a hosted VoIP provider, STIR/SHAKEN is the provider's responsibility. You might still get the call when the client complains about spam labels, and you should understand enough to explain the issue and point the client toward their provider. But the implementation is not on you.

White-label resale

In a resale model, STIR/SHAKEN signing is typically handled by your wholesale provider. Your responsibilities are:

• Ensuring that all of your clients' phone numbers are properly registered in the wholesale provider's system so that the provider can verify ownership and sign with full attestation.
• Verifying that your wholesale provider is actually implementing STIR/SHAKEN correctly and signing calls at the appropriate attestation level.
• Being the first point of contact when clients report spam labeling issues and knowing how to escalate to the wholesale provider with the right information.

The most common resale-side issue is number registration gaps. A client gets a new DID, it is provisioned on the phone system but never registered with the trunk provider's STIR/SHAKEN system, and calls from that number go out with partial or no attestation. This is an operational process issue, not a technology issue, and it is entirely preventable with proper provisioning procedures.

Co-managed and full stack

If you are originating interconnected VoIP calls on your own trunking, your responsibilities expand. You need to ensure that your trunk provider is signing your calls with appropriate attestation. You may need your own STIR/SHAKEN certificate if you are acting as the originating provider. You need to have all client numbers registered with the signing entity. And you need to have filed in the Robocall Mitigation Database, which we will cover in the next post.

If you have your own SBC that is capable of STIR/SHAKEN signing and you have obtained your own certificate, you have direct control over the signing process. This gives you more control but also more responsibility, since you need to manage certificate renewal, ensure your signing infrastructure is functioning correctly, and keep your number inventory current.

Why this matters to your clients' daily business

Most of your clients have never heard of STIR/SHAKEN. They do not know what attestation levels are, they do not know what the Identity header in a SIP message contains, and they do not care. What they know is whether their phone calls get answered.

For businesses that depend on outbound calling, attestation problems are business problems. A medical office that calls patients to confirm appointments and gets flagged as spam is going to have higher no-show rates. A sales team that makes 200 outbound calls per day and gets flagged is going to see their connect rates crater. A law firm that calls clients from a number labeled "Spam Likely" is going to have a credibility problem.

These clients do not need to understand the technical details. They need their MSP to understand the technical details and make sure the right things are configured correctly so that their calls are properly authenticated and their phone numbers have good reputations.

This is also why the caller ID configuration work matters more than ever. Making sure the right number appears on outbound calls is not just a cosmetic issue. It determines which number gets attested, which number's reputation is affected by the calling patterns, and which number gets flagged if something goes wrong. Sending calls with the wrong caller ID is not just confusing to the recipient. It can result in attestation failures that damage the reputation of a number the client does not even intend to be using.

Practical steps for MSPs

Regardless of your service model, here are the things you should be doing:

Verify attestation levels. Ask your trunk provider or wholesale provider what attestation level your clients' calls are receiving. Some providers offer dashboards or reports that show attestation statistics. If they do not, ask them to check specific numbers. You want full attestation on all outbound calls where the caller ID number is assigned to the customer through the same provider chain.

Audit number registration. Go through your clients' phone numbers and verify that every number is properly registered in the signing provider's system. Pay particular attention to numbers that were ported in from other providers, numbers that were added after the initial provisioning, and toll-free numbers (which have their own attestation considerations).

Monitor for spam labels. Periodically check your clients' main outbound numbers against the major spam databases and carrier lookup tools. Services like Free Caller Registry allow you to check how numbers are being categorized. Watch for client complaints about recipients mentioning spam labels. If you are doing proactive monitoring, consider adding caller reputation checks to your regular review cycle.

Document your STIR/SHAKEN implementation. Whether you rely on a wholesale provider or manage your own signing, document how STIR/SHAKEN is handled for your voice services. This documentation will be important for your Robocall Mitigation Database filing, which we cover next.

Build it into provisioning. When you onboard a new client or add numbers to an existing client's service, make STIR/SHAKEN registration part of your provisioning checklist. The time to ensure proper attestation is during provisioning, not after the client calls to complain that their sales team is being flagged as spam.

Next up: The Robocall Mitigation Database and FCC Filing Requirements, the federal database that determines whether your traffic gets carried or blocked and what you need to do to stay in it.