For Kajabi native marketing email, generate the unique DNS packet in Marketing settings, publish its approved records at the authoritative DNS provider and verify the resulting sender on an actual marketing message. Kajabi requires the fixed kjbm subdomain for a custom email domain. An authenticated root-domain mailbox or a website domain connection is not a substitute.
This guide covers a new custom marketing email domain with DNS already managed outside Kajabi, on an existing active subscription. It does not configure a trial, transfer nameservers, migrate an existing custom domain or authenticate transactional receipts as your brand. Kajabi’s current documentation says transactional mail continues from its own t.kajabimail.net domain. Custom email domain scope.
No customer account, DNS change, subscription purchase or message send was performed.
Choose the intended sender and confirm DNS authority
For an illustrative connected domain example.com, plan for a marketing From domain such as kjbm.example.com, not the bare example.com. Kajabi says kjbm cannot be removed, renamed or hidden. Agree that visible identity with the domain owner before setup; do not promise an exact root-domain From that the product does not support.
A Reply-To mailbox serves a different purpose from the authenticated From. Use an authorized, monitored mailbox for replies, not an address you cannot receive. Do not place a personal Gmail or Outlook address in the custom From field and treat Kajabi’s rewritten sender as successful authentication of your own domain.
Record the intended Kajabi site, marketing workflow, From identity, reply destination and DNS administrator. Confirm where the live zone is authoritative. If Kajabi already manages the domain’s DNS, stop: this external-DNS procedure is not an instruction to move nameservers. Kajabi specifically warns that changing authority to expose a registrar’s editor can disrupt the website and other services. DNS-authority warning.
Keep marketing and transactional routes separate
Kajabi identifies Broadcasts, Sequences and Event Emails as marketing mail. Its system-generated and other notification paths are separately documented. Test the actual intended workflow; do not use a purchase receipt as proof that the custom marketing domain works. Marketing and transactional email types.
For transactional mail, changing display information or a reply address does not change the provider-owned signing identity. Do not add Kajabi transactional records to your domain based on this marketing guide. Likewise, a marketing-domain change does not establish that every automation or notification uses the same route.
This is an authentication guide, not authorization to send a list or override subscription preferences. Use only an approved test recipient and respect the actual marketing consent and opt-in state.
Generate the current account-specific records
Open Settings > Marketing settings > Email Settings, complete the intended From name, a simple From local-part such as hello, and an authorized Reply-To address, then select Setup Custom Email Domain. The setup page issues the unique DNS records. Use its exact current owners, types and values. Kajabi’s main and Cloudflare instructions describe three TXT records, two MX records and one CNAME. Record issuance and Cloudflare procedure.
The public main article also mentions “DKIM CNAME” in a troubleshooting passage. Do not use that wording to convert an issued TXT key into a CNAME or invent a missing selector. If the account packet is incomplete or conflicts with the documented flow, stop and ask Kajabi to confirm the supported packet before publishing or activating it.
Capture the exact proposed records for review, including any separate DMARC row presented by the current setup. Never copy another account’s tokens, selectors, key material or target names. Public DKIM values belong in DNS; private keys and account credentials do not.
Approve routing before adding MX or CNAME records
MX records change where mail for their owner is routed. Have the domain/mail administrator approve the exact Kajabi-issued MX owners, destinations and priorities before publication. The current Cloudflare procedure uses priorities 10 and 20 for its first and second MX records, but that does not authorize a destination or override a conflicting current account packet.
Kajabi’s records belong under the issued kjbm names, not at your staff-mail root. Keep existing Google Workspace, Microsoft 365 or other business-mail MX records and priorities unchanged. Do not move the Kajabi MX rows to @, erase root SPF or replace nameservers to make the setup easier.
Review the CNAME’s actual purpose and exact destination too. If it routes tracking or other web traffic, obtain approval for that routing and its implications. Do not repoint an existing website hostname or accept an unidentified destination merely because the setup page contains it. Preserve existing NS delegations and dependencies. If the required owner is already used, ask Kajabi and the DNS administrator for a supported resolution before proceeding.
Publish exact DNS owners and values
Match each full owner to the authoritative zone. For example, _dmarc.kjbm.example.com may be entered as _dmarc.kjbm when editing example.com, or _dmarc in a separately delegated kjbm.example.com zone. A hypothetical selector owner selector._domainkey.kjbm.example.com similarly becomes selector._domainkey.kjbm in the parent zone, or selector._domainkey in the child zone. These examples explain mapping; they are not issued selectors.
If a _domainkey namespace is delegated, work with its actual authority rather than deleting the delegation. Avoid editors appending the domain twice. Preserve full tagged DKIM TXT content and the exact record type. Quoted DNS character-string splitting must not truncate the public key or insert spaces into its logical value. DNS zones and record representation.
At a CNAME owner, do not add conflicting TXT, A, AAAA, MX or another CNAME record. Kajabi’s Cloudflare guide requires DNS Only, not the HTTP proxy. Where the validator requires a visible CNAME answer, also check per-record, zone-wide, apex and same-zone flattening. Turn the relevant per-record Flatten control off when available and preserve the required aliases under applicable zone settings. If mandatory behavior prevents that answer, stop for a supported configuration; do not make blanket global changes or remove shared delegations. Cloudflare flattening controls.
SPF belongs to the actual envelope domain
SPF authenticates SMTP MAIL FROM, not automatically the visible From. Use the issued authorization at its actual owner and later compare it with the envelope domain observed on a received marketing message. Parent-domain SPF does not automatically cover a subdomain.
Maintain one v=spf1 TXT policy per evaluated owner. Preserve legitimate existing authorizations and qualifiers; never paste a second policy or blindly overwrite the root. The limit is ten evaluated DNS-dependent terms, including nested mechanisms, not ten includes. An all mechanism makes redirect ineffective and prevents later additions from authorizing senders. Resolve syntax, duplicate-policy and lookup-budget errors before sending. SPF processing rules.
Resolve Kajabi’s “Strict DMARC” requirement safely
Kajabi uses “Strict DMARC” as a product requirement and state. That label alone does not prove the protocol’s adkim=s or aspf=s alignment modes, nor does it guarantee inbox placement. Inspect the actual policy and received-message identities.
For a first-time setup, Kajabi says there is no separate Enable Strict DMARC button; the kjbm requirement is built into setup. Its separate button workflow is for applicable existing externally managed domains, not an extra new-domain step to invent. Custom email domain requirements.
Before adding _dmarc.kjbm, check both an existing direct policy and any policy inherited from the parent. A child policy can change the effective protection for that child even when the parent record is untouched. Do not accept the claim that different owners automatically mean no policy consequence.
Preserve existing enforcement and authorized report recipients. The public DMARC example contains p=none, obsolete pct and report destinations. Do not paste it uncritically, weaken inherited quarantine or reject, add a duplicate policy, or disclose reports to unapproved recipients. If Kajabi’s required packet conflicts with the approved effective policy, stop and resolve compatibility with Kajabi and the domain owner before activation. Kajabi’s published DMARC example.
Only if there is no direct or applicable inherited policy, the owner approves, and monitoring is appropriate may a first policy begin with TXT v=DMARC1; p=none at the actual _dmarc.kjbm.example.com owner. This minimal standard example does not request reports and does not establish that Kajabi accepts it. Confirm the required policy with Kajabi rather than silently omitting its requirements. Current DMARC standard.
For aggregate reports sent to a different Organizational Domain from the domain where the policy was found, the report-generating receiver must check DNS authorization. Destinations within the same Organizational Domain are excepted. That protocol check does not replace the owner’s privacy/data-sharing approval. Failure-report requests can disclose message details and need separate consideration; do not copy ruf as a routine setup step. Aggregate-report authorization.
Confirm activation, then test the real marketing path
Kajabi documents an account status and email notification when the custom domain is confirmed, with a separate error state if verification fails. During verification, mail can continue through its shared marketing domain. Therefore, receipt of any message while setup is pending is not proof that the intended branded route is active. Verification behavior.
Check authoritative DNS and the account’s confirmation, including the required DMARC state. Do not merely wait longer if owner/type/value is wrong. Kajabi describes up to 48 hours for verification; this is not a promise of successful activation for an incorrect record.
Before a controlled marketing test, confirm that Settings > Marketing Settings contains the approved Marketing Contact Address as well as From Name and From Email. Kajabi identifies a missing contact/footer address as a delivery blocker. Obtain the owner’s approval before changing that address; do not insert an arbitrary address to pass a test.
A preview is useful for layout, but Kajabi warns that preview content and links can differ from the recipient experience. After account confirmation, use an approved controlled recipient through the actual intended marketing workflow, such as an existing approved opt-in path. Do not create paid purchases, publish a draft automation, release a customer campaign, resubscribe opted-out contacts or change sequence timing merely to force a test. Kajabi preview and real-flow testing.
Collect the recipient’s original message and results produced inside the actual receiving service’s known processing boundary. Consult its documented handling of external Authentication-Results, or obtain an administrator trace. A familiar authserv-id, header position or copied string is not proof of trust; ignore injected external result fields. Authentication-Results trust boundary.
Record the actual visible From, SMTP MAIL FROM, intended Kajabi signature’s d= domain and s= selector, plus trusted SPF, DKIM and DMARC results. Acceptance requires the intended kjbm brand identity, passing aligned intended-provider DKIM and dmarc=pass, alongside correct account and DNS state. A shared-provider From or unrelated passing signature does not satisfy this custom-domain setup.
DMARC passes through either aligned SPF or aligned DKIM. Relaxed alignment compares Organizational Domains; strict aspf or adkim requires exact equality. A child envelope identity can align relaxed but fail strict alignment. Require the intended DKIM signature itself to pass and align even if SPF independently makes DMARC pass. See raw DKIM results versus aligned results.
Diagnose SPF failures and temporary or permanent lookup errors separately. Keep controlled evidence private and recheck each materially different marketing path or sender change. Authentication is not a guarantee of inbox placement or marketing consent.
Troubleshoot without destructive shortcuts
Verification loops: compare the exact issued hosts with the active DNS zone, especially kjbm placement and duplicated suffixes. Do not overwrite root-domain records. If the packet and authoritative answers agree but verification remains unresolved, ask Kajabi to investigate provisioning.
Cloudflare Error 1014: confirm the issued CNAME is DNS Only and its required answer remains visible. Kajabi directs persistent errors to Support rather than repeated record recreation. Cloudflare-specific troubleshooting.
The setup lacks expected DKIM records: stop for Support clarification. Do not follow removal/restart as a harmless refresh. Kajabi warns removal irreversibly deletes custom-domain setup and can break links in previously sent mail, even though another passage calls re-setup safe.
DKIM passes but DMARC fails: check the actual signing domain against the actual From under the applicable alignment mode. Do not rewrite the brand sender or weaken policy to manufacture a pass.
DKIM fails after an outbound security service: have the responsible administrators investigate signed-content changes and route identity without disabling required protection.
A message is missing despite passing authentication: inspect the actual rejection or workflow diagnostic, consent status and intended route. A DMARC failure alone does not prove why a recipient rejected a message, and a draft automation is not a DNS problem.
For recovery, pause the affected workflow where operationally safe and coordinate restoration to the last approved state. Do not remove the custom domain, destroy selectors or change nameservers as a default rollback. Preserve queued-mail and historical-link dependencies, and provide Support only necessary redacted diagnostics through an approved channel.