HostGator SPF, DKIM and DMARC setup, step by step

On this page: Choose the right route · SPF · DKIM · DMARC · Verification · Troubleshooting · FAQs

For email sent by HostGator’s cPanel mail service, open Email → Email Deliverability → Manage for the sending domain. Review the suggested SPF and DKIM records, preserve authorizations for your other senders, and publish the approved records wherever DNS is authoritative. Finish with a received-message check: a green cPanel status is not proof of DMARC alignment.

HostGator says SPF and DKIM are enabled by default for its cPanel accounts. That does not automatically publish the records at an external DNS host. Its documented workflow covers cPanel-hosted email, not third-party mail services. HostGator’s scope and external-DNS instructions

This is a documentary guide, not a report of changes or tests on a customer account.

Identify the sending service before editing DNS

HostGator can be your registrar, website host, DNS host, mail host, or some combination. Only the actual outbound mail service determines the SPF authorization and DKIM signing setup you need.

The instructions below follow HostGator.com’s cPanel documentation. They do not establish that every regional brand, reseller package, Windows service or separately purchased mailbox product has the same controls or outbound infrastructure.

Gather these before making a change:

• The sending domain and any aliases or subdomains used in From addresses.
• Access to its cPanel and authoritative DNS zone.
• A backup of current TXT, CNAME and other relevant records.
• A list of all legitimate outbound services, including forms, invoicing and marketing.
• One representative received message from each route, or a plan to test each after configuration.

Look at nameserver delegation, not the registrar’s logo. Do not switch nameservers merely to unlock a repair button. That would be a wider DNS migration affecting websites and other services.

Configure SPF from the account’s suggested record

1. Read the domain’s current status

Sign in to cPanel, open Email Deliverability, and select Manage beside the domain. Read the SPF problem description and the suggested name and value. Customize is available for reconciling the suggested policy. Repair lets you review recommendations before approving them, but is unavailable when the server does not control DNS. HostGator SPF management

Use the current account-generated value, not a historical SPF string copied from another customer’s installation. A server IP or include that was suitable for one hosting arrangement is not automatically right for another. If the suggestion cannot be reconciled with the service you actually use, obtain clarification from HostGator rather than guessing a universal include.

2. Merge, do not replace blindly

SPF evaluates the SMTP MAIL FROM domain, usually reflected in the delivered Return-Path, rather than the visible From address. With an empty reverse path it uses a HELO-derived identity. Publish the policy at the domain actually evaluated. An SPF policy at example.com is not inherited by bounce.example.com. SPF identities

Before installing the suggested record:

1. Read every TXT record at the intended owner name.
2. If a v=spf1 record exists, edit that policy instead of adding another.
3. Retain authorizations for other active senders. Add only verified HostGator requirements, once, before the terminal all mechanism.
4. Keep one version tag and one intentional final policy. Do not concatenate two complete SPF records.
5. Preserve unrelated TXT verification records and the existing ~all or -all choice unless a separate policy review justifies changing it.

SPF allows at most 10 evaluated DNS-query-causing terms, including nested includes and redirects. A short-looking policy can still exceed the limit. Check the whole evaluation path, not just the number of includes typed into your zone. Never use +all as a troubleshooting shortcut. SPF record selection and lookup limits

If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.

3. Publish in the authoritative zone

If HostGator controls DNS, review the final suggestion before installing it or use Domains → Zone Editor → Manage to edit the existing TXT record. HostGator’s manual example uses the domain name without www. If another provider controls DNS, copy the reviewed record there instead. The local cPanel zone is not an alternative public authority. HostGator manual DNS workflow

An owner field may expect @, a relative label or a full domain name. Follow that editor’s convention, then check the published owner. _spf is not a universal place to publish your domain’s SPF policy: it works only when that name is the evaluated identity or is deliberately referenced from another policy.

Publish the generated DKIM key and verify signing

In Email Deliverability → Manage, inspect the suggested DKIM TXT name and value. If the key is absent, use Generate Local DKIM Key as directed by the panel, then review the installation or repair. If the panel already reports a valid setup, do not regenerate a working key just to follow a checklist. For external DNS, publish the supplied public record at that host. HostGator DKIM workflow

Keep the two halves of DKIM separate: the mail server signs with a private key; receivers retrieve the corresponding public key from DNS. Publish only the public TXT record. Never place the output of View the Private Key in DNS, a ticket attachment or a public checker.

Do not publish the message’s DKIM-Signature header as a DNS key. One section of HostGator’s third-party-DNS article confusingly suggests copying that header; use the Suggested DKIM (TXT) Record Name and Value from Email Deliverability instead. A signature and a public-key record are different data. cPanel’s public-record procedure, DKIM public-key format.

cPanel offers Full and Split displays for the public value. Choose the format your DNS editor accepts. Multiple quoted chunks inside one TXT record can represent one long value; multiple separate TXT records at the same selector are not a substitute. Preserve every key character and avoid inserting extra spaces inside the key. cPanel DKIM controls

Use the exact generated selector, not an assumed default. A message’s DKIM s= selector and d= signing domain identify the lookup name:

selector._domainkey.signing-domain

For example, only if a real signature uses s=selector1 and d=example.com would you look up selector1._domainkey.example.com. The selector here is illustrative, not a HostGator setting. DKIM DNS discovery

If the requested owner already contains a CNAME or a key belonging to another active service, stop and resolve the conflict. Do not overwrite a different sender’s record. Likewise, avoid appending your domain twice when the DNS interface supplies the suffix automatically.

For an issued signing domain such as news.example.com, a full owner SELECTOR._domainkey.news.example.com is SELECTOR._domainkey.news relative to the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is SELECTOR. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.

Website mail needs its own check

For a WordPress installation, first trace the application’s real SMTP or API sending service before applying mailbox-specific DNS changes.

A successful webmail test does not establish that PHP or a WordPress plugin follows the same route. cPanel documents PHP configurations in which DKIM may not verify despite being enabled. Identify whether the application uses local mail, authenticated SMTP or a separate API service; obtain support for the actual route rather than changing server-wide security settings speculatively. cPanel’s PHP DKIM limitation

Keep DMARC aligned with the visible From domain

DMARC passes when either SPF passes with an aligned MAIL FROM domain or DKIM passes with an aligned d= domain. Both are desirable, but both are not required for a DMARC pass. Relaxed alignment accepts the same organizational domain; strict alignment requires an exact domain match. Current DMARC standard

Inspect _dmarc for the From domain and any applicable parent policy. Retain an established policy and reporting destination. Do not add a second DMARC record or downgrade p=reject to p=none merely because you are fixing HostGator authentication.

If there is no established applicable policy and you are beginning a monitored rollout, this is an illustrative TXT template, not an automatic recommendation for an existing domain:

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example reporting mailbox with an approved, functioning destination before publication. Use _dmarc only where the DNS editor appends the intended domain. Validate all legitimate senders before moving to enforcement. RFC 9989 supersedes RFC 7489 and removes the old pct tag; do not depend on percentage-based enforcement recipes.

Put DMARC at the intended DNS owner

For a policy directly on example.com, the full owner is _dmarc.example.com; a relative-name editor for the example.com zone normally needs _dmarc. For a deliberate policy directly on billing.example.com, the full owner is _dmarc.billing.example.com: enter _dmarc.billing in the parent example.com zone, or _dmarc in a separately delegated billing.example.com zone. These are naming examples, not a recommendation to override an existing parent policy. Check the published full name and applicable policy before changing it.

Aggregate reports help identify source IPs, authentication results and forgotten senders over time. External reporting destinations can require DNS authorization at the report receiver’s domain. External-destination authorization Failure reports can reveal message information, so do not enable them without considering privacy and access. Aggregate reporting, failure reporting

Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.

Verify public DNS, then a real received message

DNS checks

Substitute your real domains and observed selector. These are read-only examples, not test results:

dig +short NS example.com
dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com

Query a subdomain separately if it is the actual MAIL FROM identity. If results differ from your editor, compare the authoritative server with a public recursive resolver:

dig @ns1.dns-provider.example TXT example.com
dig @1.1.1.1 TXT example.com

Replace the illustrative nameserver with one returned by the NS lookup. Expect one SPF policy at the evaluated owner, the exact public DKIM key for the current selector, and one intended DMARC record at its policy owner. No answer, a doubled suffix, stale data or SERVFAIL requires diagnosis, not repeated record creation. Wait for the applicable TTL and negative-cache expiry when the authoritative record is correct.

Message checks

After configuration, send representative messages through the real webmail, desktop-client and application routes to an external mailbox you control. Read that receiver’s raw source or authentication summary. Trust results added by the receiving system, not an arbitrary sender-supplied header. Authentication-Results trust boundary

Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.

Record these observations for each route:

• spf=pass and the exact smtp.mailfrom domain.
• dkim=pass, the signing domain header.d, and the signature’s selector s=.
• dmarc=pass for the visible From domain, with at least one aligned passing method.
• The receiving provider, date, message ID and any bounce or spam placement.

For the HostGator DKIM setup to be verified, require dkim=pass on the signature using the expected cPanel-issued selector, with its d= domain aligned to the final visible From domain. A passing signature belonging only to an unrelated provider domain is not enough. Even if aligned DKIM makes DMARC pass, investigate SPF fail, softfail or temperror for the actual envelope domain; fix authorization or DNS errors rather than hiding them behind the DMARC pass.

Diagnose SPF at the actual observed envelope domain even when aligned DKIM produces a DMARC pass. fail or softfail means the actual connecting sender was not authorized by the evaluated policy (with different policy dispositions); temperror indicates a transient evaluation problem, such as DNS availability; permerror indicates a permanent policy problem, such as invalid syntax, duplicate SPF policies or an exceeded evaluated lookup budget. Investigate each cause separately rather than treating DKIM success as an SPF repair. SPF result definitions.

A DNS lookup proves publication, not signing or alignment. A cPanel Valid status is useful configuration evidence, not a substitute for this message-level check. Authentication also does not guarantee inbox placement.

Troubleshoot the failing layer

For escalation, provide the exact product, domain, DNS host, affected route, timestamp, bounce text and a redacted received header. Never supply a private DKIM key or mailbox password.