SPF, DKIM & DMARC for SiteGround.
Unlike a bare registrar, SiteGround tries to do most of this for you: if your domain uses SiteGround's nameservers and SiteGround's email service, then SPF, DKIM, and DMARC are all created automatically the moment the website is provisioned. So the SiteGround job is less "add three records from scratch" and more "know where SiteGround already put them, confirm they're on, and merge in any other services you send through." The catch is that SiteGround splits the controls across two places and two interfaces: SPF and DKIM live in a dedicated Email > Authentication tool inside Site Tools, while DMARC is only ever a raw TXT record you edit in the DNS Zone Editor. This guide walks both, with the exact menu paths, the default record shapes SiteGround ships, and the one condition — SiteGround actually running your DNS — that everything depends on.
Why authenticate SiteGround?
Authentication is now the entry ticket to the inbox, not a nice-to-have. Under the Google and Yahoo sender requirements every sender needs at least SPF or DKIM aligned to the From domain, and bulk senders (more than 5,000 messages a day to Gmail) must have SPF, DKIM, and a DMARC policy. Because SiteGround hosts a huge number of WordPress sites, its servers send a lot of transactional mail — order confirmations, password resets, contact-form replies — as your domain. Without these records that mail is easy to spoof and quick to land in spam, and once your domain gets a reputation for unauthenticated mail it drags down everything you send, including your human replies.
The SPF reality for SiteGround
SiteGround publishes an SPF record for you automatically. Its default shape is `v=spf1 +a +mx include:_spf.mailspamprotection.com ~all`. Each piece matters: `include:_spf.mailspamprotection.com` authorizes SiteGround's outbound mail relay (mailspamprotection.com is SiteGround's mail-filtering platform, which resolves to a handful of ip4 ranges with no nested includes — a single DNS lookup), while `+a +mx` authorize your hosting account's own IP and MX records so mail generated by the server itself — WordPress notifications, PHP mail(), contact forms — also passes. Watch the lookup budget: this stock record already spends three of your ten SPF lookups (one each for `+a`, `+mx`, and the include) before you add anyone else. If SiteGround sends all your mail, leave this record alone. The moment you add another sender — Google Workspace, Microsoft 365, an ESP like SendGrid or Brevo, or SiteGround's own Email Marketing product — its `include:` must be merged into this same one record, never published as a second SPF TXT. And if you've moved your MX to Google or Microsoft and no longer send through SiteGround at all, the `+a +mx include:_spf.mailspamprotection.com` may be authorizing servers you don't use — worth trimming. The include itself is the recommended path for SiteGround-sent mail, so keep it unless you've genuinely stopped sending through SiteGround.
Step by step
- 1
Confirm SiteGround is actually running your DNS
Every auto-created record and every toggle in the Authentication tool only reaches your live DNS if the domain uses SiteGround's nameservers or SiteGround-managed DNS. If your nameservers point to Cloudflare, your registrar, or another host, then the authoritative zone lives there and nothing in Site Tools takes effect — you'd have to recreate SPF, DKIM, and DMARC in that provider's editor instead. Check the nameservers before anything else; this is the single most common reason SiteGround records 'don't work.'
- 2
Open the Email Authentication tool
This is SiteGround's purpose-built panel for SPF and DKIM, presented as two tabs. If your domain uses SiteGround DNS and SiteGround mailboxes, both are already switched on by default, so this tool is mostly for reviewing status and customizing. Note what is NOT here: DMARC. There is no DMARC toggle in the Authentication tool — that record is edited separately in the DNS Zone Editor.
- 3
Review the default SPF record
SiteGround ships `v=spf1 +a +mx include:_spf.mailspamprotection.com ~all`. The SPF tab lets you add extra A records and MX servers to authorize, block specific IP addresses, manage the include list, and adjust the trailing 'all' qualifier. Leave the record as-is if SiteGround sends all your mail. The `~all` is a soft-fail (accept but flag) — the safe default until every legitimate sender is listed.
- 4
Merge any other sending services into that one SPF record
If you also send through Google Workspace (`include:_spf.google.com`), Microsoft 365, an ESP, or SiteGround Email Marketing, each needs its include merged into this single record — a domain may publish only one SPF TXT, and a second one breaks SPF entirely. Add includes through the Authentication tool's include list, or edit the SPF TXT directly in the DNS Zone Editor. Let the SPF record generator assemble one valid string so the includes and qualifier are ordered correctly, and keep an eye on the ten-lookup limit as you add senders.
- 5
Confirm DKIM is Active
SiteGround auto-generates a DKIM key pair and publishes the public key at selector `default` (host `default._domainkey`), with a value of the form `v=DKIM1; k=rsa; p=…`. The DKIM tab shows ACTIVE or INACTIVE. If it's inactive, click ACTIVATE and SiteGround writes the record into the zone for you — you never generate or paste a key. To rotate the key, Deactivate then Activate. Remember this key only signs mail that SiteGround itself sends.
- 6
Find and edit the auto-created DMARC record
When the website was created, SiteGround added a basic DMARC record at `_dmarc` starting `v=DMARC1; p=none;`. Open the DNS Zone Editor, find the TXT record whose value begins `v=DMARC1`, click the pencil icon, and edit the Value to add your own reporting address — e.g. `v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com` — then Confirm. Keep the policy at `p=none` so you collect reports without affecting delivery. Build the value with the DMARC record generator if you want the tags formatted correctly.
- 7
Add external providers' DKIM under their own selectors
SiteGround's `default` selector only covers SiteGround-sent mail. Google Workspace, an ESP, or Email Marketing each hand you a different selector — `google._domainkey`, `s1._domainkey`, or a CNAME target they host. Publish those exactly as given as additional records in the DNS Zone Editor. Multiple DKIM selectors living side by side is normal and correct, because each is at its own host.
- 8
Verify everything resolves
Give DNS a few minutes to a couple of hours to propagate, then run your domain — and the DKIM selector `default` — through an external checker. Confirm exactly one SPF record, DKIM found at `default._domainkey`, and a single `_dmarc` record. The DNS Zone Editor's Manage DNS Records table is your source of truth for what SiteGround is actually publishing.
Records to add
SiteGround generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.
| Type | Host | Value |
|---|---|---|
| TXT | @ | v=spf1 +a +mx include:_spf.mailspamprotection.com ~allSiteGround's auto-created default SPF record. Merge any other sender's include into THIS one record — never publish a second SPF TXT. Value is exact for SiteGround-sent mail; +a, +mx, and the include each cost one DNS lookup (three total). |
| TXT | default._domainkey | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC… (illustrative public key)Auto-generated by SiteGround at selector 'default'. You never paste this — it's created when DKIM is Active. The key shown is illustrative; yours will differ. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comSiteGround creates a minimal p=none record automatically; edit it in the DNS Zone Editor to add your own rua reporting address. Illustrative value — keep p=none until reports are clean. |
Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.
The 10-lookup budget
SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what SiteGround's setup costs against that budget.
SiteGround adds 1 of your 10 lookups; ip4: and ip6: mechanisms are free.
DKIM
DKIM at SiteGround is fully automatic and does not require you to paste a key. When your domain uses SiteGround's nameservers and email service, SiteGround generates an RSA key pair, keeps the private key on its mail servers, and publishes the public key at the fixed selector `default` — so the record host is `default._domainkey` and the value has the form `v=DKIM1; k=rsa; p=<public key>`. You manage it entirely through Site Tools > Email > Authentication > DKIM, where the status reads ACTIVE or INACTIVE; clicking ACTIVATE writes the record into your zone, and to rotate the key you Deactivate then Activate again. The important limitation: this key only signs mail that SiteGround sends. Any mail you send through Google Workspace, Microsoft 365, or an ESP is signed with that provider's own selector and needs that provider's DKIM record published separately — SiteGround's `default` selector will not cover it.
DMARC
DMARC is the policy layer that ties SPF and DKIM to the visible From address and turns on reporting. SiteGround creates a basic DMARC record for you at `_dmarc` when the website is provisioned, starting at `v=DMARC1; p=none;`. Unlike SPF and DKIM, it is NOT in the Authentication tool — you edit it as a raw TXT record in the DNS Zone Editor (Site Tools > Domain > DNS Zone Editor, or Client Area > Services > Domains > Settings). Find the TXT beginning `v=DMARC1`, click the pencil icon, and add your own reporting address so aggregate reports reach a mailbox you read: `v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com`. Keep `p=none` while you monitor — it changes nothing about delivery, it just switches on the daily reports. Only after reports confirm every legitimate stream passes SPF or DKIM in alignment should you step up to `p=quarantine` and then `p=reject`.
Check it actually worked
Wait a few minutes to a couple of hours for propagation, then confirm all three from outside SiteGround with the SPF, DKIM, and DMARC checker — paste your domain and the DKIM selector `default`. You're checking for exactly one SPF record (not two), a DKIM key found at `default._domainkey`, and a single `_dmarc` TXT. SiteGround's own DNS Zone Editor (the Manage DNS Records table) is the source of truth for what the zone actually publishes, so cross-check there if a lookup disagrees. If a record is missing, re-check in this order: that SiteGround's nameservers are the ones actually serving the domain, that you edited the DMARC record in the DNS Zone Editor rather than looking for it in the Authentication tool, and that any external provider's DKIM was published at its own selector.
Common gotchas
- Coverage
The whole system depends on SiteGround running your DNS. If your nameservers point to Cloudflare, your registrar, or another host, the auto-created records and every toggle in the Authentication tool do nothing — you must recreate SPF, DKIM, and DMARC in that provider's DNS editor. Confirm the nameservers before troubleshooting anything else.
- DNS setup
SPF and DKIM live in Site Tools > Email > Authentication, but DMARC is only in the DNS Zone Editor. People hunt for a DMARC toggle in the Authentication tool, don't find one, and assume DMARC is missing — it's already there as a TXT record starting v=DMARC1.
- Coverage
SiteGround's default DKIM (selector 'default') only signs mail SiteGround sends. Mail from Google Workspace, Microsoft 365, or an ESP is unsigned by SiteGround and needs that provider's own DKIM at its own selector, or it will fail DKIM even though SiteGround shows DKIM as ACTIVE.
- Breaks auth
Never publish a second SPF record. When you add another sending service, merge its include into the existing v=spf1 …mailspamprotection.com… record via the Authentication tool's include list or the DNS Zone Editor. Two SPF TXT records make SPF fail for the whole domain.
- Coverage
If you've moved your MX to Google or Microsoft and no longer send through SiteGround, the default +a +mx include:_spf.mailspamprotection.com is authorizing servers you don't use — review whether the SiteGround include still belongs before you tighten the policy.
- DNS setup
SiteGround's stock SPF already spends three of your ten SPF lookups before you add a thing — one each for +a, +mx, and include:_spf.mailspamprotection.com. Merging Google Workspace (roughly two more) plus an ESP can creep toward the ten-lookup limit, so keep the record lean and trim +a/+mx if the SiteGround server no longer sends your mail.
- Coverage
SiteGround Email Marketing is a separate product with its own domain authentication (its own records, including a per-account spf.dnssmarthost.net include) — don't confuse authenticating that service with the mailbox SPF/DKIM the Authentication tool manages.
- Coverage
The ~all soft-fail is SiteGround's default; don't switch it to -all (hard-fail) until the checker confirms every legitimate sender is in the record, or you'll bounce your own mail.
Build your SPF record
SiteGround is pre-selected below. Add any other platforms you send through, then publish the single merged record.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSiteGround SPF — FAQ
Related reading
Once it's published, confirm everything resolves with the domain health check, then read who's sending as you with the DMARC report analyzer. Browse all sending sources in the generator. Authentication is only half of deliverability, though — a listed sending IP or domain still lands you in spam no matter how clean your SPF is, so it's worth watching the blacklists with blacklist monitoring.
Authenticated — now keep the list clean
Passing SPF, DKIM, and DMARC gets you to the inbox; a clean list keeps you there. Verify yours — start free with 100 credits, no card required.