On this page: SPF · DKIM · DMARC · Verification · FAQs
For supported 34SP hosting, enable DKIM in the site’s Advanced settings and review the SPF record generated by its DNS tools. Publish any externally managed DNS records exactly as the account instructs. Finish by checking a real received message for SPF, DKIM and DMARC alignment, not just a successful control-panel action.
This guide covers the documented Professional Hosting, Universal Hosting and WordPress Hosting DKIM workflow. Private SMTP servers are explicitly outside that workflow. Other products, reseller arrangements and independently operated servers need their own verified instructions.
First establish which 34SP service sends your mail
A domain can be registered at 34SP, have its website hosted there and send all email elsewhere. Those are separate roles. Start with a recent message from each important application. Record the visible From domain, Return-Path, SMTP service and any DKIM signing domain and selector. Do not assume a contact form and staff mailbox use the same outgoing service.
Before proceeding you need:
- Access to the hosting product and domain in the correct 34SP account.
- Access to the authoritative DNS host, which may not be the registrar.
- A zone backup or export and the current authentication records.
- An inventory of other legitimate senders sharing the domain.
- An external test mailbox whose raw message source you can inspect.
Check the supported-product boundary before looking for an Enable DKIM button. The official article names three hosting products and excludes Private SMTP. An absent button is not evidence that adding a made-up DNS key will enable signing. Confirm the actual service with 34SP if your product or panel differs. 34SP DKIM scope
Add or reconcile SPF through the supported workflow
34SP documents this route: sign in, select the domain under Manage Sites, open DNS, then SPF Records. The Add SPF Records action creates the provider’s records automatically. The public instructions do not supply a universal literal SPF include to paste into every installation. Use the account’s generated policy or obtain the exact authorization for your service from support. The documentation allows 24–48 hours for propagation. 34SP SPF workflow
Before using an automatic DNS action, inspect what already exists. If the panel does not show how it handles your custom policy, do not click through and hope it merges safely. Ask for the required authorization and merge it through a controlled change instead. This precaution is especially important when billing, marketing or a helpdesk already sends for the domain.
SPF checks the SMTP MAIL FROM domain, or HELO when the reverse path is empty. The visible From address alone does not identify the SPF owner. A policy at example.com is not inherited by bounce.example.com. Keep one v=spf1 TXT record at each evaluated owner; retain unrelated TXT records. Merge required sender authorizations into that single policy without copying a second v=spf1 or terminal all clause. Preserve the existing final qualifier until an intentional policy review says otherwise. SPF identity and record selection
Check the resulting policy’s evaluation paths. SPF permits no more than 10 evaluated DNS-query-causing terms, counting nested includes and redirects as applicable, not just the number of providers visible in the record. Extra a, mx, exists and ptr mechanisms also matter. A +all shortcut is not a fix, and deleting still-used senders can break legitimate mail. SPF processing limits
If DNS is external, changing a non-authoritative 34SP zone does not publish anything to receivers. Obtain the generated policy for the correct service and apply the reviewed value at the authoritative host. Do not move nameservers simply to make a one-click feature work; that is a separate migration affecting much more than email.
Activate DKIM and publish the generated record
For the supported hosting products, choose the site under Manage Sites, open Advanced, then DomainKeys Identified Mail, and select Enable DKIM. The official workflow updates DNS when the domain is with 34SP. Otherwise it directs you to follow the on-screen DNS instructions. Capture those exact account-specific values rather than borrowing a selector or key from a guide. 34SP DKIM activation
Regardless of registrar, verify the domain’s nameserver delegation before relying on automatic publication. The decisive question is which zone is authoritative. Keep a record of the owner, record type, complete public value or target, and the domain and service it belongs to. Never publish private keys or mailbox credentials.
A DKIM verifier reads the selector s= and signing domain d= from the signature, then queries selector._domainkey.signing-domain. Use the generated owner precisely. If your DNS editor automatically appends the domain, enter the relative host only where that interface expects it. A doubled suffix produces a valid-looking record at the wrong name. DKIM key discovery
Do not create an arbitrary TXT key just because a checker reports no DKIM. Signing must be enabled on the outbound service, and the published public key must match the key it uses. If the displayed record is a CNAME, preserve its exact target and check for conflicting data at that owner instead of placing a TXT key alongside it. Resolve ownership conflicts before changing records used by another sender.
The following processing checks apply only if the current account instructions actually issue a CNAME; they do not convert a TXT key into an alias. Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls.
Retain the right DMARC policy
DMARC connects authentication to the visible From domain. A message passes when either SPF passes with an aligned MAIL FROM domain or DKIM passes with an aligned signing domain. Relaxed alignment permits the same organizational domain; strict alignment requires an exact domain match. Passing authentication for an unrelated platform domain is not enough. RFC 9989 DMARC
Review _dmarc at the sending domain and any applicable parent-domain policy. Do not add a competing record or replace an established p=quarantine or p=reject policy with p=none during provider setup. A monitoring policy can be appropriate for a genuinely new rollout without an existing applicable policy, but it should follow an inventory of legitimate senders. RFC 9989 supersedes RFC 7489 and removes the old pct tag: percentage-based enforcement advice is not current.
Choose an approved reporting destination and confirm any required external-report authorization. Aggregate reports can expose unrecognized senders and alignment failures over time. They are not a guarantee of inbox placement. Failure reports can disclose message information and require a deliberate privacy decision. Aggregate reporting, failure reporting
First-time monitoring record: illustrative template
Only when no applicable established DMARC policy exists, a first monitoring record can look like this. Replace the example report mailbox with an address you control or a reporting service has authorized; do not publish the placeholder unchanged.
Type: TXT
Full owner: _dmarc.example.com
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Use one DMARC TXT policy at that owner, with semicolons separating tags. In a DNS editor that appends example.com, the relative host is _dmarc. For the visible From domain news.example.com, the exact owner is _dmarc.news.example.com, or _dmarc.news within the example.com zone. Do not create a child p=none policy that overrides inherited parent enforcement. External rua destinations need the report receiver's authorization where required. RFC 9990 external reporting authorization
If news.example.com is a separately delegated authoritative zone, that same full DMARC owner is entered as _dmarc relative to the child zone, not _dmarc.news. Publish at the actual authority and preserve its NS delegation. These mappings apply only to an owner-approved first-policy rollout with no direct or inherited policy to preserve; do not create an unnecessary child override. DMARC policy publication, relative DNS names.
Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, 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 does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.
Verify DNS before judging the result
Use read-only queries with your actual names. These placeholders are not records to publish and the commands were not run against a customer domain:
dig +short NS example.com
dig +short TXT example.com
dig +short TXT selector._domainkey.example.com
dig +short CNAME selector._domainkey.example.com
dig +short TXT _dmarc.example.com
Query the exact MAIL FROM owner for SPF, not automatically the root domain. Query the generated DKIM owner and record type; follow a CNAME to confirm a usable public key at its target. Compare authoritative DNS with at least one recursive resolver. Confirm that the intended record appears once, no suffix was duplicated and no unrelated record disappeared.
The provider’s propagation estimate is a planning window, not proof of success. If authoritative DNS is wrong, waiting for caches to expire will not repair it. If authoritative DNS is right but recursive answers differ, note the old TTL and recheck after it expires. Avoid repeated edits that make it harder to identify which version a receiver saw.
Test the actual outgoing message
Send a fresh message from a 34SP-hosted mailbox to an external inbox you control. Test a desktop client, webmail and any site-generated mail as separate routes when they are used. A successful message from one route cannot certify the others.
Read raw source and use the receiving system’s trusted Authentication-Results. Ignore a similar-looking field supplied by the sender or an unrelated earlier hop. Record the sending time, Message-ID, From domain, SPF identity, DKIM d= and s= values, and DMARC result. Authentication-Results
Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.
The desired outcome is a passing SPF result for the expected envelope identity, a passing DKIM signature for the intended domain, and dmarc=pass supported by at least one aligned method. An enabled button or public DNS record is only configuration evidence. Received headers establish what actually happened to the message.
For this branded-DKIM setup, require the intended 34SP signature to have trusted dkim=pass and its actual d= to align with the intended visible From under the applicable adkim mode, together with trusted receiver dmarc=pass. An unrelated signature or an SPF-only DMARC pass does not complete this DKIM check. Diagnose SPF fail, softfail, temperror and permerror separately even when DKIM supplies DMARC: inspect the actual envelope domain, connecting IP, full SPF policy and delivery path. Do not accept an unexpected From rewrite as brand authentication. DMARC identifier alignment, SPF results.
Keep a passing sample as the baseline. Retest after moving the website, changing SMTP settings, modifying sender addresses or rotating keys. Review aggregate reports for other legitimate traffic before making an enforcement decision.
Troubleshooting by symptom
There is no Enable DKIM option: confirm the selected product and account permissions. Do not apply the shared-hosting article to Private SMTP or another unverified product.
The panel says enabled, but DNS has no key: check delegation, exact record owner and whether the external-DNS instructions were completed. A zone entry in the wrong provider is invisible to receivers.
SPF returns PermError: inspect duplicates at the evaluated owner and evaluate the DNS-term limit. Do not delete unrelated TXT records or replace the entire policy with a guessed 34SP include.
Only website emails fail: compare their actual SMTP route and From address with a passing mailbox sample. A website may be using a different relay or signing service.
DKIM passes but DMARC fails: compare the authenticated domain with the visible From domain and the required alignment mode. Repair the sender identity or signing configuration rather than relaxing policy by default.
Forwarded messages fail: compare original and forwarded raw headers. The forwarding hop can change SPF’s connecting IP and alter signed content. Diagnose that route separately.
Mail authenticates but reaches junk: investigate recipient feedback, reputation and content separately. Authentication is not an inbox guarantee.
For a support escalation, include the hosting product, domain, sanitized record values, timestamps, Message-ID and receiver results. Keep account passwords and private keys out of the request.
For a site-generated message that takes a different path, use EmailAuth’s WordPress SMTP and API route guide to identify the sending service before applying its DNS instructions.
What this review verifies
No customer account configuration, DNS publication or received-message test was performed. Follow the checks above against your own service before treating it as authenticated.