If your provider says your real estate calls are authenticated but recipients still see a spam warning, do not treat either observation as the whole diagnosis. Collect evidence for the same call at three points: what the originating provider authenticated, what happened to the call, and what the recipient’s phone displayed.
This STIR/SHAKEN troubleshooting guide is for a U.S. team leader investigating a specific warning—not for increasing call volume or bypassing filters. Our speed-to-lead guide raises caller identity as something to examine when fast attempts fail to produce conversations. Here is a proposed way to investigate that question without assuming authentication fixes every problem.
What the authentication result can establish
Twilio describes A-level attestation as the originating provider knowing the caller and the caller’s right to use the displayed number. Twilio’s technical documentation.
Verizon says its blocking analytics incorporate caller ID authentication information, and that verified status does not guarantee a caller’s intent. Verizon’s explanation.
A provider’s authentication statement therefore should not close a labeling complaint by itself. Nor should a warning be used to diagnose the originating provider’s configuration without call-specific evidence.
In a proposal published in June 2025, the FCC described authentication information being stripped when a call path includes non-IP networks. This is background from a proposed rule, not a statement about current implementation deadlines or proof that your call used such a route. FCC proposal, Federal Register.
Keep permission to contact a lead outside this technical diagnosis. Do not use a verification badge as your brokerage’s approval to make a call.
Build a record for one call, not an entire phone number
Start with an existing reported incident, or an agreed test to a team-owned phone. Do not repeatedly call prospects to reproduce a warning. Preserve privacy and use your provider’s secure support channel for necessary call identifiers.
The following is an original diagnostic worksheet, not a list of fields every platform exposes:
| Evidence to retain | Who can supply it | Question it helps answer |
|---|---|---|
| Call identifier, timestamp with time zone, originating and destination numbers | Authorized account operator | Are the provider and recipient discussing the same attempt? |
| Attestation assigned to that attempt, or “unknown” | Originating provider or available account logs | What did the provider actually assert for this call? |
| Call outcome, error information and any forwarding involved | Provider logs plus operator observation | Was the complaint a warning on a ringing call, or a failure to reach the phone? |
| Exact warning text, screenshot, receiving carrier, device and filtering app if known | Consenting test recipient | What appeared, and where? |
| Any receiving-side verification information the provider can establish | Provider investigation | What evidence survives beyond the originating side? |
Do not fill a missing value with “passed” because an account is enrolled in an authentication service. Ask the provider what it can establish for the selected attempt. Keep the screenshot and timestamp together; remove unrelated contacts and notifications before sharing.
Worked example: A-level confirmation does not answer the whole ticket
Consider a hypothetical brokerage test. The provider confirms A-level attestation for a particular outbound call. A team-owned phone rings but displays “Potential Spam.” No receiving-side authentication result is available to the team.
Record three separate conclusions:
- Known: the provider reports A-level attestation for that attempt.
- Observed: that test phone rang with the stated warning.
- Unknown: the receiving-side authentication result and the reason for the warning.
The example does not prove a broken signature, a bad reputation score or an unlawful call. It also does not justify telling the agent the issue is resolved. Those are different questions.
Send a focused request such as:
For call [identifier] at [timestamp and time zone], your team confirmed [attestation result]. The attached test-device screenshot shows [exact label] on [receiving carrier/device]. The phone [rang/did not ring]. Can you confirm what authentication evidence is available for this attempt, investigate the delivery or labeling issue, and identify the appropriate correction channel? Please separate confirmed findings from unavailable information.
This is a proposed support template, not a ticket we submitted or a promised provider capability. If the provider cannot see the receiving-side result, retain that limit rather than inventing one.
Route the finding to the right next step
If the originating provider cannot establish the expected authentication, ask it to investigate the actual number and call configuration. If authentication is confirmed but the complaint remains a warning, keep the labeling question open. If the call did not arrive, ask for a delivery investigation as well; a screenshot of a different successful call cannot resolve that failure.
Verizon directs callers who believe calls were incorrectly blocked or labeled to its Spam Feedback website. Verizon’s legitimate-call guidance. Use the relevant carrier’s own published process; this Verizon channel is not a universal remedy. A submission does not guarantee label removal.
Before buying an add-on or changing numbers, ask which observed problem the proposed change addresses and how you will check the result. After a provider-approved correction, repeat an agreed team-owned test and record the outcome. One clean test is evidence about that test, not a guarantee across all recipients.
For broader operating decisions, see the AI ISA topic library. Keep the investigation record separate from claims about answer rates, appointments or closings.
This AI-assisted guide combines opened primary documentation with a proposed diagnostic workflow. No carrier-account testing was performed, and no Callion feature or legal-compliance claim is made. Callion has a commercial interest in lead-response workflows.