> For the complete documentation index, see [llms.txt](https://seedly-crm.gitbook.io/seedly-crm-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://seedly-crm.gitbook.io/seedly-crm-docs/common-gohighlevel-problems-and-how-to-fix-them/ghl-emails-going-to-spam.md). # Emails Going to Spam ![Marketing emails being diverted from the inbox into a spam folder](/files/16wdT91KynQf4OVhuG1g) You know what nobody warns you about when you move your agency onto GoHighLevel? The day your open rates fall off a cliff and a client forwards you a screenshot of your "campaign" sitting in their junk folder. It is the single most common GHL complaint there is. Pop into the Facebook group, scroll G2, lurk on r/gohighlevel for ten minutes... it is everywhere. And here is the part that stings: most of the time it is not even GoHighLevel being broken. It is a config gap nobody told you to close. Let me walk through why it happens, then exactly how to fix it. ## Why your GoHighLevel email lands in spam Three things cause about 95% of it, and usually more than one is happening at once. **1. You are sharing an IP with strangers.** GHL's built-in LC Email (LeadConnector) sends over shared Mailgun infrastructure. Translation: your mail goes out on IP addresses pooled with thousands of accounts you have never met. So when some other agency on that pool fires a campaign at a scraped list they bought off the internet, the reputation of that IP drops. For everyone. Including you, who did nothing wrong. You are renting a sending reputation you do not control, and that is the whole problem in one sentence. **2. Your domain is not authenticated, or it is but it is wrong.** SPF, DKIM, DMARC. If those three DNS records are missing or misconfigured, inbox providers literally cannot confirm the mail is from you, so they assume the worst. This is the biggest technical cause of spam placement, and it is also the one people skip because DNS feels scary. It is not scary. It is three records. **3. Your list and your content are doing you dirty.** Old lists, purchased lists, addresses you have not touched in a year... they generate bounces and complaints, and complaints are the kiss of death. Gmail starts throttling you once your complaint rate creeps past about 0.3%. Add a spammy subject line, a body that is nothing but links, and a domain with zero sending history, and you have basically built a spam filter's dream target. ![SPF, DKIM, and DMARC are the three records that keep email out of spam](/files/foKLsWBCTZt6OxI0C2lb) ## How to actually fix it In order. Do not skip to step four because it sounds easier. 1. **Authenticate your domain first.** Stand up a dedicated sending subdomain (something like mail.yourbiz.com) and add the SPF, DKIM, and DMARC records. Highest-impact fix on the list, and the one most people never do. If you only do one thing here, do this one. 2. **Get off the shared pool.** Connect your own dedicated sending domain or your own SMTP so the reputation you build is yours. Not pooled with the guy blasting a list he bought for forty bucks. 3. **Warm the domain up.** A brand-new sending domain has no history, and dumping your whole list on it day one looks exactly like what a spammer does. Ramp the volume over two to four weeks. Slow is fast here. 4. **Clean the list before you send, not after.** Pull the dead addresses, the hard bounces, anyone who has not opened a thing in twelve months. A smaller list that actually engages beats a big dirty one every single time (I know it hurts to delete contacts... do it anyway). 5. **Test on a real inbox.** Send the campaign to a Gmail address you own, open it, hit "Show original," and read the SPF, DKIM, and DMARC line. If any of them say fail, you are not ready. Fix it, then send to humans. ## So how do you know you are actually fixed? You do not guess. That is the honest answer. Guessing is how you find out from your open rates three days later, which is the worst possible time to find out. Run your domain through something that checks SPF, DKIM, DMARC, MX, and blacklist status and tells you in plain English what is broken. We built a [free email deliverability checker](https://seedlycrm.com/blog/email-deliverability-checker) that does exactly that, so you can confirm everything is wired up right before a campaign goes out instead of after the damage is done. Run it, fix what it flags, then hit send. ## When the real fix is bigger than a DNS record Here is the uncomfortable version. Say you have authenticated the domain, moved off the shared pool, cleaned the list, warmed it up... and mail still lands in spam. At that point the problem is not your settings. It is that you do not control enough of the sending stack to fix it, because you are renting the platform underneath it. When you own and self-host the thing, you pick the email provider, the sending domain, the reputation. Nobody else's behavior is dragging your numbers down, because nobody else is on your stack. You stopped being one of ten thousand tenants. You became the landlord. That is a bigger move than editing a DNS record, sure. But if deliverability is the lifeblood of your business, at some point you have to ask whether you want to keep renting the one part of it you cannot fully control. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://seedly-crm.gitbook.io/seedly-crm-docs/common-gohighlevel-problems-and-how-to-fix-them/ghl-emails-going-to-spam.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.