Why GoHighLevel sends duplicate text messages, and how to stop it
Contacts getting the same text twice, texts from two different numbers, or a whole list blasted at once. The four causes and the fix for each.
Learn moreTroubleshooting
Is your GoHighLevel sending domain broken? Here's how to check
One agency owner audited 62 GoHighLevel sending domains and found 26 with a broken record. Here is the five-minute check to see if yours is one of them.
Short answer: A broken GoHighLevel sending domain means the SPF, DKIM or DMARC record at your domain registrar is missing, wrong, or duplicated, so email quietly lands in spam and texts lose some of the trust signal carriers use to decide what gets delivered. GoHighLevel does not warn you when this happens. You have to check the domain yourself with a free DNS lookup tool, and if you have never done that check, there is a real chance something is broken right now.
What a broken sending domain actually means
When someone says a domain is broken in this context, they do not mean the website is down. They mean the DNS records that prove GoHighLevel is allowed to send email as your domain are missing or wrong. A public check of 62 GoHighLevel agency sending domains found 26 with a real problem, from a duplicate SPF record to a DKIM key that had expired months earlier (source). None of those 26 accounts got an error message. Their email just started performing worse, a little at a time, and most owners assumed the CRM was the problem instead of the domain sitting underneath it.
The three records GoHighLevel needs
Each record answers a different question for the mail server on the receiving end, and all three sit outside GoHighLevel, at whichever company holds your DNS (GoDaddy, Cloudflare, Namecheap, your website host).
| Record | What it proves | Common failure |
|---|---|---|
| SPF | Which servers are allowed to send email as your domain | Two SPF records exist at once, which most mail servers treat as an automatic fail |
| DKIM | The email was not altered in transit and really came from an authorized sender | The DKIM key was never added, or was added under the wrong selector name |
| DMARC | What receiving servers should do when SPF or DKIM fail | No DMARC record at all, so failures get no policy and just get judged case by case |
How to check your own domain in five minutes
Go to a free checker (MXToolbox and Google's Admin Toolbox both work) and enter your sending domain, not your website's root domain if they differ. Look for three things: exactly one SPF record, a DKIM record that matches the selector GoHighLevel gave you when you verified the domain, and a DMARC record with a policy set to at least p=none. If any of the three is missing or you see two SPF lines, that domain is contributing to whatever deliverability problem you have been blaming on the CRM.
If you are not sure which domain GoHighLevel is actually sending from, check the domain settings inside your sub-account under Settings, then Domains, or under the email service section where the original verification happened. Write down the exact domain name shown there before you run the checker, because a lot of confusion comes from checking the root domain when GoHighLevel is actually sending from a subdomain like mail.yourcompany.com.
What to do once you find a broken record
If the SPF record is duplicated, the fix is to merge the two into one line rather than deleting either one blind, because one of them might be authorizing a tool you still use for email (a website form, an old newsletter provider). Open both records, list every server each one authorizes, and combine them into a single SPF line before publishing it. If DKIM is missing entirely, go back into the GoHighLevel domain verification screen, copy the exact host and value it gives you, and paste that pair into your DNS as a TXT record. If DMARC is missing, start with a policy of p=none so you can see what would have failed without actually blocking anything yet, then move to p=quarantine once you have confirmed the SPF and DKIM records are solid. DNS changes usually take anywhere from a few minutes to a few hours to take effect, so give it time before you re-check.
Why it breaks without anyone noticing
Nobody deletes a working SPF record on purpose. It usually happens in three ways: a website migration to a new host adds its own SPF line without checking for an existing one, a snapshot import from another agency's template overwrites custom values that referenced the old domain, or a DKIM key rotates and the new key never gets pasted into DNS because whoever set it up originally is no longer on the account. Each of these is invisible until open rates drop or texts stop landing, and by then it looks like a GoHighLevel problem rather than a five-minute DNS fix. If your account has changed hands between agencies, this is exactly the kind of thing that falls through a handoff, because nobody thinks to ask who owns the DNS.
How this connects to A2P and text approval
SPF and DKIM are email specific, but the same instinct applies to text. Carriers and GoHighLevel's messaging partners weigh domain and account reputation as part of the trust picture behind a phone number, alongside the A2P 10DLC registration itself. An account with no email authentication at all, sending from a domain that looks unclaimed, does not inspire more confidence than one that is properly set up. If your texts are getting flagged or your A2P campaign got rejected for reasons that felt vague, the sending domain is worth ruling out before you resubmit anything.
What we would check first
When we take on a GoHighLevel account audit and cleanup, the sending domain is one of the first things we pull up, because it takes minutes to check and the cost of ignoring it is weeks of email landing where nobody reads it. The GoHighLevel account audit starts at $497 and covers exactly this kind of thing: workflows, tags, pipelines and the DNS records nobody has looked at since the account was first set up. If you just want the five-minute answer for your own domain right now, run the check yourself first. If the audit turns something up, that is a conversation worth having on a free discovery call.
Yaakov (Koby) Oranski, Founder and CEO of Yotomations
Certified GoHighLevel Admin and Partner. Koby designs CRM migrations, two-way integrations, billing systems and AI agents for service businesses, and writes from the engagements described on this site.
Frequently asked
How do I know if my GoHighLevel sending domain is broken?
Run your domain through a free SPF, DKIM and DMARC checker like MXToolbox or Google's Admin Toolbox. If any of the three comes back missing, misconfigured, or shows more than one SPF record, your domain is broken even if GoHighLevel is not showing an error.
Does a broken sending domain affect my text messages too?
It affects email directly, but it also matters for A2P because carriers and GoHighLevel's messaging partners look at domain reputation as part of trust signals for the account sending the texts. A domain with no authentication at all makes the whole account look less legitimate.
Who is supposed to set up SPF, DKIM and DMARC in GoHighLevel?
GoHighLevel gives you the records to add, but you or your DNS provider has to paste them into the domain's DNS settings. If an agency set up your account and never sent you those records, or added them and then a website migration wiped them out, nobody owns the fix.
Can I have more than one SPF record?
No. Having two SPF records is one of the most common breaks, because a second tool (a website host, another CRM, an old email provider) adds its own SPF line and the two conflict. Mail servers are supposed to treat two SPF records as a fail, not a merge.
What does GoHighLevel actually use, Mailgun or its own servers?
GoHighLevel sends outbound email through Mailgun under the hood for most accounts, which is why the setup screen asks you to verify a domain rather than just enter an email address. The domain verification step is exactly where SPF and DKIM get added.
Keep reading
GoHighLevel appointment reminders at the wrong time, or after a reschedule: how to fix them
Patients or customers getting reminders for the old appointment, the wrong day, or after they cancelled. What causes it and how to build reminders that cancel themselves.
Learn moreInherited a messy GoHighLevel account? The 90-minute GoHighLevel audit checklist
Twelve checks, in order, that show what is broken in an inherited GoHighLevel account: shared triggers, dead tags, orphaned pipelines, phone and A2P status, and what to fix first.
Learn moreIs this happening in your account?
Book a 30-minute call. We look at the account live and tell you what is broken, what we would fix first and what it would cost.
No pitch deck. We look at your current setup and tell you what we would do and what it would cost.Need more than GoHighLevel? Yotomations, our parent company, also builds AI agents, custom software and websites.