How to fix GoHighLevel (GHL) emails going to spam

The GoHighLevel confirmations I checked had a missing DKIM record. Restoring it fixed the authentication failure, but the mail-tester score still varied between sends. Those were separate things to investigate.

The checks below show how I found the record, recovered its value from GoHighLevel, and verified a fresh message. The domain names and key fragments are examples; use the records shown for your own sending domain.

#Check the message authentication

In Gmail, expanding the sender showed an additional domain:

Cool Stuff <ghl@yourdomain.com> via cloudflare-email.net

Gmail's explanation of the “via” label describes why it can show a domain different from the sender's address. The label is a reason to inspect the headers, not proof that a particular DNS record is missing.

Open Show original and check SPF, DKIM, and DMARC. DMARC alignment requires at least one passing, aligned SPF or DKIM result. A failed DKIM check alone doesn't establish a DMARC failure if aligned SPF passes. Likewise, passing authentication doesn't guarantee inbox placement.

#Inspect the DNS records

The setup I checked used mailo as its DKIM selector:

dig +short TXT yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short TXT mailo._domainkey.yourdomain.com

Check the selector in your message's DKIM-Signature header and the values GoHighLevel supplies. If you send from a subdomain, query the corresponding record names rather than assuming they all belong on the root domain.

In my case, the DKIM query returned no record:

$ dig +short TXT mailo._domainkey.yourdomain.com
(no record)

$ dig +short TXT _dmarc.yourdomain.com
"v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:..."

That policy requests quarantine for DMARC failures and uses relaxed alignment. The missing public key prevented verification of signatures that depended on that selector. I checked the message results alongside DNS rather than treating the policy record itself as evidence of a failed message.

Sending a confirmation to mail-tester.com provided a second view:

The relevant finding was “Your DKIM signature is not valid”, with a -3 penalty in that report. The total was 6.3/10, but the authentication finding was the part I could address in DNS.

#Recover the record from GoHighLevel

GoHighLevel's domain verification instructions show where to retrieve the required DNS records. In the interface I used, the path was Settings > Email Services > Dedicated Domain And IP, then the domain card's (...) > Verify domain menu.

Copy the DKIM value from that table into your DNS provider using the exact record name and type shown. Check the other rows too: SPF, CNAME, MX, and DMARC each have their own verification status. Compare an unverified record with the required value before changing it; keep the requirements of other mail services using the domain in mind.

The setup I checked included SPF entries for mailgun.org and spf.leadconnectorhq.com. Your domain's verification table is the source for the values you need, rather than a copied SPF policy from another account.

#Verify a fresh message

After publishing the record, allow for DNS caching before testing. HighLevel's sending-domain setup guide says propagation can take up to 24 hours, so a fixed two-minute wait isn't a reliable test.

$ dig +short TXT mailo._domainkey.yourdomain.com
"k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC91X7..."

$ dig +short TXT _dmarc.yourdomain.com
"v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:..."

Run Verify domain again in GoHighLevel, then send another confirmation. An old message won't acquire new authentication results after a DNS change. The passing results I was looking for were:

Authentication-Results: mx.google.com;
       dkim=pass header.d=yourdomain.com
       spf=pass smtp.mailfrom=...mailgun.org
       dmarc=pass (p=QUARANTINE) header.from=yourdomain.com

Here, the successful DKIM signature aligns with the visible From domain. mail-tester also showed valid, aligned DKIM:

Check inbox placement separately. If authentication passes but messages still go to spam, investigate the remaining content, reputation, and sending-pattern findings rather than repeatedly changing the DKIM record.

#Why the mail-tester score still varied

I sent the same message four times without changing DNS:

The scores changed by 4.5 points while the authentication setup stayed the same. The reports showed differences in sending IP and relay-related findings, including HELO_DYNAMIC_IPADDR (-3.243) and RDNS_DYNAMIC (-0.363) when those rules fired. Those were scores from these reports, not fixed penalties for every mail system.

On shared sending infrastructure, I don't control the hostname and reverse DNS of each relay. Repeating the test helped distinguish that variation from a persistent problem in my domain's records.

#Check what each remaining rule evaluates

FROM_DOMAIN_NOVOWEL concerns the domain after @. SpamAssassin's rule definitions distinguish it from FROM_LOCAL_NOVOWEL, which concerns the mailbox name before @. Changing ghl@yourdomain.com to hello@yourdomain.com doesn't change the domain or resolve a domain-based finding.

For URI_NOVOWEL, inspect the hostnames in message links. Tracking and unsubscribe URLs can introduce domains that differ from your own. Check the reported URL before deciding which setting to change.

GoHighLevel's tracking CNAME can be checked with:

dig +short CNAME email.yourdomain.com

Use the name shown in your domain configuration. The dedicated-domain Domain Settings dialog also has Click Tracking and Open Tracking toggles. If you don't need those statistics, disable the relevant tracking and inspect a fresh message to see which URLs remain. Required unsubscribe links and other platform URLs can remain independently of those settings.

Restoring the DKIM record resolved the authentication failure I was investigating. The follow-up checks were a fresh message with aligned authentication, its actual inbox placement, and the individual findings behind any remaining score changes.