Sinch Community

The Sinch 10DLC Onboarding Guide and NA 10DLC Onboarding and Migration Guide (see below) provide a comprehensive overview of the requirements and workflows for launching A2P (Application-to-Person) 10DLC messaging campaigns in North America. Designed to establish verified sender identity and reduce spam, the onboarding framework walks businesses through brand verification, campaign registration for specific messaging use cases, and number provisioning via purchasing, porting, importing, or hosting. The onboarding resources break down the end-to-end process across eight key areas: Getting started: Overview of 10DLC messaging, benefits, timelines, and general launch expectations. Key players: Roles of The Campaign Registry (TCR), mobile network operators, DCAs, and brands in the ecosystem. 10DLC brand registration paths: Registration options for creating new brand profiles or importing existing brands. Campaign creation: Guidelines for declaring messaging use cases and submitting compliant campaign details. Rules and regulations: Core compliance standards, mandatory disclosures, and opt-in/opt-out requirements. Getting a 10DLC phone number: Options for acquiring numbers through direct purchasing, importing, hosting, or porting. Understanding throughput: Explanation of carrier throughput limits, transaction-per-minute allocations, and daily message caps. Existing 10DLC brand and campaign migration: Decision tree and workflows for migrating active brands and campaigns to Sinch. Together, these resources outline and emphasize essential compliance standards. To preserve deliverability and prevent carrier filtering, brands must maintain auditable opt-in consent, incorporate explicit program disclosures and keyword handlers, and strictly adhere to guidelines regarding privacy data protection and prohibited content categories. ... View more

Before you launch your 10DLC message program, Sinch must review your campaign. We make sure your message program aligns with carrier and industry requirements. Principally we look for alignment with the CTIA Messaging Principals & Best Practices.     Here are the top reasons Sinch may reject your campaign, and what you should do to avoid them: Insufficient opt-in: This means that you failed to convey how you get consent from the end user to send messages. Make sure you show the opt-in from the end-user's perspective. For example, if your opt-in happens online, you must specify where on the website the opt-in occurs. Brand name mismatch: This means the registered brand name or DBA doesn't match the name on the brand website or in the messages. You can use a shortened brand name in your messages, but it can't be so different that it's not clear who the sender is. If the brand names are different, make sure you explain why in the campaign description. Insufficient privacy policy: This means it's not clear in your privacy policy that you won't share or sell the end user’s personal info to a third party for marketing purposes. If you don't have a privacy policy, then you need to create one. In order to submit the most compliant campaign possible, Sinch has outlined below all of the fields needed to register a 10DLC Campaign. We want to give you guidance on how to submit the best 10DLC campaign possible, so that you don't encounter rejections from Sinch. All fields are required unless otherwise noted: Field Name Description projectId Sinch uses projects to group contacts and apps together to manage and connect a unique set of keys and secret IDs for all your Sinch API products. To identify a project, it is given a unique alphanumeric identifier that ties it to your account. Your project ID can be found in the Sinch Build Dashboard. brandId The brand is the company or entity represented in the campaign. The brand ID is an alphanumeric identifier that always begins with a "B". When registering a brand in The Campaign Registry (TCR), TCR returns a brand ID value, example: BESINCH. For more info, see Creating a new 10DLC Brand. useCase Select a use case that is the primary use case that is most applicable to the service that messages are providing to subscribers. Standard use cases are immediately available for all qualified registered brands, whereas special use cases require vetting or pre/post approval by mobile network operators (MNOs). For more information on standard use case versus special use case campaigns, see 10DLC Use Cases - Standard Use Cases vs Special Use Cases. campaignName This is an optional name to help track and view your campaign within Sinch's platform. Use a name that is easily recognizable, this will help you identify your campaign later within the Sinch customer dashboard. This name is not part of the campaign registration in TCR. description Describe in detail the service the message program is providing to the end user and the purpose of the brand’s messages (i.e. appointment reminders, OTP alerts, etc.). The description should match the selected use case and identify who is sending the messages, who is receiving the messages, and why messages are being sent. (min 40 characters) A standard description may look like this: This message program will be used to provide {purpose of brand’s messages}.  terms Provide a link to your message program terms and conditions or provide your terms and conditions body copy. Ensure that all applicable messaging terms and conditions (e.g., how to opt-out, customer care contact information, and any applicable privacy policy) are covered.  privacyPolicy Provide a link to your privacy policy, or provide your privacy policy body copy. It should be clear from your privacy policy that the end user’s personal info, including mobile phone number, will not be shared or sold to third parties for marketing purposes.  optInDocumentation Provide a URL to the online opt-in process. If opt-in is not online or not publicly accessible, provide a URL with hosted screenshots or images of the opt-in process. If you cannot provide a URL, provide your opt-in body copy. sample1 Provide sample production message content. Include the Brand name and opt out instructions (e.g. Reply STOP to stop) in every message. If you have selected Mixed use case, please provide examples of each sub use case selected (min 20 characters, max 1024 characters) A standard sample message may look like: {Brand name}: We are contacting you today to let you know your order is ready for pickup. Reply STOP to stop.  sample2 A standard sample message may look like: {Brand name}: Your confirmation code is SINCH1234. Please enter it on the authentication website. Reply STOP to stop.  sample3 A standard sample message may look like: {Brand name}: Shop at www.example.com for all your retail needs! From clothing to home goods, we've got you covered. Visit us today and save! Reply STOP to stop.  sample4 If needed, add another sample message. stopMessage Message sent in response to a STOP keyword. It must confirm that the end user has unsubscribed from the message program and will not receive any further messages. Include the brand name. You can also include customer care contact information (e.g. support email or phone number). (min 20 characters, max 255 characters)  A standard sample Stop message may look like: You have been unsubscribed and will not receive any more messages from {Brand name}.  For more information call {phone number} or email {email address}."  optInMessage Initial message that is sent confirming the end user's subscription. Include the brand name, opt-out instructions (reply STOP to stop), customer care instructions (reply HELP for help), message frequency (#msgs/mo, msg frequency varies, recurring messages, etc.) and the "message and data rates may apply" disclosure (Msg & Data rates may apply). (min 20 characters, max 255 characters) A standard opt-in message may look like: You have opted in to receive messages from {Brand name}! Msg freq varies. Msg & data rates may apply. Reply HELP for help. Reply STOP to stop.    helpMessage Message sent in response to HELP. Include the brand name and additional customer care contact information (e.g. support email or phone number) (min 20 characters, max 255 characters) A standard Help message may look like: {Brand name}: For help call {phone number} or email {email address}  Reply STOP to stop. subUseCases If you have selected a Mixed use case, select all sub use cases that apply to your message program. Choose between 2 and 5 sub use cases for this campaign.  This field is not required. The input(s) should be one of the accepted values below: 2FA ACCOUNT_NOTIFICATION CUSTOMER_CARE DELIVERY_NOTIFICATION FRAUD_ALERT HIGHER_EDUCATION MARKETING POLLING_VOTING PUBLIC_SERVICE_ANNOUNCEMENT SECURITY_ALERT autoRenewal Will your campaign automatically renew? If yes, a monthly recurring fee will be charged to the account. If no, only the initial setup fee will be charged, and the campaign will expire after three months unless it is reviewed manually. The default setting is true, campaigns will be auto-renewed. embeddedLink Will your message content include a URL? Note that public URL shorteners are not allowed. embeddedPhone Will your message content include embedded phone numbers? affiliateMarketing Will your campaign follow CTIA messaging principles and best practices and will not be used for Affiliate Marketing? This should default to true. numberPool Will your campaign support a number pool (more than 50 numbers)? If yes, your use case should clearly support the need for a number pool. For more info see: When should I use a number pool for my 10DLC campaign. ageGated Will your traffic include any content related to age-restricted goods or services? If yes, you must implement an age gate verification process. directLending Are you a financial institution engaged in direct, first-party lending to your customers? If yes, note that your campaign description should clearly indicate direct lending, even if your use case is not related to your lending services (e.g. OTP). subscriberOptIn Will your campaign collect and process end user opt-ins? This is mandatory for all use cases, except for Machine-to-Machine. subscriberOptOut Message sent in response to a STOP keyword. It must confirm that the end user has unsubscribed from the message program and will not receive any further messages. Include the brand name. You can also include customer care contact information (e.g. support email or phone number). (min 20 characters, max 255 characters) Sample opt-out message: You have been unsubscribed and will not receive any more messages from {Brand name}.  For more information call {phone number} or email {email address}.  subscriberHelp Message sent in response to HELP. Include the brand name and additional customer care contact information (e.g. support email, phone number or support website) (min 20 characters, max 255 characters) Sample Help message: {Brand name}: For help call {phone number} or email {email address}  optinKeywords If subscribers can opt-in via a keyword, enter keyword(s) here. (alphanumeric comma separated values, no blank spaces)  optoutKeywords Subscriber opt-out keywords. Default values are STOP, QUIT, END, CANCEL and UNSUBSCRIBE. If you accept additional opt-out keywords, you can enter them here. (alphanumeric comma separated values, no blank spaces)  helpKeywords Subscriber help keywords. Default value is HELP.  If you accept additional help keywords, you can enter them here. (alphanumeric comma separated values, no blank spaces)  messageFlow Instructions: Describe how end users opt-in to receive messages. A compliant opt-in is critical to the approval of your campaign. Include all opt-in mechanisms (e.g. keyword/text-to-join, online form, point-of-sale (POS) system, verbal consent, interactive voice response (IVR) system, paper form) and a clear program description. The Call-to-Action should include opt-out instructions (reply STOP to stop), customer care instructions (reply HELP for help), message frequency (#msgs/mo, msg frequency varies, recurring messages, etc.) and message and data rates disclosure (Msg & Data rates may apply). (min 40 characters, max 2048 characters) Sample message flow: Users will opt-in to receive messages from {Brand name} via {opt-in mechanism} For even more details on 10DLC brand and campaign registration requirements, please view the 10DLC Compliance Requirements and Guidance and the Sinch Disallowed Content Policy articles.   Visit the Sinch 10DLC Product Page to learn more about Sinch 10DLC or if you need more help with 10DLC or have any questions, contact Sinch, who will be happy help! ... View more

10DLC Brand & Campaign Compliance Overview   Before you launch your 10DLC message program, Sinch must review your campaign and brand. We make sure your message program aligns with carrier and industry requirements. Principally we look for alignment with the CTIA Messaging Principles and Best Practices document.    For Sinch to approve your 10DLC campaign, you will need to:   Identify the campaign use case. It should not be a prohibited use case in North America. (Read more about Sinch's Disallowed Content Policy) Describe in detail the campaign and the service it is providing to the end user. Provide information about how the end user will opt-in to the campaign. Identify the opt-in method (website, text-to-join, paper form, etc). Provide several message types. This includes the confirmation message, opt-out message, help message, and sample messages. Identify special attributes associated with your campaign. For example, if your campaign will use an age gate, if it involves direct lending, or if you will need a number pool.   10DLC Brand Requirements   Below are some specific requirements when submitting your 10DLC brand for verification. Mobile carriers expect to easily understand and know who the brand is that's sending content across their networks. In the case a campaign is audited, the MNOs will review the brand in depth to protect their network from bad actors, along with potential spam and fraud.  Legal Name and DBA name should be the same OR there should be an easily identifiable correlation between the two should the DBA name be different.   The brand website is required and must tie back to the registered brand name or DBA.  Only, if the use case is Sole Prop should the website be optional. However, if the Sole Proprietor does have a website, the action should be to ensure it is updated with a Privacy Policy that incorporates business messaging.  If the brand is a SMB, and they don't have an established website, a link to their social media business page such as, Facebook or Instagram is acceptable.  Brand support email and phone number are required and must directly tie back to the registered brand.  The use of personal emails (yahoo, gmail, hotmail, etc.) when a branded support email is available, will be rejected.  Only, if the use case is Sole Prop can the use of a personal email be accepted by default.  Branded email is recommended. 10DLC Campaign Requirements    Below are some specific requirements you must apply to 10DLC campaigns you are bringing onboard with Sinch. Think of this as a checklist of things you should comply with in order to get your message program approved and keep your messaging from getting flagged as spam.  While it may not work 100% of the time, following these practices will give you a better chance of not being flagged or your messaging blocked by wireless operators.     Call-to-Action/Message Flow   The call-to-action or message flow is how the end user opts in to the 10DLC campaign, giving their consent to receive messages.    Requirements: Clear, understandable program description that informs the end user of the nature of the message program, identifies the sender or brand associated with the program, and matches the supplied sample messages. Message frequency disclosure* (e.g., #msgs/mo, msg frequency varies, recurring messages, etc.). *Only required for recurring message programs Complete Terms and Conditions OR link to complete Terms and Conditions Link to Privacy policy “Message and data rates may apply” disclosure Opt-out instructions (e.g., Reply STOP to Opt-out) HELP instructions (e.g., Reply HELP to receive help) OR, a complete linked Terms and Conditions including help instructions.    NOTE: In the Call-to-Action/Message Flow field in the campaign record, please include a direct link or image attachment showing the point of opt in.  If the call-to-action direct link or image attachment contains all of the requirements mentioned above, then they do NOT need to be written in the Call-to-Action/Message Flow field.  If the call-to-action is via a verbal opt-in, the verbal opt-in script must be provided in the Call-to-Action/Message Flow field, including all requirements listed above. If there are multiple ways an end user can opt-in to your message program, make sure to include them all in the Call-to-Action/Message Flow field.   Opt-In Message   The opt-in message is the initial message that is sent confirming the end user's subscription to the 10DLC message program.   Requirements: Program (brand) name  Opt-out information (e.g., Reply STOP to stop)  Customer care contact information (e.g., Reply HELP for help)  Message frequency disclosure* (e.g., #msgs/mo, msg frequency varies, recurring messages, etc.). *Only required for recurring message programs "Message and data rates may apply" disclosure.    Sample Messages   Samples messages are example content messages and should represent production message content.   Requirements: Program (brand) name At least one sample message, although it's recommended to include more for variety. Some use cases require a minimum of two sample messages. Recommended but NOT required: Opt-out instructions. (Reply STOP to stop) Note: When registering a campaign and choosing the Mixed use case, please provide a sample message for each sub use case selected.       HELP Message   The HELP message is the message that is sent in reply to end users when they send a help request (e.g., HELP keyword).   Requirements: Program (brand) name  Additional customer care contact information (can be phone number, email address and/or URL that leads directly to a support contact page)      STOP Message   The STOP message is the message that is sent in reply to end users when they send an opt-out request (e.g., STOP keyword).   Requirements: Program (brand) name  Confirmation that user has unsubscribed AND no further messages will be delivered.     Privacy Policy   The privacy policy describes how you collect, use and share information from end users.    Requirements: Must be clear that the end user’s personal info, including mobile phone number, will not be shared or sold to third parties for marketing purposes.   Example privacy policy statement: “No mobile information will be shared with third parties/affiliates for marketing/promotional purposes. All the above categories exclude text messaging originator opt-in data and consent; this information will not be shared with any third parties."  Variations of the above statement are accepted, such as, "All the above excludes mobile opt in data, which will not be shared with third parties or affiliates."  Note: If for any reason a privacy policy doesn't exist, the no sharing disclosure above CAN be presented upon opt in within the call-to-action.     Terms & Conditions   The terms & conditions describes any applicable terms and conditions related to the messaging program (for example, how to opt-out, customer care contact information, and link to any applicable privacy policy).    Requirements: Program (brand) name  “Message and data rates may apply” disclosure Message frequency disclosure* (e.g., #msgs/mo, msg frequency varies, recurring messages, etc.). *Only required for recurring message programs Opt-out information (e.g., Reply STOP to stop)  Customer care contact information (e.g., Reply HELP for help)    Reference article - CTIA Messaging Principles and Best Practices   Visit the Sinch 10DLC Product Page to learn more about Sinch 10DLC or if you need more help with 10DLC or have any questions, contact Sinch, who will be happy help! ... View more

Snowshoeing or Snowshoe Messaging (or pooling) is a technique used to spread messages across many sending phone numbers, or short codes, for the purposes of overcoming carrier filtering systems.   It involves spreading similar messages (and message content) across multiple numbers as a way to avoid per number rate limits and volume limitations at carriers.   Snowshoeing is a common technique used by spammers. Adopting this technique often results in your messages being blocked based on your message content, URLs, etc. This technique is often used to dilute  reputation metrics and evade filters.    Sinch does not support Snowshoe Messaging because its purpose is to evade carrier filtering and processes.    Most, if not all of the time, snowshoeing attempts get caught and their numbers are automatically blocked by carriers.  T-Mobile has specific penalties ($1,000 per instance) around program evasion of the 10DLC program, and snowshoeing falls into that category.  It is an unsustainable way of sending message content to consumers, mainly over grey routes.  Most of the time, it is unwanted traffic.  Carrier filtering mechanisms are smart enough to detect instances of this and immediately block this traffic.  If Sinch is caught supporting this type of traffic we are at risk of losing our carrier connections.  Looking for a sanctioned alternative? Check out 10DLC.  With 10DLC Snowshoeing is not needed, the MNO’s have greatly increased TPS/TPM to accommodate multiple use cases, including marketing. Throughput is based on the Brands vetting score, higher score, higher(est) throughput.    Visit the Sinch 10DLC Product Page to learn more about Sinch 10DLC or if you need more help with 10DLC or have any questions, contact Sinch, who will be happy help! ... View more

There are two separate and distinct concepts around Verification and Vetting as applied to 10DLC messaging:   Verification   When you first register your Brand you're asked to submit the Brand name, tax ID, company address and contact details.  After you complete this, your Brand will either be in a Verified state or and Unverified state.  If you are in an Unverified state, you will not be able to run on 10DLC.  This means there is information in your Brand registration that does not match your tax filing, thus the Brand cannot be verified.  I must stress, your information must match your tax filing, or you will not get into a Verified state. Important Notes: When registering a private company, you need to provide the following information: Legal company name, country of registration, Employer ID Number (EIN) / Tax ID, address, vertical, contact details. When registering a public company, you need to provide the following information: Legal company name, country of registration, , Employer ID Number (EIN) / Tax ID, address, website address, vertical, stock symbol, stock exchange, contact details. When registering a non-profit organization, you need to provide the following information: Legal company name, country of registration, Employer ID Number (EIN) / Tax ID, address, vertical, contact details. This entity type should be selected only by orgs with the "NON PROFIT" status. Orgs with the "NOT FOR PROFIT" status should instead register as a "Private Company".   Vetting   This is a step where, as you register your Brand, you can also "Vet" the Brand in order to potentially increase the number of messages you can send on a daily basis.  CSP's can apply for vetting on behalf of the Brand through one of the external vetting partners to gain access to Special Use cases or improve quality of service (where applicable). External vetting can be imported or carried out on the “Brand Details” page in TCR.  You do not need to go through vetting, if you don't need high throughput.  Standard vetting is basically a credit check.  Enhanced vetting is a more detailed investigation into the Brand and may, or may not, increase your vetting score.   Visit the Sinch 10DLC Product Page to learn more about Sinch 10DLC or if you need more help with 10DLC or have any questions, contact Sinch, who will be happy help! ... View more