For an existing, DKIM-enabled MDDHosting native cPanel mailbox, retrieve the domain’s public authentication records through Email Deliverability, publish the approved SPF and DKIM data at the authoritative DNS provider, and test the actual outgoing mailbox route. MDDHosting explicitly supports copying these records to external DNS. Its outbound-filtering documentation identifies SpamExperts, not MailChannels; do not import a different host’s relay include or authorization marker.
This guide covers an already-configured native mailbox with server-side DKIM signing enabled. It does not provision a server, replace an external mailbox service, configure a standalone SpamExperts account, or establish signing for every website script. No customer account, DNS change or delivered-message test was performed.
On this page: Establish the native mailbox and filtering path · Use scoped cPanel controls rather than a bulk repair · Publish the correct public records at the right DNS service · Preserve one SPF policy for the actual envelope owner · Test the complete native route, including the outgoing filter · Troubleshoot authentication and filtering separately · Frequently asked questions
Establish the native mailbox and filtering path
MDDHosting’s mail authentication troubleshooting guide connects its email service to cPanel Email Deliverability and explains the external-DNS copy path. Its outbound scanning documentation names SpamExperts as an outgoing filtering partner.
That filtering relationship does not prove the customer should create a separate SpamExperts user, generate a gateway key or add a universal SpamExperts SPF include. Use MDDHosting’s account-issued records for the actual native service and ask MDDHosting to resolve any mismatch between the suggested policy and observed route. Do not substitute a MailChannels recipe merely because other cPanel hosts use that service.
Before changes, confirm the intended domain, visible From address, actual SMTP MAIL FROM domain, mailbox submission method and existing outgoing route. Determine whether a website application uses that mailbox or submits elsewhere. The same website and mailbox domain can have different outgoing paths.
Obtain the owner’s approval for the exact records and service. You need the domain’s cPanel controls and access to authoritative DNS, or a DNS administrator who can publish the approved public data. Save the existing SPF, DKIM selectors, TTLs, delegations and applicable direct or inherited DMARC policy. Inventory other legitimate senders and preserve authorized reporting destinations.
Confirm DNS authority independently of registration and website hosting. Do not change MX, nameservers, DNSSEC, credentials, mail routing or inbound filtering as a side effect of authentication setup. If the native server is not already configured to sign for the domain, ask MDDHosting to establish that prerequisite. A new public record is not itself a server-signing switch.
Use scoped cPanel controls rather than a bulk repair
MDDHosting’s article illustrates the Repair action for domains with authentication problems. The same screenshot exposes Manage. Prefer that scoped view so you can inspect the proposed records before changing them; a broad repair may affect more than the intended SPF or DKIM record, including DMARC.
- Open cPanel for the intended account.
- Select Email Deliverability.
- Locate the exact domain and choose Manage.
- Review the DKIM public Name and full Value, together with the SPF suggestion.
- Compare each proposed record with the existing authoritative configuration and approved sender inventory before publishing.
The current cPanel Email Deliverability documentation describes the public-key views, Install the Suggested Record, Generate Local DKIM Key when absent, and external-DNS limitations. Those controls supplement the host’s documented route; they do not authorize unrelated WHM administration or changes to temporary domains.
If a local key is missing, coordinate generation for the intended already-enabled native service with the administrator. Do not regenerate an existing key just to clear a status message. If the expected signing capability is absent, stop for MDDHosting confirmation rather than treating generated DNS as proof of activation.
Only the public DKIM data belongs in DNS. Do not display, copy or send the private key to a DNS provider or support ticket. Copy the complete generated tagged value, including all public p= data, not a screenshot key or a truncated first line.
Publish the correct public records at the right DNS service
If cPanel is authoritative, inspect the existing owner and apply only the intended approved suggested record. If authoritative DNS is elsewhere, use the Name and complete public Value from the account at that provider. MDDHosting explicitly says its local repair only works when cPanel handles the domain’s DNS; external DNS requires manual publication there.
For DKIM, retain the actual account-issued selector and signing domain. The general owner structure is SELECTOR._domainkey.SIGNING-DOMAIN, but this is not a universal selector or a deployable record.
For example, an issued full owner of SELECTOR._domainkey.mail.example.com maps differently depending on delegation. An editor for example.com may need SELECTOR._domainkey.mail; an editor for the separately delegated mail.example.com zone may need SELECTOR._domainkey. If _domainkey.mail.example.com is separately delegated, its administrator controls the record. Preserve that NS delegation rather than deleting it to fit an example.
Check whether the DNS editor expects a relative name, fully qualified name or trailing dot. Confirm the resulting full owner so the zone is not appended twice. Preserve other active selectors and shared dependencies.
If a CNAME already occupies the proposed TXT owner, do not add conflicting TXT or remove the alias without understanding its active service. Coordinate a supported nonconflicting configuration. This native workflow expects the account’s complete public packet, not an improvised CNAME containing key text.
Long public TXT values can use several quoted character strings within one record. Their concatenated data must match the issued public value. Do not split a key across separate TXT records, remove characters or copy only the visible portion of a field.
Check authoritative DNS after publication, then a recursive resolver after relevant positive or negative cache expiry. Record the answer, TTL and time. Local cPanel status and one resolver result are useful evidence, not guarantees that all caches have refreshed or that outgoing mail is signed correctly.
Preserve one SPF policy for the actual envelope owner
Use the account-suggested SPF authorization and the confirmed MDDHosting native route. Do not guess a literal relay include from a transport brand, another hosting provider or a corporate domain’s own DNS.
SPF normally evaluates the SMTP MAIL FROM domain rather than the visible From address. A null reverse-path uses the applicable HELO identity. Identify the real evaluated owner for the individual native route before changing apex DNS. A policy at the visible From domain cannot automatically authorize a different provider-controlled envelope or make it align.
At that authoritative owner, locate the existing TXT policy beginning v=spf1. It may begin with an IP mechanism rather than an include. Keep one policy and preserve other legitimate senders, mechanism ordering and the approved final qualifier.
Integrate only the necessary account-backed authorizations where they will be evaluated before a terminating all. Do not append a second SPF policy or put an include after all. Do not add generic a, mx, sample addresses or broad IP ranges just because a tutorial includes them.
If the policy uses redirect=, have the DNS administrator review the design deliberately. An all mechanism anywhere in the policy makes redirect ignored. A mechanical merge can therefore disable previously intended authorization semantics.
Validate the full SPF evaluation budget: ten evaluated DNS-dependent terms, including nested mechanisms and redirects, not ten top-level include strings. If no SPF policy exists, build one from the complete approved sender inventory and actual account configuration. The absence of a record does not prove the native mailbox is the only sender. These evaluation rules come from RFC 7208.
If the account’s suggested policy appears inconsistent with its real outbound filter, ask MDDHosting to confirm the supported authorization before changing it. Do not resolve uncertainty by authorizing arbitrary observed IPs. A hard-fail qualifier describes an SPF result; it does not dictate every receiver’s delivery decision.
Test the complete native route, including the outgoing filter
After DNS resolves, revisit Email Deliverability and resolve any disagreement with the public records. Then, with the owner’s approval, send a non-sensitive message from the intended mailbox through its normal authenticated route to a controlled, valid external recipient. Include the actual outgoing filtering path rather than bypassing it for a test.
Do not send private customer data to public test inboxes. Do not create a new gateway user or alter authentication methods merely to reproduce a standalone SpamExperts guide. Test application routes separately when they submit differently from the mailbox.
Use Authentication-Results generated inside the receiving service’s known processing boundary, following its documented handling of externally supplied result headers. A familiar authserv-id, favorable pass text or header position is not sufficient proof. Ignore attacker-inserted fields and ask the receiving administrator if the trusted result cannot be established. See RFC 8601.
The route is accepted only when:
- The visible From is still the intended branded address, not a provider-rewritten identity.
- The intended native DKIM signature passes after the real filtering transit. Match its actual
d=ands=to the configured account key, even if other signatures exist. - That intended passing signature aligns with the visible From under the applicable policy.
- The trusted receiver reports
dmarc=passfor that identity. - SPF is independently checked against the actual MAIL FROM identity and any unexpected failure or error is investigated.
Under relaxed alignment, the relevant DKIM d= or SPF MAIL FROM domain shares the visible From domain’s Organizational Domain. Strict alignment requires that respective domain to exactly match the visible From domain. A child envelope domain is not automatically strict-aligned. RFC 9989 defines these distinctions.
Do not accept an SPF-only DMARC pass as proof that DKIM works. Conversely, aligned DKIM can allow DMARC to pass while SPF still needs repair. EmailAuth’s raw DKIM results versus aligned DKIM policy results explains the difference.
Troubleshoot authentication and filtering separately
cPanel shows a record but public DNS does not. Confirm authoritative nameservers, the exact owner and the external copy. A local inactive zone is not a public fix.
No intended native DKIM signature appears. Confirm the saved key, native mailbox route and server-side signing prerequisite. Ask MDDHosting to investigate missing signing. Do not assume a website script, PHP handler or third-party SMTP connection follows the mailbox path.
DKIM fails after transit. Compare the actual selector and signing domain with the complete public record. Check stale caches, conflicting owners, truncated keys and modifications to signed content. Preserve upstream/native signing rather than stripping it to force a new filter signature.
SPF fails. Check the actual evaluated envelope owner, receiver’s connecting IP and approved account policy. Do not repair the wrong owner or import another host’s relay settings.
SPF reports temperror. Investigate transient DNS resolution and retry once the fault is understood. permerror requires fixing structural issues such as duplicate policies, syntax or excessive evaluated terms. Both differ from ordinary authorization failure and should be diagnosed even if DKIM yields DMARC pass.
DMARC fails although a mechanism passes. Compare actual identities and active alignment modes. Preserve direct and inherited protection and authorized report destinations while fixing the sender. Do not replace enforcement with p=none, add duplicate DMARC or copy an unapproved reporting address.
The filter holds or rejects the message. Authentication and outgoing abuse filtering are different layers. Use the actual error and approved minimal diagnostic details with MDDHosting support. Do not release quarantined messages, bypass scanning or add blanket allowlists as a side effect of this guide. The provider’s support article mentions operational release procedures; those are not required authentication steps.
Mail still lands in spam. Review recipient policy, reputation and content. SPF/DKIM success cannot guarantee delivery, inbox placement or a fixed time to resolution.
For rollback, restore only approved affected records or a supported known-good signing state after checking shared dependencies. Retain old public selectors until queued mail, TTLs and other users have been assessed. A DNS rollback does not instantly flush caches; repeat the real-route test afterward.