WritingSMS compliance

Why GoHighLevel keeps rejecting your A2P campaign

The rejection is not from GoHighLevel, and the check that fails most often is one nobody mentions. What we found getting our own campaign approved.

BrandBloom8 min read

Why GoHighLevel keeps rejecting your A2P campaign. An article by BrandBloom.

Your A2P campaign was not rejected by GoHighLevel. GoHighLevel passed it along to a registry, the registry passed it to the mobile carriers, and something in that chain looked at what you sent and at your website and decided the two did not add up. The message that came back to you is a summary of that decision, written by a system, and it is usually too short to act on.

We know how this goes because it happened to us. BrandBloom submitted, got knocked back, and spent about three weeks working out what was actually being read. It was approved on 24 September 2026. What follows is what we found, including the one thing that cost us the most time and that we have not seen written down anywhere else.

The part that wastes the most time

There are two different readers of your submission, and they do not read the same thing.

The first is an automated scan. It runs before a human is involved. It fetches the web page where you say people opt in, and it looks for specific words. It is not clever. It does not understand your page. It reads the text that sits inside each checkbox's label and it looks for a short list of required phrases.

The second is a human reviewer, who opens your website, reads your privacy policy and your terms, reads the description you wrote, reads your sample messages, and checks whether all of it describes the same business doing the same thing.

Almost every guide you will find is written for the second reader. The first one is where most people get stuck, and it fails for reasons that look insane if you do not know it exists.

Here is the version of our own form that failed. The consent sentence was inside the checkbox label. The required disclosure sat one line underneath, in its own tidy paragraph, covering both boxes:

[ ] I agree to receive account and service text messages from BrandBloom. Message frequency varies. Message and data rates may apply. Reply STOP to unsubscribe or HELP for help.

Every required element is on that page. A person reading it knows exactly what they are agreeing to. It failed four separate checks: opt-out instructions, message frequency, message type, and rates. All four things it said were missing were visible, in plain English, one line below.

They failed because the scan reads the label and stops. Anything outside the label does not exist to it.

Here is the version that passed:

[ ] I agree to receive transactional and service text messages from BrandBloom LLC, such as alerts, appointment reminders, booking confirmations, and replies to my enquiry. Message frequency varies. Message and data rates may apply. Reply STOP to unsubscribe or HELP for help. See our Privacy Policy and Terms of Service. [ ] I agree to receive marketing and promotional text messages from BrandBloom LLC about services, offers, and updates. Message frequency varies. Message and data rates may apply. Reply STOP to unsubscribe or HELP for help. See our Privacy Policy and Terms of Service.

The wording barely changed. Where it sits changed completely. Every required phrase is now inside each label, and each label is complete on its own, so neither consent depends on the other one being read.

Three details in there are doing specific work, and all three were things we got wrong first:

  • The full legal name, not the brand. We wrote "BrandBloom". The

registration says "BrandBloom LLC". The check compares them and a shortened name is a mismatch.

  • The word "transactional". Our first version said "account and service

messages", which is what a normal person would write and understand. The scan looks for the literal words transactional, promotional or alerts. "Account and service" means nothing to it. We added "transactional" and listed "alerts" among the examples, and that check went green.

  • The disclosure repeated in both labels. It looks redundant. It reads

redundant. It is the only arrangement that passes, because each checkbox is assessed on its own.

If you change one thing today, move your disclosure text inside your checkbox labels.

What the human reviewer checks

Once you clear the scan, a person compares your submission against your site. These are the things we had to fix, in the order they cost us time.

Your privacy policy needs one specific sentence

Not a general privacy policy. Not "we respect your privacy". The reviewer is looking for a statement that mobile numbers and SMS opt-in data are not shared with or sold to third parties for marketing.

If your policy is a generic template, it almost certainly says something like "we may share your information with trusted partners". That sentence, on its own, will fail you, no matter how good the rest of your submission is.

The related trap: some policies mention selling or buying leads elsewhere in the document, often in a section nobody has read since it was pasted in. The reviewer reads the whole page.

You need SMS terms, not just terms

Your general terms of service are about your service. What is wanted here is specific to messaging: what kinds of message you send, roughly how often, who to contact for help, and how someone stops them. It can live inside your terms page, but it has to be there and it has to be findable.

Your legal name has to be visible outside the checkbox

If you trade under one name and registered under another, that relationship needs to be somewhere a visitor can see it, which in practice means the footer. Putting it only inside the consent text is not enough, because the reviewer is checking whether the business on the site is the business on the registration, and the footer is where they look.

While you are in the footer: the registered address and a contact method should be there too.

Every form that takes a phone number needs its own opt-in

Not the main contact form. Every one of them. A booking form, a quote form, a newsletter box that happens to ask for a mobile, a landing page you built for an ad campaign eighteen months ago and forgot about.

We had four. All four had to match, because the reviewer can land on any of them.

The marketing box must be optional and separate

If someone has to agree to promotional texts in order to submit the form, that consent was not freely given. Service messages and marketing messages need two boxes, both unticked when the page loads, and neither of them required.

The description and the samples

This is the second most common failure after the privacy policy, and it is the one where trying to be safe makes things worse.

The instinct is to write a description that is broad enough to cover anything you might ever send. Something like: "Text messages to communicate with our customers and leads about our services."

That fails, because there is nothing in it to verify. The reviewer's job is to match your description against your website. A description with no specifics cannot be matched to anything, so it cannot be confirmed, so it is refused.

Be specific and be boring:

Appointment reminders and booking confirmations for website design clients who requested a consultation through the contact form at brandbloom.org, plus replies to enquiries and occasional service updates.

That names who is being messaged, why they are on the list, where they signed up, and what they get. Every part of it can be checked against the site.

Then the samples. Five of them. The rules that matter:

  • They must be messages you would genuinely send, in your voice.
  • At least one has to carry your business name.
  • At least one has to carry the opt-out instruction.
  • Use brackets for anything that varies: [First name], [Date].
  • They must match the use case you picked and the description you wrote.

Copying five samples off a help page is the fastest route to a contradiction, because those samples describe a different business to the one on your website.

What to do now, in order

  1. Open the campaign and read the rejection reasons in full. Write each one

down. Do not start fixing yet.

  1. Move your disclosure text inside your checkbox labels, on every form on your

site that collects a phone number. This is the change most likely to fix things and the one least likely to be mentioned in your rejection.

  1. Check that each label carries your full legal name, the words transactional

or promotional, message frequency, data rates, STOP and HELP.

  1. Read your privacy policy for the non-sharing sentence. Add it if it is not

there. Delete anything about sharing with partners.

  1. Publish SMS terms if you do not have them.
  2. Put your legal name, address and contact in the footer.
  3. Rewrite the campaign description so every claim in it can be checked against

your website.

  1. Rewrite the five samples to match.
  2. Only then resubmit, and fix everything at once rather than the one field the

rejection named. A second rejection for a different reason costs you another round.

That last point is worth sitting with. A rejection names a check that failed. It does not name the checks that would have failed next. Fixing one thing and resubmitting is how people end up on their fourth round.

Two honest notes

We have done this once. Our own registration, properly, start to finish, including getting it wrong first. We are not going to tell you we have taken hundreds of agencies through it. What is written above is what we learned doing it, which is a different and in some ways more useful thing than what we read about it.

These rules change. Carriers update their requirements and the automated checks get adjusted without announcement. This was accurate in September 2026. If you are reading it much later, treat it as a strong starting point rather than gospel, and check the current requirements in your own account.


Written September 2026, from our own registration, approved 24 September 2026. Due for review March 2027.

Read next