Most email tickets come down to one question: do the domains line up?
Type the address a client sends from and the sending domain they set up in GHL. The check below shows what inbox providers will see and whether the message passes DMARC alignment. You’ll use this reasoning on almost every ticket.
What this role owns
Setup
Getting clients onto a verified dedicated sending domain with SPF, DKIM, DMARC and tracking records correct the first time.
Diagnosis
Reading DNS and message headers to find why mail fails verification, lands in spam, shows “via”, or loses replies.
Explanation
Telling a non-technical client what happened and what to do next, in plain language, without guessing.
Three rules to work by
Look before you answer. Check the live DNS (MXToolbox or Google Admin Toolbox Dig) and a real message header. Screenshots of a DNS panel tell you what someone typed, not what the internet sees.
Never touch the client’s inbox records. The root domain’s MX and SPF belong to Google Workspace or Microsoft 365. GHL sending records go on a subdomain. Breaking a client’s inbox is the worst outcome in this job.
Explain the next step, not the theory. Clients want to know what to click and when it will be fixed. Keep the “why” to one or two sentences unless they ask for more.
Your 30-day path
Work top to bottom. Each task links to the part of this guide that covers it. Your ticks are saved in this browser, so you can come back any time.
How GHL email works
GHL’s native email (LC Email) sends through Mailgun infrastructure. A client either sends on GHL’s shared domain or on their own dedicated sending domain. Everything else follows from that choice.
The path of one email
GHL sub-account
A workflow, campaign or Conversations reply creates the message with a From address.
Mailgun (LC Email)
Signs it with DKIM for the sending domain and sets a bounce address on that domain.
Gmail, Outlook, Yahoo
Check SPF, DKIM and DMARC, then decide: inbox, spam, or reject.
Why the client ends up with two domains
Clients ask this constantly. The answer: their root domain already has a job, and GHL needs a separate place to put its records so the two jobs don’t collide.
Root domain
- Website and the client’s real mailbox (Google Workspace, Microsoft 365).
- Its MX records point to that mailbox provider. Replace them and the client stops receiving email.
- Holds the one SPF record for the domain and the DMARC record.
Sending subdomain
- Used only by GHL to send marketing and automated mail.
- Has its own SPF, DKIM, MX (for bounces and replies) and tracking CNAME pointing at Mailgun.
- Keeps bulk sending reputation separate from day-to-day staff email.
The client still sends as sarah@acmedental.com. Because mail.acmedental.com belongs to the same organizational domain, DMARC treats them as aligned. That’s why the subdomain doesn’t need its own mailbox and the recipient never notices it.
The three identities in every message
| Identity | Where you see it | Who sets it | What it must match for DMARC |
|---|---|---|---|
| From (header) | What the recipient sees | The client, in GHL settings or the workflow step | This is the domain DMARC protects |
| DKIM signing domain (d=) | “signed-by” in Gmail’s details | Mailgun, using the DKIM record on the sending domain | Same organizational domain as From |
| Return-Path (envelope) | “mailed-by” in Gmail’s details | Mailgun, a bounce address on the sending domain | Same organizational domain as From (for SPF alignment) |
DMARC passes if either SPF or DKIM passes and its domain aligns with the From domain. With a correctly set-up dedicated subdomain, both normally align.
Several sending domains in one sub-account
A sub-account can hold more than one dedicated sending domain. Clients end up here when one account sends for several brands, after a rebrand, or when someone added a domain “just in case”.
How GHL picks the domain for each email. It looks at the From address. If a verified sending domain belongs to the same root domain, the email goes out through that one and stays aligned. If none matches, it falls back to the domain marked as default, so the email is signed for a different brand and fails DMARC alignment. Unverified domains are never used.
This is how GHL describes the behaviour at the time of writing. Always confirm with a test send and a real header before telling a client which domain their email will use.
| Sending domain in GHL | Verified | Default |
|---|
When more than one domain makes sense
| Situation | What to set up |
|---|---|
| One sub-account sends for two or more brands with their own domains | One verified sending subdomain per brand domain. Set each workflow’s and campaign’s From to its own brand. Make the main brand the default. Separate sub-accounts per brand are cleaner if the client is open to it. |
| Rebrand to a new domain | Verify the new domain, make it the default, update every From address, send tests, then remove the old domain once nothing uses it. |
| Marketing and transactional split on the same brand (mail. and news.) | Possible, but both match the same root, so you can’t reliably steer which one a given workflow uses. Unless the client has a tested reason, one sending subdomain per root domain is enough. |
| Several locations or franchises of one brand, each in its own sub-account | Each sub-account needs a different subdomain (mail., em., northside.), because the same sending domain can only be connected to one account. All still align with the brand’s root. |
| “More domains will help deliverability” | They won’t. Spreading the same mail across domains to dodge filters is called snowshoeing, and inbox providers penalise it. Fix the list and content instead. |
Things you’ll be asked about
Shared domain vs dedicated domain
Without a dedicated domain, mail goes out on GHL’s shared sending domain (often seen as msgsndr.com). Recipients may see “via msgsndr.com”, the client shares reputation with every other sender on it, and Gmail and Yahoo’s bulk-sender rules can’t be met for the client’s own domain. A dedicated domain fixes all three. Recommend it for every client who sends marketing email.
Can they use the root domain as the sending domain?
It’s technically possible but risky. If the root domain already has a mailbox provider, adding Mailgun MX records there will break the client’s inbox, and a second SPF record will break SPF for both. Default answer: use a subdomain such as mail., send. or replies.. Only consider the root if the client has no other email on that domain and understands the trade-off.
Gmail and Yahoo bulk-sender requirements (2024 onward)
Senders of large volumes to Gmail and Yahoo need SPF and DKIM passing, a DMARC record on the From domain (p=none is enough to start), alignment between From and the authenticated domain, one-click unsubscribe on marketing mail, and a spam complaint rate kept under 0.3% (aim for under 0.1%). Sending “from” a free mailbox like @gmail.com through a third-party platform fails these checks.
LC Email vs connecting Gmail, Outlook or SMTP
LC Email (with a dedicated domain) is built for bulk and automated sending. Connecting Gmail or Outlook through the integration is meant for one-to-one conversations and syncs replies into GHL, but carries the provider’s own sending limits; pushing campaigns through a personal mailbox gets it rate-limited or suspended. Custom SMTP (the client’s own Mailgun or SendGrid) moves deliverability responsibility to that provider. Ask which one the sub-account is using before diagnosing anything.
Agency level vs sub-account level
Domains can be configured for the agency and for each sub-account. Each brand that sends as its own domain needs its own verified sending subdomain on that brand’s domain. A sub-account sending as @brandA.com through a domain verified for brandB.com is misaligned, even if both belong to the same agency.
DNS record builder
Use this to explain to a client what goes where, and to catch formatting mistakes in their DNS panel. The exact values, especially the DKIM key and selector, always come from the client’s domain setup screen in GHL.
Records to expect
| Purpose | Type | Host / Name | Value |
|---|
Formatting mistakes that cause most failures
Doubled host
Typing mail.acmedental.com into a panel that appends the root creates mail.acmedental.com.acmedental.com. Enter only the part before the root.
Cloudflare proxy on
The tracking CNAME must be “DNS only” (grey cloud). Proxied (orange) hides the Mailgun target and verification fails.
Two SPF records
A host may have only one record starting v=spf1. Two of them make SPF fail with a “permerror”. Merge them into one.
Broken DKIM value
Missing characters, extra spaces or added quotes break the key. Copy it in one go from GHL; some panels split long values automatically and that’s fine.
Wrong DNS host
Records added at the registrar do nothing if the nameservers point to Cloudflare, Wix or a web host. Check the nameservers first.
CNAME clashes
A host with a CNAME can’t hold other records. If mail already has a CNAME (for example to a website), pick a different prefix.
Troubleshooter
Pick what the client is reporting. Answer a question or two and you’ll get the likely cause, the fix in order, how to confirm it worked, and a reply you can send.
Practice tickets
Real-shaped tickets. Pick the response you’d send first. Wrong answers explain what would happen if you sent them.
Client cases
Ten real-style client problems. Open a case to chat with the client and check their GHL, DNS and email header side by side. Every tab tells you what to notice, and “The answer” tab shows what’s wrong, how to fix it and what to tell the client.
Reply templates
Starting points, not scripts. Replace anything in {braces}, cut what doesn’t apply, and keep the client’s own words where you can.
When to escalate
You own the ticket until it’s solved or until the fix is outside what you or the client can change. Escalate early when the platform is the problem; escalate late when it’s DNS.
Escalate
- Records resolve correctly in public DNS for 24–48 hours and GHL still won’t verify.
- The account’s email sending is paused or suspended by compliance.
- Headers show the wrong DKIM domain or Return-Path after a verified setup.
- Many clients report the same symptom at the same time.
- A sending IP or the shared domain appears on a major blocklist.
- Data or billing questions you can’t answer from the client’s screen.
Don’t escalate yet
- Records were added under an hour ago.
- You haven’t checked live DNS with a public lookup tool.
- You haven’t seen a real message header.
- The cause is the client’s list, content or From address.
- The nameservers point somewhere other than where records were added.
What to include in every escalation
Tick these off as you gather them. An escalation missing any of these usually bounces straight back.
Glossary
Terms you’ll hear from clients, engineering and inbox providers.