InMotion Hosting SPF, DKIM and DMARC setup, step by step

For an existing InMotion Hosting cPanel mailbox on the documented Shared, WordPress or Reseller MailChannels route, publish the account’s public DKIM record from Email Deliverability, maintain one SPF policy containing the applicable MailChannels authorization, and add the separate InMotion MailChannels TXT authorization. Then verify a message sent through that exact mailbox route. A green DNS status alone does not prove that the delivered message is signed and aligned.

This guide covers an already DKIM-enabled native cPanel mail service. It does not cover VPS or dedicated-server administration, a third-party email provider, or every message produced by a WordPress plugin or PHP script. Confirm your actual service and outbound route with InMotion before applying these instructions.

On this page: Confirm the service, DNS authority and change boundary · Collect the public DKIM record from cPanel · Publish at the correct DNS owner · Update the existing SPF policy for MailChannels · Add the separate MailChannels authorization TXT · Validate the actual mailbox path and alignment · Troubleshooting without weakening protection · Frequently asked questions

Confirm the service, DNS authority and change boundary

InMotion’s MailChannels DNS instructions specifically identify Shared, WordPress and Reseller servers. They describe external-DNS SPF changes and a separate domain authorization marker. That is a narrower claim than “all InMotion products use these settings.”

Before changing anything, obtain approval for the exact domain and sending service. You need access to that domain’s cPanel Email Deliverability page and the authoritative DNS zone, or a DNS administrator who can apply the approved public records. A domain registered with InMotion may use external nameservers. Conversely, a registrar elsewhere may delegate DNS to InMotion. Registration, website hosting and DNS authority are different facts.

Record the intended visible From address, actual SMTP MAIL FROM domain, existing DKIM selector and signing domain, and current mail route. Save the relevant DNS records and TTLs. Inventory other legitimate senders sharing the SPF owner, and preserve direct or inherited DMARC protection and approved report destinations. Do not switch MX, nameservers, mail routing, DNSSEC or application credentials to make this guide fit.

If the mailbox uses Google Workspace, Microsoft 365 or another external mail service, stop here. Its own signing and envelope configuration controls authentication. Likewise, a WordPress contact form using another SMTP plugin is a distinct route even if the website is hosted by InMotion.

Collect the public DKIM record from cPanel

InMotion’s SPF, DKIM and DMARC setup guide directs cPanel users to Email Deliverability → Manage and to the suggested records. The detailed control behavior is documented in cPanel Email Deliverability.

1. Sign in to the cPanel account for the intended domain.
2. Open Email Deliverability, locate the exact domain and select Manage.
3. Inspect the DKIM section. Copy the suggested Name and full public Value from this account, not from a tutorial image or a different domain.
4. If cPanel is authoritative for that DNS zone, review the existing owner and use the scoped Install the Suggested Record operation only when the proposed change is correct and approved.
5. If DNS is external, send the public record to the authorized DNS administrator or enter it in that authoritative zone. Installing a record only in a nonauthoritative local zone will not fix public validation.

cPanel also documents Generate Local DKIM Key when no local key exists. Do not treat generating a key as proof that an unconfigured server will sign mail. This guide assumes the native service is already DKIM-enabled. If the expected key or signing configuration is missing, coordinate with InMotion to establish the actual enabled route before treating setup as complete. Do not regenerate an existing key merely to make a warning disappear.

Only the public DKIM value belongs in DNS. Never open, copy or send the private key to a DNS provider, support ticket or public testing service. The full public TXT value may include v=DKIM1, k=rsa and p= tags; retain the complete account-issued value rather than copying only the key’s first displayed line. cPanel can display a full or split record. Multiple quoted character strings within one TXT record are not multiple independent DKIM records; preserve the full value according to the DNS editor’s syntax.

Avoid the bulk Repair workflow for this task. It can affect more than the intended record, including DMARC. Review and change the specific approved authentication records instead of silently replacing policy with a generated monitoring default.

Publish at the correct DNS owner

The selector and signing domain determine the DKIM lookup name. Use the full owner actually issued by cPanel; a familiar selector such as default is not permission to invent the record for another account.

Suppose the issued full owner is SELECTOR._domainkey.mail.example.com. In an authoritative example.com zone, a relative-name editor may require SELECTOR._domainkey.mail. In a separately delegated mail.example.com zone it may require SELECTOR._domainkey. If _domainkey.mail.example.com is itself delegated, work with that namespace’s administrator. These are mapping examples, not issued production values.

Check the editor’s treatment of full names and trailing dots to avoid appending the domain twice. Preserve existing NS delegations and selectors used by other services. If the proposed owner already has a CNAME, do not add conflicting TXT at the same owner or delete the alias blindly. Establish which sender owns the dependency and obtain a supported configuration. This workflow expects the account-issued TXT record, not an improvised alias.

Verify the authoritative answer after saving, then check a recursive resolver after the relevant positive or negative cache has expired. A single successful DNS lookup proves publication at that time, not that every resolver has refreshed or that a message has been signed.

Update the existing SPF policy for MailChannels

For the documented route, InMotion instructs adding this mechanism to the existing SPF policy:

include:relay.mailchannels.net

This is a mechanism, not a complete standalone SPF record. Do not publish it as a second v=spf1 policy. InMotion’s example retains existing authorization such as include:smtp.servconfig.com; preserve legitimate existing mechanisms unless the domain owner has approved their removal. Do not copy the example’s IP address or add a and mx just because they appear in a sample.

SPF normally evaluates the SMTP MAIL FROM domain, not automatically the visible From address. Identify the envelope owner used by this actual route before editing apex DNS. A null reverse-path has different HELO-based evaluation. If InMotion controls the evaluated envelope domain rather than your organization, ask which customer-domain SPF change is applicable instead of assuming an apex edit will create alignment.

At the applicable owner:

• Find the existing TXT record beginning v=spf1, including policies whose first mechanism is not include.
• Keep one SPF policy and preserve legitimate sender authorizations, ordering and qualifiers.
• Insert the required include where it can actually be evaluated, before a terminating all mechanism. Do not append an unreachable authorization after all.
• Review any redirect= design with the DNS administrator. An all mechanism anywhere in the policy causes redirect to be ignored. A redirected policy needs deliberate integration, not a blind merge.
• Validate the evaluated DNS-dependent term count, including nested mechanisms and redirects. SPF’s limit is ten such terms during evaluation, not ten literal include strings in the top-level record.

If no SPF policy exists, have the administrator assemble one from the complete authorized sender inventory and approved final qualifier. Do not use this guide’s single include as evidence that MailChannels is the domain’s only sender. -all and ~all describe SPF outcomes; they do not guarantee a particular receiver delivery or rejection decision. These rules follow RFC 7208.

Add the separate MailChannels authorization TXT

InMotion’s MailChannels guide also specifies a separate TXT record. Substitute the actual approved domain for the reserved example domain:

Full owner: _mailchannels.example.com
Type: TXT
Value: v=mc1 auth=inmotionhosting

In an example.com zone using relative names, the owner is typically _mailchannels. For a child sending domain, confirm the corresponding full authorization owner with InMotion and map it into the correct authoritative zone; do not assume a parent’s marker automatically covers every child.

This record authorizes the stated provider in the MailChannels workflow. It is not an SPF policy, a DKIM public key or DMARC policy. Obtain the owner’s approval for that service authorization and compare the exact owner/value with the intended route. Preserve any existing marker or delegation until its purpose is understood. If another provider or a CNAME already occupies the owner, stop and coordinate rather than overwrite shared authorization or create an invalid combination.

For InMotion-managed DNS, inspect what is already published before adding anything. The cited external-DNS instructions are not a reason to duplicate records already provisioned correctly. Do not assume automation occurred without checking the authoritative answer.

Validate the actual mailbox path and alignment

Revisit Email Deliverability → Manage after publication. Resolve any mismatch between the suggested public key and authoritative DNS. A valid panel status is one checkpoint; publication, server signing and receiver authentication are separate stages.

With the owner’s permission, send a non-sensitive test from the intended cPanel mailbox to a controlled, valid external recipient through its normal outbound route. Include MailChannels transit, not a substitute direct route. Do not use customer data or send to arbitrary public testing inboxes. If several applications send differently, validate them separately rather than extending this mailbox result to all hosted software.

Inspect authentication results produced inside the receiving service’s known processing boundary, using that service’s documented handling of externally supplied Authentication-Results. A familiar authserv-id, a header near the top or a copied “pass” string is not proof of origin. Ignore attacker-supplied result fields; ask the receiving administrator when the trusted result cannot be established. RFC 8601 explains this trust requirement.

Accept the configured route only when:

• The visible From remains the intended branded address, not a provider-rewritten substitute.
• The intended native DKIM signature passes at the receiver. Check its actual d= signing domain and s= selector against the configured key, even when other signatures are present.
• That intended passing signature aligns with the visible From under the applicable DMARC alignment mode.
• The trusted receiver records dmarc=pass for the intended identity.
• SPF is separately checked against the actual MAIL FROM identity and any errors are explained and corrected.

Under relaxed alignment, the DKIM d= or SPF MAIL FROM domain shares the visible From domain’s Organizational Domain. Under strict alignment, that respective domain must exactly match the visible From domain. A child envelope domain does not automatically satisfy strict SPF alignment. An SPF pass for an unrelated provider domain is authentication without brand alignment. RFC 9989 defines these distinctions.

DMARC can pass through aligned SPF while the desired DKIM signature fails. That is not a successful DKIM implementation. Conversely, aligned DKIM can give a DMARC pass while SPF has an unresolved failure. See EmailAuth’s raw DKIM results versus aligned DKIM policy results for the difference between a signature result and policy alignment.

Troubleshooting without weakening protection

cPanel says DNS is not authoritative. Check actual nameserver delegation and edit the authoritative service. Do not dismiss the warning or move nameservers merely to remove it.

The DKIM record resolves but no intended signature appears. Confirm the test used the native mailbox and the account is DKIM-enabled. Escalate with InMotion if server signing is absent. A PHP application can have different behavior; cPanel documents PHP handler limitations. Do not change server security or PHP handlers just to imitate this mailbox workflow.

DKIM fails after transit. Check selector, full public value, DNS conflicts and the message’s actual route. Investigate modifications to signed headers or body. Do not replace a working selector until you know whether the key or message changed.

SPF fails despite the include. Confirm the receiver’s connecting IP and evaluated envelope domain, the active authoritative policy and whether the include was reachable. A policy edited at the wrong owner cannot authorize the evaluated identity.

SPF reports temperror. Investigate transient DNS availability and retest; do not convert a temporary error into a permanent broad authorization. permerror instead requires fixing structural problems such as multiple policies or excessive evaluated lookup terms. Diagnose both separately from an ordinary fail, even if DKIM currently produces a DMARC pass.

MailChannels still rejects or delays mail. Confirm the authorization marker and approved route, then use the actual error with InMotion support. Authentication does not override reputation, abuse controls, quotas or recipient policy. Do not change inbound filtering or add blanket allowlists.

DMARC fails with otherwise passing authentication. Compare actual identities and alignment modes. Preserve the current direct or inherited policy and authorized reporting destinations while fixing the sender. Do not downgrade to p=none or add duplicate DMARC records to hide failure. This guide does not create a new reporting destination or authorize sharing reports.