Identify hosted mail before changing defaults
This guide covers mail sent by SiteGround's hosted-mail servers. It does not assume that SiteGround Email Marketing, a website plugin using an external SMTP service, or a mailbox hosted elsewhere follows the same route. Record the sending mailbox, selected site, From domain and authoritative DNS host. Save a baseline message and a zone export before altering the defaults.
SiteGround documents automatically created SPF and DKIM records. The authentication controls are under Site Tools > Email > Authentication; DMARC is managed in the DNS Zone Editor. A default in that panel is a starting configuration, not proof of a delivered aligned message. SiteGround authentication controls.
Inspect existing values instead of replacing them
Open the domain's DNS Zone Editor and inspect the current TXT records. SiteGround's record-checking article documents a default DKIM owner of default._domainkey beneath your domain. Use the actual key and hostname from your own account. Identify any customizations and their owners before choosing a reset action. Inspect SPF and DKIM.
If DNS is hosted elsewhere, copy the necessary public records to that authoritative service through its administrator. Query the nameservers used by receivers to confirm publication. Do not migrate DNS merely because the hosting panel contains a convenient editor. Keep the website's A records and working inbound MX routing outside the scope of this authentication change.
If SPF already authorizes other systems, preserve their verified permissions in the single applicable SPF policy. A reset to the hosting default could silently discard a payroll or CRM route. Check syntax and lookup cost after merging, and distinguish the domain SPF actually evaluates from the visible From domain. SPF protocol.
Treat DKIM regeneration as a key change
The provider documents deactivating and reactivating DKIM to regenerate a record. Do not use regeneration as the first diagnostic step for a transient delivery issue. Capture the current selector and public key, identify any queued mail, and plan publication with the DNS owner before replacing a working key. SiteGround controls.
A new DNS value can propagate differently across resolvers, so an apparently immediate panel change does not prove that every recipient can verify the new signature. Use a controlled message after the change and check the selector in that message against the public key it actually references. Keep the operational rollback plan separate from a promise that an old private key can be restored; confirm that capability with the provider first.
Build a route-specific acceptance record
The table is a synthetic test plan. No SiteGround tenant or delivered message was inspected for this guide.
- Route: Hosted mailbox via normal client; Evidence to preserve: Original headers and client SMTP target; Acceptance decision: Confirm the intended SiteGround sending route
- Route: Website notification; Evidence to preserve: Plugin transport and receiver results; Acceptance decision: Establish whether it actually shares that route
- Route: Separate marketing service; Evidence to preserve: Service-specific settings and original message; Acceptance decision: Do not inherit the mailbox's pass result
- r each message, record visible From, SMTP envelope domain, DKIM d= and s=, and the trusted receiver's results. A validated d=example.com signature with From user@example.com is an exact-domain alignment example; it is not a claim about SiteGround's observed output. If SPF passes for another domain, evaluate aligned DKIM before declaring DMARC broken. DMARC alignment.
Recover without widening the incident
When records appear in Site Tools but not public DNS, investigate nameserver authority and hostname construction. When mail is unsigned, confirm the product and SMTP path before changing keys. When signature verification fails, compare the selector lookup and any message-modifying gateway. When only website mail fails, inspect the website's transport configuration rather than resetting mailbox authentication.
If a change disrupts another sender, restore the saved SPF or DMARC policy and retest that sender plus the hosted mailbox. Retain the before-and-after records, timestamps, approved scope and received originals. Review defaults after a hosting migration, custom-domain addition or DNS move. Authentication success does not establish inbox placement, and this documentary draft does not claim live validation.
Separate the working mailbox from the failed website route
Written case SG-01 stipulates a hosted-mail message with From help@example.org and trusted DKIM pass using d=example.org, s=default. A website plugin instead submits through an unrelated external SMTP service and has no collected authentication results. The hosted message supplies exact DKIM alignment only for its own route. The website owner should identify that plugin’s actual envelope and signing configuration before any SiteGround reset. Keep the mailbox key and other SPF senders intact. These are fictional identities and outcomes; no tenant, plugin, DNS query or message was inspected.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.