STIR/SHAKEN firma la llamada. No responde por quien llama.

La respuesta corta

El dueño de un negocio oye que "las operadoras resolvieron las llamadas automáticas con STIR/SHAKEN" y luego ve sus propias llamadas marcadas como "Spam Likely" (probable spam). Suele pensar que algo está roto. Casi siempre no lo está: nunca fueron el mismo sistema.

STIR/SHAKEN es un esquema de firma. El proveedor que introduce una llamada en una red de voz IP firma un pequeño token que indica qué número llama, qué número recibe, cuándo, y qué tan seguro está el proveedor de que su cliente puede usar ese número de origen. El proveedor del otro extremo verifica la firma. Eso es todo. El estándar del IETF que define la firma es explícito: "The verification of an Identity header field does not entail any particular treatment of the request." (verificar el encabezado Identity no implica ningún trato particular de la solicitud).1 Lo que ocurra después con la llamada es, en palabras del estándar, un asunto de "local policy" (política local).1

Esa política local es de donde salen "Spam Likely", "Scam Likely" y "Potential Spam". El propio marco SHAKEN describe la función que los aplica como un componente aparte y opcional, el Call Validation Treatment, "for applying call analytics and treatment techniques once the signature is positively or negatively verified" (para aplicar análisis y tratamiento de llamadas una vez que la firma se verifica o no).4

Qué firma realmente STIR/SHAKEN

"STIR" es el grupo de trabajo del IETF y sus estándares; "SHAKEN" es el perfil de la industria norteamericana de esos estándares, publicado conjuntamente por ATIS y el SIP Forum. Cuatro documentos hacen el trabajo:

• RFC 8225, PASSporT (febrero de 2018) define un token firmado que "cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator" (verifica criptográficamente una identidad de origen o, en general, un URI o número telefónico que representa al originador).2 Todo PASSporT debe llevar un campo "orig", un campo "dest" y una hora "iat" (de emisión).2
• RFC 8224, SIP Identity (febrero de 2018) define cómo viaja ese token en un encabezado SIP Identity y cómo lo verifica la red receptora. Existe porque, sin él, "the recipient of a SIP request has no way to verify that the From header field has been populated appropriately" (el receptor de una solicitud SIP no tiene forma de verificar que el campo From se haya llenado correctamente).1
• RFC 8588 (mayo de 2019) agrega los dos campos que hacen al token "SHAKEN": un nivel de atestación y un identificador de origen, "a unique origination identifier ... to support a traceback mechanism" (un identificador único de origen para apoyar un mecanismo de rastreo).3
• ATIS-1000074.v003, el estándar SHAKEN en sí (aprobado el 16 de agosto de 2022), define los niveles de atestación, los roles de los certificados, el procedimiento de verificación y lo que la red receptora le indica al teléfono.4

Este es el ejemplo de carga útil de un token SHAKEN del propio RFC 8588, sin cambios (las dos comas que faltan son del RFC):3

{
   "attest":"A"
   "dest":{"tn":["12155550131"]}
   "iat":"1443208345",
   "orig":{"tn":"12155550121"},
   "origid":"123e4567-e89b-12d3-a456-426655440000"
}

Fíjese en lo que no está: ni el nombre de la empresa, ni el motivo de la llamada, ni nada sobre consentimiento, volumen o intención. El RFC 8224 es explícito en que la verificación abarca el número del encabezado From y "does not cover the display-name portion of the From header field (e.g., "Alice Atlanta")" (no abarca la parte del nombre visible del encabezado From).1 El nombre que ve su cliente viene de otro sistema distinto (más abajo).

Las firmas también duran poco: el RFC 8224 hace que el verificador compare el encabezado Date con una ventana de vigencia, "sixty seconds is RECOMMENDED" (se recomienda sesenta segundos),1 lo que limita que alguien reutilice más tarde un token capturado.

Cuando la verificación tiene éxito, la red receptora lo comunica al teléfono con un parámetro verstat en el número de origen. ATIS-1000074 indica que el valor "TN-Validation-Passed" se envía solo si la verificación pasa y, o bien la atestación era "A", o bien el nivel de atestación también se pasa al dispositivo; para B o C, la red envía "No-TN-Validation" u omite el parámetro, "based on local policy" (según la política local).4 Así que la marca de verificación o la etiqueta "Verified" que muestran algunos teléfonos es, por diseño, la presentación de un resultado de verificación, en el caso normal de una llamada con nivel A. No dice nada sobre quién llama más allá del número, ni por qué llama.

Los niveles de atestación A, B y C, y qué significa cada uno

El nivel de atestación es la declaración del firmante sobre lo que sabe. El RFC 8588 define los valores "'A', 'B', or 'C'", que corresponden a "'Full Attestation', 'Partial Attestation', and 'Gateway Attestation', respectively" (atestación completa, parcial y de pasarela), y remite a ATIS para las definiciones.3 Estas son las definiciones, citadas de ATIS-1000074.v003:4

Desplace la tabla hacia los lados para ver todas las columnas.

Dos notas del estándar importan más que la tabla. Cómo establece un proveedor la "verified association" (asociación verificada) queda a su criterio: ATIS da ejemplos, como que el proveedor "has ascertained that the customer is authorized to use a TN (e.g., by business agreement or evidence the customer has access to use the number)" (ha comprobado que el cliente está autorizado a usar un número, por ejemplo, mediante un acuerdo comercial o evidencia de que tiene acceso al número), y luego dice "Ultimately it is up to service provider policy" (en última instancia depende de la política del proveedor).4 Y B significa que el firmante "can trace the origination of the call to a customer" (puede rastrear el origen de la llamada hasta un cliente).4 B es una promesa de trazabilidad, no una acusación.

Cuánto vale una "A" en la práctica

La propuesta de la FCC de julio de 2026 para endurecer las reglas de atestación es el documento público más franco sobre este tema. Al afirmar A, dice, "the provider is claiming that is has knowledge that the number has not been spoofed" (el proveedor afirma saber que el número no ha sido falsificado).22 Luego presenta evidencia de que la A se otorga con demasiada liberalidad:22

• La FCC "found that Lingo Telecom applied A-level attestations to 3,978 spoofed robocalls" (encontró que Lingo Telecom aplicó atestaciones nivel A a 3,978 llamadas automáticas falsificadas) con una voz falsa del entonces presidente.
• "93.4% of robocall traffic from the most prolific robocall signers now carry A-level attestations" (el 93.4 % del tráfico de llamadas automáticas de los firmantes más prolíficos lleva atestación A) y "48 percent of illegal calls are A-attested" (datos que la FCC cita del expediente).
• De "12,900 calls that illegally spoofed telephone numbers belonging to 47 large banks, retailers, and healthcare providers" (12,900 llamadas que falsificaron ilegalmente números de 47 grandes bancos, comercios y proveedores de salud), un análisis de la American Bankers Association encontró que "more than half of the calls received an A-level or B-level attestation" (más de la mitad recibió atestación A o B).
• Transaction Network Services informó que en el primer semestre de 2025, "certain top tier carriers had marked around 8% of their invalid number calls with A-level attestation, and non-top tier carriers had marked 57%" (ciertas operadoras de primer nivel marcaron con A alrededor del 8 % de sus llamadas de números inválidos, y las de menor nivel el 57 %).

Son cifras de terceros que cita la FCC, no mediciones de la FCC. Pero explican por qué un motor de análisis no puede tratar una A como un pase, y la FCC lo dice: "Because voice service providers also use attestations to inform call analytics engines, improper attestations can undermine their effectiveness, contributing to inaccurate blocking and labeling determinations." (Como los proveedores también usan las atestaciones para alimentar los motores de análisis, las atestaciones indebidas pueden minar su eficacia y causar bloqueos y etiquetados erróneos.)22 En el mismo aviso pregunta si, una vez que la atestación sea confiable, se debería "prohibit blocking or spam labeling of calls with A-level attestations" (prohibir el bloqueo o el etiquetado como spam de llamadas con atestación A).22 Esa pregunta es la confirmación oficial más clara de que hoy una llamada con atestación A puede bloquearse o etiquetarse legalmente.

Nuestra opinión: la atestación es una higiene necesaria y está muy lejos de ser suficiente. Una empresa que recibe B o C tiene un problema corregible con su proveedor; una empresa que recibe A y aun así es etiquetada tiene un problema de reputación, que se resuelve hablando con otras personas.

Las reglas de EE. UU.: lo que exige la FCC, sección por sección

La ley. La Pallone-Thune TRACED Act (Pub. L. 116-105, promulgada el 30 de diciembre de 2019) ordenó a la FCC exigir STIR/SHAKEN "in the internet protocol networks" (en las redes de protocolo de internet) de los proveedores de voz en un plazo de 18 meses, y "reasonable measures to implement an effective call authentication framework in the non-internet protocol networks" (medidas razonables para implementar un marco eficaz de autenticación en las redes que no son IP).7 También exigió prohibir cargos en la factura por esta tecnología y "a process to permit a calling party adversely affected by the information provided by the call authentication frameworks ... to verify the authenticity of the calling party's calls" (un proceso para que quien llama y resulte perjudicado por la información de los marcos de autenticación pueda verificar la autenticidad de sus llamadas).7 Esa última cláusula es la raíz legal de los derechos de reparación que veremos más abajo.

Los reglamentos están en 47 CFR Parte 64, Subparte HH, §§ 64.6300 a 64.6308. El texto vigente, leído en eCFR para esta página:

Desplace la tabla hacia los lados para ver todas las columnas.

El propio resumen de la FCC: "Because the STIR/SHAKEN framework is only operational in IP networks, Commission rules also require providers using older forms of network technology to either upgrade their networks to IP or actively work to develop a caller ID authentication solution that is operational in non-IP networks." (Como STIR/SHAKEN solo funciona en redes IP, las reglas de la Comisión también exigen que los proveedores con tecnologías más antiguas actualicen sus redes a IP o trabajen activamente en una solución de autenticación que funcione en redes no IP.)17

La brecha de las redes no IP es real y, según una medición, crece

Una llamada que cruza un tramo TDM (conmutación de circuitos) pierde su firma. El aviso de la FCC de 2026 cita estadísticas de TransNexus según las cuales "the percentage of calls terminating in the United States that are signed with STIR/SHAKEN dropped from 49% in October 2024 to 38% in September 2025" (el porcentaje de llamadas que terminan en EE. UU. firmadas con STIR/SHAKEN bajó del 49 % en octubre de 2024 al 38 % en septiembre de 2025), atribuido "at least in part, to the routing of calls over non-IP segments" (al menos en parte, al enrutamiento por tramos no IP), y recoge la afirmación de ACA International de que "scam calls are deliberately routed through TDM interconnections for the purpose of stripping out STIR/SHAKEN information" (las llamadas fraudulentas se enrutan deliberadamente por interconexiones TDM para eliminar la información STIR/SHAKEN).22

En junio de 2025 la FCC propuso eliminar la opción del grupo de trabajo: exigir que "all providers using non-IP technology in their networks implement one or more non-IP caller ID authentication frameworks within two years" (todos los proveedores con tecnología no IP implementen uno o más marcos de autenticación no IP en dos años), proponiendo que la autenticación en banda (ATIS-1000095) y fuera de banda (ATIS-1000096) estén "developed and reasonably available" (desarrolladas y razonablemente disponibles).19 A la fecha de esta página no encontramos una regla final que adopte esa propuesta en el Federal Register, y el texto de eCFR del § 64.6303 todavía contiene la alternativa del grupo de trabajo.11 Tome con cautela cualquier resumen que diga que la autenticación no IP ya es obligatoria: se adelanta a la ley.

El Robocall Mitigation Database se está vigilando, y se nota

Las reglas en vigor desde el 5 de febrero de 2026 fijan "a base forfeiture of $10,000 for each violation for filers that submit false or inaccurate information to the Database, as well as a base forfeiture of $1,000 for failure to update information that has changed in the Database within 10 days" (una multa base de $10,000 por infracción a quienes presenten información falsa o inexacta, y de $1,000 por no actualizar en 10 días la información que cambió).21 Una propuesta de septiembre de 2026 registra "over 11,000 filings" (más de 11,000 registros), "over 1,400 deficient filings" (más de 1,400 registros deficientes) eliminados desde enero de 2025 y, lo más revelador para quien supone que su proveedor firma las llamadas, que "6,689 RMD filings indicate full or partial implementation of STIR/SHAKEN, but that only 2,143 providers appear on the Governance Authority's list of authorized providers." (6,689 registros indican implementación total o parcial de STIR/SHAKEN, pero solo 2,143 proveedores aparecen en la lista de proveedores autorizados de la Governance Authority.)23

Si su proveedor es dado de baja, otros pueden dejar de aceptar su tráfico directamente.13 La base de datos es pública: la página de la FCC sobre ella (ahora archivada) dice "you may search the database for filings or download a .CSV file of all filings" (puede buscar registros o descargar un archivo .CSV con todos).34

Falsificar su propio número no es la infracción

La regla Truth in Caller ID prohíbe transmitir "misleading or inaccurate caller identification information" (información de identificación engañosa o inexacta) solo cuando se hace "with the intent to defraud, cause harm, or wrongfully obtain anything of value" (con la intención de defraudar, causar daño u obtener indebidamente algo de valor).16 Mostrar su propio número comercial en llamadas hechas desde un celular o un marcador en la nube es legal. Mecánicamente también es lo que hace un falsificador, y por eso, según los criterios de ATIS, el proveedor de origen solo puede darle A cuando ha verificado que el número es suyo.4

Canadá: el mandato del CRTC y en qué se diferencia

El CRTC hizo obligatorio STIR/SHAKEN mediante la Compliance and Enforcement and Telecom Decision CRTC 2021-123 (6 de abril de 2021). Convirtió STIR/SHAKEN para las llamadas de voz sobre IP en "a condition of offering and providing telecommunications services, effective 30 November 2021" (una condición para ofrecer y prestar servicios de telecomunicaciones, en vigor desde el 30 de noviembre de 2021), conforme a los artículos 24 y 24.1 de la Telecommunications Act; la Canadian Secure Token Governance Authority (CST-GA) selecciona al administrador de políticas y a la autoridad certificadora.24

Conviene conocer tres diferencias con EE. UU.:

• Sin excepción para proveedores pequeños. El CRTC razonó que "Excluding some TSPs from the obligation to implement STIR/SHAKEN, or delaying their obligation to implement it, would undermine the effectiveness of the system" (excluir a algunos proveedores de la obligación, o retrasarla, minaría la eficacia del sistema).24 EE. UU., en cambio, dio a los proveedores de 100,000 líneas o menos una prórroga hasta el 30 de junio de 2023.12
• Solo llamadas IP, por diseño. La obligación "applies to calls that travel over a TSP's IP-based network, including any portion of its network that is able to initiate, transit, or terminate IP-based calls" (se aplica a las llamadas que viajan por la red IP de un proveedor, incluida cualquier parte de su red capaz de iniciar, transitar o terminar llamadas IP), y el CRTC se negó a limitarla a llamadas IP de extremo a extremo.24
• El acceso a los certificados fue disputado. En 2021, las reglas de CST-GA implicaban que "a TSP must have access to numbering resources in order to receive a certificate" (un proveedor debe tener acceso a recursos de numeración para recibir un certificado).24 La plantilla de informes del CRTC de 2024 menciona una determinación posterior (CETD 2021-267) tras la cual más proveedores obtuvieron certificados, y permite que un proveedor diga que está "Satisfied with having calls originating from our network attested and signed downstream (e.g. by the underlying LEC)" (satisfecho con que las llamadas originadas en su red se atesten y firmen más adelante, por ejemplo, por la LEC subyacente).25

En diciembre de 2025 el CRTC puso fin a los informes semestrales de estado para la mayoría de los proveedores, al concluir que "on average, TSPs employ STIR/SHAKEN successfully to authenticate the vast majority of their IP-based voice calls" (en promedio, los proveedores usan STIR/SHAKEN con éxito para autenticar la gran mayoría de sus llamadas de voz IP).26 El informe simplificado que queda sigue preguntando si un proveedor da "A level attestation or B level attestation to non-IP switched customers" (atestación A o B a clientes conmutados no IP) conforme a las Directrices STIR/SHAKEN de la industria y si envía el parámetro verstat a los usuarios finales.26 Así que en Canadá, como en EE. UU., que el teléfono de su cliente muestre algún indicador de verificación es una decisión del proveedor.

En los documentos del CRTC que leímos no encontramos un equivalente canadiense del Robocall Mitigation Database público ni de la regla de reparación de la FCC, ni un portal oficial de registro canadiense; el Free Caller Registry pide "10-digit US phone numbers" (números telefónicos de 10 dígitos de EE. UU.).27 Las empresas canadienses deben preguntar a su proveedor cómo disputar una etiqueta.

La reputación es un sistema aparte y opaco

El etiquetado y el bloqueo ocurren en el lado receptor: la operadora de la persona a la que usted llamó, su proveedor de análisis y, a veces, una aplicación o el fabricante del teléfono. El fundamento legal en EE. UU. es 47 CFR § 64.1200(k)(3), que permite a un proveedor receptor bloquear "without liability" (sin responsabilidad) con base en "reasonable analytics designed to identify unwanted calls" (análisis razonables diseñados para identificar llamadas no deseadas) que "include consideration of caller ID authentication information where available" (incluyen la consideración de la información de autenticación cuando esté disponible), aplicados "in a non-discriminatory, competitively neutral manner" (de forma no discriminatoria y competitivamente neutral), con la opción del consumidor de excluirse.15

Léalo con atención. La autenticación es un dato que el análisis debe "consider" (considerar). La regla no dice cuánto peso tiene, y nada obliga al proveedor ni a su proveedor de análisis a publicar el modelo. La regla incluso permite que un proveedor "rely on Caller ID information to determine the purported originating number without regard to whether the call, in fact originated from that number" (se base en la información de identificación para determinar el supuesto número de origen sin importar si la llamada realmente se originó en ese número).15

Hiya, una de las tres empresas detrás del Free Caller Registry, describe los datos de entrada: "Carriers use spam detection systems that analyze call patterns and customer behavior. Even legitimate businesses can be flagged if recipients frequently ignore or block calls, or if the calls are perceived as disruptive." (Las operadoras usan sistemas de detección de spam que analizan patrones de llamadas y el comportamiento de los clientes. Incluso empresas legítimas pueden ser marcadas si los destinatarios ignoran o bloquean las llamadas con frecuencia, o si se perciben como molestas.)28 Y sobre si registrarse evita las etiquetas: "Registration reduces the risk of spam or nuisance labels, but it doesn't completely prevent them. Carriers also consider how customers respond to your calls — if many people report or block your number, it can still be flagged." (El registro reduce el riesgo de etiquetas de spam o molestia, pero no las evita por completo. Las operadoras también consideran cómo responden los clientes a sus llamadas; si muchas personas reportan o bloquean su número, aún puede ser marcado.)28

Las operadoras son igual de cautelosas. Verizon dice que "automatically blocks in the network calls that we have determined are highly likely to be illegal based on reasonable analytics that incorporate caller ID authentication information" (bloquea automáticamente en la red las llamadas que ha determinado que muy probablemente son ilegales con base en análisis razonables que incorporan la información de autenticación), y usa STIR/SHAKEN para actualizar el algoritmo de su Call Filter, que "may, in some cases, reduce the chances of incorrectly blocking or identifying a 'good' call as 'Potential Spam.'" (puede, en algunos casos, reducir la posibilidad de bloquear o identificar por error como "Potential Spam" una llamada buena).30 "May, in some cases" (puede, en algunos casos) es lo más firme que dice una operadora en su documentación pública.

Nuestra opinión: esta opacidad es en parte defendible (publicar los umbrales enseñaría a los emisores de llamadas automáticas a quedarse justo por debajo) y en parte una falla del mercado, porque la empresa perjudicada por un falso positivo no tiene forma de ver la evidencia en su contra. La ley lo anticipó, y por eso existe el proceso de reparación que veremos abajo.

El nombre en la pantalla es un tercer sistema

Las quejas por "Spam Likely" suelen venir con una segunda: el nombre de la empresa es incorrecto, o no aparece. Eso es CNAM (nombre de quien llama) y no forma parte de SHAKEN en absoluto. Como vimos, la verificación del RFC 8224 "does not cover the display-name portion of the From header field".1 El Free Caller Registry explica la separación desde el otro lado: "neither call protection providers nor their carrier partners use Registration Data to deliver Caller ID Name." (ni los proveedores de protección de llamadas ni sus operadoras asociadas usan los datos de registro para entregar el nombre de quien llama.)27 Hiya dice igualmente que su registro gratuito "does not create a name or logo to appear on your outbound calls" (no crea un nombre o logotipo que aparezca en sus llamadas salientes).28

Un nombre firmado viene en camino, lentamente. El RFC 9795 (julio de 2025) amplía PASSporT para llevar "rich metadata about a call and caller that can be signed and integrity protected" (metadatos enriquecidos sobre la llamada y quien llama, que pueden firmarse y protegerse en su integridad), yendo "beyond human-readable display name" (más allá del nombre legible).6 En diciembre de 2025 la FCC propuso "requiring terminating providers to transmit verified caller name or other caller identity information for presentation on a consumer's handset whenever they transmit an indication that a call has received an A-level attestation" (exigir que los proveedores receptores transmitan el nombre verificado u otra información de identidad para mostrarla en el teléfono del consumidor siempre que indiquen que una llamada recibió atestación A).20 Su razón respalda directamente la tesis de esta página: "consumers might mistakenly believe that a checkmark or other indication that a call received an A-level attestation is an assurance that a call is not a scam or otherwise unlawful." (los consumidores podrían creer por error que una marca de verificación u otra indicación de atestación A es una garantía de que la llamada no es una estafa ni es ilegal.)20 Es una propuesta, no una regla; el periodo de comentarios cerró a principios de 2026.20

Cómo se ven las llamadas reenviadas

Muchas pequeñas empresas hacen pocas llamadas; las reciben y las reenvían al celular de alguien. El reenvío rompe una verificación SHAKEN ingenua: la firma cubre el número de destino, así que cuando una llamada a su número comercial se redirige al celular de un empleado, el "dest" del token ya no coincide. El RFC 8946 (febrero de 2021) se escribió para este caso, y señala que "the original called party number is not always the number to which a call is delivered" (el número original llamado no siempre es el número al que se entrega la llamada) y que los encabezados de reenvío existentes no "provide any cryptographic assurance of secure redirection" (dan ninguna garantía criptográfica de una redirección segura).5 Agrega un PASSporT "div" para que el proveedor que reenvía pueda firmar el desvío.5

Donde no se admite esa firma del desvío, ATIS-1000074 le dice al verificador receptor qué hacer: "If the canonicalized value of the Request-URI TN does not match the canonicalized value of the TN in the To header field, then the verifier shall skip verification, and treat this event as if no Identity header was received" (si el valor canónico del número del Request-URI no coincide con el del encabezado To, el verificador omitirá la verificación y tratará el caso como si no se hubiera recibido encabezado Identity).4 Un proveedor que reenvía y recibe una llamada sin encabezado Identity debe "perform authentication and add a SIP Identity header field" (realizar la autenticación y agregar un encabezado SIP Identity).4

En conjunto, una llamada comercial reenviada llega al celular de una de tres formas:

1. El número de quien llama, con la firma original transmitida. Si la plataforma que reenvía pasa el encabezado Identity original y el desvío está firmado, la operadora del celular puede verificar a quien llamó originalmente. La documentación para desarrolladores de Twilio, como un ejemplo documentado, dice que las llamadas reenviadas con su verbo <Dial> "can use the original caller ID by default" (pueden usar de forma predeterminada el identificador original), y que las llamadas reenviadas con su API de llamadas necesitan el CallToken de la llamada entrante, que "contains any SHAKEN/STIR and DIV" headers de la llamada entrante, para conservar el identificador y "facilitate SHAKEN/STIR verification" (facilitar la verificación SHAKEN/STIR).33
2. El número de quien llama, sin verificar. Si la firma se pierde, o el verificador la omite por la discrepancia de números, el celular ve el identificador original sin verificación. La etiqueta, si la hay, refleja la reputación del número de quien llama en el análisis de la operadora del celular.
3. Su número comercial (o el de la plataforma), como llamada nueva. Algunos servicios presentan su propio número para que el personal sepa que es una llamada del negocio. Es un origen nuevo, firmado (si acaso) por el proveedor de la plataforma, y la operadora del celular juzga la reputación del número presentado, no la de quien llamó.

La consecuencia que sorprende a la gente: en las formas 1 y 2, un "Spam Likely" en una llamada reenviada es un juicio sobre el número de su cliente, y nada de lo que registre para su propio número lo cambiará. Un cliente que llama desde un número con mala reputación (un celular reciclado, el conmutador de un hospital, una troncal de call center) puede ser etiquetado en los teléfonos de su personal y quedar sin respuesta. La forma 3 cambia ese riesgo por otro: cada llamada reenviada lleva ahora la reputación de un solo número. Esperaríamos que un número de reenvío muy activo parezca un emisor de alto volumen, aunque ningún proveedor documenta cómo lo trata.

No hay una forma universalmente correcta. Si reenvía llamadas, haga la prueba: llame a su línea comercial desde celulares de distintas operadoras y anote qué muestra el teléfono de cada empleado. Nuestro artículo sobre cómo probar llamadas reenviadas, identificador de llamadas y buzón de voz (en inglés) da un método paso a paso. Por transparencia: autoattendant.io vende un servicio construido justo sobre este patrón, un número comercial entrante reenviado a celulares comunes, y usa la forma 3: una llamada reenviada muestra el número de la línea comercial en el teléfono del integrante del equipo, no el de quien llama. Con cualquier proveedor, haga la prueba anterior en los teléfonos de su propio personal, incluido el nuestro.

Lo que una pequeña empresa sí puede hacer

Aproximadamente de mayor a menor influencia:

1. Asegúrese de que sus llamadas salientes puedan obtener una A. Pregunte por escrito a su proveedor qué atestación reciben sus llamadas y por qué. Si presenta un número que su proveedor no emitió (por ejemplo, su línea principal, en manos de otra operadora, mostrada en llamadas desde un marcador), los criterios de ATIS dan B salvo que el proveedor haya "ascertained that the customer is authorized to use a TN" (comprobado que el cliente está autorizado a usar el número).4 Pregunte cómo puede demostrarlo. Según las reglas de 2025, si un tercero firma por su proveedor, este debe seguir tomando "all attestation-level decisions" (todas las decisiones sobre el nivel de atestación).9
2. Verifique que su proveedor esté en el Robocall Mitigation Database y no haya sido eliminado. Cualquiera puede consultarlo,34 y el tráfico de un proveedor dado de baja puede no ser aceptado directamente por otros.13
3. Presente un número consistente por propósito, el que los clientes tienen guardado y al que devuelven la llamada. Rotar números es lo que hacen los emisores de llamadas automáticas, y los proveedores dicen que puntúan el comportamiento.28
4. Registre sus números, gratis. El Free Caller Registry, operado por First Orion, Hiya y TNS, pide datos de la empresa, el "call purpose" (propósito de las llamadas) y las "outbound calls per month" (llamadas salientes al mes), acepta solo números de EE. UU. y dice sin rodeos que "does not guarantee redress" (no garantiza reparación).27 El Number Registration de Hiya también es gratuito; Hiya dice que la verificación suele tardar unas 24 horas y que los cambios tardan luego "a few additional days" (algunos días más) en propagarse.28 Ninguno define el nombre que se muestra.2728
5. Observe cómo responden los destinatarios. Hiya dice que se marca a empresas legítimas "if recipients frequently ignore or block calls" (si los destinatarios ignoran o bloquean las llamadas con frecuencia).28 Llame a personas que lo esperan y deje mensajes de voz que lo identifiquen.
6. Dispute una etiqueta directamente con la operadora donde aparece. El formulario de comentarios de Verizon dice que los comentarios "will be shared with our third party spam analytics provider" (se compartirán con nuestro proveedor externo de análisis de spam) y advierte "you should not assume the calls will no longer be blocked or labeled" (no debe suponer que las llamadas dejarán de bloquearse o etiquetarse).29 TNS tiene un sitio de comentarios con opciones como "My business number was blocked" (mi número comercial fue bloqueado) y "My business number was mislabeled as spam" (mi número comercial fue etiquetado erróneamente como spam).31 El equivalente de T-Mobile se titula "Report Improperly Identified Calls" (reportar llamadas identificadas incorrectamente).32 Conserve fechas, horas y números llamados.
7. Use la regla legal de reparación si una operadora se demora. Todo proveedor receptor que bloquea llamadas "or utilizes caller ID authentication information in determining how to deliver calls" (o usa información de autenticación para decidir cómo entregarlas) debe publicar "a single point of contact" (un punto de contacto único), "provide a status update within 24 hours" (dar una actualización de estado en 24 horas) y, si concluye que el trato fue erróneo, "promptly cease the call treatment for that number" (cesar sin demora el trato a las llamadas de ese número), sin cobrar a quien llama.15 No se aclara si una etiqueta por sí sola cuenta como "call treatment" (trato de la llamada); citar la sección no cuesta nada.
8. Para las llamadas que usted recibe, pida la lista de llamadas bloqueadas. Un proveedor receptor que bloquea bajo un programa de análisis opt-in u opt-out debe entregar al suscriptor, gratis y "within 3 business days" (en 3 días hábiles), una lista de las llamadas bloqueadas a ese número "within the 28 days prior to the request" (en los 28 días previos a la solicitud).15 Si los clientes dicen que llamaron y usted nunca lo vio, así se entera.
9. No pague por la autenticación en sí. Un proveedor no puede agregar un cargo en la factura a un suscriptor de pequeña empresa por la tecnología de autenticación de llamadas.14 Los productos de pago de llamadas con marca y de monitoreo de reputación son un mercado aparte y opcional.

Los artículos extensos profundizan en el diagnóstico (en inglés): why a business number shows Spam Likely recorre las pruebas en cada operadora, why a business number shows up as spam reúne los portales de corrección y la evidencia que conviene juntar, y stopping spam calls to your business cubre el lado de las llamadas entrantes.

Qué está cambiando y qué esperamos

Cuatro procedimientos abiertos de la FCC podrían cambiar las respuestas de esta página:

• Reglas de atestación. El aviso de julio de 2026 propone "codifying attestation levels, defining improper attestations" (codificar los niveles de atestación y definir las atestaciones indebidas) y reglas para verificar la asociación entre número y cliente. La FCC dice que no cree que una asociación de número "can be established by a business agreement or certification that includes only a general statement" (pueda establecerse mediante un acuerdo comercial o certificación que solo incluya una declaración general) de que el cliente usará únicamente números a los que tiene derecho, lo que llama "essentially the mechanism that Lingo Telecom used" (esencialmente el mecanismo que usó Lingo Telecom).22 Los comentarios vencían el 10 de agosto de 2026 y las réplicas el 8 de septiembre de 2026.22
• Nombre verificado de quien llama. La propuesta de diciembre de 2025 de acompañar todo indicador de nivel A con un nombre verificado, posiblemente mediante Rich Call Data.20
• Autenticación no IP. La propuesta de junio de 2025 de exigir marcos no IP en dos años.19
• Revisión del Robocall Mitigation Database. La propuesta de septiembre de 2026 sobre quién debe registrarse, la revisión de nuevos registrantes y la eliminación acelerada; comentarios hasta el 9 de octubre de 2026, réplicas hasta el 9 de noviembre de 2026.23

Nuestra opinión, que es un pronóstico y no un hallazgo: la dirección es hacer que A signifique algo más cercano a "conocemos a este cliente y a este número", y adjuntarle un nombre verificado. Eso ayuda a las empresas cuyo proveedor las verifica bien. No hará transparente el etiquetado: ninguna de estas propuestas obliga a los proveedores de análisis a publicar su puntuación. Incluso la pregunta de la FCC sobre prohibir etiquetas en llamadas con atestación A está condicionada a que primero las atestaciones sean confiables.22 En el futuro previsible, una empresa necesita tanto una firma limpia como un patrón de llamadas limpio, y debe esperar manejar lo segundo a través de los portales de los propios proveedores.

Lo que no pudimos verificar

• Qué proveedor de análisis atiende hoy a cada operadora. Las páginas de las operadoras que leímos hablan de un "third party spam analytics provider" (proveedor externo de análisis de spam) sin nombre29; los anuncios de alianzas de proveedores que encontramos tenían años. Dejamos fuera la correspondencia en lugar de repetirla de sitios secundarios.
• Los umbrales de etiquetado. Ningún proveedor los publica; vea arriba.
• Un portal de registro canadiense y una regla de reparación canadiense. No los encontramos en los documentos del CRTC que leímos; lo decimos en lugar de suponerlos.
• La pantalla del teléfono. Qué teléfonos muestran una marca de verificación, "Verified" o nada varía según la operadora, el sistema operativo y el modelo, y cambia con las actualizaciones de software. ATIS fija solo lo que envía la red (verstat), no lo que muestra la pantalla.4
• Las estadísticas de atestación citadas provienen de partes de un procedimiento de la FCC y se reproducen en el aviso de la FCC; no pudimos auditarlas de forma independiente.22

Las páginas del CRTC se leyeron mediante copias de Internet Archive, porque crtc.gc.ca bloquea a los lectores automáticos. Cada reglamento está enlazado en las fuentes para que pueda consultar el texto vigente.