On this page: Identify the relay route and its administrator · Merge the MailChannels SPF authorization · Restrict account access with Domain Lockdown · Generate and activate DKIM on the originating server · Publish DNS without damaging another route · Preserve DMARC before introducing monitoring · Check DNS and a trusted receiver independently · Troubleshooting and frequently asked questions
For MailChannels Outbound Filtering, authorize the relay in the correct SPF policy with include:relay.mailchannels.net, configure Domain Lockdown for the permitted account or sender identities, and keep domain-aligned DKIM signing on the originating mail server. Verify the public records and a real receiver's authentication results separately. Publishing SPF does not activate DKIM.
This guide covers the Outbound Filtering SMTP relay, particularly mail originating on cPanel/Exim. It is not universal coverage for MailChannels Email API, its separate SMTP submission workflow, Inbound Filtering or historical Cloudflare Workers integrations. Product-specific account instructions take precedence over examples for another MailChannels route. MailChannels Outbound setup
Identify the relay route and its administrator
Draw the actual path: application or mailbox client, your mail server, MailChannels, recipient. For this product, smtp.mailchannels.net is the smart host for your mail transfer agent, not a replacement outgoing server for every desktop client. You need an Outbound Filtering account, its SMTP username and password, and control of the originating mail server. MailChannels documents TLS-protected connections, including STARTTLS on port 587. Connection requirements
If your hosting company operates MailChannels, ask it for the relevant account identity and signing configuration. Your own domain login is not necessarily the relay account identifier. Split responsibilities explicitly: the host manages transport and signing, the authoritative DNS operator publishes records, and the domain owner approves which senders remain authorized.
For the separate host-managed route described by Krystal, use its Krystal cPanel authentication guide. Its documented relay.k.io authorization is not interchangeable with the directly administered relay route here.
Inventory mailbox mail, PHP-generated messages, scheduled jobs, forwarded messages and any route that bypasses the relay. Preserve the current DNS zone and mail-server configuration before a planned change. Do not change incoming MX records merely to authenticate an outbound service.
Merge the MailChannels SPF authorization
The official Outbound SPF guide requires include:relay.mailchannels.net in the sending domain's SPF policy. Add it before the terminal all, keeping existing legitimate senders. The provider maintains the included address set. MailChannels SPF records
For a domain sending only through this relay, with no existing SPF policy, the minimal authorization is illustrated here:
Owner: example.com
Type: TXT
Value: v=spf1 include:relay.mailchannels.net ~all
This deliberately does not authorize the website's A address or incoming MX servers without a reason. If those servers genuinely send directly, account for them in the inventory. Preserve an existing policy's failure qualifier and other authorizations rather than replacing it with this example.
SPF evaluates the envelope sender domain, not just the visible From address. Confirm smtp.mailfrom on delivered mail. An apex record does not automatically configure an independently used subdomain's SPF, and a provider-owned return path cannot be repaired by editing unrelated customer DNS.
Only one TXT record starting v=spf1 is allowed at an owner. Other TXT records may coexist. Check the complete evaluation against SPF's ten DNS-query-causing-term limit, including nested includes; an apparently short record can exceed it. SPF standard and EmailAuth SPF reference.
If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.
Restrict account access with Domain Lockdown
SPF authorizes infrastructure; Domain Lockdown restricts identities within MailChannels. Publish the policy at _mailchannels for the sending domain using the real permitted identity. The simplest account-level format is:
Owner: _mailchannels.example.com
Type: TXT
Value: v=mc1 auth=YOUR_VERIFIED_ACCOUNT_ID
Replace both placeholders. The value uses spaces, not DMARC-style semicolons. If a host sends for you, obtain its MailChannels account ID. auth= permits every sender under that account, so it may be too broad for a shared hosting relationship. The documented senderid= and sidw= controls support narrower identities; adding a broad auth= alongside a narrow identity does not narrow the broad permission. Domain Lockdown formats and matching
Find the account ID in the Host Console footer, or read X-MailChannels-Auth-Id from a known authentic message delivered through your host. Obtain the exact sender identity from that message's X-MailChannels-Sender-Id, and confirm it with the host. For a narrow rule, the following is a placeholder pattern, not a ready-to-publish value:
Owner: _mailchannels.example.com
Type: TXT
Value pattern: v=mc1 senderid=ACCOUNT_ID|SENDER_TYPE|EXACT_SENDER
Replace the entire identity with the verified sender ID. Do not add broad auth= permission alongside it if the intention is to allow only that sender. Find account and sender identities
Preserve all intentionally authorized identities during a migration. A record containing only v=mc1 blocks every sender through the service. Do not copy obsolete Workers cfid examples into this SMTP configuration. Investigate an authorization rejection against the real account and sender identity instead of deleting the restriction to make mail flow.
Keep the planned permission scope in the change ticket. A DNS administrator should be able to distinguish “allow this hosting account” from “allow only these mail users,” especially when multiple customers share one platform.
Generate and activate DKIM on the originating server
For the cPanel route, configure signing in the Exim transport that actually relays through MailChannels. The provider's DKIM guide assumes the base cPanel setup already exists. It distinguishes Exim 4.93 and earlier from 4.94 and later, where tainted-filename restrictions change domain lookup handling. Use the version-appropriate instructions in WHM, Service Configuration, Exim Configuration Manager, Advanced Editor. MailChannels cPanel DKIM guide
Have the server administrator supply the generated public DKIM record for the domain and confirm that its corresponding private key is available to the active transport. The documented cPanel example uses selector default; do not assume every host or server uses it. The DNS owner follows this pattern, with the actual selector and signing domain substituted:
Owner pattern: SELECTOR._domainkey.SIGNING_DOMAIN
Type: TXT
Value: complete public DKIM value supplied by your signing server
That last line is an instruction, not a literal DNS value. There is no universal MailChannels Outbound public key. Never publish the private key or copy another domain's key from a screenshot.
After the authorized server change, save and activate the configuration as the official version-specific guide directs, including its Exim restart step. A record in DNS cannot make an inactive transport sign. Confirm the intended domain appears in the resulting DKIM signature's d= field.
If using the official cPanel plugin, review what it already manages before layering manual settings over it. MailChannels recommends the plugin and documents removal of prior manual configuration when moving to it. Its known issues include SPF not automatically updating for cPanel subdomains and possible update timeouts on servers with at least 1,000 domains. Automation therefore does not replace per-domain verification. cPanel setup and limitations
Publish DNS without damaging another route
Edit the authoritative zone, not an inactive registrar copy. Translate full record owners into the DNS editor's expected format; a host field may append example.com automatically. Check the resulting fully qualified name before saving.
For an issued signing domain such as news.example.com, a full owner SELECTOR._domainkey.news.example.com is SELECTOR._domainkey.news relative to the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is SELECTOR. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.
Keep separate DKIM selectors for separate signing systems. If default._domainkey already exists, determine who uses it before replacing the key. A sender using an old private key will fail after an incompatible public-key replacement. Plan any necessary selector rotation with the signing administrator and allow for messages already in transit.
Do not place a TXT public key at an owner that is already a CNAME. Nor should a CNAME be created over an existing TXT key without a coordinated migration. Long DKIM TXT data may appear as multiple quoted chunks within one resource record; that is different from accidentally creating multiple competing records. DKIM verification and key retrieval
Preserve DMARC before introducing monitoring
Inspect the visible From domain's _dmarc record and applicable parent policies before adding anything. Retain established enforcement, reporting recipients and alignment tags. Creating a local p=none record can weaken inherited protection, even when that subdomain currently has no local record.
Only where no existing or inherited policy applies, and the owner approves a monitored rollout, this illustrates valid syntax:
Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
In an example.com DNS zone that appends its suffix, use relative owner _dmarc. For visible From alerts@news.example.com, the exact-domain policy owner is _dmarc.news.example.com, or _dmarc.news relative to that zone. Check inherited policy before creating that more-specific record.
In a separately delegated news.example.com zone, that same full TXT owner _dmarc.news.example.com is relative _dmarc. Preserve its actual authority and any applicable inherited policy.
Replace the domain and use a functioning reporting destination. Semicolons separate tags; multiple rua destinations are comma-separated URIs. If reports go to EmailAuth or another external processor, use the assigned reporting address and its required external authorization. Do not publish two DMARC policies at the same owner. External destination authorization, RFC 9990 section 4
Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.
A DMARC pass needs either an aligned SPF pass or an aligned DKIM pass. Relaxed alignment allows an organizational-domain match; strict alignment requires exact domain equality. Authentication for an unrelated provider domain is not enough. p=none requests monitoring, not guaranteed acceptance. Current RFC 9989 replaces RFC 7489 and removes pct; retain established policy rather than applying an obsolete percentage rollout recipe. Current DMARC standard and EmailAuth DMARC guidance.
Check DNS and a trusted receiver independently
These commands only read public DNS. Substitute the actual domain and signing selector:
dig +short NS example.com
dig +short TXT example.com
dig +short TXT _mailchannels.example.com
dig +short TXT SELECTOR._domainkey.example.com
dig +short TXT _dmarc.example.com
Expect one SPF policy with the needed authorization, the intended account restriction, the server-issued public key, and the effective DMARC policy. If a result is missing, compare authoritative DNS with a recursive resolver. Check owner spelling, record type and cache timing before repeatedly editing values. Use EmailAuth's tools for supplementary public-record inspection.
During an authorized implementation, send representative mail through the real production path to a controlled external recipient. Inspect Authentication-Results added by that receiving system, not a sender-supplied assertion. Capture SPF's smtp.mailfrom, DKIM's header.d and selector, and the visible header.from. Require an aligned pass and the expected dmarc=pass; investigate missing or failed DKIM even if aligned SPF saves DMARC. Receiver-header trust
Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.
Complete this branded-DKIM setup only when the intended originating-server signature preserved through the MailChannels relay has trusted dkim=pass, its actual d= aligns with the intended visible From under the effective adkim mode, and the trusted receiver reports dmarc=pass for that From. An unrelated MailChannels transport signature is not evidence that the originating cPanel/Exim signer works. DMARC success through SPF alone does not establish that this DKIM deployment works; neither does an unnoticed provider-domain From rewrite. Diagnose SPF independently at the actual smtp.mailfrom: fail or softfail calls for checking sender authorization, temperror indicates a transient evaluation failure such as DNS availability, and permerror calls for checking invalid syntax, duplicate policies and lookup limits. Investigate these even if aligned DKIM supplies DMARC pass; a passing but unaligned provider envelope is a different outcome. DMARC alignment, SPF result meanings.
Test mailbox and script routes separately. Save the date, route, message correlation and redacted results. A relay acceptance response is not proof of recipient delivery, and neither authentication nor DNS verification guarantees inbox placement.
Troubleshooting and frequently asked questions
Why does DKIM fail only for some application mail?
MailChannels documents a specific case: an application omits Message-ID, the upstream signer includes that absent header in its signed-header list, and MailChannels adds it later. The insertion invalidates that signature. Ensure the application or originating server creates a valid Message-ID before signing, rather than weakening authentication indiscriminately. Message-ID failure explanation
Why does Domain Lockdown reject my hosting mail?
Compare the allowed identity with the host's actual relay account. Also check whether a narrow sender rule omits the affected script or user. Repair the approved identity list; do not remove all restrictions as a troubleshooting shortcut.
Does MailChannels automatically create my cPanel DKIM key?
Not in the upstream-signing workflow described here. Obtain the domain's generated public record from the signing server administrator and confirm the active Exim transport uses its matching private key. EmailAuth DKIM background
Is this also the Email API setup?
No. Email API and its submission routes have their own authentication and DKIM lifecycle. Do not generalize a cPanel default selector or local-signing instruction to those products.
What has this guide actually verified?
No account configuration, DNS changes or delivery tests were performed. Successful implementation still requires your actual public DNS, server activation and trusted receiver evidence.