Why a call shows as spam likely

The number on your screen is information the calling side supplies. US rules on misleading caller ID turn on the intent behind it ¹. That matters for labels, because showing a different number is not by itself proof of bad intent, and a label cannot read intent from a number.

Phone companies therefore look for ways to check the number cryptographically and, where they cannot, to judge the traffic around it.

STIR is the IETF framework for signing caller identity. RFC 8224 defines a SIP Identity header that carries a signature, so that a receiving service can check that the sender has been authenticated and that its claim of a particular identity has been authorized ². The signed content is a PASSporT token, which RFC 8225 describes as a method for creating and validating a token that cryptographically verifies an originating identity ³. RFC 8226 adds certificates that assert authority over telephone numbers ⁴.

SHAKEN is the profile that puts this into practice, and it adds an attestation level that says how much the signing provider knows about the call. RFC 8588 defines three: full, when the provider can fully attest to the calling identity; partial, when the provider originated the call but cannot fully attest to the identity; and gateway, the lowest level, when the provider received the call from a gateway that does not support these tokens ⁵. The values are written A, B and C ⁵.

In the United States, 47 CFR 64.6301 requires a voice service provider to authenticate caller identification information for the SIP calls it originates and, where technically feasible, pass that information on, and it makes the provider responsible for the attestation-level decisions ⁶. Two limits follow from the standards themselves. A signature covers calls that travel over SIP, and the specifications leave open what a receiver should do after validation ². So an attestation is an input to a decision, not the decision.

Where authentication is missing or inconclusive, labels rest on analytics. The FCC rule that lets terminating providers block on this basis describes the analytics as reasonable analytics designed to identify unwanted calls, and it requires that a consumer can turn blocking off ⁷. The same rule makes a provider offer a single point of contact for call blocking error complaints, and says the provider must promptly cease the call treatment for a number when a caller makes a credible claim of erroneous blocking ⁷. Rules that include a way to correct mistakes exist because mistakes happen.

The other common input is reports from people. Those are unverified by nature: a person who received a call decides it was unwanted and says so. Our product is built on that kind of data and nothing else, which the next section describes.

The phone-spam product looks up a number in public complaint data: FCC consumer complaints and, when the dataset carries them, FTC Do Not Call reported calls. It does not read any carrier label, any attestation result or any call analytics, so it cannot tell you what a given phone company will display. Datasets hold per-number totals, not individual reports.

The answer contains the E.164 number, the total complaints, the first and last reported dates, the distinct issue types with the most serious first, which sources were used, a score from 0 to 100, a risk level and the score breakdown. The score adds three parts. Volume is up to 50 points and grows with the log of the complaint count, reaching its maximum at 100 complaints. Recency is up to 30 points and halves every 90 days since the newest complaint. Issue type is up to 20 points, full for scam, fraud, robocall, spoofing and similar words, 60 percent for telemarketing and unwanted contact, 30 percent for anything else. Risk is none at 0, low from 1 to 24, medium from 25 to 49 and high from 50 up.

1curl -X POST https://YOUR_API_HOST/v1/phone-spam \
2  -H "Authorization: Bearer $LOOKVALID_API_KEY" \
3  -H "Content-Type: application/json" \
4  -d '{"phone":"+12025550143"}'

1{
2  "phone_e164": "+12025550143",
3  "complaints_total": 2,
4  "first_reported": "2017-03-23",
5  "last_reported": "2017-03-23",
6  "issue_types": ["prerecorded voice", "unwanted calls"],
7  "spam_score": 32,
8  "risk_level": "medium"
9}

A number nobody reported comes back as not_found with a reason, and the reason says that an unreported number is not proof it is safe. If the complaint data is missing or older than 14 days, the answer is unavailable rather than a guess. A cached answer keeps the score it had when it was computed, so the recency part can lag.

The table below lists what each signal tells you and what limits it.

• Treat a high score as a reason to look closer, not as proof about the person or company calling.
• Treat no complaints as no information, because new numbers and quiet campaigns have no reports yet.
• Remember that a spoofed number can carry complaints that belong to whoever actually dialed.
• Combine the score with other checks such as the phone number validator, and read layered checks against fake signups for how to weigh several signals.

1. Normalize the number to E.164.
2. Call phone-spam and read complaints_total, last_reported and issue_types alongside spam_score.
3. Decide with other evidence, and treat unavailable as try again later.

To check one number by hand, try the free who called me tool, or see the API reference for phone spam.