How to Set Up a Dedicated Email Sending Domain in GoHighLevel

by Fahim

You launch a broadcast campaign in a brand-new GoHighLevel sub-account, check your dashboard the next morning, and watch your open rate tank below 8%. Almost every time I’ve debugged this for a client, the culprit is the exact same thing: they’re sending off HighLevel’s default shared sending pool.

Setting up a dedicated sending domain isolates your reputation from spammers on that shared pool and gives you full ownership of your inbox placement. Here is how to configure LC Email (LeadConnector) with a dedicated subdomain, add the required SPF, DKIM, MX, and CNAME records, configure DMARC, and verify the whole stack using command-line tools before sending a single email.

Terminal screen showing DNS SPF and DKIM record verification for GoHighLevel dedicated email domain
Terminal screen showing DNS SPF and DKIM record verification for GoHighLevel dedicated email domain

Why Shared Sending Pools Tank Your Deliverability

When you spin up LC Email without adding a custom domain, your outbound mail routes through a shared IP and domain cluster. If another agency on that same cluster blasts 50,000 scraped leads and gets flagged by Gmail, your transactional booking confirmations and client newsletters get dragged down with them.

Google and Yahoo enforce strict sender requirements. If your visible From: address doesn’t align with the envelope sender (return-path) and your DKIM signature, your emails either drop straight into spam or bounce outright with a 550 SMTP error code.

A dedicated sending domain fixes three critical problems:

  • Domain Alignment: Your From header domain matches your SPF and DKIM signing domains.
  • Isolated Reputation: Hard bounces and spam complaints from other accounts can’t touch your deliverability score.
  • Custom Tracking URLs: Click-tracking and unsubscribe links use your own branded subdomain instead of generic third-party URLs.

Picking the Right Subdomain Strategy

Never use your naked apex domain (like example.com) directly as your HighLevel sending domain if you already run Google Workspace or Microsoft 365 on it. HighLevel requires MX records to capture inbound replies and bounce events. If you point your apex MX records to HighLevel, you’ll overwrite your corporate mail routing and knock your team’s everyday inbox completely offline.

Always pick a dedicated subdomain reserved strictly for platform or marketing automation:

  • mg.example.com (Standard mail-gateway pattern)
  • mail.example.com (Common for system notifications)
  • send.example.com (Clean separation for marketing broadcasts)
  • replies.example.com (Great when you prioritize inbound conversational workflows)

For almost every client setup, I stick with mg.yourdomain.com. It isolates your email infrastructure cleanly from any funnels or websites running on other subdomains—the same way you isolate routing when you connect a custom domain and subdomain to GoHighLevel funnels.

Generating the DNS Records in GoHighLevel

You can set this up at the Agency Level (under Settings > Email Services > Dedicated Domains) or inside an individual Sub-Account (under Settings > Email Services > Domain Services).

Click Add Domain, enter your chosen subdomain (like mg.domain.com), and hit Save & Continue. HighLevel will spit out five DNS records that you need to copy into your DNS manager:

  1. TXT Record (SPF): Authorizes HighLevel’s mail servers to send for this subdomain.
  2. TXT Record (DKIM): The public cryptographic key used to verify message integrity.
  3. MX Record 1 (Priority 10): Routes incoming replies and bounce events to mxa.mailgun.org (or the LC cluster equivalent).
  4. MX Record 2 (Priority 10): Backup routing pointing to mxb.mailgun.org.
  5. CNAME Record: Points a tracking host (like email.mg.domain.com) to HighLevel’s servers for open and click tracking.

Adding the DNS Records to Your Provider

Open your DNS management panel (Cloudflare, AWS Route53, Namecheap, etc.) and add each record. Here’s what a complete BIND-style zone setup looks like for mg.clientdomain.com:

;
SPF record for authorization
mg.clientdomain.com. 300 IN TXT "v=spf1 include:mailgun.org ~all"
;
DKIM public key record
krs._domainkey.mg.clientdomain.com. 300 IN TXT "k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC0...IDAQAB"
;
MX records for replies and bounce notifications
mg.clientdomain.com. 300 IN MX 10 mxa.mailgun.org.
mg.clientdomain.com. 300 IN MX 10 mxb.mailgun.org.
;
CNAME record for open/click tracking
email.mg.clientdomain.com. 300 IN CNAME mailgun.org.

If you’re using Cloudflare, pay close attention to the CNAME record: make sure it is set to DNS Only (Grey Cloud) and not Proxied (Orange Cloud). If Cloudflare proxies that tracking CNAME, the automated SSL handshake fails, your tracking links break, and anyone clicking a link in your emails will hit a 520 or 525 browser error.

Verifying SPF and DKIM via Terminal

Don’t sit there mashing the verify button in HighLevel while waiting for DNS propagation. Check the public resolvers directly from your terminal using dig to see if your records are live:

# Check the SPF TXT record
dig @8.8.8.8 TXT mg.clientdomain.com +short # Expected output:
# "v=spf1 include:mailgun.org ~all" # Check the DKIM selector record
dig @8.8.8.8 TXT krs._domainkey.mg.clientdomain.com +short # Expected output:
# "k=rsa; p=MIGfMA0GCSqGSIb3..."

Once dig returns your records from Google’s resolver (@8.8.8.8), head back to HighLevel and click Verify Domain. You should see green checkmarks next to all five rows. If one stays red, give it another 60 to 120 seconds and click verify again.

Setting Up DMARC for Sender Alignment

HighLevel generates your SPF and DKIM records, but you’re still responsible for putting a DMARC policy on your root domain. Google and Yahoo require DMARC for bulk sending, as laid out in the Google Email Sender Guidelines.

If you don’t have a DMARC record on your root domain yet, create a TXT record for the host _dmarc.clientdomain.com. If you’re setting this up for the first time and don’t want to accidentally drop legitimate corporate emails, start with a relaxed monitoring policy (p=none):

;
DMARC Policy on root domain
_dmarc.clientdomain.com. 300 IN TXT "v=DMARC1; p=none; sp=none; rua=mailto:dmarc-reports@clientdomain.com; pct=100; adkim=r; aspf=r"

You can run your domain through the MXToolbox DMARC Lookup to confirm the syntax is valid.

Common Verification Errors and How I Fixed Them

I’ve run into these three issues across dozens of domain setups:

1. The Subdomain Name Doubling Bug

Registrars like GoDaddy and Namecheap automatically append your root domain to the host field. If HighLevel tells you to create a record for mg.clientdomain.com and you paste mg.clientdomain.com into Namecheap, the actual record becomes mg.clientdomain.com.clientdomain.com.

To fix this, enter only the prefix (mg) in the host field. For DKIM, enter only krs._domainkey.mg instead of the full domain string.

2. HighLevel Shows Unverified DKIM Despite DNS Being Live

I’ve hit instances where Cloudflare served the DKIM key cleanly in dig in under a second, but HighLevel refused to verify it. The issue usually comes down to string formatting.

If your DNS manager splits long TXT strings into multiple quoted segments (common with 2048-bit keys), double-check what was pasted into HighLevel. Ensure there are no stray spaces or missing semicolons between k=rsa; and p=....

3. SSL Certificate Handshake Failures on Tracking Links

When HighLevel sends an email with links, it rewrites them as http://email.mg.clientdomain.com/c/.... If a contact clicks that link and gets an SSL warning, the automated SSL certificate provisioning for your CNAME failed.

Go to your dedicated domain settings in HighLevel, click the three dots next to the domain, and hit Verify SSL. If it fails, confirm your CNAME record in Cloudflare is set to DNS Only (Grey Cloud).

Testing Deliverability with Real Inboxes

Once all five records show green in HighLevel, don’t immediately blast your entire list. Run an end-to-end test to verify the authentication headers in a real inbox.

Create a test contact with your personal Gmail address, assign it to yourself, and send a manual email from the HighLevel conversation tab. Open the email in Gmail, click the three dots, and select Show original.

Check the authentication box near the top of the raw message. You want to see clean passes across the board:

Authentication-Results: mx.google.com;
dkim=pass header.i=@mg.clientdomain.com header.s=krs header.b=...;
spf=pass (google.com: domain of bounces@mg.clientdomain.com designates 198.61.254.10 as permitted sender) smtp.mailfrom=bounces@mg.clientdomain.com;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=clientdomain.com

If you see spf=pass and dkim=pass, your dedicated domain is working properly. If you’re building complex automations around these emails, make sure you also know how to fix GoHighLevel webhooks not firing so your transactional triggers don’t drop silently.

Frequently Asked Questions

Can I use the same sending domain on multiple HighLevel sub-accounts?

No. HighLevel requires each dedicated domain to map to a single location or agency to prevent routing conflicts on inbound replies. If you manage multiple accounts for the same business, use separate subdomains like mg1.domain.com and mg2.domain.com.

Do I need to warm up a new dedicated sending domain?

Yes. Even though you’re on HighLevel’s infrastructure, mailbox providers track your specific subdomain’s reputation. Start with 50 to 100 emails per day to contacts you know will engage, and double your volume every 4 to 5 days over a 3-week period.

What happens to replies sent to my HighLevel emails?

Because your MX records point to HighLevel’s mail servers, incoming replies parse straight into the Conversations tab of that sub-account. You can also turn on forwarding in your Email Services settings if you want a copy routed to a team inbox.

Why are my tracking links showing HTTP instead of HTTPS?

HighLevel provisions a Let’s Encrypt SSL certificate for your CNAME tracking record (email.subdomain.com). It typically takes 15 minutes to 2 hours after DNS verification for the certificate to deploy. If it’s still unencrypted after a few hours, trigger a manual re-check from the Domain Services tab.

Next Steps for Your HighLevel Infrastructure

Now that your dedicated sending domain is live, your outbound emails carry your own cryptographic signature and skip the shared-pool penalties. If your pipeline involves importing leads from external tools or spreadsheets, check out my guide on how to push Google Sheets contacts to the GoHighLevel API with Apps Script to feed contacts straight into your newly authenticated campaigns.

all_in_one_marketing_tool