Provider documentation checked on 8 November 2026. Account-generated values and current product support must still be verified for a real deployment.
34SP exposes DKIM activation under a site's Advanced settings and SPF publishing under DNS. Use those controls for the service they document, then verify the result outside the control panel. This guide applies to the Professional, Universal and WordPress Hosting scope listed by 34SP. Its DKIM article explicitly excludes Private SMTP servers, so do not apply this procedure to that product by analogy.
Confirm the service and existing permissions
Record the hosting product, domain, authoritative DNS provider and actual outbound route. A domain registered at 34SP may use external nameservers; the live delegation, not the registrar logo, determines where records matter. Save current SPF, selector records and DMARC policy before using an automatic control. Prepare an external test recipient and identify the owner who can reverse a bad change.
34SP's DKIM walkthrough identifies the supported hosting plans and external-DNS handoff. That distinction is important when a website, mailbox and private SMTP service share a brand but not a signing configuration.
Enable DKIM and inspect the generated DNS
References: RFC 6376 §3.6.2.
Sign in to the 34SP account, open Manage Sites and select the website. Go to Advanced, choose DomainKeys Identified Mail and select Enable DKIM. Inspect the resulting instructions and retain the public record details. Where 34SP manages the relevant DNS, verify the automatic publication. Otherwise, use the on-screen records at the actual authoritative DNS host.
Do not invent a selector or key from another customer's example. The generated owner and value must match the service that signs the message. If the expected selector already exists, resolve ownership before overwriting it. A provider-supplied CNAME and a raw TXT public key are different publication models; preserve the actual instruction.
Use the SPF shortcut only after inventory
References: RFC 7208 §4.5, RFC 7208 §4.6.4.
The SPF publishing guide directs users through Manage Sites, the domain, DNS, SPF Records and Add SPF Records. Because this is an automatic operation, compare the before-and-after records. Do not assume the control merged every third-party service already authorized for your domain.
There must be only one selected v=spf1 policy at an SPF owner. Other TXT records, such as verification tokens, may coexist there. If a policy already exists, establish the desired combined result before making changes and use the supported editor or support route to achieve it. Check evaluated include, a, mx, ptr, exists and redirect terms, including nested processing, against the ten-term limit. The limit is not simply the number of visible includes or raw DNS packets. Keep provider authorization scoped to the actual envelope sender, not merely the domain printed in a logo or Reply-To field.
Prove the change at DNS and receiver
References: RFC 9989 §5.3.5.
Query the exact selector at each authoritative server and compare its answer with the account instructions. Use dig @AUTH_SERVER TXT SELECTOR._domainkey.example.com for a TXT key, replacing placeholders; use CNAME when that is the supplied type. Query the SPF owner separately and ensure only one SPF policy is returned. A resolver's printed quotation marks are not necessarily literal key characters.
Then send from the real mailbox or application to the controlled recipient. Record visible From, Return-Path, DKIM d= and s=, and trusted Authentication-Results. A passing aligned DKIM signature can satisfy DMARC even if SPF's evaluated domain is different. A provider-domain signature that passes cryptographically is not automatically aligned with your own From domain.
Illustrative failure case: the control panel says enabled, but the authoritative selector query returns no record because DNS lives elsewhere. The correct repair is publishing the generated public record at that host, not changing DMARC to none. If DNS is correct but the message lacks a signature, confirm that the message used the supported 34SP route rather than Private SMTP or another relay.
Keep the recovery scope narrow
References: RFC 2308 §5.
The provider gives propagation estimates, but authoritative publication and cache expiry are distinct checks. Restore only the changed records or service setting when a regression is confirmed and the prior configuration is safe. Recheck unrelated business senders after any SPF edit. Repeat the test after a hosting-plan migration, external DNS move or selector change. This guide is based on provider documentation and protocol review; it does not claim an executed 34SP tenant test.