Verstat Explained: The Verification Status Parameter in STIR/SHAKEN Calls
You open a SIP trace on an inbound call, and there it is on the P-Asserted-Identity line: verstat=TN-Validation-Passed. Or a customer forwards you a screenshot of their phone showing “Verified Caller” and asks what the carrier actually checked. Both come back to the same small piece of data. Verstat is the verification-status parameter a terminating network attaches to a call after it runs the STIR/SHAKEN check, and it is the closest thing to a plain-English answer to “did this call’s caller ID pass STIR/SHAKEN verification?”
In this article, we’ll walk through what verstat is, where the value comes from, what each value means (including the “verified by the carrier” language consumers see), and how it differs from the attestation level and the green checkmark that people constantly mix it up with. If you operate an SBC or a softswitch and you’re trying to make routing or display decisions off the verification result, this is the parameter you’re reading.
What Is Verstat?
Verstat is a parameter that carries the result of STIR/SHAKEN verification for a single call. When a terminating service provider receives a call with a signed Identity header, it validates that signature and then records the outcome as a verstat value so that downstream systems, and eventually the called party’s device, can act on it.
The parameter typically rides in the caller’s identity on the terminating leg, most often appended to the user portion of the P-Asserted-Identity (PAI) header, and it takes one of three canonical values defined by the industry: TN-Validation-Passed, TN-Validation-Failed, and No-TN-Validation. “TN” is the telephone number, so the three states read as “the number was validated and passed,” “the number was validated and failed,” and “no validation happened.” That is the whole vocabulary. Everything a consumer sees as “verified” or a spam label reads about traces back to which of those three strings the terminating network wrote.
The important thing to hold onto is that verstat is a result, not a claim. It is produced at the end of the call’s journey, by the network delivering the call, after a cryptographic check has actually run. That distinction is what separates it from attestation, which we’ll get to.
Where Verstat Comes From
To see where the value originates, follow a call through the terminating side of a STIR/SHAKEN deployment.
A signed call arrives at the terminating provider carrying an Identity header. That header holds the PASSporT, a signed token built at origination from the calling number, the called number, and a timestamp, defined in the framework built on RFC 8224. The terminating SBC hands that Identity header to a verification service (the STI-VS), which checks three things: that the cryptographic signature is valid, that the certificate chain traces back to a trusted authority, and that the token is fresh rather than replayed. The verification service returns a pass or fail, and the SBC translates that outcome into the verstat value it stamps onto the call before delivering it inward.
If a call arrives with no Identity header at all, there is nothing to validate, and the result is No-TN-Validation. That is common today because a large share of traffic still originates on networks that have not deployed signing.
The Verstat Values and What They Mean
There are only three values, and each maps to a clear condition.
| Verstat value | What happened | What it tells downstream systems |
|---|---|---|
TN-Validation-Passed |
An Identity header was present and the signature, certificate chain, and freshness all checked out | The caller ID was cryptographically verified based on the originating provider’s signature. |
TN-Validation-Failed |
An Identity header was present but validation failed (bad signature, untrusted or expired certificate, stale token, or number mismatch) | The caller ID could not be confirmed and may be spoofed; treat with suspicion |
No-TN-Validation |
No Identity header was present, or verification could not run | Verification is simply absent; this is not the same as a failure |
The middle and last values get conflated constantly, and the difference matters. TN-Validation-Failed means the network tried and the call did not pass, which is a genuine signal of a problem. No-TN-Validation means the network never had anything to check, which today mostly reflects gaps in industry-wide deployment rather than anything wrong with the specific call. Treating “no validation” as “failed validation” would flag an enormous volume of legitimate traffic, so downstream policy handles the two very differently.
This is also where the phrase people search for comes in. “Verified by the carrier” is the consumer-facing translation of TN-Validation-Passed. When a terminating carrier maps a passed verstat to a “Verified Caller” badge or a checkmark on the handset, the meaning is narrow and worth stating precisely: the carrier confirmed that the call was signed by a provider vouching for that calling number, and the signature held up. It does not mean the carrier knows the caller personally, that the call is wanted, or that it isn’t a scam from a business that legitimately owns its number. It means the caller ID is authentic, and nothing more.
Verstat vs Attestation vs the Green Checkmark
Three concepts sit close together in STIR/SHAKEN, and getting them straight removes most of the confusion around verstat.
Attestation is the claim the originating provider makes when it signs the call. It is a single letter, A, B, or C, placed in the attest field of the PASSporT, and it says how much the originating provider knows about the caller. A means full knowledge, B partial, C gateway-level. The attestation level is set at the start of the call’s life, by the network the call came from.
Verstat covers the result the terminating provider records at the other end. It does not re-judge the attestation letter; it confirms whether the signature carrying that letter is cryptographically valid. A call can be signed at A-level and still come back TN-Validation-Failed if the certificate has expired, and a call signed at C-level will happily pass verification as long as the signature is sound. Attestation is about how much the originator vouches; verstat is about whether the vouching survived the trip intact.
The green checkmark, or “Verified Caller” label, happens at the display layer. It sits on top of the verstat result but is not the same thing. The terminating carrier decides how to present a passed verification to the subscriber, and it often blends the verstat outcome with analytics, reputation data, and its own policy before deciding what to show. A passed verstat can still land under a “Spam Risk” banner if the calling number has a bad reputation, because the checkmark is a product decision layered above the raw verification result.
So the clean mental model is a relay: attestation is stamped at origination, verstat is recorded at termination, and the checkmark is what the carrier chooses to render for the human. Each hands off to the next, and each answers a different question.
How the Verstat Result Drives Routing and Display
Once the verstat value exists on the call, it becomes an input a terminating network can act on. Two things typically happen with it.
The first is display. The carrier decides what the called party sees, using the verstat result as one factor. A passed verification might drive a “Verified” badge; a failed one might drive a warning or a “Scam Likely” treatment; and depending on the carrier, “No-TN-Validation” is usually shown neutrally, because penalizing every unsigned call would punish legitimate traffic from networks still catching up on deployment.
The second is routing and policy. Because the verstat value lands in a SIP header, any device that can read SIP headers can branch on it. On a programmable SBC, that is where the verification result stops being informational and starts being operational. A configurable routing engine can read the verstat parameter and apply a policy per call: pass verified calls straight through, route failed ones to an announcement or other policy treatment, tag everything into the call detail records for later analysis, or feed the result into a fraud-scoring decision alongside other signals. The value of putting this logic in the routing layer is that a single SBC handling mixed traffic can treat each call on its own merits rather than applying one blanket rule to a whole trunk.
None of this is exotic. It is the natural consequence of STIR/SHAKEN putting a machine-readable verdict onto every inbound call. The verstat parameter is simply the field that carries that verdict, and the network’s job is to decide what to do about it.
Frequently Asked Questions
What does verstat mean in a SIP header?
Verstat is a parameter that records the result of STIR/SHAKEN verification for a call. It usually appears in the P-Asserted-Identity header on the terminating leg and takes one of three values: TN-Validation-Passed, TN-Validation-Failed, or No-TN-Validation. It tells downstream systems whether the caller ID successfully passed STIR/SHAKEN verification.
What is the difference between TN-Validation-Failed and No-TN-Validation?
TN-Validation-Failed means an Identity header was present but the verification check did not pass, which is a real signal that the caller ID may be spoofed. No-TN-Validation means there was no Identity header to check in the first place, usually because the call came from a network that has not deployed STIR/SHAKEN signing. The two are handled very differently by downstream policy.
Does verstat mean the same thing as “verified by the carrier”?
Effectively yes. “Verified by the carrier” is the consumer-facing wording for a TN-Validation-Passed result. It means the carrier confirmed the call was signed by a provider vouching for the calling number and that the signature was valid. It does not mean the call is wanted or safe, only that the caller ID is authentic.
Is verstat the same as the attestation level?
No. The attestation level (A, B, or C) is a claim the originating provider makes about how well it knows the caller, stamped at the start of the call. Verstat is the verification result recorded at the terminating end, confirming whether the signature carrying that attestation was cryptographically valid. A call can carry any attestation level and still pass or fail verification independently.
Where is the verstat value set?
It is set by the terminating service provider after its verification service checks the inbound Identity header. In common SBC deployments, the SBC routes the call to a verification service over SIP, receives a pass or fail, and writes the corresponding verstat value into the P-Asserted-Identity before delivering the call.
Conclusion
Verstat is a small field that answers a big question: did this call’s caller ID pass its STIR/SHAKEN check? It carries one of three values, it is written by the terminating network after a real cryptographic verification, and it is distinct from the attestation letter set at origination and from the “Verified Caller” badge the carrier chooses to display. Read in a trace, it is the fastest way to see whether an inbound call was authenticated, failed authentication, or was never signed at all. Acted on in a routing engine, it becomes a live control for how you treat inbound traffic. Understanding how STIR/SHAKEN authentication and verification work end to end is what turns that one parameter from a curiosity in a log into something your network can use.
Read and Act on the Verstat Result with ProSBC
Verstat only becomes useful when something in your network can read it and decide what to do. ProSBC supports both sides of STIR/SHAKEN: the authentication service that signs calls at origination and the verification service that validates them at termination and produces the verstat result. Because ProSBC follows an open partner model, it integrates with third-party verification services such as TransNexus ClearIP and Neustar over the protocol the partner prefers, SIP for those two in production, with HTTPS-based services supported where required.
The part that matters most for verstat is what happens next. ProSBC’s configurable Ruby routing engine can read the verification result on each inbound call and apply policy per call: route verified traffic through, divert failed validations, tag outcomes into call detail records, or combine the verstat result with fraud scoring in a single flow. That per-call flexibility is the difference between knowing a call’s verification status and doing something about it.
Prefer to evaluate on your own first? Start your 30-day free trial.