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

For WHC-hosted mailbox email, open cPanel → Email → Email Deliverability and select the domain. If that cPanel system controls authoritative DNS, review its proposed changes before approving Repair. If DNS is hosted elsewhere, use Manage to copy the domain’s generated SPF and DKIM TXT records, then publish them at the actual DNS provider. WHC does not publish one universal SPF value or DKIM key for every account. WHC authentication procedure.

This guide covers an existing Web Hosting Canada native mailbox service administered through cPanel, with Email Deliverability available. It includes both WHC/cPanel-hosted and external authoritative DNS. It does not configure Microsoft 365, Google Workspace, an independent mail provider merely using WHC DNS, temporary domains, PHP mail, or a different hosting control panel.

No customer login, DNS change or test send was performed.

Identify the sending account and DNS authority

Confirm that the mailbox really sends through WHC’s native mail service. A website hosted at WHC or a domain registered there does not establish the email route. Record the intended From address, actual SMTP or webmail route, account owner and domain before opening a repair tool.

WHC tells readers to distinguish email hosting from DNS management. Nameservers determine which provider serves the public DNS; the registrar may be different. Also inspect any existing delegated child zone or _domainkey namespace before publishing there. Do not move nameservers to make a local DNS editor authoritative. WHC DNS authority and editor guide.

A WHC account can involve more than one DNS interface. In particular, the authentication article’s external-authority screenshot shows a local cPanel record that would be ineffective even though the actual nameserver names also belong to WHC. “Hosted at WHC” is not enough: use the panel serving the exact authoritative zone.

You need authorized access to the relevant cPanel account and the actual DNS editor. cPanel’s documentation says the hosting provider controls whether Email Deliverability is available. If the feature is missing, confirm the product and permissions with WHC; do not try to change server-wide features or switch accounts by assumption. Temporary cpanel.site domains do not support email services. cPanel applicability.

Before making changes, save the current SPF policy, DKIM records, direct or inherited DMARC policy, relevant delegations and TTLs. List every legitimate sender using the domain. If employee mail actually uses Exchange Online, follow the separate Microsoft 365 SPF and DKIM guide, not the native WHC values.

Retrieve the domain-specific public records

In the correct cPanel account:

1. Open Email → Email Deliverability.
2. Find the intended domain, rather than selecting all listed domains.
3. Open Manage to inspect the domain’s current state and suggestions.
4. In Suggested “DKIM” (TXT) Record, copy the complete Name and public Value.
5. In Suggested “SPF” (TXT) Record, copy the Name and Value for review against the existing policy.

WHC documents the Manage-and-copy path for external DNS. The current cPanel manual explains the generated Name/Value fields, public-key display options and SPF customization. These are account outputs, not records to construct from another customer’s screenshot. WHC native workflow; cPanel generated records.

If the system has no DKIM key, cPanel documents Generate Local DKIM Key for that case. Do not generate a replacement merely because the public record is missing or a DNS cache is stale. Preserve a working signing configuration and obtain WHC’s help if the account state is unclear.

Copy the entire public DKIM value, including its tags and complete p= key. Full displays the complete value; Split displays it in 255-character parts for editors that need that representation. Those parts belong to one logical TXT record. Do not publish each part as an independent DKIM key or truncate a long value.

Do not use View the Private Key for DNS setup or share a private key with a public checker. The public TXT record is sufficient. The native records in this guide are TXT; do not substitute CNAMEs from another mail provider’s instructions.

Reconcile SPF before accepting a suggestion

WHC’s screenshot contains a particular server IP, include domain and A/MX mechanisms. They are examples, not a WHC-wide policy. Use the current output for the selected domain, while retaining legitimate authorizations already present.

SPF evaluates the SMTP MAIL FROM domain, often reflected in the received Return-Path, rather than automatically evaluating the visible From. For a null reverse-path, HELO handling is relevant. Inspect the actual receiver-reported smtp.mailfrom identity. A provider-owned envelope identity cannot be made aligned with your brand merely by editing the brand’s apex SPF. SPF identity selection.

At the actual evaluated owner:

• Publish only one TXT policy beginning v=spf1.
• Compare the existing policy with cPanel’s suggestion. Merge only the approved required authorizations; do not overwrite other senders or add a second policy.
• Review every suggested IP address, a, mx and include against the actual authorized routing plan. cPanel can automatically include server addresses and mail-exchanger-related hosts. A website’s address or an inbound MX host should not gain outbound authorization without that review.
• Preserve the intended qualifier. cPanel normally recommends ~all, but a template does not authorize changing an existing -all or another deliberate result.
• Preserve redirect= behavior. Adding an all mechanism causes that redirect to be ignored.

Do not change A/AAAA records, MX routing or nameservers to make an SPF suggestion look correct. Those changes affect services beyond authentication. A child envelope domain needs its own applicable SPF policy; the parent’s policy does not automatically apply there.

SPF permits no more than ten evaluated DNS-query-causing terms, including nested processing. Count the full tree, not just the visible include entries; a, mx and redirect also matter. Duplicates, malformed syntax or an excessive evaluated term count can cause permerror. SPF limits; redirect and all.

Use Customize for an approved mixed-sender policy

cPanel’s Customize option shows the current and suggested SPF records and a preview of the updated value. It exposes host, MX, IP and include settings. Use it only to implement the reviewed sender inventory, not to add broad authorizations experimentally. Inspect the full preview before Install a Customized SPF Record. That local installation still does not publish to an external authoritative DNS service. cPanel SPF customization.

An unmatched source’s ~all result is softfail, and -all produces fail. Neither qualifier by itself determines the receiver’s final delivery decision. Do not adopt the manual’s simplified implication that softfail guarantees acceptance.

Publish through the correct DNS branch

When this cPanel system controls authoritative DNS

WHC documents Repair beside the domain in Email Deliverability. cPanel’s current manual says a window lets you review and confirm recommended repairs, and copy or customize a suggestion before approval. Inspect that proposal against the approved SPF policy and exact DKIM public record. If it would remove other senders or overwrite shared data, stop and reconcile it before approval. The system then rechecks repaired records. Repair review and recheck.

For a manual record edit in WHC’s hosting panel, open Domains → Zone Editor. Edit the intended record and choose Save Record, or use + Add Record, the correct record type and details, then Save Record. Save only the approved changes. Do not reset the zone or batch-repair unrelated domains. WHC DNS editing.

When another DNS system is authoritative

Use Manage, copy the domain’s public DKIM Name/Value and reconciled SPF policy, then publish them as TXT at the actual DNS host. Repair is unavailable when the cPanel system does not control the records. A local Install the Suggested Record can leave public DNS unchanged; the WHC screenshot explicitly warns about that case.

If the domain uses WHC’s separate parked-DNS service rather than hosting cPanel DNS, its documented route is Client Area → Domains → My Domains → Manage → gear icon → DNS Zone Editor. Add or edit the exact record, then Publish Changes. Use this only when it is the authoritative service for that domain, not as a second place to create duplicate records. WHC’s separate DNS interfaces.

Map full and relative owner names

SELECTOR below is a placeholder for the actual selector in the account’s issued Name:

• Signing domain example.com: full owner SELECTOR._domainkey.example.com; relative owner SELECTOR._domainkey in its zone.
• An actually configured signing domain news.example.com: full owner SELECTOR._domainkey.news.example.com; relative SELECTOR._domainkey.news in the parent zone, or SELECTOR._domainkey in a separately delegated child zone.
• An existing _domainkey.example.com delegation: publish relative owner SELECTOR in that delegated zone. For _domainkey.news.example.com, the selector is likewise relative to that authority. Preserve existing NS delegation; do not delete it or add an ineffective parent-zone copy.
• SPF at example.com uses that full owner or the editor’s apex convention. SPF for an actual envelope domain news.example.com uses news in the parent zone or the child zone’s apex.

Check whether the editor automatically appends the domain. Do not create a doubled suffix. Preserve unrelated TXT records and other services’ selectors. If the exact DKIM owner contains a CNAME or another service’s key, resolve that conflict with its owner before writing TXT. Multiple independent public keys at the same selector are not a safe workaround. DKIM public-key lookup.

This TXT-only native route does not need HTTP proxy or CNAME-flattening changes. Keep MX, parent nameservers, DNSSEC, website records and unrelated security settings unchanged.

Check public DNS and prove the intended signature

Use read-only lookups, replacing the fictional domains, server and SELECTOR with the account’s real values:

dig NS example.com
dig @ns1.example.net TXT example.com
dig @ns1.example.net TXT SELECTOR._domainkey.example.com
dig TXT example.com
dig TXT SELECTOR._domainkey.example.com
dig TXT _dmarc.example.com

Query the authority that actually serves each owner, then compare a recursive resolver. Expect one applicable SPF policy and the exact current public DKIM value. One TXT resource record may contain several quoted character strings; interpret them together. Record the change time and prior TTL before blaming a correct authoritative record for an older cached response.

Return to Email Deliverability and recheck the domain’s status. Keep that DNS-status evidence separate from message evidence. WHC’s supported procedure is Repair or Manage/publication; it does not document a separate customer signing toggle here. Do not invent one. If the expected signature is missing after the correct records are public, have WHC confirm the native mailbox route and signing state.

For message acceptance, send a new message through each actually used in-scope mailbox route, with harmless synthetic content and controlled, valid external recipient mailboxes. Do not test on customers, a live campaign list or only an internal recipient. This project has not performed those sends.

Open the received original message. Use Authentication-Results generated inside the receiving service’s known processing boundary, with its documented treatment of externally supplied result fields. If uncertain, ask the receiving administrator. A familiar authserv-id or header position alone is not proof; ignore attacker-supplied or otherwise untrusted results. Receiver-result security.

Record the unchanged approved From, actual connecting IP and smtp.mailfrom, SPF result, intended DKIM d= and s=, DKIM result and DMARC result. Match the intended WHC signature to the account’s public key. DNS existence or a signature header’s presence does not prove verification.

Acceptance requires that intended signature to pass DKIM and align with the intended branded From, plus trusted dmarc=pass. DMARC passing only through SPF, a passing unrelated signature or a provider-rewritten From does not validate the intended custom-DKIM configuration.

Relaxed alignment permits a common Organizational Domain; strict alignment requires identical domains. DKIM compares d= with From under adkim; SPF compares the authenticated envelope domain under aspf. The reviewed sources do not guarantee one WHC Return-Path or strict-alignment pattern. Inspect the actual identities and resolve a mismatch without weakening policy. DMARC alignment.

Add DMARC only when there is no applicable policy

Inspect the exact From domain’s DMARC record and applicable inherited policy before using a suggestion. Preserve existing protection, an existing p=none, alignment settings and authorized report destinations. Do not overwrite policy with a dashboard template or create a weaker child override.

Only if no direct or applicable inherited policy exists, and the domain owner approves the first policy with an assigned monitoring and review plan, a minimal initial TXT value is:

v=DMARC1; p=none

For From domain example.com, use full owner _dmarc.example.com, relative _dmarc in its zone. For news.example.com, use _dmarc.news.example.com, relative _dmarc.news in the parent zone or _dmarc in the delegated child zone. Publish one policy. This value requests neither enforcement nor reports; add a real rua recipient only after approving and configuring reporting. DMARC policy discovery.

When the reporting destination’s Organizational Domain differs from that of the domain where the policy was found, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted. A different hostname alone is not the boundary. Have the report receiver provide the required authorization arrangement. RFC 9990 section 4.

That DNS check does not replace the owner’s permission to share sending-activity data. Approve the recipient, access and retention separately. Do not copy report addresses or enable forensic reporting from a generic example.

DMARC can pass with either an aligned SPF pass or an aligned DKIM pass; it does not require both to pass on every message. The intended DKIM setup still has its own acceptance requirement above. Before any domain-wide p=reject decision, review all legitimate and indirect routes: RFC 9989 requires valid DKIM signatures rather than reliance solely on SPF, and warns about forwarding and mailing-list interoperability. Interoperability requirements.

Diagnose failures and recover narrowly

Repair is unavailable: verify the actual authoritative DNS. Use the external-publication path when the local system lacks control; do not move nameservers just to enable Repair.

Manage shows records but public DNS does not: check the full owner, suffix handling, selected zone, delegation and whether changes were saved in the authoritative interface. A local installation warning is not a propagation issue.

DKIM is missing or fails: inspect the actual SMTP/webmail route, d=/s=, complete public key, selector conflicts and any message-modifying gateway. Preserve working keys; ask WHC to confirm signing if exact public records and the expected route still produce no intended signature.

SPF fail or softfail: inspect the actual connecting source, envelope owner and authorized route. None or neutral: check the evaluated owner and policy rather than treating these as passes. Permerror: inspect duplicate policies, syntax and nested lookup-budget exhaustion. Temperror: investigate temporary DNS availability and resolution, then retest before rewriting a correct policy. Diagnose SPF independently even when DKIM supplies DMARC pass.

DMARC fails despite an authentication pass: compare the passing identity with the unchanged From under the effective policy. Additional includes cannot repair a signing-domain mismatch.

Before rollout, obtain mailbox/application-owner and DNS-owner approval for the narrow recovery plan: who may pause affected sends, restore exact approved prior records, or coordinate account-side recovery. Preserve concurrent changes, shared selectors, unrelated records and public keys needed by queued messages. Avoid bulk Repair or zone restoration as an unreviewed rollback.

Retest after restoration and after account, server, DNS, mail-route or signing-key changes. Keep original/final records, account-issued values, status evidence and controlled test results together. PTR changes, PHP handler changes, private-key export and obsolete-zone deletion are outside this mailbox-authentication task.

Sources and verification limits

The main sources are WHC’s native SPF/DKIM procedure, its DNS-management guide, and the current cPanel Email Deliverability manualfor versions 130 onward. Confirm the actual installed interface rather than assuming every account has that version.

Four WHC interface images were inspected. Its linked DKIM-output image could not be retrieved; no visual validation of that image is claimed. The full procedural text and cPanel Name/Value documentation support the instructions. WHC’s authentication body did not establish an update date; its DNS guide displayed a relative update label, not an absolute date.

These checks concern documentation and the manuscript only. Customer eligibility, actual DNS, account state, delivered-message evidence and production behavior remain untested.