Unlimited Web Hosting SPF, DKIM and DMARC setup, step by step

For an existing Unlimited Web Hosting (UWH) cPanel mail account with DKIM already enabled and cPanel authoritative for its DNS, use Email Deliverability → Manage for the intended domain. Review the server's suggested SPF policy and DKIM public record before publishing or repairing anything. Then verify the intended UWH-hosted message's signature and DMARC alignment at a controlled receiving mailbox. Do not copy a universal UWH include or selector: the documented values depend on the actual server and domain.

This guide combines UWH's cPanel SPF procedure with the cPanel software interface reference. It does not claim that a customer account was inspected.

On this page

• Check the account and sending route
• Review SPF before installing the suggestion
• Inspect and repair the DKIM public record
• Verify DNS owners and public answers
• Preserve DMARC and approve reporting
• Test the intended mailbox route
• Troubleshoot without changing unrelated services
• Frequently asked questions
• Sources and verification limits

Check the account and sending route

This is a native cPanel mailbox workflow, not a configuration for every product sold by Unlimited Web Hosting. It excludes Plesk, DirectAdmin, self-managed servers, external authoritative DNS, external SMTP platforms and independent website/PHP mail. A website hosted at UWH can still send through a completely different provider.

Confirm these prerequisites with the account and DNS owners:

• The domain belongs to the correct existing UWH cPanel account and uses that account's native mail service.
• DKIM signing is already enabled for the account. UWH's WHM provisioning instructions document Enable DKIM and Enable SPF during account creation. That supports the product's provisioning capability, not a claim that every existing account has the same settings. Do not create a replacement account to repair authentication.
• The DNS server managed through this cPanel account is actually authoritative for the relevant domain and signing namespace. A local zone alone is not proof. Stop if the public authority is elsewhere rather than migrating nameservers for this task.
• You have authorized cPanel access and the Email Deliverability feature is available. cPanel says the hosting provider controls feature availability; do not grant broad WHM privileges or buy an upgrade merely to expose a control.
• The mailbox and DNS owners have approved the change scope, test recipients and recovery plan.

Record the current DNS, selectors, direct or inherited DMARC policy, approved visible From address, actual outgoing transport and every other service sending for the same domain. Keep the intended mailbox account, address book or client configuration separate from unrelated application mail.

The software documentation excludes email and DNS editing for temporary cpanel.site domains. Do not apply this procedure to a temporary preview identity. For mail actually sent through Microsoft 365, use its separate SPF and DKIM setup guide; a UWH cPanel repair does not enable Microsoft signing.

Review SPF before installing the suggestion

UWH documents cPanel → Email → Email Deliverability → Manage beside the intended domain, then the SPF section. The suggested record is based on the current mail server configuration. Treat it as a proposal to compare with your complete sending inventory, not permission to replace a multi-provider SPF policy.

Before approving Install the suggested record:

1. Identify the actual SMTP MAIL FROM domain used by the native message. It may differ from the visible From; a null reverse-path uses the relevant HELO identity. SPF evaluates that identity, not the brand address simply because it appears in the email.
2. Query the current TXT policy at the evaluated owner and identify every legitimate authorization. Keep exactly one applicable v=spf1 policy there. Other unrelated TXT records are allowed and must remain separate.
3. Compare the suggestion with existing authorized senders, the actual outbound server and the owner's chosen qualifiers. Resolve conflicts or missing information with UWH and the DNS owner before installation.
4. Publish only the approved result, then requery authoritative DNS and an independent resolver. A successful local install does not prove that public DNS changed.

UWH's basic v=spf1 +a +mx ~all is an explanatory example, not a universal account policy. The a and mx mechanisms can authorize web-host and inbound-mail addresses; check whether those systems genuinely send outbound mail. Do not change A or MX routing to make an example appear correct. Likewise, do not copy private example IPs or illustrative include domains from a syntax lesson into production.

The current cPanel reference provides Customize for reconciling the current and suggested SPF records, a preview, and Install a Customized SPF Record. Review the entire preview, including automatically included server addresses and existing authorizations. Adding a service does not mean adding another full SPF policy. Preserve the owner's intended final qualifier rather than adopting a UI default automatically.

SPF's limit is ten evaluated DNS-query-causing terms, including nested mechanisms and redirects, not ten includes or ten network packets. An all mechanism makes redirect ineffective; careless merging can disable an existing redirect-based policy. SPF does not inherit from a parent domain. Qualifiers determine SPF results, not a guarantee of final inbox placement or rejection.

When the approved policy needs the Zone Editor

UWH also documents Domains → Zone Editor → Manage. For a new SPF policy, use Add Record, choose TXT, enter the full domain name with its trailing period in Name, enter the approved policy in Record, and choose Save Record. For example, example.com. is the full apex owner; it is not a literal hostname named @. For news.example.com, use the intended full owner news.example.com..

If an SPF policy already exists, reconcile that policy rather than using Add Record to create a duplicate. This guide does not prescribe an undocumented edit-button sequence. Use the actual interface's supported existing-record controls or the documented Customize workflow, and stop if you cannot verify the result. The authoritative-cPanel-DNS prerequisite applies to both UWH methods.

Inspect and repair the DKIM public record

After selecting Manage for the correct domain, inspect the DKIM section. The software reference identifies a Suggested “DKIM” (TXT) Record with generated Name and Value when a problem is detected. Use the actual account's complete public record, not a selector or key copied from another hosting guide.

For this existing-DKIM-enabled scope:

1. Inspect the current DNS and signing state first. If the intended signature already passes and aligns, leave the working key alone.
2. Compare the suggested public TXT owner and full value with authoritative DNS, existing selectors and any delegated _domainkey namespace.
3. If a repair is necessary and approved, use cPanel's documented Repair review to inspect the proposed invalid-record corrections before confirming them. cPanel says the system rechecks repaired records, which can take up to five minutes depending on the server. Do not accept unrelated recommendations as a batch by accident.
4. Requery the actual authoritative records and then test a newly delivered native-mail message. A repaired DNS status is not proof of signing activation or alignment.

Copy supplies the public Name and Value. Full displays the whole record for DNS systems that split long values automatically; Split displays 255-character parts for systems that need them. These are representations of one complete TXT value, not separate keys or independent TXT policies. Preserve all tags and key characters without truncation or inserted spaces.

The interface also documents Generate Local DKIM Key when no key exists and View the Private Key. Neither is a routine repair step in this guide. If the account has no usable key or signing is not enabled, stop and have UWH confirm the account-specific enablement/recovery procedure before changing keys. Do not expose a private key in DNS, screenshots, tickets or external generators. Public-key publication and the server's private-key signing operation are different responsibilities.

The Repair control is unavailable when cPanel does not control the DNS. Although the software reference discusses local records and external nameserver coordination, this UWH guide deliberately does not extend to an unverified external-DNS workflow. Never move nameservers or remove a delegation to make Repair available.

Verify DNS owners and public answers

The actual DKIM signature supplies selector s= and signing domain d=. Its verification name is the selector followed by ._domainkey. and the signing domain. The following are mappings only; issued-selector is not a prescribed UWH selector:

• Full owner issued-selector._domainkey.example.com is relative issued-selector._domainkey in the example.com zone.
• Full owner issued-selector._domainkey.news.example.com is relative issued-selector._domainkey.news in the parent zone, or issued-selector._domainkey in a separately delegated news.example.com zone.
• If _domainkey.news.example.com is separately delegated, its relative selector is issued-selector. Preserve that delegation and coordinate with its actual authority rather than publishing an ineffective parent-zone record below it.
• Full SPF owner example.com is the apex; news.example.com is relative news in the parent zone or the apex of its own child zone. UWH's documented Zone Editor input uses full names with trailing periods. Do not duplicate the zone suffix.

These examples explain DNS names, not eligibility to add a new sending subdomain. Stop if the actual authority or required record type differs from this established TXT workflow. Do not substitute CNAMEs, enable HTTP proxying or change global flattening controls for a TXT-only repair.

Use read-only queries with the actual domains, selector and authoritative server substituted:

dig @ns1.example.net TXT example.com
dig @ns1.example.net TXT issued-selector._domainkey.example.com
dig @1.1.1.1 TXT issued-selector._domainkey.example.com
dig @1.1.1.1 TXT _dmarc.example.com

ns1.example.net is an authoritative-server placeholder, not a UWH server address. Compare the complete returned public key and policy with the approved account values. Multiple quoted character strings can concatenate into one TXT record; do not split one key into multiple independently published records. Distinguish authoritative publication from resolver caching and cPanel's status refresh before repeatedly editing records.

Preserve DMARC and approve reporting

Discover the applicable direct or inherited DMARC policy for the visible From domain before making changes. Keep existing protection and approved report destinations. Do not install cPanel's suggested DMARC record automatically over a working policy or add a child monitoring override that weakens inherited enforcement.

Only if no applicable policy exists, and the domain owner approves a first monitoring policy and ongoing review plan, this minimal TXT example may be appropriate:

Full owner: _dmarc.example.com
Relative owner in example.com zone: _dmarc
Type: TXT
Value: v=DMARC1; p=none;

For news.example.com, full owner _dmarc.news.example.com is relative _dmarc.news in the parent zone or _dmarc in its own delegated zone. Use the correct editor convention and publish only one policy at the intended owner. Monitoring is not a reason to downgrade an established policy.

The example intentionally has no report recipient. Add only a provisioned, monitored destination approved for the report data, access and retention. Compare its Organizational Domain with that of the domain where the DMARC policy was found. A different Organizational Domain requires the report-generating receiver to verify DNS authorization; the same-Organizational-Domain exception applies even if hostnames differ. RFC9990 section 4 defines this rule. Protocol authorization does not replace the domain owner's separate data-sharing decision.

cPanel's UI prerequisites are not a replacement for the protocol: DMARC can pass through either aligned SPF or aligned DKIM. For this DKIM setup, however, require the intended DKIM path to work, not merely a DMARC pass supplied by SPF. Review all legitimate sources and indirect-mail paths before stronger enforcement. RFC9989 section 7.4 addresses valid DKIM signatures for domains publishing p=reject. Do not revive obsolete pct rollout advice or tighten policy based on one successful mailbox test.

Test the intended mailbox route

With the mail owner's approval, send harmless synthetic content to controlled, valid external recipients through each native mailbox route actually used. Use the approved authenticated client or webmail configuration; do not change credentials, transport security or routing merely for the test. Do not generate customer notifications or use customer lists for diagnostics.

Establish which Authentication-Results fields were generated inside the receiving service's known processing boundary, using that service's documented handling of externally supplied fields or its administrator's guidance. A familiar authserv-id string or header position alone is not evidence. Ignore attacker-supplied and otherwise untrusted results. RFC8601 security requirements.

Record the actual MAIL FROM, connecting source, unchanged approved visible From, DKIM d= and s=, SPF result, DKIM result and trusted DMARC result. Completion requires:

• The intended UWH-hosted native signature passes DKIM.
• Its signing domain aligns with the approved visible From under the current DMARC policy.
• The visible From has not been rewritten to a provider identity.
• The trusted receiver reports dmarc=pass.

Strict alignment requires identical domains; relaxed alignment permits the applicable Organizational Domain relationship. A child envelope domain does not automatically meet strict SPF alignment. Neither the DNS key's existence nor an unrelated passing signature proves this acceptance gate. The sources do not establish a universal UWH MAIL FROM, selector or signing domain for every account.

Investigate SPF separately even when DKIM supplies DMARC pass. Distinguish authorization fail or softfail, policy/syntax/lookup-limit permerror, temporary DNS temperror, and none or neutral. A DNS status or one passing mailbox does not certify every application, alias or forwarding route.

Troubleshoot without changing unrelated services

Email Deliverability is absent: confirm the hosting product, cPanel version and feature availability with UWH. Do not broaden privileges or switch to another panel's instructions.

Repair is unavailable: inspect authoritative DNS and delegated namespaces. A local cPanel zone may not control the public answer. Do not change nameservers to force the repair.

Suggested SPF removes another service: stop and reconcile the current policy with every legitimate sender. Review Customize's complete preview and preserve the intended qualifier and redirect behavior.

DNS passes but DKIM is missing: verify the actual outgoing route and account's signing state. A PHP script running under a shared nobody process can have different signing behavior; the software reference discusses host-level settings for that case. It is outside this mailbox procedure. Ask UWH to diagnose it rather than enabling header-trust or server-security options yourself.

DKIM verification fails: compare the signature's selector/domain with the actual authoritative public key, full TXT value and intended account. Investigate downstream modifications to signed content. Do not rotate or regenerate a working key as the first diagnostic action.

DMARC fails while SPF or DKIM passes: compare the authenticated identities with the unchanged From and effective alignment mode. Do not add unrelated SPF includes or weaken policy to hide an identity mismatch.

An old domain appears in the panel: cPanel explains that retained DNS zones can keep former domains listed. A listing does not prove current authority or ownership. Zone deletion is a separate reviewed cleanup, not part of this authentication fix.

A change disrupts mail: obtain the relevant owner's approval to pause the affected stream and restore only the approved prior configuration. Preserve unrelated concurrent changes, shared selectors, delegated namespaces and keys needed by queued mail. Retest the failed path and a previously known-good path before resuming. Recheck after account migration, server/IP changes, DNS-authority changes, key changes or a new sender. Never reset a zone or change MX/PTR merely to satisfy a suggested-record screen; inbound routing and IP-owner reverse DNS require separate authority and review.

Sources and verification limits

• UWH: add or edit SPF in cPanel, including the current-server suggestion and full-name Zone Editor method.
• UWH: create a cPanel account, used only to establish DKIM/SPF provisioning support, not as an instruction to create an account.
• cPanel: Email Deliverability, software-reference controls, public-key handling, authoritative-DNS and PHP-route limitations.
• RFC7208 SPF, RFC6376 DKIM, RFC8601 Authentication-Results, RFC9989 DMARC and RFC9990 aggregate reporting.

The procedures above are supported by explicit current source prose. Linked SPF and provisioning screenshots could not be visually inspected, so no additional fields or values were inferred from them. No customer cPanel screen, DNS change, send, delivery outcome or CMS rendering was tested. Keep those operational checks separate from this documentary guide.