The GoHighLevel SMTP, SPF, DKIM, and DMARC setup that actually lands in inboxes

GoHighLevel will let you send email with no DNS authentication at all. The sub-account UI does not block you; mail will leave the platform and a fraction of it will arrive. That fraction shrinks over time as Gmail, Microsoft 365, Yahoo, and the smaller mailbox providers tighten their unauthenticated-mail policies. By 2026, sending from an unauthenticated domain to Gmail in any meaningful volume gets you 50–70% spam-folder placement on a good day and a hard reject on a bad one.

This post is the working setup. It assumes you are running a sub-account that sends from a domain the client controls (not a @gohighlevel.com shared sender), and that you have access to the domain's DNS at the registrar. The instructions are agency-friendly: I will mark which records are per-sub-account and which can be done once at the agency level.

The four records you are publishing

Before you touch DNS, here is what you are about to put in place:

SPF (per sub-account, on the sending domain) — a TXT record at the apex telling mailbox providers which servers are allowed to send from this domain.
DKIM (per sub-account, on the sending domain) — a public key (or CNAME pointing to a hosted public key) that lets mailbox providers verify a cryptographic signature on each message.
DMARC (per sub-account, on _dmarc.<domain>) — a policy record telling mailbox providers what to do when SPF or DKIM fails, and where to send aggregate reports.
MX (already in place; verify only) — required for receiving bounces back. If MX is missing, every bounced message is silently lost, which kills your ability to maintain a clean list.

Order matters. SPF first, DKIM second, DMARC third (at p=none to start), MX verified throughout. Then iterate the DMARC policy from none to quarantine to reject over 6–12 weeks once aggregate reports show clean alignment.

Step 1 — SPF

Open the sub-account in GoHighLevel and find the LC – Email DNS settings page. The platform will tell you the include host you need to add to SPF; for the LC – Email service this is typically include:smtp.gohighlevel.com (verify the exact value in your sub-account because GHL has changed sending hosts before).

If the domain has no existing SPF record, publish:

v=spf1 include:smtp.gohighlevel.com ~all

If the domain already has an SPF record (most common: Microsoft 365 or Google Workspace customers), merge into the existing record. Do not publish a second SPF record. RFC 7208 §3.2 explicitly forbids multiple SPF records on a single domain — mailbox providers will return a permerror on lookup, which is treated as worse than no SPF at all.

A merged record for a domain that uses Microsoft 365 plus GoHighLevel:

v=spf1 include:spf.protection.outlook.com include:smtp.gohighlevel.com ~all

The ~all (soft fail) is the correct policy while you are bringing up authentication. Move to -all (hard fail) only after DMARC has been at p=reject cleanly for a month and you are confident no rogue senders are using the domain.

Common SPF problem: the 10-DNS-lookup limit. RFC 7208 §4.6.4 caps SPF evaluation at 10 DNS lookups. Each include: is one lookup, plus any nested include: chains in the included domains. Microsoft 365's SPF chain alone burns 4 lookups; adding Google Workspace plus a marketing tool plus GHL can push you over 10, at which point the entire SPF check fails. The free SPF checker counts the actual lookup expansion and flags overrun.

If you hit the limit, the fixes in priority order are: drop sending services you no longer use, use SPF flattening for one of the heaviest includes (with the caveat that flattened records need monitoring because the IPs you flattened can change), or move infrequent senders to a subdomain with its own SPF.

Step 2 — DKIM

GoHighLevel provides DKIM in one of two ways depending on the sub-account configuration: a CNAME pointing to a hosted public key, or a TXT record containing the public key directly. Both work; the CNAME approach is preferred because GHL can rotate the key without you touching DNS again.

Publish whichever the sub-account UI tells you to publish, at the host shown (typically dkim._domainkey.<domain> or <selector>._domainkey.<domain>). The selector is the label that lets multiple DKIM keys coexist on one domain — useful when you also send from Microsoft 365 (selector selector1), Google Workspace (selector google), or another tool (its own selector).

After publishing, give the record 5–10 minutes to propagate, then use the DKIM checker to verify:

The TXT or CNAME at <selector>._domainkey.<domain> resolves
The key is present and parses
The key length is at least 1024 bits (preferably 2048)

Common DKIM problem: the key length is too short. Keys under 1024 bits are quietly ignored by many mailbox providers in 2026. Most DKIM defaults today are 2048-bit, but legacy Microsoft 365 tenants from before 2020 sometimes still use 512 or 1024. If your client's domain has a stale legacy key, regenerate it from the Microsoft 365 admin console and re-publish.

Common DKIM problem: the wrong selector. If you copy a selector from a tutorial instead of the one your sub-account UI tells you to use, the cryptographic signature will fail to verify because the public key won't be at the location the signature header points to. Always pull the selector from the sub-account itself.

Step 3 — DMARC at p=none with reporting on

Publish this at _dmarc.<domain>:

v=DMARC1; p=none; rua=mailto:dmarc-reports@<your-domain>; pct=100; adkim=s; aspf=s

A few notes on the values.

p=none is monitor-only mode. You will see authentication results in the aggregate reports without affecting delivery. This is correct for the first 14 days.
rua=mailto: is the reporting address. Mailbox providers will email aggregate XML reports to this address daily. Use a real inbox you read, or use a DMARC report parsing service that ingests the reports for you.
pct=100 means the policy applies to 100% of mail. Once you move past p=none, you can ramp this from pct=10 upward to control rollout.
adkim=s and aspf=s request strict alignment. This is correct for most agency setups; relaxed alignment (r) opens the door to subdomain spoofing if you don't control all subdomains.

After 14 days at p=none, look at the aggregate reports. If 95%+ of legitimate mail is aligning correctly under both DKIM and SPF, move to p=quarantine; pct=25 and watch for another 14 days. Then pct=50, pct=75, pct=100. Then p=reject; pct=25, ramping the same way. Total time from p=none to p=reject; pct=100 for a clean domain: about 8 weeks.

Do not skip the ramp. A premature jump to p=reject will silently nuke any legitimate mail flow you didn't account for — transactional mail from a tool you forgot, a CMS that emails password resets, an ATS that emails interview confirmations. The aggregate reports surface those flows so you can authenticate them before they get rejected.

The free DMARC checker parses your record and surfaces every issue I have just listed.

Step 4 — MX, briefly

This one is short because if you are sending from a real domain, MX is almost certainly already set up. The thing to check is that bounce mail can come back. Run an MX lookup with the MX checker and confirm:

Records exist
Priorities are sorted (lowest first is preferred)
Target hostnames resolve to valid mail servers
Reverse DNS (PTR) on the target IPs matches the hostname (this catches a common Microsoft 365 misconfiguration where PTR is stale)

If MX is broken, fix it before any authentication work. Authentication on a domain that cannot receive bounces is incomplete.

The validation step that catches everything

After all four records are live, run the free deliverability audit against the domain. The audit reports:

SPF — record exists, parses, lookup count, included senders
DKIM — public key at expected selectors, key length, parse status
DMARC — policy, alignment mode, reporting URIs, percentage
MX — records, priorities, reverse DNS
Blocklists — Spamhaus ZEN, Barracuda BRBL, SpamCop SCBL, SORBS, plus three more

If any line is amber or red, fix it before you start sending. The cost of fixing authentication after a campaign has gone out is much higher than fixing it before.

Where the agency-level shortcuts are

For agencies running 20+ sub-accounts, three shortcuts:

Use a DMARC report parser. Aggregate XML reports from mailbox providers are unreadable. Tools that parse them and visualise alignment per source save hours per week.
Centralise the audit. Running the audit on every sub-account every Monday catches DNS drift caused by registrar UIs, third-party tools that overwrite records, or a clients' IT team making changes. The MailerMonk agency reputation scorecard runs the same audit against every sending domain you manage and surfaces deltas week-over-week.
Standardise the SPF/DKIM/DMARC values per ESP combination. If you have ten clients on Microsoft 365 + GHL, the SPF and DMARC records are nearly identical. Maintain a template per ESP combination and apply it consistently. The ESP setup guides cover the major ESPs in the same shape.

Common failure modes

The client's IT team adds a third SPF record. Common when a marketing tool gets onboarded directly by the client without your knowledge. Fix: weekly SPF check, alert on multiple-record drift.
DKIM key gets rotated by an ESP and the old TXT is left in place. Common when DKIM is published as TXT rather than CNAME. Fix: prefer CNAME; on TXT, rotate by adding the new selector first, then removing the old one.
DMARC rua= address becomes a black hole. Reports go to a mailbox no one reads, and authentication problems compound silently. Fix: route DMARC reports to a parser, not a human inbox.
The DMARC record has an extra ; or unbalanced quotes. Even small syntax errors cause mailbox providers to ignore the record. Fix: always validate the record after publishing.

What to do today

Pick one sub-account that is sending and confirm SPF, DKIM, DMARC are published correctly.
Run the free audit; fix any amber or red lines.
Add the audit to your weekly cadence for that sub-account.
Once it works for one, replicate the pattern across the agency.

If you want the audit running daily across every sub-account you manage with delta alerting, the agency reputation scorecard does it in one place. For the underlying protocols, the RFCs are the canonical sources: RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC).