# Ekas 10DLC Rule Registry — Website > The 93 website rules Ekas checks during A2P 10DLC registration. - Source: https://ekas.io/rules/10dlc/ - Rules in this document: 93 - Registry last updated: 2026-07-25 - Licence: CC BY 4.0 — https://creativecommons.org/licenses/by/4.0/ - Layer: `WEBSITE` --- ## WEB-001 — A brand website URL is required > Every brand registration must carry a website URL or an equivalent hosted online-presence artifact. - **Rule ID:** WEB-001 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand.website` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** Deterministic (settled in code from the submitted values) - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** TCR, Twilio, Bandwidth, Telnyx, AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-001/ ### Why this rule exists The website is the primary artifact a reviewer uses to decide the business is real and does what the campaign claims. Without one there is nothing to corroborate the registration against, and most providers will not vet a brand at all. ### How to fix it Add the business website. If the business genuinely has no site, a public, indexable business profile page can substitute at some providers — but expect additional scrutiny and a slower vet. ### Example of a compliant value ```text https://acmecoffee.com ``` --- ## WEB-004 — The website value must fit the provider field limit > The website URL must fit within the provider field cap (100 characters at the tightest). - **Rule ID:** WEB-004 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand.website` - **Severity:** MEDIUM — Usually survives review, but lowers your trust score or invites manual review. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** Deterministic (settled in code from the submitted values) - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** Telnyx, TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-004/ ### Why this rule exists Some providers cap the website field at 100 characters and truncate silently rather than erroring, which produces a stored URL that no longer resolves. A deep link with tracking parameters overruns easily. ### How to fix it Use the bare site root without tracking parameters or deep paths in the brand website field. ### Example of a compliant value ```text https://acmecoffee.com ``` --- ## WEB-006 — The website should sit on a custom domain > The brand website should be on a domain the business owns, not a free platform subdomain. - **Rule ID:** WEB-006 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand.website` - **Severity:** MEDIUM — Usually survives review, but lowers your trust score or invites manual review. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** Deterministic (settled in code from the submitted values) - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** TCR, Twilio, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-006/ ### Why this rule exists A free platform subdomain costs nothing and takes minutes to create, so it carries almost no evidential weight about a business existing. Reviewers treat it as a weak signal rather than an automatic rejection, but it materially raises the chance of a manual review. ### How to fix it Point a custom domain at the site and register that domain as the brand website. Keep the brand email on the same domain so the two corroborate each other. ### Example of a compliant value ```text https://acmecoffee.com rather than https://acmecoffee.myshopify.com ``` --- ## WEB-009 — The website must resolve and return content > The submitted website URL must resolve to a live host and return a successful response. - **Rule ID:** WEB-009 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand.website` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** TCR, Twilio, Bandwidth, AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-009/ ### Why this rule exists A site that does not load cannot be assessed, and DNS or timeout failures are indistinguishable to a reviewer from a business that does not exist. This is checked at submission and again during vetting, so intermittent hosting fails it twice. ### How to fix it Confirm the URL loads from a clean network with no VPN, and check DNS resolves publicly. Fix hosting before submitting rather than resubmitting hopefully. --- ## WEB-012 — A parked or for-sale domain is not a website > A registrar placeholder, parked domain, or domain-for-sale page is rejected. - **Rule ID:** WEB-012 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** TCR, Twilio, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-012/ ### Why this rule exists A parked domain proves someone bought a name, not that a business operates. It is a strong fraud signal because it is exactly what a registration created to obtain numbers looks like. ### How to fix it Publish the real site at that domain, or submit the domain where the business actually operates. --- ## WEB-013 — A pre-launch placeholder is not a website > A "coming soon" or "under construction" page is rejected as the brand website. - **Rule ID:** WEB-013 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** TCR, Twilio, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-013/ ### Why this rule exists A business not yet open to customers has no consenting subscribers to message, so the placeholder page and the campaign contradict each other. Reviewers read it as registering ahead of having a programme. ### How to fix it Launch the site before registering. Register once you have a live site and real subscribers. --- ## WEB-014 — Staging, admin and internal hosts must not be the brand website > Non-production hosts — staging, dev, preview, admin, internal — are not acceptable brand websites. - **Rule ID:** WEB-014 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand.website` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** Deterministic (settled in code from the submitted values) - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** TCR, Twilio, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-014/ ### Why this rule exists A staging host is not the business's public presence, is frequently access-gated, and often disappears between submission and review. Submitting one usually means someone pasted the URL they had open rather than the live site. ### How to fix it Submit the public production URL customers actually visit. If the staging host is the only one currently live, launch the production site before registering — the vetter will re-fetch this URL days later and a staging box is usually gone by then. ### Example of a compliant value ```text https://acmecoffee.com rather than https://staging.acmecoffee.com ``` --- ## WEB-015 — Pages the registration points at must not be broken > Any page the registration references must load — no broken internal links, 404s, or links pointing at the wrong page. - **Rule ID:** WEB-015 - **Layer:** Website (`WEBSITE`) - **Checks:** `internal links on the referenced pages` - **Severity:** MEDIUM — Usually survives review, but lowers your trust score or invites manual review. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** Bandwidth, Telnyx, Bird, Aerialink - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-015/ ### Why this rule exists A reviewer following a link from the registration into a 404 concludes the site is unmaintained, and unmaintained sites are the ones that disappear between submission and the vet weeks later. The links that break are almost always the ones nobody clicks: the policy page renamed during a redesign, the old opt-in path left in the message flow. ### How to fix it Click every URL in the registration and every link on the pages they open, and fix or remove the ones that fail. Done when the policy, terms and opt-in links all resolve to the pages they name. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth/DCA | `804` | yes | ### Notes Needs a multi-page crawl to settle properly. Against the current single-page fetch it can only see links on the one page retrieved, and must say so rather than reporting the rest as sound. --- ## WEB-016 — The website must be machine-crawlable > The site must be fetchable by an automated vetter — no robots.txt disallow, no noindex, no JS-only render, no geofence. - **Rule ID:** WEB-016 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** TCR, Twilio, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-016/ ### Why this rule exists Vetting uses a headless fetcher, not a browser. A single-page app that renders only after JavaScript returns an empty shell to the reviewer, so a fully compliant opt-in becomes invisible and the campaign is rejected for having no discoverable consent flow. ### How to fix it Server-render the opt-in page, or provide a server-rendered alternative URL carrying the same consent surface. Remove robots.txt disallows on that path and confirm the page returns content from a US IP with JavaScript disabled. --- ## WEB-017 — The site must not be gated by geo, bot challenge or app wall > A geo-gate, bot challenge, captive portal, or app-install wall blocking the reviewer is rejected. - **Rule ID:** WEB-017 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** TCR, Twilio, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-017/ ### Why this rule exists Vetting fetches from a US datacentre IP, which aggressive bot protection frequently blocks outright. The site works perfectly for customers and returns a challenge page to the reviewer, so the failure is invisible from the brand's side. ### How to fix it Allowlist datacentre traffic for the policy and opt-in pages, or lower the bot-protection level on them. Confirm the pages load from a cloud IP, not just from your office. --- ## WEB-018 — The site must be readable in English > The website must be renderable in English, or an English version must be supplied. - **Rule ID:** WEB-018 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** TCR, Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-018/ ### Why this rule exists US 10DLC reviewers assess against US requirements in English. A site with no English version cannot be evaluated for the disclosures and business description the registration depends on. ### How to fix it Provide an English version of the site, or at minimum English pages for the business description, privacy policy, and SMS terms. --- ## WEB-019 — The site must stay live for the whole vetting window, not just at submission > The brand website must remain live and publicly reachable for the entire vetting period, which runs weeks after submission. - **Rule ID:** WEB-019 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand.website over the review window` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** Not knowable before submission — reported with its deadline - **Fix type:** Wait on an external system or a required interval - **Required by:** AWS, Bandwidth, Klaviyo, Postscript - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-019/ ### Why this rule exists Vetting re-fetches the site days or weeks later, so a site that was up when the form was filled in is not the thing being judged. The named failure is a password-protected storefront: a shop put into maintenance mode for a redesign, or a trial plan that lapses, takes the brand down with it and the rejection arrives with no hint that timing was the cause. ### How to fix it Keep the site public and unchanged until the brand and campaign are approved. Do not schedule a migration, a password gate or a plan downgrade during the window; AWS states 10DLC review takes at least four to six weeks and toll-free three to ten business days. ### Check this yourself **Is any redesign, migration, password gate or hosting downgrade scheduled between now and approval?** 1. Ask whoever runs the site what is planned for the next six weeks. AWS states 10DLC review takes at least four to six weeks and toll-free three to ten business days. 2. Hold the site public and unchanged until the brand and campaign are approved. 3. Check any trial plan or hosting subscription that could lapse mid-review. *What wrong looks like:* A shop is put into maintenance mode for a redesign three weeks after submission. Vetting re-fetches the site, finds a password-protected storefront, and the rejection gives no hint that timing was the cause. ### Notes Nothing at submission time can settle this — the failure happens after we stop looking. Surfaced as a warning with the deadline: the user has to hold the site up, and to hold off any redesign or hosting change, until approval lands. --- ## WEB-021 — The site must not be behind a login or access wall > The brand website must be publicly reachable without authentication. - **Rule ID:** WEB-021 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** Twilio, TCR, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-021/ ### Why this rule exists A reviewer with no account cannot assess a site they cannot open, so an SSO or password wall is functionally identical to a site that does not exist. This is a distinct code from a broken site because the fix is different: expose a public surface rather than repair anything. ### How to fix it Publish a public marketing site describing the business, even where the product itself sits behind a login. Where the opt-in genuinely lives inside the authenticated area, supply a screenshot of it instead. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30921` | yes | --- ## WEB-022 — A login-gated product needs a public description page > Where the brand's service genuinely sits behind a login, a public page describing the business and its messaging programme is required. - **Rule ID:** WEB-022 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** TCR, Twilio, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-022/ ### Why this rule exists Plenty of legitimate businesses are entirely authenticated products, and rejecting them outright would be wrong. The requirement is a public surface a reviewer can read — not that the product itself be open. ### How to fix it Publish a public marketing or about page describing what the business does, who it serves, and what the SMS programme sends, and register that URL as the brand website. --- ## WEB-024 — The site must not look inauthentic > A site judged to be a shell, an unmodified template, scraped or fabricated content, or stock-imagery-only is rejected. - **Rule ID:** WEB-024 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** TCR, Twilio, AWS, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-024/ ### Why this rule exists Fraudulent registrations stand up a plausible-looking site to satisfy the website requirement, so reviewers learned to judge authenticity rather than mere existence. This is distinct from a site being incomplete: an unmodified theme demo with lorem text fails even though every required page exists. ### How to fix it Publish real content: actual products or services with real descriptions and prices, a real About page, real contact details, and photography of the actual business. --- ## WEB-026 — The site must look established rather than erected for the registration > The website should show signs of being an operating business, not a shell created to pass vetting. - **Rule ID:** WEB-026 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** TCR, Twilio, AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-026/ ### Why this rule exists Reviewers weigh apparent age and depth because a site built the week before registration is the standard fraud pattern. Thin, brand-new sites are not automatically rejected but attract manual review and slower vetting. ### How to fix it Publish real depth before registering: products or services with detail, an about page, contact information, and any customer-facing content that shows the business operating. --- ## WEB-027 — The site must be more than a bare lead-capture form > A URL resolving to a standalone lead form with no surrounding business site is rejected. - **Rule ID:** WEB-027 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** Twilio, TCR, AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-027/ ### Why this rule exists A page whose only content is a form collecting a phone number is the archetypal lead-generation surface, and lead generation is precisely what the consent-transfer rules prohibit. Reviewers therefore treat a bare form as evidence of the business model rather than as a thin website. ### How to fix it Point the brand website at your full site — home, about, contact, and product or service pages — rather than at the campaign landing page. Keep the landing page for the message flow field. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30920` | yes | --- ## WEB-028 — A campaign landing page is not the brand website > Where the business runs a main site, that site must be registered as the brand website rather than a single campaign landing page. - **Rule ID:** WEB-028 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand.website vs the discoverable main site` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** Twilio, AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-028/ ### Why this rule exists A landing page is written to sell one thing, so it describes an offer rather than a business — and the reviewer needs the business. This is distinct from a bare lead form: the page can be perfectly substantial and still be the wrong page, which is why the fix is to change the URL rather than to build anything. ### How to fix it Put the main business domain in brand.website and keep the landing page where it belongs, in the message flow as the opt-in URL. Done when brand.website opens a site with navigation to the rest of the business. ### Example of a compliant value ```text website: https://acmecoffee.com · message flow opt-in URL: https://acmecoffee.com/rewards-signup ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30920` | yes | ### Notes Different fix from WEB-027, which rejects a bare lead-capture form with no business behind it at all. Here the business exists and the wrong URL was submitted. --- ## WEB-030 — E-commerce brands need a published catalog > An e-commerce brand must show a real, populated product catalog rather than a placeholder store. - **Rule ID:** WEB-030 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** TCR, Twilio - **Applies:** Applies when the vertical is RETAIL. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-030/ ### Why this rule exists An empty or demo store is the e-commerce version of a shell site, and it directly contradicts a campaign describing order and promotional messaging. There are no orders to notify anyone about. ### How to fix it Publish the real catalog with products, prices and descriptions before registering. --- ## WEB-031 — The business name on the site must match the registered brand > The name displayed on the website must match the registered legal name or DBA. - **Rule ID:** WEB-031 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website + brand.company_name` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** TCR, Twilio, Bandwidth, AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-031/ ### Why this rule exists The name match is how a reviewer connects the registration to the site, and it is the check that catches a reseller registering a client's traffic under the wrong entity. A mismatch with no stated relationship is treated as an identity failure rather than a branding choice. ### How to fix it Display the registered name prominently in the header, footer, or about page. Where the site trades under a different name, register that name as the DBA on the brand record. --- ## WEB-032 — The business name must be visible on the page, not only in the markup > The business name or branding must be displayed in the logo, header or footer of the rendered page, not carried only in the title tag or metadata. - **Rule ID:** WEB-032 - **Layer:** Website (`WEBSITE`) - **Checks:** `rendered header, footer and logo region` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI vision over a consent artifact (screenshot, scan, MMS media) - **Fix type:** Fix the website — no form edit clears it - **Required by:** Twilio, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-032/ ### Why this rule exists A reviewer decides whose site this is by looking at it for a few seconds. A name that lives only in the page title, or only in an image with no text near it, means the answer is "nobody in particular" — which is the impression a template site left unbranded also gives, and it is the one this rule exists to catch. ### How to fix it Put the business name in the site header or footer as text, next to or instead of the logo image. Done when the name is legible in a screenshot of the top of the page without opening the source. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30492` | yes | | Bandwidth | `TFV 1205` | yes | ### Notes Whether the name is present in the text at all is WEB-031, which reads the body. This rule is about prominence, which only the rendered page shows — hence VISION. --- ## WEB-034 — The site must describe the business and the messaging programme > The website must carry enough information about the business, and ideally the messaging programme, for a reviewer to understand what is being registered. - **Rule ID:** WEB-034 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** Twilio, TCR, AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-034/ ### Why this rule exists Reviewers cross-check the site against the campaign, so a site that never says what the business does leaves nothing to check against. Twilio codes this separately from "site is a bare form" because a site can be substantial and still never explain the business. ### How to fix it Add a clear description of what the business does and who it serves, plus a page describing the SMS programme and linking to the SMS terms. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30919` | yes | --- ## WEB-035 — The reseller platform website must not stand in for the customer site > An ISV or reseller must not submit its own platform website in place of the end customer's. - **Rule ID:** WEB-035 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand.website + brand.company_name` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** TCR, Twilio, Bandwidth, AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-035/ ### Why this rule exists This is the website-side twin of registering the wrong entity. It looks harmless — the platform site is real and substantial — but it means the brand being vetted is not the business that will send the messages. ### How to fix it Submit the end customer's own website. Your platform belongs on the CSP record, never on the brand. --- ## WEB-037 — The site, the registered name and the registered address must agree > The business described on the website, the registered company name and the registered postal address must corroborate one another. - **Rule ID:** WEB-037 - **Layer:** Website (`WEBSITE`) - **Checks:** `website content vs brand.company_name + brand address` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-037/ ### Why this rule exists Verification works by finding the same business in two independent places, so a site that names a different company, or shows an address in another state, leaves the reviewer with two businesses and no way to join them. The honest version of this is common: the registration carries the legal entity and the accountant's address while the site carries the trading name and the shop, and nothing on either says they are the same people. ### How to fix it Publish the legal entity name and the registered address somewhere on the site — the footer, the contact page or the terms — even where the business trades under a shorter name. Done when a stranger reading the site can find both values exactly as the registration states them. ### Common mistakes - A registered agent or accountant address on the brand record and the shop address on the site is a mismatch even though both are true. Publish both on the site, or register the one the site shows. ### Notes The catalog scopes this to the toll-free verification path, where AWS applies it as the business-verification standard. It is authored universally because the same corroboration is what every vetting path performs; where a provider does not apply it, satisfying it costs nothing. --- ## WEB-039 — Contact details on the site must match the brand record > The support phone and contact shown on the website should match the brand registration. - **Rule ID:** WEB-039 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website + brand.phone + brand.email` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** TCR, Twilio, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-039/ ### Why this rule exists Corroboration between site and registration is what turns two weak signals into one strong one. Divergent contact details are a common sign that the registration was assembled from someone else's business information. ### How to fix it Make the contact details on the site and on the registration the same, or explain the difference (for example a separate support line) somewhere visible. --- ## WEB-043 — The site must have an About page and a Contact page > An About page and a Contact page must exist on the brand domain. - **Rule ID:** WEB-043 - **Layer:** Website (`WEBSITE`) - **Checks:** `site navigation` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** Plivo, TCR, MessageIQ - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-043/ ### Why this rule exists These two pages are where a reviewer goes first, because between them they answer who this is and how to reach them — the two questions the whole website requirement exists to settle. A site that answers both somewhere in a scrolling home page still fails the reviewer's habit of looking for them in the navigation. ### How to fix it Add an About page describing the business and a Contact page carrying an address, a phone number and an email, and link both from the site navigation. Done when both are reachable in one click from the home page. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30919` | yes | ### Notes Absorbs POL-039, which states the same page inventory and adds the privacy policy and terms — those two are already required by WEB-045 and WEB-046. Severity divergence in the catalog: Plivo lists the missing pages among its rejection reasons while the row itself is graded MEDIUM; graded HIGH here because two of the four pages it names are separately BLOCKING. --- ## WEB-044 — The footer should carry a phone number, an email and a street address > The site footer should show a business phone number, an email address and a physical street address rather than a PO box. - **Rule ID:** WEB-044 - **Layer:** Website (`WEBSITE`) - **Checks:** `site footer` - **Severity:** MEDIUM — Usually survives review, but lowers your trust score or invites manual review. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-044/ ### Why this rule exists The footer is the one place a reviewer can check on every page without navigating, so a business that puts all three there answers the corroboration question wherever the crawl happens to land. This is the stricter, conjunctive form of the contact requirement, and the street address is the element most often missing — a PO box proves a mailbox was rented, not that anyone works anywhere. ### How to fix it Add all three to the site footer template so they appear on every page, using the same values as the brand record. Done when the footer of an interior page carries a street address, a phone number and an email. ### Notes Single secondary source in the catalog, flagged unverified, and the "not a PO box" element in particular has no carrier code behind it — hence MEDIUM and worded as an expectation. The weaker, disjunctive requirement that contact information appear somewhere is WEB-047, which is the one that fails a site outright. --- ## WEB-045 — A privacy policy must be reachable from the website > The brand website must link to a reachable privacy policy. - **Rule ID:** WEB-045 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** CTIA, TCR, Twilio, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-045/ ### Why this rule exists Reviewers navigate from the site to the policy rather than trusting the URL field alone, and a policy that exists but is unlinked reads as one created solely for the registration. CTIA also requires it to be reachable from the call to action. ### How to fix it Link the privacy policy from the site footer and from the opt-in surface. --- ## WEB-046 — Terms must be reachable from the website > The brand website must link to reachable Terms & Conditions or SMS Terms. - **Rule ID:** WEB-046 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** CTIA, TCR, Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-046/ ### Why this rule exists The terms are where the messaging programme is documented for consumers, so an unlinked terms page is unreachable by the people it exists to inform. Reviewers check the path a real consumer would take. ### How to fix it Link the terms (or a dedicated SMS terms page) from the site footer and from the opt-in surface. --- ## WEB-047 — The site must show business contact information > The website must display contact details — an address, phone number, or support email identifying the business. - **Rule ID:** WEB-047 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** CTIA, TCR, Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-047/ ### Why this rule exists Contact details are how a reviewer corroborates that the business is real and matches the brand record, and CTIA separately requires that a message URL and its destinations identify the owner with contact information. A site with no way to reach anyone reads as a front. ### How to fix it Publish a contact page with the business address, a phone number, and a support email on the brand domain, and check they match the brand registration. --- ## WEB-054 — A brand with a website must publish its policies as web pages, not as PDFs > Where the brand has a website, the privacy policy and terms URLs must serve an HTML page rather than a PDF or other downloadable file. - **Rule ID:** WEB-054 - **Layer:** Website (`WEBSITE`) - **Checks:** `Content-Type of privacyPolicyUrl and termsOfServiceUrl` - **Severity:** MEDIUM — Usually survives review, but lowers your trust score or invites manual review. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** Deterministic (settled in code from the submitted values) - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** TCR, Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-054/ ### Why this rule exists Vetters read policy pages with a text fetcher, and a PDF frequently comes back as an empty body — so a complete, correct policy is scored as a missing one. It also breaks the consumer path the rules exist to protect: a phone that downloads a file instead of showing a page is a dead end at exactly the moment someone is deciding whether to consent. ### How to fix it Publish the policy as an HTML page on the brand domain and submit that URL; keep the PDF as an extra download if you want one. Done when the policy URL returns text/html. ### Example of a compliant value ```text privacy_policy_url: https://acmecoffee.com/privacy (text/html), not https://acmecoffee.com/files/privacy.pdf ``` ### Common mistakes - Uploading a PDF is the sanctioned route for a brand with NO website — this rule only fires when a site exists, and swapping a working page for a file to satisfy a provider that accepts uploads makes things worse. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio | `7102` | yes | ### Notes Absorbs POL-019, the same warning stated from the policy-page side. The catalog marks the underlying source unverified — inferred from Twilio 7102 rather than published as a rule — so it is graded MEDIUM and worded as an expectation rather than a refusal. --- ## WEB-055 — The site should describe the SMS programme > The website should carry information about what the messaging programme sends, to whom, and why. - **Rule ID:** WEB-055 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** CTIA, TCR, Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-055/ ### Why this rule exists A programme described only inside the registration exists only for the reviewer. Documenting it publicly is both a CTIA expectation and the thing that lets a consumer verify the messages they receive are legitimate. ### How to fix it Add a short SMS programme section to the site or the SMS terms page: what you send, how often, who it is for, and how to stop. --- ## WEB-056 — Opt-in and opt-out information must be clear on the site > The website must display how to opt in and how to opt out. - **Rule ID:** WEB-056 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** CTIA, TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-056/ ### Why this rule exists A consumer who wants to stop should not have to wait for the next message to find out how. Publishing both routes on the site is a CTIA expectation and materially reduces the complaint rate that drives carrier filtering. ### How to fix it State on the site how to join and how to leave, naming the keywords: "Reply STOP to any message to unsubscribe." --- ## WEB-057 — Website content must be consistent with the declared use case > What the website shows the business doing must be consistent with the campaign use case. - **Rule ID:** WEB-057 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website + campaign.usecase` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the submitted form - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** TCR, Twilio, AWS, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-057/ ### Why this rule exists The use case determines the consent standard and throughput a campaign receives, so reviewers verify it against the business rather than accepting the selection. A site that is plainly an e-commerce store behind a 2FA-only registration reads as an attempt to obtain transactional treatment for marketing traffic. ### How to fix it Choose the use case that matches what the site shows the business doing. Where you genuinely send several categories, use MIXED and collect promotional-grade consent. ### Example of a compliant value ```text A retail site sending promotions and order updates → MIXED, not ACCOUNT_NOTIFICATION. ``` --- ## WEB-058 — Website, description, flow and samples must identify one sender > The website, campaign description, message flow and sample messages must all identify the same sending business. - **Rule ID:** WEB-058 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website + campaign fields + samples` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the submitted form - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** TCR, Twilio, Bandwidth, AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-058/ ### Why this rule exists Each artifact is written separately, so a single inconsistent name is common and innocent — but a reviewer cannot distinguish that from a registration assembled out of several businesses. Consistency across all four is what makes the sender verifiable. ### How to fix it Use one customer-facing name everywhere, and make it the registered brand display name or DBA. ### Example of a compliant value ```text Website header, description, message flow and every sample all say "Acme Coffee". ``` --- ## WEB-059 — The site referenced in the message flow must be the registered brand site > The website referenced inside the message flow must belong to the same business as the registered brand website. - **Rule ID:** WEB-059 - **Layer:** Website (`WEBSITE`) - **Checks:** `campaign.message_flow + brand.website` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the submitted form - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** TCR, Twilio, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-059/ ### Why this rule exists A message flow pointing at a different domain usually means consent is collected on a partner or platform property, which raises the consent-transfer question directly. Where it is legitimate, it needs explaining rather than leaving for a reviewer to infer. ### How to fix it Reference the brand's own domain in the message flow. Where consent is collected on a third-party platform, say so explicitly and explain the relationship. ### Example of a compliant value ```text Brand website acmecoffee.com; message flow references acmecoffee.com/signup. ``` --- ## WEB-060 — Declared attributes must be consistent with the crawled site > The declared campaign attributes must be consistent with what the website shows, not only internally consistent with the form. - **Rule ID:** WEB-060 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website + campaign attributes` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the submitted form - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** TCR, Twilio, AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-060/ ### Why this rule exists Attributes are self-declared, so the website is the only independent evidence available. A site showing age-restricted products behind a campaign declaring no age gating is a contradiction the form alone can never reveal. ### How to fix it Reconcile each attribute against the website: age-gated products, lending offers, links and phone numbers in messaging. ### Example of a compliant value ```text Site sells age-restricted products → age gated: true. ``` --- ## WEB-062 — An undeclared additional use case must be surfaced > Where the website or description implies a message category the campaign has not declared, it must be flagged. - **Rule ID:** WEB-062 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website + campaign.description` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the submitted form - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** TCR, Twilio, Sinch - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-062/ ### Why this rule exists Live traffic must match the registered use case, and an undeclared category is a violation waiting to happen the first time that content is sent. Catching it at registration is the difference between adding a use case and being filtered later. ### How to fix it Declare every category you will send, or remove the undeclared one from your plans. MIXED covers promotional plus transactional. ### Example of a compliant value ```text Site shows cart-abandonment flows → declare MARKETING (or MIXED), not ACCOUNT_NOTIFICATION alone. ``` --- ## WEB-063 — Charitable solicitation on the site forces the charity use case > Where the website, description, or samples solicit donations, the charity use case must be used. - **Rule ID:** WEB-063 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website + campaign.usecase` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the submitted form - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** TCR, Twilio, Infobip - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-063/ ### Why this rule exists Donation solicitation carries eligibility requirements — verified 501(c)(3) status — that exist precisely to stop fraudulent charity messaging. Running it under a marketing use case bypasses that check, so reviewers force the correction. ### How to fix it Register under the CHARITY use case with 501(c)(3) status declared on the brand, or remove the donation ask from both the campaign and the messaging programme. ### Example of a compliant value ```text Entity type: NON_PROFIT · Tax exempt status: 501(c)(3) · Use case: CHARITY ``` --- ## WEB-064 — Political content on the site forces the political use case > Where the website, description, or samples carry political-campaign content, the political use case must be used. - **Rule ID:** WEB-064 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website + campaign.usecase` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the submitted form - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** TCR, AT&T, T-Mobile - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-064/ ### Why this rule exists Political messaging requires external vetting recognised by both major carriers, and that requirement is meaningless if the category can be avoided by choosing a different label. Reviewers therefore assess the content, not the selection. ### How to fix it Register under POLITICAL on a NON_PROFIT brand with political vetting imported, or remove political content from the programme entirely. ### Example of a compliant value ```text Use case: POLITICAL, on a NON_PROFIT brand with Campaign Verify vetting. ``` --- ## WEB-066 — Lending content anywhere requires the direct-lending declaration > Where lending content appears in the description, the message flow, or the website, directLending must be declared. - **Rule ID:** WEB-066 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website + campaign.direct_lending` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the submitted form - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** TCR, Twilio, Bandwidth, AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-066/ ### Why this rule exists The attribute exists so carriers can apply the right scrutiny to credit messaging, and it is assessed against the website as well as the form. Undeclared lending is treated as concealment rather than oversight, which is a much worse posture than declaring it. ### How to fix it Set the direct-lending attribute true when the business offers credit of any kind. Declaring it is a fixable attribute question; concealing it is a business-model rejection. ### Example of a compliant value ```text Site offers financing → direct lending: true. ``` --- ## WEB-068 — A cart-reminder programme must say so in the opt-in terms on the site > Where the programme sends shopping-cart reminders, the opt-in terms shown at the call to action must disclose it. - **Rule ID:** WEB-068 - **Layer:** Website (`WEBSITE`) - **Checks:** `opt-in disclosure text on the site` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** T-Mobile - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-068/ ### Why this rule exists A cart reminder is a message about something the consumer did not finish doing, sent because their behaviour was tracked — so T-Mobile requires it to be disclosed where consent is given rather than discovered when the first one arrives. Retailers add abandoned-cart flows through a platform months after the checkbox copy was written, and nothing in that flow prompts anyone to go back and update it. ### How to fix it Add cart reminders to the message types named in the opt-in disclosure beside the consent control. Done when the text at the checkbox names them alongside whatever else the programme sends. ### Common mistakes - Updating the SMS terms page is not enough on its own — T-Mobile asks for the disclosure at the call to action, which is the checkbox copy, and POL-109 separately asks the privacy policy to say how abandonment is detected. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | T-Mobile | `8003` | yes | ### Notes Conditional on cart-reminder traffic being in scope, which no applicability dimension expresses — there is no cart-reminder attribute. The condition is carried in the criteria, which pass immediately when the programme sends no cart reminders. --- ## WEB-069 — The described opt-in and the live opt-in must both pass, separately > The call to action as described in the registration and the call to action as it appears live on the website must be audited as two separate passes. - **Rule ID:** WEB-069 - **Layer:** Website (`WEBSITE`) - **Checks:** `campaign.message_flow + live website opt-in` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** TCR, Twilio, Bandwidth, AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-069/ ### Why this rule exists Ranked the #2 most-missed check in the catalog. A brand can describe a perfect opt-in that does not exist on the site, or run a compliant opt-in and describe it badly — those are different failures with different fixes, and collapsing them into one verdict hides whichever one is broken. Reviewers genuinely do both passes. ### How to fix it Reconcile the two: make the live page carry everything the description claims, and make the description match what the page actually shows. Where they diverge, fix the page first — the page is what the consumer saw. --- ## WEB-070 — The call to action described in the registration must exist on the site > Where consent is collected on the site, the call to action the registration describes must be findable on the crawled site. - **Rule ID:** WEB-070 - **Layer:** Website (`WEBSITE`) - **Checks:** `live site vs campaign.message_flow` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** Twilio, Zoom - **Applies:** Applies when consent was collected by web form, checkout and QR code. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-070/ ### Why this rule exists A described opt-in that cannot be found reads to a reviewer as consent that does not exist, which is the strongest possible reason to refuse a campaign — and it is usually true by accident: the page moved in a redesign, the form sits behind an interaction the crawler never triggers, or the description was written from the plan rather than from the site. The consumer-side stake is the same one: an opt-in nobody can locate is one nobody can audit. ### How to fix it Give the exact URL of the page holding the consent control in the message flow, and confirm the control is present in the page source rather than injected after an interaction. Done when opening that URL in a private window shows the opt-in without clicking anything. ### Common mistakes - A consent box that only appears after a product is added to the cart is invisible to a crawler that never adds one. Supply a screenshot of the checkout step as well, or the reviewer sees a page with no opt-in on it. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen1) | `30891` | yes | ### Notes The twin of WEB-069, which audits the described and live opt-ins as two passes. This rule is the narrower question underneath it: does the described surface exist at all. --- ## WEB-072 — A verbal-only programme should not point at a website with no consent surface > Where verbal opt-in is the only declared consent method, the registration must not supply a website opt-in URL that shows no SMS consent surface. - **Rule ID:** WEB-072 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand.website vs the declared consent method` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** AWS - **Applies:** Applies when consent was collected by live verbal and IVR. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-072/ ### Why this rule exists A reviewer given a URL looks for the opt-in on it, finds nothing, and records that the consent surface could not be verified — which is a worse outcome than the honest one, where a phone script is the evidence and the site was never offered as such. Brands do this by reflex because the form asks for a URL, so they paste the home page. ### How to fix it Describe the call in the message flow and attach the script or recording as the evidence, rather than pointing at a page that does not collect consent. Keep the website on the brand record, where it belongs — this rule is about the opt-in URL only. ### Example of a compliant value ```text message flow: "Consent is captured verbally during the support call; the agent reads the disclosure from the attached script." No opt-in URL supplied. ``` ### Notes Flagged unverified in the catalog — an inference from the AWS UNCLEAR_OPT_IN reason rather than a published rule. Tagged to the two verbal methods, so a brand that also collects consent on the web is never asked about it. --- ## WEB-073 — The brand website must serve a certificate that verifies > The brand website must present a valid TLS chain — not expired, not self-signed, and issued for the hostname actually submitted. - **Rule ID:** WEB-073 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand.website TLS chain` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** Deterministic (settled in code from the submitted values) - **Fix type:** Fix the website — no form edit clears it - **Required by:** Bandwidth, TCR, Twilio, Plivo - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-073/ ### Why this rule exists A vetting crawler stops at a certificate error and never reads a word of the site, so the rejection arrives as "the website could not be verified" rather than as anything about a certificate. Browsers hide this: the people who work at the business have been clicking through the warning for months, and a certificate valid for the bare domain but not for the www form fails only for whoever submitted the other one. ### How to fix it Reissue the certificate for the exact hostname in brand.website, covering both the www and bare-domain forms, and renew before expiry. Done when an external SSL checker — not your own browser — reports a complete, valid chain for the URL you are about to submit. ### Common mistakes - A certificate valid for acmecoffee.com and not for www.acmecoffee.com fails whenever the submitted URL uses the other form. Submit the form the certificate actually covers. - An expired intermediate is invisible in Chrome, which caches the issuer, and fatal to a strict crawler that does not. Test from outside your own network. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth | `1103` | yes | | Bandwidth/DCA | `2103` | yes | ### Notes Absorbs BRD-128, which states the same certificate requirement from the brand-record side. Severity divergence in the catalog: website-evidence-012 and CARR-008 grade a TLS failure HIGH; Bandwidth, Plivo and Twilio grade it BLOCKING. Strictest kept. --- ## WEB-074 — Pages must not load sub-resources over HTTP > A page must not load sub-resources over, or redirect through, unencrypted HTTP — mixed content fails. - **Rule ID:** WEB-074 - **Layer:** Website (`WEBSITE`) - **Checks:** `opt-in landing page` - **Severity:** MEDIUM — Usually survives review, but lowers your trust score or invites manual review. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** TCR, Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-074/ ### Why this rule exists Mixed content produces browser warnings on the exact page where a consumer is about to hand over a phone number, which undermines the trust the whole framework is built on. It also frequently signals an unmaintained site. ### How to fix it Serve every asset over https and remove any http:// redirect hop in the chain to the opt-in page. ### Notes Not decidable from a markdown-only fetch — needs the raw HTML and the sub-resource list. Recorded so the crawler gap is visible rather than silently unchecked. --- ## WEB-075 — Submitted URLs must not redirect > A URL submitted to TCR must resolve directly rather than returning a 30x redirect. - **Rule ID:** WEB-075 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand.website + campaign URLs` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** Deterministic (settled in code from the submitted values) - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-075/ ### Why this rule exists TCR forbids redirection on fetched URLs. This is deeply counter-intuitive because the link works perfectly in a browser — including the http-to-https upgrade almost every site performs — so brands submit a URL they have personally tested and are rejected anyway. ### How to fix it Submit the canonical URL you land on after all redirects resolve — with https, the final host (www or bare), and the final path. ### Example of a compliant value ```text Submit https://www.acmecoffee.com/signup rather than http://acmecoffee.com/signup ``` --- ## WEB-077 — The website must not redirect to an unrelated brand > A brand website that redirects to a business other than the registered brand is rejected, whatever the submitted URL says. - **Rule ID:** WEB-077 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand.website final host + landing content` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** Twilio, TCR, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-077/ ### Why this rule exists A domain that forwards to somebody else is the signature of a registration assembled from a bought or borrowed domain, and it is also what happens innocently when a business is acquired and its old domain is pointed at the new owner. Reviewers cannot tell those apart from the outside, so the one that gets explained on the registration is the one that survives. ### How to fix it Register the domain the business actually trades under. Where the redirect is deliberate — a rebrand, an acquisition, a franchisor site — say so in the campaign description and make the destination state the relationship in visible page content. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30907` | yes | | Bandwidth/DCA | `603` | yes | ### Notes Absorbs BRD-131. The ambiguous case named in the catalog is a redirect to a parent company or franchisor: legitimate, and indistinguishable from a hijack unless the destination says so on the page. --- ## WEB-079 — A redirected URL is reviewed at its destination, not where it was submitted > Where a submitted URL redirects off the registered domain, the full content review applies to the destination, so the destination is what the registration must be able to survive. - **Rule ID:** WEB-079 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand.website redirect chain` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** Deterministic (settled in code from the submitted values) - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** CTIA, AT&T - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-079/ ### Why this rule exists Reviewers follow the chain and judge whatever they land on, which means a brand can be assessed against a site it did not submit and does not control — a marketing shortener, an agency landing page, a marketplace storefront. The business believes its own site was reviewed and cannot understand the finding, because nothing in the rejection names the page that produced it. ### How to fix it Register the URL the chain actually ends on, or remove the off-domain hop so the submitted address serves the content directly. Done when brand.website and the final URL of the fetch are the same registrable domain. ### Example of a compliant value ```text brand.website: https://acmecoffee.com — fetch ends on acmecoffee.com, not on a link-shortener or an agency landing page. ``` ### Common mistakes - Pointing the registration at the destination fixes this and can still fail WEB-077 if the destination belongs to a different business — moving the URL does not change whose site is being judged. ### Notes A scoping rule: it changes what every other content check reads. Fenced against its two neighbours — WEB-075 fails any redirect at all because TCR forbids 30x on a fetched URL, and WEB-077 judges whether the destination is an unrelated brand. This one is the mechanical fact that the destination is a different domain, which is what makes the other two matter. --- ## WEB-081 — A newly registered domain is scored as higher risk > A recently registered, disposable or short-lived domain raises the risk score on the brand, independently of what the site contains. - **Rule ID:** WEB-081 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand.website domain registration date` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** External record we cannot query — reported as a warning to verify - **Fix type:** Wait on an external system or a required interval - **Required by:** Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-081/ ### Why this rule exists Fraudulent registrations need a domain, and the cheapest one is bought the same week. No provider publishes a threshold, so this is scored rather than refused — which is worse to be on the wrong side of than a rejection, because the brand verifies and then quietly underperforms with no finding to point at. A genuinely new business is in exactly the same position and can do nothing about it. ### How to fix it Where the business owns an older domain, register that one. Where it does not, expect slower vetting and stronger scrutiny of everything else, and make the rest of the registration corroborate the business as heavily as it can — matching contact details, a published address, an active social presence. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30961` | yes | ### Check this yourself **How old is this domain — and if it is only weeks old, have you planned for a slower vet rather than a resubmission?** 1. Check the registration date in your registrar account or a public WHOIS lookup. 2. Where the business owns an older domain, register that one instead. 3. Where it does not, make the rest of the record corroborate the business as heavily as it can: matching contact details, a published address, an active social presence. *What wrong looks like:* Nothing is refused. The brand verifies and quietly underperforms, and resubmitting an unchanged registration produces the same score — no form edit changes a domain's age. ### Notes Absorbs WEB-086, which states the same signal together with its remediability: no form edit changes a domain's age. We run no WHOIS lookup, so the user is the one who has to know how old their domain is — and if it is weeks old, to plan for a slower vet rather than resubmitting into the same score. --- ## WEB-083 — Hosting shared with malicious neighbours is scored against the domain > A domain resolving to an IP or ASN shared with known-malicious sites carries that reputation into the brand score. - **Rule ID:** WEB-083 - **Layer:** Website (`WEBSITE`) - **Checks:** `resolved IP and ASN neighbours` - **Severity:** MEDIUM — Usually survives review, but lowers your trust score or invites manual review. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** External record we cannot query — reported as a warning to verify - **Fix type:** Wait on an external system or a required interval - **Required by:** Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-083/ ### Why this rule exists Reputation is assessed at the address as well as the name, so a business on cheap shared hosting inherits whatever its neighbours did. Nothing about the business causes it and nothing on the site reveals it, which makes it one of the hardest findings to act on — the brand looks clean from every angle the operator can see. ### How to fix it Where vetting repeatedly stalls with no finding on the content, move the site to a dedicated IP or a reputable host and re-submit. Done when the domain resolves to an address whose other tenants you can account for. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30961` | yes | ### Check this yourself **Does this domain share its IP address with sites you cannot account for?** 1. Run a reverse-IP lookup on the domain. 2. Hundreds of unrelated sites on the same address is the signal — cheap shared hosting inherits whatever its neighbours did. 3. The only fix is moving to a dedicated IP or a reputable host, then resubmitting. *What wrong looks like:* Vetting stalls repeatedly with no finding on the content. Nothing about the business caused it and nothing on the site reveals it, so the brand looks clean from every angle the operator can see. ### Notes We resolve no addresses and hold no reputation feed. The user can check this themselves with a reverse-IP lookup on their domain: if it shares an address with hundreds of unrelated sites, that is the signal, and changing host is the only fix. --- ## WEB-084 — A lookalike domain is treated as a phishing signal > A domain that imitates a better-known brand through misspelling, homoglyphs or an added word is screened as a phishing indicator. - **Rule ID:** WEB-084 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand.website domain string` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** External record we cannot query — reported as a warning to verify - **Fix type:** Wait on an external system or a required interval - **Required by:** Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-084/ ### Why this rule exists Impersonation domains are the standard vehicle for credential phishing over SMS, so screening the name itself is cheap and catches attacks before any content exists to judge. Legitimate businesses collide with it innocently — a reseller whose domain contains the manufacturer's name, a regional franchise — and the rejection reads as an accusation rather than a score. ### How to fix it Where the domain contains another company's brand, be able to show the relationship — an authorised-reseller page, a franchise agreement named on the site. Where it does not, expect a slower vet and make the brand record and the site agree on the business name exactly. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30960` | yes | ### Check this yourself **Does this domain contain, or closely resemble, another company's brand name?** 1. Read the domain as a stranger would and name the brand it resembles — misspellings, homoglyphs and an added word all count. 2. Where the resemblance is a real relationship, publish it: an authorised-reseller page or a franchise agreement named on the site. 3. Where it is coincidence, expect a slower vet and make the brand record and the site agree on the business name exactly. *What wrong looks like:* A reseller whose domain carries the manufacturer's name is screened as a phishing indicator, and the rejection reads as an accusation rather than as a score. ### Notes The catalog flags this as unverified: no primary source names homoglyph domains as a rule, and the nearest hooks are Twilio's obfuscated-URL language and codes 30960/30961. Recorded as a heuristic, not as a quoted requirement. We run no similarity screen, so the user should judge their own domain against the brands it resembles. --- ## WEB-085 — Adverse reputation on the domain blocks the brand > Third-party reputation signals on the domain — prior compromise, complaint volume, adverse media, blocklist entries — block the registration. - **Rule ID:** WEB-085 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand.website domain reputation` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** External record we cannot query — reported as a warning to verify - **Fix type:** Wait on an external system or a required interval - **Required by:** Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-085/ ### Why this rule exists Carriers buy reputation data and apply it before anyone reads the site, so a domain that was compromised two owners ago arrives already refused. The business has no visibility into which feed flagged it or why, and the rejection names none of that, which is why brands re-submit unchanged registrations several times before anyone tells them the domain is the problem. ### How to fix it Check the domain against the public blocklists and safe-browsing services before registering, and clear whatever they report — a compromised page, an old redirect, a listing from a previous owner. Where the history belongs to a previous owner, expect to have to appeal with evidence of the transfer. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth | `TFV 1604` | yes | | Bandwidth | `TFV 1609` | yes | ### Check this yourself **Is this domain clean on the public blocklists and safe-browsing services today?** 1. Check it against Google Safe Browsing, VirusTotal and the major blocklists — these are the feeds the vendors draw on. 2. Clear whatever they report: a compromised page, an old redirect, a listing left by a previous owner. 3. Where the history belongs to a previous owner, have evidence of the transfer ready for an appeal. *What wrong looks like:* A domain compromised two owners ago arrives already refused. The rejection names no feed and no reason, so unchanged registrations are submitted several times before anyone mentions the domain. ### Notes Absorbs WEB-082, prior compromise being one of the signals the same lookup returns. We query no reputation source. The user has to run this themselves — Google Safe Browsing, VirusTotal and the major blocklists are the ones the vendors draw on — and to do it before submitting, because a blocked domain burns the registration rather than pausing it. --- ## WEB-090 — The message flow must deep-link the opt-in page, not the homepage > The URL given in the message flow must point at the page carrying the consent surface, not at the site root. - **Rule ID:** WEB-090 - **Layer:** Website (`WEBSITE`) - **Checks:** `campaign.message_flow` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** Deterministic (settled in code from the submitted values) - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** TCR, Twilio, Bandwidth, AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-090/ ### Why this rule exists A reviewer given a homepage has to hunt for the opt-in, and if they do not find it quickly they reject. Deep-linking converts a search into a single click, and it is one of the cheapest possible improvements to approval odds. ### How to fix it Replace the homepage link in the message flow with the direct URL of the page holding the consent checkbox. ### Example of a compliant value ```text https://acmecoffee.com/signup rather than https://acmecoffee.com ``` --- ## WEB-098 — The QR landing page must be publicly reachable > The page a QR code opens must be fetchable by anyone — no login, geo-gate, app-install wall or captive portal in front of it. - **Rule ID:** WEB-098 - **Layer:** Website (`WEBSITE`) - **Checks:** `QR destination fetch` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** Twilio, Bird - **Applies:** Applies when consent was collected by QR code. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-098/ ### Why this rule exists A QR code is scanned in a shop, on a table, at an event — and if the page behind it demands an app or a login, the consumer never opts in and the reviewer never sees the surface either. The captive-portal case is the one that catches careful operators: a code that works perfectly on the store Wi-Fi opens nothing at all for someone on a mobile network, and nobody tests it that way. ### How to fix it Host the QR destination on a public https page on the brand domain, with no login, no app interstitial and no dependence on the venue network. Done when scanning the code on a phone with mobile data and no app installed shows the opt-in. ### Common mistakes - Test the printed code, not the URL. A code printed from a draft, or one pointing at a short link whose account has lapsed, opens something entirely different from what was designed. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30909` | yes | | Bandwidth/DCA | `804` | yes | --- ## WEB-101 — The QR landing page must display the registered brand name > The page a QR code opens must display the brand name as registered, so the consumer can see whose programme they are joining. - **Rule ID:** WEB-101 - **Layer:** Website (`WEBSITE`) - **Checks:** `QR landing page branding` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** Aerialink - **Applies:** Applies when consent was collected by QR code. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-101/ ### Why this rule exists A QR code is opaque by design: the consumer has no idea where it goes until the page loads, so the page is the first and only chance to say who is asking for their number. An unbranded hosted form — the platform's template with the merchant name left at its default — gives them nothing to recognise, and gives the reviewer nothing to tie the surface to the brand. ### How to fix it Put the registered brand name or DBA in the heading of the landing page, not only in the page title or the platform footer. Done when someone who has just scanned the code can see whose programme it is without scrolling. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Aerialink | `806` | yes | ### Notes Distinct from WEB-102, which asks whether the landing page carries the full disclosure set. A page can carry every required sentence and still never say who is sending. --- ## WEB-107 — Age-restricted content on the site must sit behind a working age gate > Where the site or the campaign carries age-restricted content, the site must present a functioning age gate in front of it. - **Rule ID:** WEB-107 - **Layer:** Website (`WEBSITE`) - **Checks:** `age-gate interstitial on the site` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page; Human check — only someone holding the document can settle it - **Fix type:** Fix the website — no form edit clears it - **Required by:** T-Mobile, Twilio, AWS, CTIA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-107/ ### Why this rule exists The gate is what keeps a minor from reaching alcohol, tobacco, firearms or adult material through a link in a text message, and carriers charge per-message violation fees rather than merely rejecting, so the cost of getting it wrong keeps accruing. Businesses that gate their checkout often leave the marketing pages open, which is the version of this a compliance-minded operator is most likely to trip. ### How to fix it Put a date-of-birth gate in front of every page carrying restricted content, enforced server-side so a direct link cannot skip it. Done when opening a product URL in a private window shows the gate before the product. ### Common mistakes - Gating the checkout and leaving the catalog open fails: the reviewer opens a product page directly and never sees the gate. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30956` | yes | | T-Mobile | `706` | yes | ### Check this yourself **Opening a restricted product URL directly, in a fresh private window, are you stopped by the gate before you see the product?** 1. Copy a deep link to a restricted page — not the homepage — and open it in a private window. 2. Confirm the gate appears before any restricted content is rendered. 3. Repeat for the marketing and catalog pages, not just the checkout. *What wrong looks like:* The checkout is gated and the catalog is open. The reviewer opens a product page directly, never sees the gate, and carriers charge per-message violation fees rather than merely rejecting. ### Notes Absorbs MSG-176, which states the requirement from the message-copy side, and BRD-280 from the brand-eligibility side. The gate's form is WEB-108 (a full date of birth), its position WEB-109, its threshold WEB-112, and whether it survives a determined visitor WEB-110 — that last one is why HUMAN is declared alongside CRAWL here: a crawl can see a gate and cannot tell whether it holds. The user has to try to bypass their own gate, by opening a restricted URL directly in a fresh browser, and confirm they are stopped. --- ## WEB-109 — The age gate must come before the restricted content, not after it > The age gate must be presented before any age-restricted content is accessible, including on a page reached by a direct link. - **Rule ID:** WEB-109 - **Layer:** Website (`WEBSITE`) - **Checks:** `page flow ordering` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** Twilio, Aerialink - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-109/ ### Why this rule exists A gate that appears after the visitor has already seen the product has protected nobody — the harm the rule addresses happened on page load. The usual cause is a gate wired into the home page template only, so every deep link from a message, a search result or a QR code lands past it. ### How to fix it Enforce the gate on every restricted URL rather than on the home page, and check the answer server-side before the page renders. Done when pasting a product URL into a fresh browser shows the gate first. ### Common mistakes - For a QR opt-in the date of birth must be captured before consent is collected, not on the confirmation step — a gate after the number has been submitted is too late for both requirements. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30956` | yes | ### Notes Conditional on age-restricted content being present, the same condition as WEB-107, and carried in the criteria for the same reason: tagging on the declared ageGated attribute would exempt exactly the brands that under-declare. --- ## WEB-110 — The age gate must not be trivially bypassable > The age gate must not be defeatable by dismissing it, by loading a page directly, or by clearing a cookie. - **Rule ID:** WEB-110 - **Layer:** Website (`WEBSITE`) - **Checks:** `age-gate implementation` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** Human check — only someone holding the document can settle it - **Fix type:** Fix the website — no form edit clears it - **Required by:** Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-110/ ### Why this rule exists A gate implemented in front-end code is decoration: it stops nobody who does not want to be stopped, and it stops the reviewer not at all, since the first thing they try is the direct URL. Businesses build it this way because that is what the plugin does, and because the version that actually holds requires the server to know the answer. ### How to fix it Enforce the gate server-side: refuse to render restricted pages until the age has been submitted and recorded for the session. Done when a direct link, a dismissed dialog and a cleared cookie all still land on the gate. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30956` | yes | ### Check this yourself **Does the gate still hold after a direct link, a dismissed dialog and a cleared cookie?** 1. Open a restricted URL directly in a private window. 2. Press Escape on the dialog, and try to interact with the page behind it. 3. Clear the cookie and reload. If any of the three gets through, the gate is decoration. *What wrong looks like:* A front-end plugin renders the page and covers it with an overlay. It stops nobody who does not want to be stopped, and it stops the reviewer not at all — the first thing they try is the direct URL. ### Notes Nothing we fetch can tell a real gate from a dismissible overlay, so this one is on the user to test: open a restricted product URL directly in a private window, press Escape on the dialog, and clear the cookie between attempts. If any of the three gets through, the gate is decoration and WEB-107 will be judged on it. --- ## WEB-111 — Alcohol delivery must gate the ordering flow, not just a splash page > An alcohol delivery brand must present the age gate on the ordering flow itself, not only on a marketing splash page. - **Rule ID:** WEB-111 - **Layer:** Website (`WEBSITE`) - **Checks:** `checkout and ordering flow` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** Twilio - **Applies:** Applies when the vertical is alcohol_delivery. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-111/ ### Why this rule exists Delivery is the case where the gate has to hold, because the transaction ends with alcohol arriving at a door rather than with someone standing at a counter. A splash gate on the marketing site is satisfying to build and does nothing for the ordering app or the checkout subdomain, which is usually a different system entirely. ### How to fix it Add the date-of-birth gate to the ordering flow — the cart, the checkout, and the app — as well as to the marketing site, and verify age again at handover. Done when the order path itself refuses an under-21 date of birth. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30956` | yes | ### Notes Twilio scopes 30956 to "all linked websites and opt-in flows", which is what makes a splash-page-only gate insufficient here. Tagged to the alcohol_delivery vertical per the catalog condition; the general alcohol threshold rule is WEB-112 and applies whether or not delivery is involved. --- ## WEB-112 — An alcohol age gate must enforce 21, not 18 > Where the restricted content is alcohol, the age gate must enforce a 21+ threshold rather than 18+. - **Rule ID:** WEB-112 - **Layer:** Website (`WEBSITE`) - **Checks:** `age-gate threshold` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** Twilio, CTIA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-112/ ### Why this rule exists Twenty-one is the US drinking age, so an 18+ gate admits a whole cohort the rule exists to exclude and does it while looking compliant. The mistake travels with software: templates and plugins ship with 18 as the default because that is the threshold most of the world uses, and nobody changes it. ### How to fix it Set the gate's minimum age to 21 wherever alcohol content is served, and check the plugin default rather than assuming it. Done when entering a date of birth for a twenty-year-old is refused. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30955` | yes | ### Notes Conditional on alcohol content being present, carried in the criteria rather than as a tag — there is no alcohol attribute on the registration, and the declared ageGated flag says nothing about which substance is behind the gate. --- ## WEB-115 — A landing page reached from a message must publish a postal address > Any landing site a message links to must publish contact information including a postal mailing address. - **Rule ID:** WEB-115 - **Layer:** Website (`WEBSITE`) - **Checks:** `landing page contact block` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** CTIA, AT&T - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-115/ ### Why this rule exists CTIA requires the destination of a bulk message to identify who is behind it, and a postal address is the element that makes the owner findable by someone who has no account and no relationship with them. It is also the element businesses drop first when they build a campaign landing page separately from the main site, because the page is designed to convert rather than to inform. ### How to fix it Add the business postal address to the footer of every page a message can reach, alongside a phone number or email. Done when the landing page shows a street address, a city, a state and a postal code. ### Notes Distinct from WEB-114, which requires the landing page to name the owner: this rule is about the address specifically, which is the part most often missing from an otherwise identified page. --- ## WEB-116 — A landing page that collects personal information must publish a privacy policy > Any landing site collecting personal information must carry a conspicuously accessible privacy policy. - **Rule ID:** WEB-116 - **Layer:** Website (`WEBSITE`) - **Checks:** `landing page policy link` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** AT&T, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-116/ ### Why this rule exists The page where a consumer types their phone number is the page where they are entitled to know what happens to it, and a policy two clicks away on a different domain does not reach them at the moment it matters. Campaign landing pages are built to convert and routinely ship without the footer the main site has, so this fails on exactly the page the messages point at. ### How to fix it Link the privacy policy from the landing page itself, next to the form rather than only in a footer nobody scrolls to. Done when the policy is reachable in one click from the page that collects the number. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio | `7100` | yes | ### Notes WEB-045 asks the same question of the brand home page. Both are kept because a brand routinely satisfies one and not the other: the main site has a footer and the campaign landing page does not. --- ## WEB-119 — The whole site must be screened for prohibited content, not just the landing page > Prohibited-content screening must cover the entire website, not only the page the campaign points at. - **Rule ID:** WEB-119 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website (all pages)` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** TCR, Twilio, AWS, T-Mobile - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-119/ ### Why this rule exists Vetting crawls the brand's whole site, so a compliant campaign landing page does not protect a business whose shop sells vape hardware two clicks away. This is a common and expensive surprise: the campaign content is clean and the registration still fails on the brand. ### How to fix it Audit the whole site against the prohibited-content list before registering. Where the business genuinely sells a restricted category alongside a compliant one, expect the brand to be judged on the restricted category. ### Notes Requires multi-page crawling. Today the product fetches a single page, so this rule is a known coverage gap rather than an implemented check. --- ## WEB-122 — No adult content on the site or any page it links to > The brand website must not host or promote adult, pornographic, escort or nudity content. - **Rule ID:** WEB-122 - **Layer:** Website (`WEBSITE`) - **Checks:** `crawled website content` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Hard stop — not remediable, resubmission will not help - **Required by:** Twilio, AT&T, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-122/ ### Why this rule exists Adult content is the category carriers refuse outright rather than gate, because the recipient of an unwanted message has no way to un-see it and the complaint goes straight to the carrier. The site is screened as well as the messages because the brand is what carries the traffic: a compliant booking campaign registered by an adult venue is refused on the venue, not on the campaign. ### How to fix it This category cannot be registered for 10DLC in the US. There is no age gate or paywall that makes it registrable, and no re-framing of the campaign that separates it from the brand. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30953` | no | ### Notes The message-side twin is MSG-SHAFT-SEX. Both are kept because they fail independently: this one fires on a clean campaign whose brand website carries the content. --- ## WEB-123 — No hate-group brand > The brand website must not host or promote the identity, materials or fundraising of a hate group. - **Rule ID:** WEB-123 - **Layer:** Website (`WEBSITE`) - **Checks:** `crawled website content` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Hard stop — not remediable, resubmission will not help - **Required by:** Bandwidth, CTIA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-123/ ### Why this rule exists CTIA names hate groups as a category carriers will not carry, and the assessment is of the organisation rather than of any particular message — so nothing in the campaign can rescue it. Public listings are consulted alongside the site, which means a brand can be refused on an identification it has never seen and cannot argue with inside the registration. ### How to fix it This category cannot be registered. Where the brand is a research, journalism or advocacy organisation whose site quotes such material to counter it, say so in the campaign description and expect the registration to be reviewed by a person. ### Notes Judged partly from external listings the product does not hold, so a PASS here is a PASS on the retrieved content only. Ranked alongside WEB-122 as a refusal rather than a finding. --- ## WEB-124 — No advertising that ridicules a protected group or trivialises an atrocity > The brand website must not host or promote advertising that misrepresents or ridicules people by age, colour, national origin, race, religion, sex, sexual orientation or disability, or that trivialises a historic atrocity. - **Rule ID:** WEB-124 - **Layer:** Website (`WEBSITE`) - **Checks:** `crawled website content` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the submitted form - **Fix type:** Fix the website — no form edit clears it - **Required by:** AT&T - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-124/ ### Why this rule exists AT&T bars this in its own schedule, separately from hate-group content, because the harm is done by ordinary marketing rather than by an extremist organisation — an edgy campaign, a joke about a disability, a genocide used as a punchline in a sale. Businesses get here through a copywriter reaching for shock rather than through anything anyone would call a policy, which is why the fix is usually one page. ### How to fix it Remove or rewrite the offending copy and imagery, then re-crawl before resubmitting. Done when nothing on the site sells a product by reference to who somebody is. ### Example of a compliant value ```text Replace a campaign page joking about an ethnicity with the same offer stated plainly: "Acme Coffee — 20% off all espresso blends this weekend." ``` ### Notes Severity divergence inside the single source: AT&T Schedule 1 grades the discrimination clause HIGH and the atrocity-trivialisation clause MEDIUM. Strictest kept. --- ## WEB-125 — No graphic violence on the linked site > The brand website must not host or promote excessive or graphic violence. - **Rule ID:** WEB-125 - **Layer:** Website (`WEBSITE`) - **Checks:** `crawled website content` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI vision over a consent artifact (screenshot, scan, MMS media) - **Fix type:** Fix the website — no form edit clears it - **Required by:** AT&T, CTIA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-125/ ### Why this rule exists The rule exists for the person who follows a link from a text message and is shown something they did not ask to see, which is why it is assessed on the destination rather than on the message. It reaches ordinary businesses through imagery chosen for impact — a self-defence course, a game studio, a haunted attraction — where nothing about the business is objectionable and one page is. ### How to fix it Move graphic imagery behind the age gate rather than onto the public landing page, and choose a different image for the page the messages link to. Done when the destination of every campaign link is safe to open in public. ### Example of a compliant value ```text Campaign link points at https://acmecoffee.com/events — a text-and-photography event page — rather than at the artwork gallery. ``` ### Notes VISION because the finding is in the pictures: a site whose copy is unremarkable can fail on a single image, and a text-only crawl sees none of it. --- ## WEB-126 — No firearms, ammunition or explosives sales on the site > The brand website must not host or promote the sale of firearms, ammunition, explosives or fireworks. - **Rule ID:** WEB-126 - **Layer:** Website (`WEBSITE`) - **Checks:** `crawled website content` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Hard stop — not remediable, resubmission will not help - **Required by:** Twilio, Bandwidth, Telnyx, T-Mobile, Verizon - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-126/ ### Why this rule exists Two carriers treat firearms as age-gateable and two providers ban them outright, so the same site is registrable at one destination and refused at another — and a brand that builds around the permissive reading discovers the strict one at submission. The harm the strict reading protects against is a channel that reaches a phone without any of the checks a gun sale otherwise carries. ### How to fix it This category cannot be registered under the strict reading the registry applies. Where the business sells instruction, membership or non-firearm goods, separate that site from the sales catalog and register the one with no purchase path. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30957` | no | ### Notes Genuine divergence, not a strictness difference: T-Mobile §5.7 and Verizon treat firearms as age-gateable, Telnyx permits education-only content but bans sales, and Twilio and Bandwidth ban the category outright. The strict-superset model takes the outright ban as the default; a brand submitting only to a permissive destination should read this as a warning rather than a refusal. --- ## WEB-127 — No tobacco or vape product content on the site > The brand website must not host or promote tobacco, vape, e-cigarette or nicotine product content. - **Rule ID:** WEB-127 - **Layer:** Website (`WEBSITE`) - **Checks:** `crawled website content` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Hard stop — not remediable, resubmission will not help - **Required by:** Twilio, Telnyx, Bandwidth, T-Mobile - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-127/ ### Why this rule exists Nicotine marketing reaching a phone is the specific harm the age-gating regime exists to prevent, and carriers found that gates on retail sites do not survive contact with a link in a text message. Operators in this trade are usually compliant with every rule their own regulator imposes, which is why the refusal lands as a surprise: the sector's own age verification is not the standard being applied. ### How to fix it This category cannot be registered under the strict reading. Where a general retailer carries a small nicotine range, expect the brand to be judged on that range rather than on the rest of the catalog. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30958` | no | ### Notes Age-gateable under T-Mobile §5.7 and banned outright by Twilio, so this is a real divergence between destinations. Strictest kept, per the superset model. The message-side twin is MSG-SHAFT-TOBACCO. --- ## WEB-128 — No cannabis, CBD, hemp or kratom content anywhere on the site > The brand website must not host or promote cannabis, CBD, hemp, kratom, dispensary or drug-paraphernalia content. - **Rule ID:** WEB-128 - **Layer:** Website (`WEBSITE`) - **Checks:** `crawled website content` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Hard stop — not remediable, resubmission will not help - **Required by:** Twilio, Bandwidth, Telnyx, AWS, TCR - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-128/ ### Why this rule exists The industry applies federal law where federal and state law diverge, so a fully licensed dispensary in a legal state is refused exactly like an unlicensed one — and this is the rule that surprises operators more than any other, because everything about their business is lawful where they stand. The screen covers the whole site rather than the landing page, so a wellness retailer with one CBD line fails on that line. ### How to fix it This category cannot be registered for 10DLC in the US regardless of state licensing. Removing the product pages does not help while the business is the dispensary; the refusal is on the brand. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30940` | no | | Bandwidth/DCA | `701` | no | ### Notes AWS marks the category non-remediable, and Telnyx extends the prohibition to shipping services for these products and cites a T-Mobile fine. State legality is irrelevant to the outcome and saying so early saves the appeal. --- ## WEB-129 — No gambling content on the site > The brand website must not host or promote casino, sportsbook, lottery or online gambling content. - **Rule ID:** WEB-129 - **Layer:** Website (`WEBSITE`) - **Checks:** `crawled website content` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Hard stop — not remediable, resubmission will not help - **Required by:** AWS, Bandwidth, Telnyx - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-129/ ### Why this rule exists Gambling is banned by some providers and routed to a special use case by others, so the safe default is refusal — and the split is invisible from outside, which is how a licensed operator ends up registering into a destination that will not take it. The consumer harm behind the strict reading is the same one age gates exist for, arriving on a device with no gate in front of it. ### How to fix it Confirm before registering whether your destination offers a gambling or sweepstakes use case; several refuse the category outright. Where one exists, register under it rather than under marketing. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30944` | no | ### Notes Telnyx allows a licensed-and-age-gated carve-out and AWS marks the category non-remediable. Strictest kept. The message-side twin is MSG-GAMBLING. --- ## WEB-130 — No high-risk financial services on the site > The brand website must not host or promote payday and short-term high-interest lending, third-party loan solicitation, debt collection, credit repair, debt forgiveness, crypto or retail investment content. - **Rule ID:** WEB-130 - **Layer:** Website (`WEBSITE`) - **Checks:** `crawled website content` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Hard stop — not remediable, resubmission will not help - **Required by:** AWS, Bandwidth, Telnyx, Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-130/ ### Why this rule exists This is the category most associated with consumer-harm complaints on SMS, and AWS records it as not eligible for resubmission at all — a rejection here ends the registration rather than opening a fix loop. The line that decides an outcome is first-party versus third-party: a bank servicing its own loans is a different business from a site that solicits borrowers for other lenders, and the site is where the difference shows. ### How to fix it This business model cannot be registered. A regulated lender servicing its own customers is a different category — if that is you, remove the acquisition-style offers from the site and declare the direct-lending attribute instead of concealing the lending. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30942` | no | | Bandwidth/DCA | `709` | no | ### Notes AWS states the category is "not eligible for resubmission under A2P 10DLC" — permanently non-remediable, unlike most BLOCKING findings. The first-party carve-out is what keeps a licensed lender registrable and must not be dropped: it is the same carve-out MSG-HIGH-RISK-FINANCIAL carries on the message side. --- ## WEB-131 — No lead-generation, affiliate-marketing or SEO-services content on the site > The brand website must not host or promote lead generation, affiliate marketing or SEO and marketing-agency services. - **Rule ID:** WEB-131 - **Layer:** Website (`WEBSITE`) - **Checks:** `crawled website content` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** AWS, Bandwidth, Telnyx, Twilio - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-131/ ### Why this rule exists Selling consumer contact details onward is the activity the whole consent framework exists to stop, so a site that advertises it describes a business model carriers refuse rather than a page they want edited. The trap for honest businesses is the word rather than the trade: an ordinary shop with a partner or referral programme page reads, to a screen looking for exactly this, like a lead broker. ### How to fix it Remove lead-generation, affiliate and SEO-services copy from the brand website and re-crawl before resubmitting; Telnyx states the remediation in exactly those terms. Done when nothing on the site offers to pass a visitor's details to anybody else. Where that copy describes what the business actually does, the registration cannot be saved by editing. ### Example of a compliant value ```text Replace "Join our affiliate network and monetise your traffic" with "Refer a friend and you both get $10 credit — we never share your friend's details." ``` ### Common mistakes - AWS and Twilio both mark their codes non-remediable, so a rejection under this heading ends that campaign even where the site edit would have been enough. Fix the site before submitting, not after. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30951` | no | | Bandwidth/DCA | `708` | no | ### Notes failureClass is TERMINAL_WEBSITE because the common case is removable copy and Telnyx publishes exactly that remediation, while the provider codes are marked non-remediable. The two answer different questions — ours is what to do before submitting, theirs is what happens after a rejection. --- ## WEB-133 — Sweepstakes content on the site must be registered as sweepstakes > The brand website must not host or promote sweepstakes, prize-draw or contest-entry content that the registration does not declare. - **Rule ID:** WEB-133 - **Layer:** Website (`WEBSITE`) - **Checks:** `crawled website content` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** AWS - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-133/ ### Why this rule exists Prize promotions carry their own use case and their own disclosure obligations, and a brand running one under a marketing registration has skipped both. AWS rejects on the brand rather than the campaign, so a business whose messages never mention the giveaway is still refused for the page that hosts it. ### How to fix it Register under the sweepstakes use case where the promotion is live, and publish the official rules alongside the entry page. Where the promotion is over, take the page down or mark it closed before resubmitting. ### Example of a compliant value ```text Use case: SWEEPSTAKE, with official rules published at https://acmecoffee.com/rules and linked from the entry page. ``` ### Notes Related to but distinct from MSG-206, which reads the campaign copy. This one fires on site evidence alone, which is the case a campaign-only screen cannot see. --- ## WEB-134 — No multilevel-marketing content on the site > The brand website must not host or promote multilevel-marketing or distributor-recruitment content. - **Rule ID:** WEB-134 - **Layer:** Website (`WEBSITE`) - **Checks:** `crawled website content` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Hard stop — not remediable, resubmission will not help - **Required by:** Telnyx - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-134/ ### Why this rule exists MLM recruitment over SMS produces complaint volumes carriers treat as a category problem rather than a sender problem, so the screen is applied to the business rather than to the messages. Individual distributors are caught by it while believing they are registering an ordinary small retail business, because from the inside that is what it is. ### How to fix it This business model cannot be registered. An independent distributor cannot separate themselves from it by registering the personal brand instead — the site is what is screened. ### Notes Single-source in the catalog (Telnyx AUP) but authored universally: the message-side twin MSG-LEAD-GEN carries the same prohibition on recruitment content across several providers, so narrowing this to one provider would drop a real requirement. --- ## WEB-135 — No site impersonating another service to collect credentials > The brand website must not host or promote impersonation of a legitimate service in order to capture credentials, identity numbers or other sensitive data. - **Rule ID:** WEB-135 - **Layer:** Website (`WEBSITE`) - **Checks:** `crawled website content` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Hard stop — not remediable, resubmission will not help - **Required by:** Twilio, CTIA - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-135/ ### Why this rule exists This is the phishing pattern the whole landing-page review exists to catch: a page that looks like a bank, a carrier or a delivery service, reached from a text message, collecting whatever the real one would ask for. It is judged from design and form fields together, because the copy alone is by construction indistinguishable from the genuine article. ### How to fix it This cannot be registered. Where the brand is an authorised partner using another company's marks legitimately, state the relationship in visible page content and expect the registration to be reviewed by a person. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30960` | no | ### Notes CTIA A65-03 extends the same prohibition to brand impersonation on any message landing page or download, and A65-04 to promotion of illegal activity. Both are discharged here. --- ## WEB-136 — No malware or insecure downloads served from the site > The brand website must not host or promote malware, or application downloads served from non-secure locations. - **Rule ID:** WEB-136 - **Layer:** Website (`WEBSITE`) - **Checks:** `crawled website content` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** CTIA, AT&T - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-136/ ### Why this rule exists A link in a text message that ends in a drive-by download is the highest-severity outcome in the whole framework, so the destination is screened for it directly. The common cause is not malice: an unmaintained plugin on a small business site gets compromised, the owner never sees the injected script, and the first they hear of it is a registration refusal that says nothing about their site being hacked. ### How to fix it Scan and clean the site, update the platform and plugins, and serve every download over https from your own domain. Done when a safe-browsing check on the domain comes back clear and no download link points at a plain-HTTP host. ### Example of a compliant value ```text App links point at https://apps.apple.com/... and https://play.google.com/... rather than at a self-hosted APK. ``` ### Common mistakes - Cleaning the site does not clear the blocklist entry. Request a review with the safe-browsing service as well, or the domain reputation rules keep failing after the malware is gone. ### Notes The landing-page malware screen is routed to WEBSITE by the catalog's layer-ownership rule, so it carries no MESSAGE_CONTENT alias: the message-side row was folded into this obligation rather than kept as a separate one. --- ## WEB-137 — No deceptive marketing claims on the site > The brand website must not host or promote unsubstantiated health or product claims, fabricated urgency, unverifiable guarantees, unauthenticatable testimonials or false endorsements. - **Rule ID:** WEB-137 - **Layer:** Website (`WEBSITE`) - **Checks:** `crawled website content` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** Twilio, Bandwidth, AT&T, CTIA, FTC - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-137/ ### Why this rule exists CTIA folds the FTC truth-in-advertising rules into the messaging framework, so the site is read against them and a claim that would draw an FTC letter draws a carrier rejection first. Almost every business trips this through ordinary conversion copywriting — a countdown that resets, a "doctor recommended" with no doctor, a testimonial with initials instead of a name — none of which was written to deceive anyone. ### How to fix it Qualify or remove each claim: name the source for a health or performance claim, make the deadline on any urgency real, and attribute testimonials to identifiable people. Done when every claim on the page could be defended with something you hold. ### Example of a compliant value ```text "In a 2025 survey of 400 Acme Coffee subscribers, 82% said they brewed more often at home" — rather than "everyone brews better with Acme". ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30962` | yes | ### Notes Distinct from WEB-024, which asks whether the site is real at all. A completely genuine business fails this rule on its marketing copy. --- ## WEB-139 — No counterfeit goods or falsified documents sold on the site > The brand website must not host or promote counterfeit, replica or imitation designer goods, fake identification or falsified documentation. - **Rule ID:** WEB-139 - **Layer:** Website (`WEBSITE`) - **Checks:** `crawled website content` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Hard stop — not remediable, resubmission will not help - **Required by:** AT&T - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-139/ ### Why this rule exists AT&T bars the category outright because the messages promoting it are, by construction, promoting a crime — and fake identification carries a harm beyond the trade itself. The replica trade advertises openly enough that this is usually read straight off a product page rather than inferred. ### How to fix it This cannot be registered. A resale business that deals in authenticated genuine goods should say so on the product pages and in the campaign description, since the distinction is exactly what the screen is looking for. ### Notes Severity divergence in the source: AT&T Schedule 1 grades counterfeit goods HIGH and fake identification BLOCKING. Strictest kept, and both limbs are one screen because they sit on the same catalog page in practice. --- ## WEB-140 — No law-evasion or questionable-legality products in the catalog > The brand website must not host or promote law-evasion and protection-bypass products, or products of questionable legality. - **Rule ID:** WEB-140 - **Layer:** Website (`WEBSITE`) - **Checks:** `crawled website content` - **Severity:** MEDIUM — Usually survives review, but lowers your trust score or invites manual review. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** AT&T - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-140/ ### Why this rule exists AT&T names a specific old list — radar detectors, descramblers, copyright-bypass tools, miracle cures, witchcraft and good-luck merchandise — and it survives because those categories still attract the complaint patterns that put them there. A general retailer meets it through a single novelty line nobody thought about, which is why the fix is almost always the catalog rather than the business. ### How to fix it Remove the named product lines from the catalog, or drop the effectiveness claim where the item is a novelty. Done when nothing in the catalog is sold as a way around a law or as a remedy it cannot deliver. ### Example of a compliant value ```text List a "lucky bean charm — novelty gift, no claims made" rather than "brings prosperity within 7 days". ``` ### Notes Severity divergence inside the source: the questionable-legality clause is graded HIGH and the descrambler and radar-detector clauses MEDIUM. Graded MEDIUM overall because the enforcement in practice attaches to the product line rather than the brand, and the fix is a catalog edit. --- ## WEB-141 — No infringing content on the site > The brand website must not host or promote content that infringes another party's intellectual property. - **Rule ID:** WEB-141 - **Layer:** Website (`WEBSITE`) - **Checks:** `crawled website content` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** CTIA - **Applies:** Applies to every 10DLC registration. - **In force from:** 2025-01-01 - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-141/ ### Why this rule exists CTIA added this in SCMH v1.9, and it reaches messaging because a link in a text message is a distribution channel like any other — the rights holder's complaint arrives at the carrier. Small businesses trip it with stock imagery they did not license and fonts or music lifted from elsewhere, none of which they would describe as infringement. ### How to fix it Replace unlicensed media with material you hold a licence for, and remove third-party marks you are not authorised to use. Done when every image, font and logo on the site traces to a licence or to your own work. ### Example of a compliant value ```text Swap an unlicensed press photo on the home page for your own photography of the Mission St roastery. ``` ### Notes New in CTIA SCMH v1.9. `effectiveFrom` is set to the start of 2025 because the catalog records the version rather than a publication date, and dating it earlier would apply a requirement before it existed. --- ## WEB-142 — A storefront catalog must be screened for SHAFT merchandise before submitting through a strict platform > The brand website must not host or promote SHAFT merchandise in the storefront catalog, where the destination platform refuses such merchants outright. - **Rule ID:** WEB-142 - **Layer:** Website (`WEBSITE`) - **Checks:** `crawled website content` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** AWS, TCR - **Applies:** Applies when the vertical is RETAIL. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-142/ ### Why this rule exists Some ISV platforms refuse SHAFT merchants entirely rather than age-gating them, which is stricter than the carrier baseline and invisible until a submission is refused. A homeware store with a single hip-flask-and-whiskey gift set is a SHAFT merchant to that screen, and the seller has no reason to think of themselves as one. ### How to fix it Search your own catalog for alcohol, tobacco, firearms and adult items — including bundles — before submitting, and confirm with your platform whether it refuses such merchants outright or age-gates them. Done when you can state which of the two applies to your account. ### Example of a compliant value ```text Catalog audit: 0 results for alcohol, tobacco, firearm and adult categories across all products and gift sets. ``` ### Notes The catalog conditions this on `provider=Postscript`, which is not in the Provider enum and would in any case be the wrong shape: a provider tag narrows when a rule fires, and this platform-strictness is a warning every retail merchant benefits from. Tagged to the retail vertical instead, with the platform condition carried in the criteria. --- ## WEB-143 — Affiliate marketing plus lending on the site is a harder rejection than either alone > The brand website must not host or promote affiliate or lead-generation activity in the campaign combined with high-risk lending on the website. - **Rule ID:** WEB-143 - **Layer:** Website (`WEBSITE`) - **Checks:** `crawled website content` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Hard stop — not remediable, resubmission will not help - **Required by:** Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-143/ ### Why this rule exists Bandwidth escalates the two signals together rather than scoring them independently, because the combination is the shape of a payday-loan lead broker — the highest-complaint pattern on the channel. It matters to an honest business because remediating one limb leaves the escalation in place: taking the affiliate page down while the lending stays up does not return the brand to where it started. ### How to fix it This combination cannot be registered. Removing one limb does not restore the other to a clean score, so a business that genuinely does both needs to separate them into different entities before either can be registered. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth | `3101` | no | ### Notes The applicability model has no "both limbs present" predicate, so the condition lives in the criteria: the judge passes immediately unless it finds affiliate or lead-sharing activity in the campaign AND lending content on the site. Recorded here rather than left implicit, so the rule does not read as universal. --- ## WEB-145 — A business social profile can stand in where no website exists > Where the brand genuinely has no website, an established, active, public business profile is accepted as the online presence. - **Rule ID:** WEB-145 - **Layer:** Website (`WEBSITE`) - **Checks:** `submitted social profile URL` - **Severity:** MEDIUM — Usually survives review, but lowers your trust score or invites manual review. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** Twilio, Bandwidth, Telnyx, AWS, Sinch - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-145/ ### Why this rule exists Plenty of real small businesses trade entirely through a Google Business Profile, a Facebook page or an Etsy shop, and refusing them outright would fail the registrations the framework least wants to lose. What providers actually reject is a private or dormant profile — the evidential work is being done by the profile being open and alive, not by it being a website. ### How to fix it Submit a public profile on a platform the providers name — Facebook, Instagram, LinkedIn, Yelp, Google Business Profile or Etsy — that shows recent activity and is visible without logging in. Done when the profile opens in a private browser window and its most recent post is inside the last few months. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30490` | yes | | Bandwidth | `TFV 1202` | yes | ### Notes Absorbs BRD-137. Bandwidth TFV 1202 rejects a private or inactive account, which is the failure mode this rule is really about — the substitution itself is permitted. --- ## WEB-146 — A substituted profile must be a business page, not a personal one > A social profile standing in for a website must be a business page carrying the business name, a description of what it does, and contact information. - **Rule ID:** WEB-146 - **Layer:** Website (`WEBSITE`) - **Checks:** `substituted social profile type and content` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page; AI vision over a consent artifact (screenshot, scan, MMS media) - **Fix type:** Fix the website — no form edit clears it - **Required by:** AWS, Twilio, Zoom - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-146/ ### Why this rule exists A personal timeline proves a person exists, which is not the question — the registration is asserting that a business exists and does what the campaign claims. The distinction matters most for the sole proprietors this route was built for, who often run the business from the account they already had, and who can fix it by converting the page rather than building a site. ### How to fix it Convert the profile to a business or page account and fill in the name, the category, a description of the products or services, and a contact method. Done when the profile shows the registered business name and a way to reach it without sending a direct message. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Twilio (gen2) | `30490` | yes | ### Notes Absorbs BRD-138. Readable either from the crawled profile text or from a screenshot, which is why it is dual CRAWL + VISION rather than vision-only. --- ## WEB-147 — A social profile must not stand in for a website the brand has > A social-media profile is accepted as the online presence only where the brand genuinely has no website of its own. - **Rule ID:** WEB-147 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand.website vs brand.social_profile_urls` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** Deterministic (settled in code from the submitted values) - **Fix type:** Fix the field — a better value in the form clears it - **Required by:** TCR, Bandwidth - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-147/ ### Why this rule exists The substitute exists for businesses that never built a site, and it costs them extra scrutiny. Using it while a real site exists throws away the strongest evidence the registration has, and a reviewer who finds the website independently reads the substitution as an attempt to keep them off it. ### How to fix it Put the business website in brand.website and leave the social profiles as supporting links. Done when brand.website holds the domain the business trades on rather than a profile page. ### Example of a compliant value ```text website: https://acmecoffee.com — with facebook.com/acmecoffee listed as a social profile, not as the website. ``` ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | Bandwidth | `1100` | yes | ### Notes Single secondary source in the catalog (alive5) with no carrier code behind it, so it is graded HIGH rather than BLOCKING and worded as a misuse of the substitute rather than a prohibition. --- ## WEB-148 — The profile substitute is for small businesses without an established site > The social-profile route is available to small businesses and sole proprietors that have no established website, not to larger businesses choosing not to submit one. - **Rule ID:** WEB-148 - **Layer:** Website (`WEBSITE`) - **Checks:** `entity size vs the substitute path` - **Severity:** MEDIUM — Usually survives review, but lowers your trust score or invites manual review. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** Human check — only someone holding the document can settle it - **Fix type:** Supply evidence only you hold - **Required by:** Sinch, SignalWire - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-148/ ### Why this rule exists Two providers restrict the substitution by business size while the others do not, so the same profile is accepted at one destination and rejected at another. A business large enough to be expected to have a site, submitting a profile instead, reads as evasive rather than small — and that judgement is made by a person, from facts about the business we do not hold. ### How to fix it Where the business has any web presence of its own, register it and keep the profile as a supporting link. Where it genuinely has none, expect the substitute to be questioned and be ready to say why no site exists. ### Check this yourself **Would this business look odd to a stranger for having no website of its own?** 1. Judge it as a reviewer would, from size and trading history: the social-profile substitute is for small businesses and sole proprietors with no established site. 2. Where the business has any web presence of its own, register that and keep the profile as a supporting link. 3. Where it genuinely has none, be ready to say why. *What wrong looks like:* A substantial business submits a Facebook page instead of a site. Sinch and SignalWire restrict the substitution by size and Twilio and Bandwidth do not, so the same profile is accepted at one destination and read as evasive at another. ### Notes Nothing on the form carries employee count, revenue or trading history, so we cannot decide whether a brand is small enough for this route. The user has to make the call themselves: if the business would look odd to a stranger without a website, build one before registering. The catalog records this as a genuine divergence — Sinch and SignalWire restrict the substitution by size, Twilio and Bandwidth do not. --- ## WEB-152 — A sole proprietor site must not present as a registered company > Where the brand is registered as a sole proprietor, the website must not hold itself out as an LLC or incorporated entity. - **Rule ID:** WEB-152 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand website + brand.entity_type` - **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** AI judgement over the crawled website or policy page - **Fix type:** Fix the website — no form edit clears it - **Required by:** TCR, Twilio - **Applies:** Applies when the brand is a sole proprietor. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-152/ ### Why this rule exists A site displaying "Acme Coffee LLC" behind a sole proprietor registration tells the reviewer the tier is wrong — the business evidently is a registered entity and should have registered as one. The mismatch is caught on the website even when the brand form looks internally consistent. ### How to fix it Either register the brand as the company the website advertises, using its EIN, or remove the corporate designation from the site if it is not accurate. --- ## WEB-153 — A charity campaign must supply both its own site and an accreditation listing > A Charity campaign must supply the charity's own website URL and a listing URL at an accreditation organisation, and both must resolve. - **Rule ID:** WEB-153 - **Layer:** Website (`WEBSITE`) - **Checks:** `charity website URL + accreditation listing URL` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** External record we cannot query — reported as a warning to verify - **Fix type:** Supply evidence only you hold - **Required by:** T-Mobile, Bandwidth, Infobip - **Applies:** Applies when the use case is CHARITY. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-153/ ### Why this rule exists Donation messaging is the most impersonated category there is, so the carriers demand a second, independent source that the charity exists — a listing nobody can create for themselves. A real charity that has simply never registered with an accreditation body is stopped here, and finding that out at submission rather than after a rejection is worth weeks. ### How to fix it Supply the charity's own website alongside a listing at an accreditation organisation — a GuideStar/Candid profile, a Charity Navigator entry, or the state charity register — and open both links yourself before submitting. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | T-Mobile | `9002` | yes | | Bandwidth | `TFV 1110` | yes | ### Check this yourself **Do you have both URLs — the charity's own site and its accreditation listing — and do both open in a private window?** 1. Obtain the listing URL: a GuideStar/Candid profile, a Charity Navigator entry, or the state charity register. 2. Open both links yourself, logged out, before submitting. 3. Supply them with the organisation name and EIN. *What wrong looks like:* A real charity that never registered with an accreditation body is stopped here. Donation messaging is the most impersonated category there is, so a second, independent source that the charity exists is not negotiable. ### Notes We cannot verify an accreditation listing, and we do not hold the listing URL as a field. The user has to obtain it, confirm it resolves publicly, and supply it with the registration alongside the organisation name and EIN. --- ## WEB-154 — A political campaign must supply a resolving organisation website > A Political campaign must supply the candidate's or organisation's website URL alongside the FEC Committee ID, and that URL must resolve. - **Rule ID:** WEB-154 - **Layer:** Website (`WEBSITE`) - **Checks:** `political organisation website URL` - **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright. - **When it bites:** Gates approval — get this wrong and registration is refused - **How it is detected:** External record we cannot query — reported as a warning to verify - **Fix type:** Supply evidence only you hold - **Required by:** T-Mobile, Bandwidth, Infobip - **Applies:** Applies when the use case is POLITICAL. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-154/ ### Why this rule exists The Committee ID proves a filing exists; the website is what ties the filing to the messages a voter is about to receive. Campaign sites are stood up and taken down on a schedule nobody else keeps, so a URL that worked when the registration was drafted is a common and entirely innocent way to fail a political vet. ### How to fix it Supply the campaign or organisation website beside the FEC Committee ID, and confirm it loads publicly on the day you submit and stays up through the review window. ### Provider rejection codes | Provider | Code | Resubmission allowed | | --- | --- | --- | | T-Mobile | `9001` | yes | ### Check this yourself **Does the campaign or organisation website load publicly today, and will it stay up through the review window?** 1. Open it in a private window and confirm it loads for someone who is not logged in. 2. Pair it with the FEC Committee ID in the submission. 3. Keep it live until the campaign is approved — campaign sites are stood up and taken down on a schedule nobody else keeps. *What wrong looks like:* A URL that worked when the registration was drafted is down when the vet runs. The Committee ID proves a filing exists; the site is what ties the filing to the messages a voter is about to receive. ### Notes We hold neither the Committee ID nor a separate political-website field, and we cannot check a filing against the FEC. The user has to pair the two themselves and keep the site live until the campaign is approved. --- ## WEB-157 — A changed domain must be updated on the brand record > When the business moves to a new domain, the registered brand website must be updated to match. - **Rule ID:** WEB-157 - **Layer:** Website (`WEBSITE`) - **Checks:** `brand.website currency` - **Severity:** MEDIUM — Usually survives review, but lowers your trust score or invites manual review. - **When it bites:** Falls due after approval, once you are live and sending - **How it is detected:** Not knowable before submission — reported with its deadline - **Fix type:** Wait on an external system or a required interval - **Required by:** TCR, EZ Texting - **Applies:** Applies to every 10DLC registration. - **Canonical URL:** https://ekas.io/rules/10dlc/website/web-157/ ### Why this rule exists The brand record is re-checked long after approval, so a stale website field turns into a dead link on somebody else's schedule — and the consequence is not a request to update it but delivery problems and a re-vetting flag. Nobody thinks of the 10DLC record when a domain changes, because it is not part of any migration checklist. ### How to fix it Update brand.website on the brand record as part of any domain migration, and keep the old domain redirecting until the change has been through vetting. Done when the registered URL is the one customers are being sent to. ### Check this yourself **Is the 10DLC brand record on your domain-migration checklist, alongside DNS, email and analytics?** 1. Add brand.website to the checklist now — nothing will prompt you at migration time. 2. Update the brand record as part of the move, and keep the old domain redirecting until the change has been through vetting. *What wrong looks like:* The brand record is re-checked months later against a dead link. The consequence is a re-vetting flag and delivery problems, not a request to update the field. ### Notes Post-approval hygiene, invisible at submission. The user has to put the brand record on their own domain-migration checklist alongside DNS, email and analytics — nothing prompts them, and the failure surfaces as a delivery problem rather than as a registration one.