SPF, DKIM, and DMARC Setup for Local Business Email

Setting up SPF, DKIM, and DMARC is a one-time task that protects every email your business sends afterward — this covers the exact setup process, including where these records go and how to verify they’re working.

Key Takeaways

• All three records get added in your domain’s DNS settings, not inside your CRM or email platform.
• Most platforms, including GoHighLevel, generate the exact record values you need to copy in.
• DNS propagation is usually fast (under an hour) but can occasionally take up to 48 hours.
• Verifying the records after setup catches formatting mistakes before they affect real sends.
• This is a one-time setup per sending domain, not a recurring task.

Where These Records Actually Live

SPF, DKIM, and DMARC records are added to your domain’s DNS settings through your registrar or DNS host (GoDaddy, Namecheap, Cloudflare, Google Domains, etc.), not inside the email or CRM platform you use to send. This confuses a lot of business owners the first time, since the values themselves are generated by your sending platform.

The general process is the same regardless of platform:

1. Log into your CRM or email platform’s domain/sending settings and locate the SPF, DKIM, and DMARC record values it generates for your domain.
2. Log into your domain registrar’s DNS management panel separately.
3. Add each record as a new DNS entry, matching the record type (TXT, CNAME) exactly as provided.
4. Save the changes and wait for propagation.
5. Return to your sending platform and use its verification tool to confirm each record was detected correctly.

Setting This Up Inside GoHighLevel

GoHighLevel generates the specific SPF, DKIM, and DMARC values for your sending domain inside the email settings of your sub-account, typically under a domain or email settings section. The platform walks through adding a sending domain and displays the exact DNS records to add — the work on your end is copying those into your registrar’s DNS panel accurately.

Step	Where It Happens
Generate record values	Inside your CRM/email platform’s domain settings
Add the records	Inside your domain registrar’s DNS panel
Wait for propagation	Automatic — typically under an hour
Verify	Back inside your CRM/email platform’s domain settings

A common mistake is adding the records under the wrong subdomain (adding to the root domain when the platform specified a subdomain, or vice versa) — double-checking the exact host/name field the platform specifies, not just the value, prevents this.

What Each Record Should Actually Look Like

Record formats vary slightly by platform, but the general shape is consistent:

• SPF is a TXT record, usually at your root domain or a mail subdomain, listing which servers are authorized to send on your behalf (v=spf1 include:... ~all).
• DKIM is typically a CNAME or TXT record at a specific selector subdomain (something like s1._domainkey.yourdomain.com) pointing to a cryptographic key your platform manages.
• DMARC is a TXT record at _dmarc.yourdomain.com specifying a policy (p=none, p=quarantine, or p=reject) and, usually, an email address to receive reports.

Starting DMARC with p=none is a common and reasonable first step — it lets you monitor reports without affecting delivery, and you can move to a stricter policy once you’ve confirmed your legitimate mail is passing authentication consistently. For more on how these three records fit into the bigger deliverability picture, see the full email deliverability guide.

Verifying the Setup Worked

Once records have propagated, most platforms include a built-in verification check that confirms each record is correctly published and readable. If a platform doesn’t provide this, free third-party DNS lookup tools can confirm whether a specific TXT or CNAME record is live and correctly formatted at your domain.

It’s worth checking all three separately rather than assuming that because email is sending, everything is configured correctly — a domain can send email successfully with a broken or missing DMARC record, for example, and the problem only shows up later as unexplained deliverability issues covered in why local business emails land in spam.

Common Setup Mistakes to Avoid

A handful of small mistakes account for most failed or delayed authentication setups, and all of them are easy to catch with a careful second pass:

• Adding a record to the wrong host/name field — pasting the value correctly but under the root domain when the platform specified a subdomain (or the reverse).
• Leaving old, conflicting SPF records in place — a domain can only have one SPF record; if an old one exists from a previous email tool, it needs to be merged or replaced, not left alongside the new one.
• Forgetting to save changes at the registrar — some DNS panels require a separate “publish” or “save” step after adding a record, and it’s easy to assume the record is live when it’s still pending.
• Checking too soon — verifying immediately after adding a record, before propagation completes, can show a false failure; waiting even 15-30 minutes before checking avoids unnecessary troubleshooting.

After Setup: What Changes and What Doesn’t

Correct authentication doesn’t guarantee every email lands in the inbox — it removes one entire category of reason an email might get flagged, which is a meaningful head start. List quality and engagement, covered in email list hygiene for local business marketing, still matter just as much after authentication is set up correctly.

Think of authentication as a prerequisite rather than a complete fix: without it, inbox providers have a legitimate reason to distrust your domain regardless of how good your list and content are. With it, your actual sending reputation — built through list hygiene and engagement over time — becomes the deciding factor instead.