For email sent from a StableHost hosting account, open cPanel → Email Deliverability → Manage for the sending domain and use that account’s suggested SPF and DKIM records. If StableHost controls the authoritative DNS, reviewed records can be installed there. If DNS is elsewhere, copy the suggested TXT Name and Value to the actual authoritative provider. There is no universal StableHost SPF string, DKIM selector or public key to copy from another account.
Review DMARC before using Repair. StableHost says the bulk repair can add a basic DMARC record when one is missing, even though that record is not listed in the confirmation. An existing inherited policy must not be weakened by an unnoticed child monitoring record. Prefer the individually reviewed Manage controls when the bulk action cannot preserve the approved policy.
This guide covers native outbound hosting-account mail, including the distinction between StableHost-controlled and external DNS. It does not configure Google Workspace, Microsoft 365, a separate SMTP provider or a self-managed server merely because the domain is registered or hosted with StableHost. StableHost’s current procedure.
Confirm the route and change authority
You need authorized cPanel access for the hosting account, permission from the domain and mail owners, and access to the authoritative DNS service if it is external. The provider article does not establish a universal plan name or account-role label; confirm the feature is available in your actual account. cPanel’s underlying documentation notes that the hosting provider controls whether Email Deliverability is enabled. If it is missing, ask StableHost about your account rather than changing a plan or server configuration as a side effect. cPanel Email Deliverability.
Identify the actual sending path. A mailbox using the native hosting mail server is not the same as a website plugin configured for an independent SMTP service. A domain’s visible From address alone cannot tell you which transport sent a message. Inventory each legitimate sender sharing that domain before editing authentication.
Save the current SPF policy, relevant DKIM records, TTLs, direct and applicable inherited DMARC policy, and any child or _domainkey NS delegation. Record the approved From address and the application or mailbox path to test. Agree who can approve changes, pause affected sends and restore the prior configuration if needed.
Confirm DNS authority from the actual delegation, not registrar branding. StableHost’s article identifies its nameservers as ns1.stablehost.com and ns2.stablehost.com; use that as context, not an instruction to change nameservers. A separately delegated child zone can have a different authority. Do not move DNS, MX, DNSSEC, mailbox credentials or inbound routing to make this tutorial’s interface work.
Read the domain status before installing anything
- Sign in to the correct cPanel account.
- Under Email, open Email Deliverability.
- Locate the intended sending domain and read Email Deliverability Status.
- Open Manage to inspect the individual records and proposed values.
StableHost describes Valid and Problems Exist states. A Valid state means the tool considers the relevant DNS configuration correct; it does not establish that your actual outgoing message carries the intended aligned DKIM signature. Keep an already working configuration and proceed to message verification rather than replacing records for appearance’s sake.
For Problems Exist, identify the specific issue. Copy the exact proposed names and complete public values for review. cPanel shows account-specific suggestions, not a universal table applicable to every StableHost domain. If no usable DKIM suggestion is available, ask StableHost to establish the correct local signing configuration instead of generating an unrelated key yourself.
Preserve SPF while authorizing the native server
SPF normally evaluates the actual SMTP MAIL FROM domain, often reflected in Return-Path, or HELO in the applicable null-reverse-path case. It does not automatically evaluate the visible From domain. Obtain the account’s proposed SPF policy, then confirm which identity the actual native route uses before claiming that the policy aligns with From.
At the evaluated owner, publish one TXT record beginning v=spf1. Other unrelated verification TXT records may coexist. If a policy already exists, reconcile the mechanisms cPanel says must be included with every other legitimate sender and the owner’s intended qualifier. Do not paste a second complete SPF policy or merge unrelated TXT strings.
StableHost’s troubleshooting article suggests combining the content between the version tag and ending qualifier. Do not apply that mechanically: duplicate or incompatible terms, redirect logic and unneeded authorizations require review. An all mechanism causes redirect to be ignored. Adding an all ending can therefore disable an existing delegated SPF policy.
Check the limit of ten evaluated DNS-dependent terms across nested processing, including include, a, mx, ptr, exists and redirect. This is not simply ten visible includes. Review any a or mx mechanisms: they authorize the applicable address records or mail-exchanger addresses, so a web or inbound-mail infrastructure change can affect outbound authorization. Do not add those terms solely because a sample contains them. Qualifiers such as ~all and -all produce SPF results, not guaranteed delivery or rejection decisions. RFC7208 processing rules.
Where needed, cPanel documents Customize in the SPF section and Install a Customized SPF Record after reviewing the updated preview. Use only the owner-approved policy. If the current interface cannot safely express it, stop and coordinate with the DNS administrator and StableHost rather than installing a destructive default.
Publish DKIM and choose the right DNS branch
The required public record is the account’s Suggested DKIM TXT record. Copy its complete Name and Value, retaining the actual selector, tags and full public key. Do not assume a screenshot’s default selector is your issued selector.
Never open or share View The Private Key for this task. The public suggested record is what a DNS administrator needs; a private signing key is not a DNS value. If the public key is long, StableHost documents the Copy buttons and Split view. Split text represents multiple character strings in one logical TXT record, concatenated without additional spaces. It does not mean several independent DKIM records or truncated key fragments.
StableHost controls the authoritative DNS
Review existing and proposed values first. StableHost documents Manage → Install The Suggested Record separately for DKIM, SPF and DMARC. Install only the individual missing or incorrect record whose change is approved. For an existing multi-sender SPF policy, use the reviewed customized policy rather than an unexamined replacement.
The bulk alternative is Repair, review the proposed SPF/DKIM records, then Repair at the bottom to confirm. However, that action may also install basic DMARC without displaying it in the list. Do not confirm it until you have established that all effects preserve direct and inherited policy and the domain owner approves them. If you cannot establish that, use individual controls or obtain support assistance.
When only DMARC is missing, StableHost says Repair is greyed out and points to Manage → DMARC → Install The Suggested Record. That control is not permission to install monitoring over an inherited enforcement policy. Apply the DMARC decision below first.
DNS is managed outside StableHost
StableHost documents a greyed-out Repair control and the warning “This system does not control DNS.” Installing local DNS records will not publish them at external authority.
Open Manage, then use Copy in the DKIM section for the suggested Name and Value. Have the authorized DNS administrator create or correct the TXT record at the actual authoritative service. Repeat the review for SPF, merging only the required legitimate mechanisms into its single policy. Treat any DMARC suggestion separately, not as an automatic third record to add.
Preserve the local server’s intended signing configuration and publish the corresponding public record externally. If DNS becomes correct but the actual message is unsigned, involve StableHost to investigate the native path; a public TXT alone cannot enable signing by an unrelated server.
Map each DNS owner without duplicating the domain
A DNS editor may accept full names or append the zone suffix automatically. Match its documented convention and inspect the resulting full owner. The examples below explain naming, not account-issued values or a claim that every child domain is provisioned for mail.
- Apex SPF: full owner
example.commaps to the DNS provider’s documented apex input, often blank or@, in theexample.comzone. - Child SPF: full owner
news.example.commaps tonewsin the parent zone or the apex input in a delegatednews.example.comzone. A child SPF policy is not inherited from the parent. - Apex DKIM: an issued owner such as
ISSUED-SELECTOR._domainkey.example.commaps toISSUED-SELECTOR._domainkeyin a suffix-appending parent-zone editor. - Child DKIM:
ISSUED-SELECTOR._domainkey.news.example.commaps toISSUED-SELECTOR._domainkey.newsin the parent zone, orISSUED-SELECTOR._domainkeyin the delegated child zone. - Delegated signing namespace: if
_domainkey.news.example.comitself is delegated, that full owner maps toISSUED-SELECTORwithin that namespace. Coordinate with its administrator; adding a record below the cut in the parent zone will not replace its authoritative answer.
Replace ISSUED-SELECTOR with the actual suggested selector. Preserve NS delegations and selectors used by other senders or queued mail. If a proposed TXT owner already has a CNAME or an unexplained conflicting key, stop and resolve ownership and dependencies before changing it. This documented workflow uses TXT, not DKIM CNAME targets; no HTTP proxy or CNAME-flattening change is needed.
Keep DMARC an explicit owner decision
Look for the direct policy at _dmarc of the actual visible From domain and determine whether a parent policy applies. Preserve existing direct or inherited protection and authorized report destinations. A missing local record is not proof that no policy applies.
Only if no direct or applicable inherited policy exists, the domain owner approves first monitoring, and there is a monitoring plan, a minimal first policy may be:
Type: TXT
Full owner: _dmarc.example.com
Relative owner in example.com zone: _dmarc
Value: v=DMARC1; p=none;
For From domain news.example.com, full owner _dmarc.news.example.com maps to _dmarc.news in the parent zone or _dmarc in its separately delegated child zone. Use one policy at the selected owner. Do not downgrade enforcement, create a duplicate or install a child override merely to make a dashboard green.
The example has no report address. Add rua only for an actual provisioned, monitored destination approved by the domain owner, after reviewing privacy and access. Under RFC9990 section 4, a destination in a different Organizational Domain from the domain where the policy was found requires the report-generating receiver to verify DNS authorization. The same-Organizational-Domain exception applies even when hostnames differ. Protocol authorization does not replace permission to share report data.
StableHost recommends beginning with monitoring and later strengthening policy. Do not turn “a few weeks” or one successful mailbox test into a universal enforcement schedule. Inventory all legitimate senders and indirect paths before a separate owner-approved enforcement change. Current DMARC standard.
Verify publication, then the intended signature
Query authoritative DNS and an independent recursive resolver. Substitute the actual authoritative server, domain and issued selector in these read-only examples:
dig @AUTHORITATIVE-SERVER TXT example.com
dig @INDEPENDENT-RESOLVER TXT example.com
dig @AUTHORITATIVE-SERVER TXT ISSUED-SELECTOR._domainkey.example.com
dig @INDEPENDENT-RESOLVER TXT ISSUED-SELECTOR._domainkey.example.com
dig @AUTHORITATIVE-SERVER TXT _dmarc.example.com
dig @INDEPENDENT-RESOLVER TXT _dmarc.example.com
Compare complete TXT answers with the approved policy and public key, including concatenated strings. Repeat any inherited-policy lookup as needed. StableHost allows a few minutes to 24–48 hours for changes; actual TTLs and cache state matter. Record when authoritative answers became correct rather than repeatedly changing good records while a cache catches up.
Return to Email Deliverability and Manage. StableHost documents Valid and “is properly configured for this domain” for correct records. Keep DNS status separate from message acceptance.
With the mailbox/application owner’s approval, send harmless synthetic content through the intended native route to a controlled, valid external inbox. Test the mailbox, SMTP client and any application path you actually use separately. cPanel warns that some PHP configurations may not produce a valid DKIM signature even when DKIM is enabled; do not change server security or PHP settings from a generic tutorial. Ask StableHost to investigate that specific path.
Use Authentication-Results generated inside the actual receiving service’s known processing boundary, with its documented treatment of externally supplied fields. It must remove, ignore or distinguish untrusted external results. Header position or matching authserv-id text alone is not proof; ignore attacker-inserted results. If trust cannot be established, obtain the receiving administrator’s trace. RFC8601 security considerations.
Completion requires the intended StableHost native signature to pass, its actual d= signing domain to align with the unchanged approved From under the effective policy, and trusted receiver dmarc=pass. Inspect the actual s= selector; the public lookup owner derives from s= and d=, not an assumed account default. A rewritten provider From, unrelated signature or DMARC pass supplied only by SPF does not prove your intended branded DKIM route works.
Relaxed alignment compares Organizational Domains; strict alignment requires exact domain equality. Inspect the actual envelope identity independently. A child MAIL FROM may align in relaxed mode but not strict mode; this guide does not establish a custom Return-Path feature. For the distinction between raw and aligned success, see raw DKIM results versus aligned DKIM policy results.
Troubleshooting and controlled recovery
SPF fail: inspect the actual envelope owner and connecting sender. Confirm the message used the native route and authorize only legitimate required sources. SPF permerror: check duplicate policies, syntax and the nested term budget. SPF temperror: investigate temporary DNS failure before rewriting correct authorization. Diagnose these independently even when DKIM yields a DMARC pass.
DKIM absent or failing: compare the actual route, selector, signing domain and complete public record. Check authority, suffix duplication, truncated values and downstream message modification. A correct DNS result with an unsigned message needs signing-path investigation, not a new invented public key.
Repair remains unavailable: distinguish external authority from the DMARC-only case. Do not change nameservers or routing to enable a button. Valid but spam: examine receiving policy, reputation and content; authentication is not an inbox-placement guarantee.
If an approved change disrupts sending, coordinate a pause of affected traffic and restoration of the exact previously approved configuration, preserving concurrent legitimate changes. Keep selectors still needed by queued messages. Do not reset the zone, weaken DMARC or delete unrelated authorizations. Retest the repaired and previously working routes before resuming. Share only necessary redacted error/header evidence with support, never private keys or credentials.
Sources and verification limits
StableHost’s [SPF, DKIM and DMARC cPanel guide](https://support.stablehost. The companion [cPanel Email Deliverability documentation](https://docs.cpanel. Hosting configuration may limit the available controls; the provider’s actual account remains authoritative for issued values.
The reviewed StableHost body supplies explicit written steps, not decisive setup screenshots. No customer account, DNS changes, test sends, CMS rendering or live implementation were performed. The account-specific records and delivered-message results still need authorized operational verification.