Strict Sender-ID — (destination rule gate)
Qu'est-ce que Strict Sender-ID?
Cette entrée n'est actuellement disponible qu'en anglais.
Strict Sender-ID is an opt-in, tenant-owned toggle that re-checks every outbound alphanumeric sender ID against the destination country's format, prefix, and length rules before the send is submitted. Flipped on, a violating sender fails closed as 422 SENDER_INVALID_FOR_DESTINATION with details.rule naming the offending rule. Flipped off (the default), the same send is accepted and a deliverability advisory rides on the message metadata instead.
More detail
The posture is fail-closed by choice, not by default. In permissive mode a non-conforming sender is accepted and billed at submit, with a sender_deliverability_advisory on the message metadata warning the traffic will likely be filtered or rejected downstream; strict mode turns that advisory into a pre-send 422, so the reject lands in your API response rather than a carrier DLR after wallet spend.
The rule codes strict mode enforces include wrong_length_exact (countries like India mandate an exact character count), restricted_prefix (government/bank reserved prefixes such as India, Turkey, KSA, or UAE restrictions), leading_trailing_space (boundary whitespace carriers reject), and alpha_unsupported_country (destinations whose carriers refuse alphanumeric senders entirely, such as the US and Canada).
Strict Sender-ID gates the sender's format, not the recipient — that makes it distinct from a DNC/DND scrub (which blocks opted-out recipients before dispatch) and from sender-ID registration (which pre-approves the name itself with carriers and regulators before any send attempted). The three controls stack: registration gets the name approved, strict mode keeps the value conforming per destination, and DNC keeps the recipient reachable.
Questions fréquentes
- Is strict Sender-ID the same thing as sender-ID registration?
- No. Sender-ID registration is the carrier-side pre-approval of the name itself before sending — strict Sender-ID re-checks the format of the identifier on each outbound send. With the toggle on, a violating format fails closed as 422 SENDER_INVALID_FOR_DESTINATION before your wallet is charged; with it off (the default), the send passes and a deliverability advisory rides on the message metadata instead.
- What does the rejection tell me about which rule my sender violated?
- The 422 SENDER_INVALID_FOR_DESTINATION rejection carries the violated code in details.rule — for example wrong_length_exact (an exact character count, like India's 6 letters), restricted_prefix (a reserved government/bank prefix), leading_trailing_space (boundary whitespace), or alpha_unsupported_country (a destination with no alphanumeric support at all). Read the rule code out of details.rule before retrying, because a blind retry re-burns the same code.
- How is strict Sender-ID different from a DNC/DND scrub?
- A DNC/DND scrub gates recipients — it blocks opted-out numbers before dispatch. Strict Sender-ID gates the sender's own format — it validates the identifier between recipient checks, so the two controls sit on different sides of the send path and can be used together.
See also
Build it on Orbit
Voice, messaging, email, video, and AI agents on one platform and one pay-as-you-go bill. Start free — no credit card required.