Webnames.ca SPF, DKIM and DMARC setup, step by step

Webnames.ca documents v=spf1 include:_spf.webnames.ca -all for its hosted email. Obtain DKIM through your domain’s Email → Manage Accounts and Settings → Manage → DKIM page. Webnames publishes the DKIM TXT automatically when it hosts DNS; with external DNS, copy the account-issued TXT yourself. Its system checks propagation, enables signing and sends confirmation. Important: the current DKIM instructions require Webnames to be the domain’s only legitimate outbound email source. Webnames SPF setup; Webnames DKIM setup.

This guide is for an existing Webnames-hosted mailbox service meeting that sole-sender requirement, with either Webnames or third-party authoritative DNS. It is not a general mixed-provider DKIM guide, a mailbox migration, or instructions for mail hosted elsewhere merely because Webnames registered the domain.

No account configuration, DNS change or live email test was performed.

Check eligibility before touching DNS

Confirm that the mailboxes send through Webnames and that you have authority to administer the selected domain’s email service. Access to domain registration alone does not establish access to the email management interface or the authoritative DNS zone.

Inventory all legitimate outbound mail using the domain: mailbox users, website forms, CRM tools, marketing platforms, invoicing systems and gateways. The DKIM documentation says no other platform or email system may send from that domain under its current procedure. If another legitimate sender exists, stop the DKIM rollout and ask Webnames to establish the supported configuration for your account. Do not delete that sender’s records or redirect its mail just to make the inventory appear compliant.

The restriction is a documented Webnames product prerequisite, not a limitation of DKIM itself. Different services can technically use separate selectors and keys. That protocol capability does not override Webnames’ stated eligibility rule. The same article says its limitation may change; obtain current account-specific confirmation before treating a multi-sender domain as an exception.

Webnames’ newer SPF article expressly discusses multiple providers and includes an SPF merge tool. That does not by itself remove the separate DKIM restriction. Keep SPF authorization correct while the broader configuration is being resolved. DKIM prerequisites; SPF multi-provider guidance.

Have authorized access to the correct email account, the real DNS editor and any delegated child namespace. Save the existing SPF, selectors, public keys, direct or inherited DMARC policy, TTLs and sending-route configuration before a change. Arrange controlled external recipients for later testing.

The reviewed instructions do not identify a universal paid-plan requirement or administrator role label for DKIM. Missing controls need an access/product check with Webnames, not a guessed upgrade or permission expansion. Do not move nameservers, change MX, disable DNSSEC or alter credentials to fit this guide.

Review SPF and the actual envelope identity

The current SPF setup article and the main external-DNS table agree on this example:

v=spf1 include:_spf.webnames.ca -all

Use the current account’s confirmed requirements and the approved sender inventory before publishing it. The self-managed-DNS article still has a footnote referring to a:spf10.webnames.ca, despite its own main table now using include:_spf.webnames.ca. Do not reflexively combine both or assume an old existing policy can be replaced without review. Resolve an account-output discrepancy with Webnames. Current SPF article; external-DNS table and older footnote.

The include delegates the maintained sending-address list to Webnames’ SPF policy. -all means SPF fail for an otherwise unmatched source, not a guaranteed rejection by every receiver. Keep any deliberate existing qualifier until the owner approves a policy change; do not impose a stricter or weaker ending just to match a template.

SPF evaluates the SMTP MAIL FROM identity, normally visible in the delivered Return-Path, not automatically the address readers see in From. For a null reverse-path, SPF defines a HELO-derived identity. Record the receiver’s actual smtp.mailfrom rather than inventing a universal Webnames envelope domain. An SPF record at the parent does not automatically authorize a child envelope domain. RFC 7208 identity rules.

Publish only one v=spf1 TXT policy at the evaluated owner. Other unrelated TXT records may remain. Preserve legitimate existing authorizations; if their presence reveals another active sender, stop the sole-sender DKIM procedure rather than removing them without approval.

Check the full evaluated SPF tree before saving. Its ten-term DNS-query budget includes nested include, a, mx, exists, ptr and redirect processing as applicable, not merely ten literal includes. An all mechanism anywhere in a policy makes redirect= ineffective. A merge tool’s output still needs this review. SPF limits; redirect handling.

Apply SPF at the authoritative DNS service

When Webnames hosts both email and DNS, the dedicated SPF page says the policy is applied automatically. Inspect the existing authoritative TXT before adding anything. Do not create a duplicate policy because the tutorial has an example.

There is a documentation difference worth checking: the self-managed-DNS page also describes manual publication in Webnames DNS Hosting and website-hosting configurations. Use your actual service and current account instructions to determine whether publication has happened. For Webnames Website Hosting it names the Plesk Control Panel DNS section; for Webnames DNS Hosting it names DNS Admin. If a required policy is missing despite an automatic-provisioning expectation, resolve that state with Webnames rather than resetting the whole zone.

When another provider hosts DNS, edit that authoritative provider’s zone:

1. Confirm the actual domain and zone, including any separately delegated child.
2. Find the existing SPF TXT. Edit the reviewed policy if present; create one only if absent.
3. Use record type TXT and the full owner for the domain being authorized. For example.com, an editor managing that apex may use @ or a blank Name. Use that editor’s convention and confirm the expanded name is exactly example.com.
4. For an applicable child owner mail.example.com, the relative name would be mail in the example.com zone, or the apex marker in a separately delegated mail.example.com zone. Do not duplicate the zone suffix.
5. Save the complete, approved policy and inspect authoritative and recursive answers.

Webnames also documents Email → Manage Accounts and Settings → Manage → SPF. Its Merge Record Inputs control combines the supplied provider policies, followed by on-screen application instructions. This can help review existing SPF, but neither proves that every sender is legitimate nor approves mixed-sender DKIM. Do not import arbitrary search-result includes into the policy. SPF management procedure.

The full external-DNS onboarding table contains MX, SRV and mail-client autoconfiguration CNAME records. Do not apply that whole table as an authentication repair. Replacing MX changes inbound delivery; client-discovery records serve a different purpose. Preserve the established routing and configure only the approved authentication records here. The guide does not require new A, MX or CNAME records.

Webnames estimates 4–6 hours for SPF propagation. Existing cache TTLs and record correctness still matter; a timer is not a verification result. Lowering a TTL requires planning and does not expire older cached data immediately.

Obtain DKIM from the selected email domain

Recheck the sole-Webnames-sender prerequisite immediately before provisioning. Then follow the documented account path:

1. Open the domain that has Webnames email service.
2. Select the Email tab.
3. Under Manage Accounts and Settings, click Manage.
4. Click DKIM in the left margin and use the provisioning instructions shown for that domain.

The current help page establishes this entry point and the two provisioning branches. It does not give a universal additional button label for starting the process. Do not invent a separate “Verify” or “Activate” click. If the actual screen asks for a decision not explained by the account’s instructions, confirm it with Webnames before proceeding. DKIM setup and provisioning.

Webnames-hosted DNS

Webnames says it applies the required TXT automatically. Its system waits to confirm public propagation, then enables signing on the domain’s email service. A confirmation email follows when DKIM is active.

Inspect the generated record in the authoritative zone. If a child or _domainkey namespace is separately delegated elsewhere, do not assume a record in the parent zone is effective. Resolve that authority boundary before relying on automatic publication; never remove the delegation to force the workflow.

External authoritative DNS

The selected domain’s DKIM page provides the required TXT record on screen. Copy its exact owner and complete public value into the authoritative DNS editor. Use the account-issued selector and key, not the illustrative mail selector, sample domain or public-key text embedded in the help article.

Preserve all supplied tags and the full p= key data. Do not publish only the base64 portion, truncate it, create an empty p= value, or substitute a separately generated key. The signing private key stays with the provider; it must not be published in DNS or shared with another sender. DKIM public-key format.

After publication, Webnames periodically checks for the record and its propagation. Once confirmed, it enables signing and emails confirmation. The page does not publish a fixed check interval or guaranteed activation deadline. Do not repeatedly replace keys or toggle signing because a check has not completed immediately.

Map the issued DKIM owner without breaking existing DNS

A DKIM lookup uses the actual selector and signing domain: SELECTOR._domainkey.SIGNING-DOMAIN. Treat the current account’s issued name as authoritative; the following are owner-mapping illustrations, not Webnames account values:

• Full owner SELECTOR._domainkey.example.com: relative Name SELECTOR._domainkey inside the example.com zone.
• Full owner SELECTOR._domainkey.mail.example.com: relative Name SELECTOR._domainkey.mail in the parent zone, or SELECTOR._domainkey in a separately delegated mail.example.com zone.
• Full owner SELECTOR._domainkey.example.com inside a delegated _domainkey.example.com zone: relative Name SELECTOR.

Use the editor responsible for that namespace and confirm the final expanded owner. Preserve NS delegations and unrelated selectors. If the issued TXT owner already contains a CNAME, do not add conflicting TXT or delete that alias blindly. Establish the record’s owner and dependencies with Webnames and the DNS administrator first.

For a long public key, follow the DNS editor’s supported TXT entry format. Multiple quoted character strings in one TXT record are joined for evaluation; do not turn the segments into separate records or paste zone-file owner/TTL/type text into a value-only field. The help article’s displayed sample has adjoining example text, so copying it is particularly unsafe.

This is a native TXT workflow. There is no authentication CNAME to proxy or flatten, and no reason to change zone-wide CNAME settings. A DNS record’s presence still does not establish which key a sending service used.

Read-only lookup examples, with every uppercase placeholder replaced before use:

dig @AUTHORITATIVE-NAMESERVER SPF-DOMAIN TXT +noall +answer
dig @AUTHORITATIVE-NAMESERVER SELECTOR._domainkey.SIGNING-DOMAIN TXT +noall +answer
dig SELECTOR._domainkey.SIGNING-DOMAIN TXT +noall +answer

Compare the authoritative result and a recursive result with the exact account packet. Expect the approved SPF policy and complete DKIM TXT at the intended owner. No answer, an unexpected CNAME, a duplicated suffix or a truncated key is a problem to resolve, not a reason to skip verification.

Preserve DMARC and use the wizard deliberately

Inspect the visible From domain’s direct policy and any applicable inherited DMARC policy first. Preserve existing enforcement, alignment settings and authorized reporting recipients. Neither the SPF merge tool nor DKIM provisioning justifies replacing a working policy.

Webnames documents a DMARC entry in the same email management interface, available to its email customers. The wizard builds a record. For Webnames DNS, its Apply button inserts the crafted record into DNS; for external DNS, you copy the generated TXT manually. Treat Apply as an actual policy change, not a preview. Review the full proposed value and whether it would conflict with an existing policy before using it. Webnames DMARC wizard.

Only if no direct or applicable inherited policy exists, the owner approves a first policy and a monitoring plan is in place, a minimal monitoring TXT can be:

v=DMARC1; p=none

For From domain example.com, publish at full owner _dmarc.example.com, normally _dmarc relative to that zone. For From domain mail.example.com, its direct owner is _dmarc.mail.example.com: _dmarc.mail in the parent zone or _dmarc in a separately delegated child zone. Confirm the expanded owner and keep one valid policy there. Do not override inherited protection just to use this example.

This value does not request reports. Add an actual rua address only after the recipient and purpose are approved by the domain owner. Under RFC 9990 section 4, when the Organizational Domain where the policy was discovered differs from that of the report URI’s destination host, report-generating receivers must check DNS authorization. The same-Organizational-Domain case is excepted, even if the hostnames differ. Technical authorization is separate from approval to share report data.

The provider’s wizard article still illustrates pct and a one-week monitoring progression. Do not copy obsolete percentage rollout or move to enforcement merely because a week elapsed. Use current DMARC standards and evidence covering the legitimate sending inventory. Do not add failure-report destinations without a separate privacy review. Reports and inbox placement are not guaranteed by a policy string.

For message acceptance, DMARC may pass through either aligned SPF or aligned DKIM. But this DKIM implementation is not complete until the intended Webnames signature passes and aligns with the intended unchanged From, plus the trusted receiver reports dmarc=pass. A pass supplied only by SPF does not prove DKIM works. RFC 9989 DKIM identifiers.

Strict alignment requires exact domains; relaxed alignment uses the applicable Organizational Domain relationship. A child signing/envelope domain can therefore align with the parent From under relaxed rules but not strict rules. Do not claim strict SPF alignment or a custom Return-Path feature from this provider’s setup page. See raw DKIM results versus aligned DKIM policy results when a cryptographic pass and a policy result appear to disagree.

Confirm activation with actual mailbox messages

Separate three checkpoints: public DNS publication, Webnames signing activation, and delivered-message acceptance. The confirmation email establishes the provider’s reported activation state; it is not an authentication test of your own outgoing message.

After activation, send harmless mail from the intended Webnames mailbox to an authorized external recipient. Use the actual clients and outbound paths in scope. Another provider’s SMTP server, a website relay or a forwarded sample does not substitute for this direct mailbox-path test.

Inspect the receiving service’s original-message view or logs. Establish that the authentication results were generated within its known processing boundary and that its ingress handling strips, ignores or otherwise distinguishes externally supplied Authentication-Results. If uncertain, ask the receiver administrator to identify the real results in trusted logs. Neither a familiar authserv-id string nor a field’s position proves its origin. Discard attacker-supplied results. RFC 8601 forged-result safeguards.

Keep these identities together for the new sample:

• The intended visible From domain, unchanged rather than silently rewritten to a provider domain.
• The actual envelope smtp.mailfrom and its SPF result.
• The intended Webnames signature’s d= signing domain, s= selector and verification result, matched to the current account record.
• Its alignment under the applicable adkim policy, and the trusted receiver’s overall DMARC result.

Do not accept an unrelated passing signature as proof that the configured one works. Redact message content, personal addresses and other unnecessary identifiers before sharing diagnostic evidence. A single pass is evidence for that route and sample, not proof of every mailbox, message or future key rotation.

Troubleshoot provisioning and authentication separately

Another legitimate sender is discovered. Pause this DKIM procedure and obtain Webnames confirmation of a supported architecture. Do not use the SPF merge tool as an implied waiver of the sole-sender rule.

DKIM confirmation has not arrived. Verify the selected domain, current account packet, authoritative nameservers, delegated namespace, full owner and complete TXT value. Check DNS rather than repeatedly generating keys. No fixed activation SLA is established by the page; escalate a persistent correctly published-but-pending state with redacted records.

Activation is confirmed but DKIM is absent or fails. Confirm the message used Webnames outbound mail. Compare the actual selector and signing domain with the account’s record; investigate stale keys and downstream message modification. Do not replace the private key or disable security controls as a shortcut.

DKIM passes but is unaligned. Compare d= with the intended From and alignment mode. A provider-domain signature or rewritten From is not proof of branded authentication. Resolve the signing identity before marking DKIM complete.

SPF fail. Inspect the actual envelope owner and sending IP against its current policy. Do not blindly add an include to the visible From’s apex when a different domain was evaluated.

SPF temperror. Investigate temporary DNS lookup problems and retry after they are resolved.

SPF permerror. Check multiple SPF policies, malformed values, invalid referenced policies and the evaluated lookup budget. Fix these defects even if DKIM presently supplies a DMARC pass.

Automatic SPF appears missing. Reconcile the service-specific account instructions with the dedicated SPF page’s automatic claim and the self-managed page’s manual branches. Use the real authoritative zone, without duplicating records or applying the entire mail-onboarding table.

Authentication passes but mail lands in spam. Authentication is not a guarantee of delivery, content safety or inbox placement. Investigate the receiver’s handling separately without relaxing the domain’s policy by default.

Plan key rotation and rollback before using them

The DKIM page offers optional automatic key rotation every 180 days. It explicitly promises automatic DNS updates when Webnames hosts DNS. It does not establish an unattended external-DNS update mechanism or a complete external rotation handoff sequence.

For external DNS, do not enable automatic rotation blindly. Establish who will receive each new public record, how publication and signing cutover are coordinated, and how old keys remain available for in-flight mail. Confirm that procedure with Webnames before relying on rotation. After an approved rotation, repeat DNS, activation and delivered-message checks.

For a bad SPF edit, restore the saved, approved single policy for the affected owner. Do not reset the zone or change inbound MX. For a DKIM problem, coordinate signing state and key publication: removing a public key while it is still being used can cause failures. Webnames says its tool can enable or disable signing, but the reviewed article does not establish every rollback control or retention interval. Avoid speculative toggling; preserve the known-good key and route until an approved recovery plan is established.

Never weaken DMARC or remove other services’ selectors simply to conceal a failed check. Keep the evidence, approved changes and recovery state together.

Sources and documentation dates

The full retrieved help bodies display the following dates; they are distinct from this guide’s check date. The reviewed procedural prose establishes the controls and provisioning sequence. No customer screen or procedural screenshot was visually inspected for Webnames.

• DKIM Setup and Support.
• SPF Setup and Support.
• Email and Self-Managed DNS.
• DMARC Setup and Support. Current standards govern the obsolete pct example and policy-rollout cautions above.
• RFC 7208: SPF, RFC 6376: DKIM, RFC 9989: DMARC, RFC 9990: aggregate reporting, and RFC 8601: Authentication-Results.