Overview
When creating a new Message Type for SMS sending, a US-based toll-free phone number is automatically assigned. For compliance reasons, each Message Type must complete a verification process before it can be enabled for sending. This process validates business identity, opt-in practices, and message use cases to ensure alignment with US carrier and regulatory requirements.
This document explains the verification process, common reasons for rejection, and best practices to improve approval timelines. Clients should ensure their legal and compliance teams review all policies, disclosures, and opt-in language before submission.
What Is SMS Message Type Verification?
SMS verification is a required compliance step enforced by mobile carriers and US regulation (see our What To Know article for more details on TCPA). The goal is to:
Confirm the identity of the end business sending messages
Validate that recipients have explicitly opted in to receive SMS messages
Ensure message content aligns with the declared use case (e.g., marketing, account notifications)
Reduce spam, fraud, and consumer complaints
A Message Type cannot send SMS messages until it has been successfully verified.
Verification Roles and Responsibilities
It is important to understand who the "sender" is from a compliance perspective:
End Business: The organization whose brand, products, or services are being promoted or referenced in the messages. This is the entity that must be verified.
Service Provider (Omeda): Acts as the messaging platform and ISV, but should not be listed as the sending business during verification.
All submitted business details (company name, website, address, and contact information) must match the end business exactly. Mismatches are a common cause of rejection.
In the event that the privacy policy and consent sites are hosted by the parent business, the Business Name should be “Parent Company DBA Sub Brand” (ie: Omeda DBA SMS Magazine).
Common Reasons for Verification Rejection
Message Type submissions are most commonly rejected for the following reasons:
Business information does not match the end business
Incorrect message use case selection (e.g., marketing submitted as account notifications)
Opt-in language is missing required disclosures
Opt-in language is vague or implied rather than explicit
Opt-in is pre-selected on the form
Screenshot does not match submitted opt-in language
Sample messages do not align with the declared use case
Best Practices to Ensure Approval
To improve approval speed and reduce rework:
Ensure all business details consistently reflect the end business
When in doubt, classify messages as marketing
Use explicit, consumer-facing opt-in language
Avoid internal terminology or platform references in opt-in text
Submit real examples and screenshots from live or staging environments
Double-check that sample messages, opt-in language, and use case all align
