Kajabi Skills
Kajabi Domain, Email & CDN Setup
End-to-end technical setup for your Kajabi site: custom domain connected through Cloudflare, business email configured across Microsoft 365 or Google Workspace, Kajabi marketing emails sending from your own domain, and an optional CDN-backed asset library on your own subdomain.
Kajabi is straightforward until you try to connect a real domain. Then DNS, SSL, email authentication, and shared mailboxes become four separate problems, usually handled by three different freelancers. I set up the whole stack end to end: registrar, Cloudflare, Kajabi site domain, Kajabi marketing sending domain, business email, mailbox structure, and optional S3 plus CDN for course assets. One person owns the setup, every record is documented, and you keep all access afterward.
Book a Discovery CallThe Problem
Kajabi is straightforward until you connect a real custom domain. That's when DNS enters the picture, and DNS is unforgiving. A misconfigured CNAME takes the site down. A wrong Cloudflare SSL mode breaks the page behind the proxy. A missing SPF or DKIM record sends your marketing emails to spam, and Kajabi quietly shows "domain not configured" without explaining why.
The symptoms are always the same. The www version of your site works but the root domain doesn't, or the other way around. Emails from your contact form arrive fine but marketing campaigns land in spam. A shared support@ mailbox exists in Microsoft 365 but nobody can see it in Outlook. An S3 bucket serves PDFs correctly on the raw AWS URL and then returns an SSL error the moment it's behind a Cloudflare subdomain. Each of these is a small misconfiguration. Diagnosing them takes hours if you do not know what to look for.
The second problem is fragmentation. Creators typically split this work across three freelancers: one for Kajabi, one for email, one for AWS. When something breaks later, nobody owns the whole picture. The Kajabi freelancer says it's a DNS issue. The email person says it's a Kajabi issue. The AWS person was not around when the marketing domain was set up and has never seen it. Meanwhile the site is down, or email is bouncing, or course downloads are failing.
What's actually missing is a single technical owner who understands how the pieces connect: how DNS records control both the website and email, how Cloudflare's SSL mode interacts with an S3 endpoint, how Kajabi's marketing sending domain needs SPF alignment to pass DMARC, how shared mailboxes need permissions assigned in a specific order before they appear in Outlook. One person setting this up end to end is faster, cleaner, and safer than three people setting up pieces of it.
What This Service Delivers
I connect your custom domain to your Kajabi site, configure Cloudflare as the DNS layer, set up your business email environment (Microsoft 365 or Google Workspace), build out your mailbox structure including any shared inboxes, configure the DNS records that let Kajabi send marketing emails from your own domain (SPF, DKIM, DMARC), and optionally create an AWS S3 bucket with a Cloudflare-backed CDN subdomain for hosting course PDFs, HTML tools, and downloadable assets. The work happens end to end. One person owns the setup.
Before anything changes, I audit the current state: registrar, DNS zone, existing Cloudflare configuration (if any), email platform, Kajabi site settings, and any existing AWS setup. I map what's already working, what's broken or half-configured, and what needs to change. You see the plan before I touch DNS. For live sites, TTLs get lowered 24 to 48 hours ahead of the switch so rollback is measured in minutes, not hours. I do not make changes on production without a rollback plan already in place.
What you own after handoff: every credential on every platform (registrar, Cloudflare, Microsoft 365 or Google Workspace, AWS if applicable), a written setup document listing every DNS record with its purpose, mailbox access instructions for your team, and a documented rollback procedure. I do not retain admin access after handover unless you specifically want me as a shared admin. Nothing about your setup is a black box, and any competent admin can take it over without needing to call me back.
What's not included: ongoing DNS administration, ongoing email environment management, email deliverability remediation for reputation problems caused by previous sending history, cold outreach list warmup, custom application development against the S3 bucket, or anything beyond the initial setup. Ongoing technical support beyond the 30-day post-delivery window is available as a separate retainer. This service is a clean setup, done properly, handed over complete.
Frequently Asked Questions
Yes. The domain can be registered anywhere: GoDaddy, Namecheap, Squarespace Domains (formerly Google Domains), Porkbun, Cloudflare Registrar, or any other provider. I do not need to transfer the registration to set this up. What actually matters is pointing the DNS to Cloudflare, which happens through a nameserver change at your current registrar. The registration itself stays where it is unless you specifically want to transfer it for consolidation.
Yes. This is one of the most common issues I see. The cause is usually a DNS record set up for one version but not the other, combined with a missing redirect rule. The fix is a combination of correcting the DNS records (A or CNAME depending on the setup and whether the zone is Cloudflare-proxied) and adding a Cloudflare redirect rule so one version always forwards to the other. The result is that both versions resolve, both work over HTTPS, and visitors land on your preferred version consistently.
In most cases it's because the custom email sending domain is not set up, so Kajabi is either sending from shared infrastructure (which has a mixed reputation across all Kajabi customers) or showing "via kajabi.com" in the sender header, which modern inbox providers flag. The fix is configuring the full set of DNS records (SPF, DKIM, DMARC) so Kajabi can send as your domain, validated by your recipients' mail servers as legitimate. This service includes that setup and validation with a real test send. It does not fix deliverability issues caused by prior sending behavior (purchased lists, high bounce rates, previous spam complaints). Those need sustained remediation, which is a different kind of project.
Not strictly, but it's strongly recommended. Cloudflare gives you DNS control, redirect rules, SSL options, proxy behavior, and CDN functionality in one interface. If you are already using Cloudflare, I work within the existing account. If not, I onboard the zone as part of the setup at no extra cost. The alternative is managing DNS at your registrar directly, which works for the basics but gives you less control over redirects, no CDN option for S3 assets, and weaker tooling if something goes wrong.
A user mailbox is for a real person. It has its own login, password, inbox, sent items, calendar, and email identity. An alias is an additional email address that routes into an existing mailbox without creating a separate inbox. It's lightweight and useful for extra address variants (like hi@ routing to hello@), and it does not need its own license. A shared mailbox is a separate inbox that multiple users can access with permissions. It has its own sent items, its own inbox, and in Microsoft 365 it does not require a license per user who accesses it. Use a user mailbox for a person, an alias for extra address variants, and a shared mailbox for team-managed addresses like support@, team@, info@, or hello@.
Yes. This includes Outlook on desktop (Windows and Mac), Outlook on the web, and mobile apps. Shared mailbox access is set up with the correct permissions (Full Access, Send As where needed) assigned in the correct order, so the shared inbox actually appears in everyone's Outlook without the manual workarounds that most setups rely on. If your team is migrating from a previous email provider, I plan the mail flow cutover so messages are not lost in transit.
Yes, as the optional S3 plus CDN scope. I create an AWS S3 bucket, configure it correctly for public asset serving, add a Cloudflare CNAME on your chosen subdomain (cdn.yourdomain.com is the typical pattern), and validate that assets load cleanly over HTTPS behind the Cloudflare proxy. This is especially useful for Kajabi course PDFs, embedded HTML widgets, custom front-end files, and any downloadable resource you don't want to upload directly into Kajabi. This piece is quoted separately during discovery because not everyone needs it. If your asset library is small and you're happy serving through Kajabi's built-in file hosting, you can skip this entirely.
Yes, and honestly, for most creators that's the right call. Kajabi's Media Library (available on Builder 2.0) is free, integrated into every Kajabi media picker, and supports videos, audio, images, PDFs, and documents. It also includes genuinely useful features the custom S3 setup does not give you: automatic video transcripts and translations, video chapters, Wistia-powered analytics, Adobe Express editing, tags and saved views, and automatic location tracking so you can see every place an asset is used across your site. A small bit of trivia worth mentioning: Kajabi itself stores your uploaded files on AWS S3 behind the scenes. The preview URLs resolve to kajabi-storefronts-production.s3.amazonaws.com. So when you upload to Kajabi Media Library, you are already using S3. It is just Kajabi's bucket, not yours.
The custom S3 plus CDN subdomain is only worth paying for in specific cases. You want a branded asset URL (cdn.yourdomain.com/course-workbook.pdf reads better and looks more professional than a long Kajabi S3 path). You are hosting embeddable HTML tools, interactive widgets, JS, CSS, or SVG sprites, which Kajabi Media Library does not support. You want your assets to survive a platform migration: files in your own AWS account stay exactly where they are if you ever leave Kajabi, while files in Kajabi Media Library have to be re-uploaded. You serve assets to properties outside Kajabi (separate marketing sites, external embeds, partner platforms, landing pages built elsewhere). You want fine-grained control over caching, headers, or access policies that Kajabi's built-in library does not expose.
For a pure Kajabi course business where every asset lives inside a Kajabi lesson, page, or offer, skip the custom S3 plus CDN piece. Kajabi Media Library does the job and costs you nothing. For creators running anything outside Kajabi (a separate website, embeddable tools, custom blog components, or just a preference for branded URLs), the custom setup pays for itself quickly.
In almost all cases, yes. The approach is to lower DNS TTLs 24 to 48 hours before any migration, make the switch during a pre-agreed low-traffic window, validate everything is working, and then raise TTLs back to normal. If something goes wrong, rollback is measured in minutes because the old records are still cached briefly and the DNS change reverts quickly. For high-traffic sites, the switch is timed around your lowest-traffic window. I do not make changes to live production without a documented rollback plan already in place.
I offer a 30-day post-delivery support window at no additional cost for anything that goes wrong with what I set up. Beyond that, paid support sessions are available, or a small ongoing retainer for DNS and email monitoring if you want someone watching it. Because every DNS record is documented with its purpose, and you hold all admin credentials, most future changes can be done by you or by any competent admin without needing to call me back. Nothing about the setup is locked to me, and nothing is a black box.
Ready to set up your Kajabi infrastructure?
No commitment. We will talk about your current setup, what's working, what's half-configured, and whether this service is the right fit for where your business is today.
Book a Discovery Call