SiteGround SPF, DKIM and DMARC setup, step by step

Use SiteGround's DNS Zone Editor to publish the authentication records supplied by your email sender. The current central path is Client Area → Services → Domains → Settings → DNS Zone Editor. SiteGround mailbox defaults do not authenticate every external service, and SiteGround Email Marketing has a separate domain-authentication workflow. Current DNS-management guide

This guide covers publishing SPF, DKIM and DMARC in SiteGround DNS for outside mail services, with separate branches for SiteGround mailboxes and Email Marketing. It also explains how to handle SiteGround mail when DNS is hosted elsewhere.

Start with DNS authority and a sender inventory

Check the delegated nameservers before editing. SiteGround's DNS editor manages domains pointed to SiteGround nameservers. A website hosted there can still have its authoritative DNS elsewhere. The editor's presence in your account does not prove its records are the public ones. SiteGround authority requirement

List every route using your domain: hosted mailboxes, WordPress forms, newsletters, receipts, help-desk systems and SMTP relays. For each, record the visible From domain, envelope MAIL FROM domain, intended DKIM signing domain and selector. Obtain the exact DNS instructions from that sender's account and administrative access to the relevant zone.

Do not infer mail settings from the website's server region or from a regional storefront. SiteGround describes mailbox SPF/DKIM records as domain-specific. The values displayed for the account are the source of truth, not another customer's generated hostname. Domain-specific authentication values

Before changing anything, save the record names, types, full values and TTLs. Preserve existing senders, verification tokens, MX and website records. An authentication-only task does not require a nameserver migration or switching MX presets. If DNS is elsewhere, publish at that provider without moving the zone.

Find the right SiteGround editor

For central management, open Client Area → Services → Domains, select the domain's Settings, then DNS Zone Editor. In Create New Record, choose the required TXT or CNAME type and save with Create. For an existing record, use the pencil icon under Manage DNS Records, then Confirm. A one-hour cache duration is SiteGround's suggested choice when you are unsure; retain sender-specific requirements where applicable. Central editor workflow

For domains associated with an active site, Site Tools → Domain → DNS Zone Editor is another supported entry point. It has the same distinction between creating a record and editing one. Do not confuse this DNS editor with Site Tools → Email → Authentication, which manages SiteGround mailbox authentication rather than generating every external sender's DKIM key. Site Tools DNS editor

Enter the exact DNS owner, type and value

SiteGround appends the domain to DKIM record names in Site Tools. Use the relative label, not the full domain repeated twice. For an apex SPF TXT record, the documented DNS-editor example leaves Name empty. DKIM owner handling and SPF Name field

If you are editing example.com, map required names as follows:

A separately delegated news.example.com zone instead uses s1._domainkey and _dmarc. Confirm the final saved full name in the editor and public DNS. These examples explain names only; s1 is not a SiteGround-wide selector to copy.

If _domainkey.news.example.com itself is a separately delegated zone, full s1._domainkey.news.example.com uses relative s1 there. For the mailbox selector, substitute the actual default label only where that is the issued configuration. Preserve the existing NS delegation and publish at its operator, not an inactive parent-zone copy. DNS zone boundaries.

For TXT DKIM, use the sender's full public-key value in Value. For CNAME DKIM, use its exact target hostname in Resolves to, without a URL scheme. Keep all required records, including spare selectors needed for rotation. If a CNAME owner already has other data, stop and identify the dependency. Do not delete another sender's working selector just to satisfy the new request. SiteGround TXT/CNAME DKIM procedure

For CNAME-based external senders or the Email Marketing CNAME branch, verify the DNS host preserves the requested literal alias. This is not a claim that SiteGround provides a proxy or flattening switch. When DNS is external and such behavior applies, where the issued authentication or return-path records require literal CNAME answers, use DNS-only aliases returning the exact targets, without an HTTP proxy or flattening hiding them. Turn the relevant per-record Flatten control off when available and ensure applicable zone settings preserve those aliases. Cloudflare documents that flatten-all cannot be overridden per record, apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory apex/same-zone behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sender. Do not blindly change the whole zone or remove an existing delegation. CNAME verification, flattening controls and limits. These controls do not apply to the native mailbox TXT key.

Never publish a private key. TXT public keys and CNAME delegations are distinct instructions, not interchangeable formats. A long public key may appear as multiple quoted strings inside one TXT record; this is different from creating multiple conflicting records at that selector. DKIM record format

Publish SPF for the actual envelope sender

SPF checks the SMTP MAIL FROM domain. It does not directly authenticate the visible From address. Use receiver evidence, especially smtp.mailfrom and the sending IP, to determine the policy that was evaluated. A root SPF policy does not automatically apply to a subdomain; adding an include at your root does not align an unrelated provider-owned return path. SPF identity rules

For an external sender, use its current domain-authentication instructions. If it requests an SPF include at an owner that already has SPF, edit that policy rather than adding a second one. If it configures a custom MAIL FROM through CNAME or other supplied records, preserve that design instead of inventing a root include. For sender-side Workspace configuration, see the Google Workspace guide.

Keep one v=spf1 policy per owner. Preserve approved mechanisms and the intended final all qualifier, placing new authorizations before it. Validate syntax and the full path of DNS-lookup-causing terms, including nested includes, against the limit of ten. ~all is softfail for unmatched IPs, not pass. Never add +all as a workaround. SPF publication and evaluation

If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed design. SPF all and redirect processing.

SiteGround hosted mailbox SPF

SiteGround creates default SPF and DKIM records for websites. Inspect the current TXT entries in the central DNS Zone Editor: the SPF record begins v=spf1. The documented defaults are recommended for SiteGround outbound mail unless manually changed. Do not assume they cover an external newsletter or relay. How to inspect current mailbox records

For mailbox settings, Site Tools → Email → Authentication → SPF exposes customization. Use the value for your own domain, preserving other legitimate authorizations. Do not copy the hashed hostname from a generic article, replace the full policy with a guessed mailspamprotection.com include, or use Reset to default on a multi-sender domain without reviewing what would be removed. Mailbox SPF controls

Activate DKIM at the sender, not just in DNS

For external services, first generate or retrieve their records in the sending account, publish them in SiteGround, then complete that service's verification and signing activation. SiteGround cannot enable signing in Google, Microsoft or a transactional sender by storing a record alone. Check that the intended domain is selected in the sending account. SiteGround's sender-provided DKIM model

SiteGround hosted mailbox DKIM

The documented mailbox selector is normally default._domainkey.example.com, a TXT record whose public value belongs to the domain. Check the actual record rather than assuming a static key. Default selector and current-value inspection

In Site Tools → Email → Authentication → DKIM, inspect ACTIVE/INACTIVE. Mailbox DKIM is enabled by default; if disabled, ACTIVATE restores the documented configuration when SiteGround manages the zone. Do not deactivate a working selector merely to regenerate it. Key changes can invalidate in-flight messages or leave external DNS with the old key. Mailbox DKIM activation

When SiteGround mail uses external DNS

The message SPF/DKIM RECORD CANNOT BE UPDATED can mean SiteGround is not authoritative, not that the records are invalid. Copy the domain-specific SPF/DKIM information from Site Tools → Email → Authentication and publish it at the actual DNS provider. Reconcile SPF with existing senders there. Changing nameservers is not necessary for this manual alternative. Official external-DNS procedure

SiteGround Email Marketing is a separate product

Email Marketing requires a registered main domain that is not already linked to another SiteGround Email Marketing tool. Generic subdomain DNS examples do not override this product restriction. Check the selected domain carefully: SiteGround says it cannot be changed after confirmation. Select Authenticate, then Confirm in the irreversible-process warning to start authentication. Domain eligibility and initiation

With SiteGround nameservers, the product creates SPF/DKIM automatically. With external DNS, copy the supplied record, normally a CNAME at mailmarketing._domainkey; rare accounts receive TXT instead. Use the account's exact type and target. Check Sender Details for successful domain authentication. Email Marketing authentication

For Email Marketing with external DNS, SiteGround documents this product-specific SPF mechanism:

include:_spf.emsnd.net

It belongs inside an applicable SPF policy, not as a standalone TXT policy. For an owner with no existing SPF and no other senders, the documented complete example is:

v=spf1 include:_spf.emsnd.net ~all

Preserve other sending services and their policy qualifier when merging. This is not the universal mailbox SPF record. Email Marketing SPF instructions

SiteGround's marketing pages differ on whether DMARC is automatically created. Inspect the existing policy and report destination rather than assuming either outcome. Do not overwrite a functioning policy or add a duplicate. The authentication page says a custom reporting destination requires attention; the DMARC page describes automatic configuration for SiteGround DNS. Authentication guidance and marketing DMARC guidance

Keep DMARC and reporting consistent across all senders

DMARC needs a passing, aligned SPF or DKIM result. Relaxed alignment means the authenticated domain and visible From share an organizational domain; strict alignment means an exact match. For a normal example.com setup, news.example.com can align in relaxed mode but not strict mode. Read existing aspf and adkim settings before deciding a result is aligned. Current DMARC standard

Retain an existing policy, including inherited parent protection and reporting settings. A new child p=none record can change that protection. Do not weaken enforcement just because a setup article starts with monitoring.

Only if no direct or applicable inherited DMARC policy exists, and the domain owner approves this first policy and a monitoring/review plan, publish one TXT record using the following illustrative value. Provision the approved reporting destination before using it:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Use an approved monitored mailbox instead of the example. The owner is _dmarc.example.com, not the apex. Use _dmarc in the example.com zone; for _dmarc.news.example.com, use _dmarc.news in the parent zone or _dmarc in the delegated child zone. Check for an existing DMARC record first. Policy publication and inheritance

Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Obtain the reporting operator's exact authorization instructions when required. This protocol check is separate from the domain owner's approval to share report data; agree access, retention and privacy. RFC 9990 section 4.

Review legitimate senders, failures and alignment over representative traffic before enforcement. p=none does not override other spam filters; reports are evidence, not a delivery guarantee.

Before a separate domain-wide move to p=reject, follow RFC 9989 section 7.4: legitimate outbound mail needs valid DKIM, and indirect-mail interoperability, including forwarding and mailing lists, needs review. Completing this sender alone does not authorize enforcement for every route.

Verify public DNS and each actual sending route

Replace the example domains, nameserver and selector below. Query the actual SPF owner, not automatically the visible From domain. Use default only for the matching mailbox configuration, mailmarketing only when supplied for Email Marketing, or the external sender's actual selector.

dig +short NS example.com
dig @ns1.dns-host.example TXT example.com +noall +answer
dig @ns1.dns-host.example TXT default._domainkey.example.com +noall +answer
dig @ns1.dns-host.example CNAME mailmarketing._domainkey.example.com +noall +answer
dig @1.1.1.1 TXT bounce.example.com +noall +answer
dig @1.1.1.1 TXT _dmarc.example.com +noall +answer

Repeat against each authoritative nameserver and a public resolver, including each required DKIM owner. For CNAMEs, follow the exact returned destination with a TXT lookup. Expect the complete public key or correct delegation, a single appropriate SPF policy, and the intended DMARC policy. Distinguish missing names, incorrect values, SERVFAIL and caching. Provider estimates vary by workflow; compare authoritative answers now rather than waiting blindly for a fixed propagation window.

Next, after activation, send an authorized new message through each actual mailbox, campaign and application route, using harmless synthetic content and controlled valid external recipient mailboxes. Do not test on customers or a live campaign audience. In raw headers, inspect the receiving system's trusted Authentication-Results. Match the intended branded DKIM-Signature domain d= and selector s= to a dkim=pass, and record actual smtp.mailfrom, SPF result and sending IP. Require dmarc=pass for the visible From and identify the aligned mechanism. Receiver-result trust boundary

Establish which results were generated inside the receiving service's known processing boundary and how it removes, ignores or distinguishes externally supplied Authentication-Results. Use receiver-controlled diagnostics or have the receiving-mail administrator confirm its documented handling. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain authenticated receiving-system evidence when provenance is uncertain. Receiver-result trust.

For each route, require its intended branded DKIM signature to pass and align with the unchanged approved From under the effective adkim policy, together with trusted dmarc=pass. Reconcile the expected and observed signing domain and selector; do not accept an unrelated signer or provider-rewritten From as completion.

A generic vendor-domain signature or an ARC signature does not prove your branded DKIM configuration works. A DMARC pass supplied only by SPF is also insufficient to close a DKIM task. Investigate actual SPF errors: duplicate/syntactically invalid/over-limit policies for permerror, DNS resolution for temperror, and the real sending IP versus envelope policy for fail or softfail. A valid DNS string alone is not an SPF pass. Test forwarding separately and repeat unaffected sender tests after a merge.

Troubleshooting and safe rollback

SiteGround documents Reauthenticate under Email Marketing → Sender Details → Domain & Address after correcting a missing or misspelled marketing record. A repeated domain suffix is a known failure pattern. Marketing authentication troubleshooting

Rollback only the affected record to its saved value after checking concurrent changes. Avoid whole-zone restoration, SPF resets and DKIM deactivation as general troubleshooting shortcuts. Keep old keys until the sender's rotation and queue requirements permit removal. Confirm DNS, sender status and fresh-message results after rollback.

Before rollout, agree the narrow recovery plan with the mailbox or application owner and the DNS owner: who may pause affected sending, who may restore the exact approved prior records, and when recovery is authorized. Preserve concurrent changes and keys still needed by queued messages; coordinate any account-side restoration before retesting the affected route.

Retaining old public DNS keys can help validate earlier messages, but does not guarantee that a regenerated private signing key can be restored. Coordinate any key change with SiteGround or the actual sender before disrupting a working route.

Documentation review and testing limits

No provider account, DNS zone or mail-delivery operation was tested or changed. The procedures are based on public documentation; generated values, real message authentication, inbox placement and deployed-page behavior require separate verification.