Radicenter SPF, DKIM and DMARC setup, step by step

For an existing Radicenter-hosted sender whose DNS is authoritative at the provider, inspect Email Deliverability in cPanel. For missing DKIM, the documented route is Manage → Generate Local DKIM Key → Install The Suggested Record. Keep the existing approved SPF policy intact, then verify public DNS and an actual native message. A Valid status alone is not proof of aligned signing or inbox placement. Radicenter's native setup instructions

This is a bounded DKIM installation or repair guide for an existing hosted outbound domain with an already-approved SPF route. It is not a migration to Radicenter, an external-DNS walkthrough, a generic recipe for every cPanel host, or configuration for a third-party marketing service.

On this page: Confirm the sender and DNS authority first · Inspect Email Deliverability before using Repair · Generate and install the intended public DKIM record · Check record placement and complete key content · Retain the already-approved SPF route · Preserve DMARC instead of copying enforcement examples · Validate public DNS and the actual native message · Troubleshooting · Frequently asked questions

Confirm the sender and DNS authority first

A domain registered or hosted at Radicenter can still send email through another service. Identify the actual outbound route used by the mailbox or application. A website using an external SMTP connection needs that sender's authentication, not a locally generated key merely because the website resides on this server.

Confirm that the provider serves the authoritative DNS for the relevant owner. Check nameserver delegation rather than assuming that a visible cPanel zone is public. If DNS is external or a child zone is delegated elsewhere, stop this direct-install procedure and obtain the supported publication and signing instructions for that layout. Do not switch nameservers to make the button work.

Record the approved visible From address, actual sending domain, existing selector and public DNS values. Confirm that the account administrator has permission to change the intended domain. Do not expand a role, connect a different account or change the sender identity as a troubleshooting shortcut.

Inspect Email Deliverability before using Repair

Open Email Deliverability in the Radicenter cPanel account and find the exact domain. Radicenter documents Valid and Problems Exist in the Email Deliverability Status column. Provider control names

Save the current DNS owners, values and TTLs before an approved repair. Include SPF, all active DKIM selectors, direct and inherited DMARC policy, MX records and relevant delegations. Also record which applications depend on the existing selector. A selector already in use by another sender is not an empty slot.

The provider describes Repair as a way to install SPF and DKIM. Do not treat it as an inspection-only button. Review its exact proposed changes against the approved records and other senders before authorizing it. If its effects are broader or unclear, do not run a bulk repair merely to remove a warning. Prefer reviewing the individual domain under Manage and restrict the work to the intended DKIM record. Preserve established DMARC protection even if an automated action proposes a basic policy.

If the domain is already Valid and the expected public key exists, proceed to message validation. Generating a new key just because a message went to spam can unnecessarily rotate a working signer.

Generate and install the intended public DKIM record

For a missing key on the scoped native route:

1. Open Manage for the correct domain.
2. Inspect the DKIM section and existing suggested record. Confirm that there is no active conflicting key or dependency requiring a separate rotation plan.
3. Where a local key is absent and generation is appropriate, select Generate Local DKIM Key.
4. Inspect the complete generated public record, including its exact owner and value.
5. Select Install The Suggested Record for that DKIM record after confirming the intended DNS change.
6. Return to the domain's status and check the published record before testing a message.

These generation and installation controls are explicitly described by Radicenter. The public instructions do not establish another separate “Start Signing” switch for this route. If public DNS is correct but fresh native messages remain unsigned, ask Radicenter to confirm signing for that account and domain; do not invent an activation control. Native DKIM workflow

Radicenter's accompanying practices guide names the default selector owner as default._domainkey.<domain>. Treat the actual generated account value as authoritative. Never paste an abbreviated example public key, rename the selector arbitrarily or overwrite another sender's record at that owner. Radicenter's DKIM practices

Only the public DKIM TXT belongs in DNS. Do not export a private signing key, put it into a checker or attach it to a support request. If a key change is genuinely necessary, coordinate the signing change, publication and retention of old public selectors for delayed messages instead of rotating during an unrelated diagnostic check.

Check record placement and complete key content

The complete DKIM owner is the selector followed by _domainkey and the actual signing domain. For example, default._domainkey.example.com is commonly entered as default._domainkey in an editor serving example.com that appends the zone name. Do not append the domain twice.

For an issued owner at SELECTOR._domainkey.news.example.com, the relative label is SELECTOR._domainkey.news in the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com is itself delegated, it is SELECTOR there. These examples explain DNS placement, not automatic eligibility for an external-DNS or new-subdomain route. That route remains outside this direct-install scope.

Keep the complete public key, including its full p= value. A long TXT value can be presented as multiple quoted character strings within one DNS record; that is different from publishing competing key records at the same owner. Do not truncate the value or insert unexplained characters into it.

If a CNAME already occupies the intended owner, do not add a conflicting TXT or delete that alias without identifying its existing service. This guide installs the native generated TXT; it does not convert a third-party sender's CNAME setup into Radicenter signing.

Retain the already-approved SPF route

The provider's instructions include an SPF example containing a, mx and include:_spf.radicenter.eu, ending in -all. That is not permission to replace a multi-service policy, broaden address authorization or change its terminal qualifier. This guide deliberately retains the existing approved SPF configuration while repairing DKIM. Provider SPF context

SPF evaluates the actual SMTP MAIL FROM domain, not simply the visible From. Inspect the trusted receiver's smtp.mailfrom and evaluate the policy at that owner. A website, mailbox and external relay may use different envelope paths even when the visible brand looks the same.

If SPF itself is incorrect, pause acceptance and plan a separately reviewed correction with all legitimate senders represented. Maintain one SPF policy per evaluated owner. Do not install a second v=spf1 record, concatenate whole policies, authorize every sender with +all, or remove another service solely to fit a canned example.

Review nested includes and other lookup-causing terms against SPF's ten-term evaluation limit. The number of mechanisms visible in the top-level string alone does not establish the total. Any all mechanism causes redirect to be ignored, so preserve the semantics of a redirect-based policy during a reviewed merge. a and mx authorize addresses reached through those mechanisms; they are not harmless formatting. SPF specification

Preserve DMARC instead of copying enforcement examples

Before any change, inspect the intended From domain's direct policy and applicable inherited policy. A missing child-domain record does not establish that the child is unprotected. Preserve existing enforcement, alignment modes and report recipients unless the owner approves a specific change. Current DMARC requirements

Do not automatically copy Radicenter's quarantine, strict-reject or percentage examples into an established domain. A DKIM repair is not a complete assessment of all authorized senders. Do not publish the obsolete pct tag, add failure reporting by default or treat a green cPanel result as permission to enforce a new policy.

If no applicable policy exists, plan an owner-approved first monitored rollout separately, with the correct _dmarc owner at the actual authority. A sample at _dmarc.example.com maps to _dmarc in the example.com zone; a separately intended policy at _dmarc.news.example.com maps to _dmarc.news in the parent zone or _dmarc in the delegated child zone. Coordinate child exceptions with the parent owner.

Aggregate-report rua destinations receive authentication reports, not forwarded quarantined messages. Compare the Organizational Domain of the reporting URI destination host with the Organizational Domain of the domain where the policy was found, including an inherited policy. Different Organizational Domains require external report authorization; the same-Organizational-Domain exception uses that policy-found domain. This DNS authorization does not replace the owner's approval to share report data. RFC 9990 section 4: reporting requirements

Validate public DNS and the actual native message

Confirm the intended status becomes Valid, then inspect authoritative and recursive DNS answers. Use the actual selector and signing domain, not a guessed customer value. These read-only command patterns require replacing every uppercase placeholder:

dig +short NS DNS_ZONE
dig @AUTHORITATIVE_NS TXT SELECTOR._domainkey.SIGNING_DOMAIN
dig +short TXT SELECTOR._domainkey.SIGNING_DOMAIN
dig +short TXT MAIL_FROM_DOMAIN
dig +short TXT _dmarc.FROM_DOMAIN

Compare the entire returned public key with the generated record. If the direct DMARC query is empty, investigate inherited policy rather than assuming none exists. Radicenter gives an approximate DNS delay; it is not proof of propagation or a delivery guarantee. A wrong owner or non-authoritative zone needs correction, not indefinite waiting or unrelated cache-flush actions.

Have an authorized operator send a harmless message through the existing native Radicenter route to a controlled external mailbox. Use no confidential customer content. Do not change SMTP routes, trigger purchases, reset passwords or exercise a real customer's workflow just to generate a sample. If no safe authorized message is available, mark message-level acceptance pending.

Use receiver-controlled diagnostics, or have the receiving administrator identify which authentication fields originated within its trusted processing boundary and how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id or header position alone is insufficient. Retain sanitized identities, results and timestamps. Authentication-results trust

For acceptance, require all of the following:

• The message used the intended native route and approved visible From, without an unnoticed provider-domain rewrite.
• The intended Radicenter signature has trusted DKIM pass using the actual active selector.
• That same passing signature's d= aligns with From under the effective adkim mode.
• The trusted receiver reports DMARC pass for that From.
• SPF on the actual MAIL FROM route has been assessed independently, with errors resolved rather than hidden by DKIM success.

Relaxed DKIM alignment compares Organizational Domains; strict alignment requires exact equality. SPF alignment compares MAIL FROM with From under the separate aspf mode. A child envelope domain does not automatically meet strict alignment with its parent From. A DMARC pass supplied only by SPF does not validate this DKIM installation. Raw versus aligned DKIM results

Troubleshooting

cPanel remains Problems Exist

Inspect the specific failing record rather than repeating Repair. Verify the domain, authority, complete public key and existing conflicts. If the scoped DNS is correct but the provider status remains wrong, escalate with sanitized DNS evidence, not private keys or account passwords.

Valid appears but the intended signature is missing

Confirm that the message actually traversed native Radicenter mail, not an application's external SMTP connection. Ask the provider to confirm account signing after the documented generation/install workflow. Public key availability is not proof that a sender used the corresponding key.

SPF has fail, softfail, temperror or permerror

Investigate the actual envelope owner. Fail or softfail calls for checking sender authorization; temperror indicates a transient evaluation problem such as DNS availability; permerror calls for checking invalid syntax, duplicate policies and lookup limits. Continue investigating even when aligned DKIM supplies DMARC pass. A passing but unaligned envelope is a different result from an SPF error.

DKIM passes but DMARC fails

Identify which signature passed and compare its signing domain with the visible From under the effective alignment mode. Do not weaken policy just to accommodate the wrong sender. Correct the intended route or obtain a supported aligned configuration.

Another sender breaks after repair

Compare the before-and-after SPF and selector data. Coordinate a bounded restoration after checking intervening edits. Do not restore an entire old DNS zone or delete every selector; either could disrupt unrelated mail and websites.