How to Host Email and Website Separately (And What Breaks If You Don't)

What Actually Breaks When You Split Them

Separating email from web hosting is technically straightforward, but rushing through DNS updates can disrupt delivery. If you modify records out of sequence, here is what typically breaks:

1. Immediate Inbound Bounces from Premature MX Cutover

If you point your MX records to your new email provider before your mailboxes, addresses, and aliases are fully created in the provider's system, incoming mail bounces. Sending mail servers receive hard reject codes (such as 550 5.1.1 User unknown ). Those messages do not queue for later; they return immediately to the sender as failed deliveries. often configure and provision all user addresses and aliases at the new email host before modifying a single DNS record.

2. Multiple or Conflicting SPF Records

Sender Policy Framework (SPF) rules dictate that a domain must have exactly one TXT record starting with v=spf1. Operators often make the mistake of adding a second SPF record for their new mail provider instead of updating the existing one. When receiving mail servers inspect a domain with multiple SPF records, they evaluate the check as a PermError (permanent error), which breaks authentication and often lands mail straight in the spam folder. You must merge your mechanisms into a single TXT entry, keeping legitimate sending includes while removing stale web host relays.

3. Broken DKIM Verification

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to message headers that is validated against a public key published in your DNS. According to AutoSPF, DKIM signatures are published as TXT records at a designated selector, which allows older and newly deployed keys to coexist cleanly during migration phases. If you adjust your email system without publishing the new provider's selector key, or if you delete the old selector while outbound messages are still in transit, digital signature validation fails, degrading your deliverability score.

4. Silent Failures on Website Forms and Transactional Mail

Many multi-brand operators forget that local web platforms (such as WordPress, custom PHP scripts, or platform form handlers) routinely hand messages off to a local sendmail utility or an internal mail transfer agent. Once you switch your domain's authoritative MX records away from that web host, two problems emerge:

• Local scripts may attempt to deliver messages internally to an unmonitored mailbox on the web server rather than routing out over the internet to your new mail provider.
• If the web script does route externally using your domain name, receiving inboxes will reject the message because the web server's IP is no longer included in your updated SPF record.

To prevent this, configure your CMS and website plugins to send transactional notifications using an authenticated SMTP integration or dedicated API rather than the local hosting relay.

5. Delivery Loops from Stale, Lower-Priority MX Records

MX records use numerical priorities (such as 10, 20, 30). Sending MTAs often attempt delivery to the lowest numeric value first. If you add your new provider's MX record at priority 10 but leave your old web host's MX record in place at priority 20, sending servers will fall back to your old web host whenever your primary route encounters a temporary network timeout. Those messages will deposit silently into abandoned mailboxes on your web server that nobody checks.

Step by Step: How to Host Email and Website Separately Without Downtime

To implement this setup safely across your brands, follow this sequential cutover procedure:

1. Audit your environment: Document every domain name you operate, where its nameservers live, who the domain registrar is, which MX records are currently active, and every specific address, alias, and forwarder that receives real business mail. Reviewing your setup through dedicated guides—like our overview for multi-LLC owners managing distinct corporate properties—helps keep your naming conventions organized across different legal entities.
2. Provision the destination mailboxes: Configure your target email provider first. Add your custom domains and configure every necessary mailbox, routing alias, and forwarder. Ensure that all downstream addresses exist and are ready to receive mail before touching public DNS records.
3. Lower your TTL values: At least 24 hours prior to switching, log in to your DNS management interface and lower the Time to Live (TTL) on your existing MX and TXT records to 300 seconds (5 minutes). Standard TTLs often default to 14,400 or 86,400 seconds (up to 24 hours). Lowering the TTL ensures that once you swap records, caching servers across the internet recognize the new routes in minutes rather than days.
4. Publish authentication records (SPF, DKIM, DMARC): Publish the DKIM public key provided by your new email platform under its designated selector TXT record. Merge the new provider's SPF include string into your existing SPF record. As detailed in the Google Workspace Admin Help guide to DMARC, your domain's DMARC policy sits at the _dmarc host label and relies on aligned SPF or DKIM validation to confirm an email's legitimacy. If you are starting fresh, deploy a neutral monitoring policy:

   v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com;

   Because these authentication records run in parallel with existing mail delivery, publishing them in advance causes zero disruption.

5. Update your MX records: Delete the legacy MX records pointing to your web hosting provider. Add the destination MX records provided by your dedicated email host. Double-check that your website's A, AAAA, and CNAME records remain untouched. Your site visitors will experience zero downtime because web server traffic continues flowing to the exact same IP addresses.
6. Verify and run test deliveries: Send test messages from an external account (like a personal Gmail or iCloud address) to your newly pointed domain. Check that inbound delivery lands directly inside your new inbox. Then, send an outbound test message from your custom domain to both a Google and an Outlook account. Inspect the full headers in the receiving inbox to confirm that SPF, DKIM, and DMARC indicate a clean PASS. For operators juggling multiple web storefronts, reviewing our breakdown for Shopify operators provides useful context for coordinating store transactional notifications with primary business mail.
7. Complete post-migration cleanup: After five to seven days of clean operation, review your DNS. Remove any legacy DKIM selectors and delete any old SPF includes tied to your former web host that are no longer used by internal forms. Finally, raise your MX and TXT record TTL values back to a standard duration (such as 3600 or 14400 seconds) to reduce ongoing DNS query load.

The Records That Move and the Records That Stay

When executing this separation, keeping a clear distinction between which records change and which stay put prevents unintended website outages:

Watch out for host-specific automation rules. Some shared web hosts automatically re-inject wildcard MX records or default local mail delivery handling via cPanel. In your hosting panel, make sure to set the email routing setting from "Local Mail Exchanger" to "Remote Mail Exchanger." This instructs the local server software to stop attempting local inbox routing for your domain name.

If your registrar supports modern protocols like Domain Connect, certain dedicated providers can publish these DNS configurations automatically, removing the need to copy and paste records manually.

Doing the Arithmetic: What Separation Costs Per Domain

Once you decide to move your email away from your web host, evaluating the costs across multiple domains becomes the primary consideration. Traditional corporate platforms charge on a per-user, per-month seat basis. If you are an individual consultant running five distinct brands, those platforms require you to either buy five separate user licenses or stitch secondary domains together under a single user account as simple aliases.

Relying on secondary domain aliases under a single mailbox introduces practical problems: secondary domains often lack completely distinct DKIM signatures, custom brand personas, or isolated outbound identities. If you instead purchase five individual seats across multiple accounts, your costs scale linearly per domain for mailboxes only one person checks. Reviewing alternatives across the market—such as exploring a cPanel email comparison—illustrates why paying per-seat fees for basic portfolio domains quickly becomes impractical.

In contrast, independent mailbox providers generally prioritize flat-rate, storage-based, or domain-based pricing rather than per-seat licensing models:

• Fastmail focuses on private productivity suites and charges accounts based on user tiers.
• Zoho Mail offers low-cost entry plans geared toward traditional organization structures.
• Platforms like Purelymail, Migadu, and Forward Email focus their models on storage limits, overall domain counts, or simple routing rather than per-seat costs.

The arithmetic shifts depending on whether your provider bills by the user or by the overall portfolio. If you have four domains, paying standard per-user seat fees across separate accounts scales rapidly. A flat multi-domain structure provides clear cost ceilings for independent operators.

FolioInbox structures its plans specifically for the single operator managing multiple web entities. Pricing is flat per plan, not billed per user or per seat:

• Solo: Covers up to 3 domains with a monthly cap of 1,000 sends, including separate per-domain DKIM and distinct signatures.
• Studio: Covers up to 10 domains with a monthly cap of 6,000 sends, priority support, and per-domain authentication.
• Holding Co.: Supports unlimited domains with a monthly cap of 30,000 sends, priority support with response SLA, onboarding assistance, and DNS review.

We believe in laying out service boundaries plainly before you migrate. Send volume caps sit at 1,000, 6,000, and 30,000 messages per month across the respective plans. Message attachments are limited to 15 MiB per email. Folio has no free plan. New accounts receive a 14-day evaluation: 100 sends on up to two domains, no card required; when it ends, sending stops and receiving continues while your account is active. Paid plans (Solo, Studio, Holding Co.) need a card: chosen during the evaluation they start with a 14-day trial; chosen after it, they are charged the day they start.

Furthermore, Folio is strictly a single-operator product. Folio has no shared or team inboxes, message assignment or internal notes. Folio encrypts mail in transit (TLS) and at rest, but is not end-to-end or zero-knowledge encrypted: mail is stored server-side and readable by Folio for spam filtering and search. Folio is a fully hosted service and cannot be self-hosted or run on your own servers or infrastructure. Folio is a proprietary, hosted service; its source code is not public. For operators managing a portfolio of projects alone, the single flat tier delivers separate cryptographic domain isolation without unnecessary per-seat overhead.

When Keeping Them Together Is the Better Choice

Separating email from website hosting is an architectural best practice for multi-brand operators, but it is not universally necessary. In certain circumstances, keeping both on a single bundled provider makes practical sense:

• Single brand with minimal outbound mail: If you run a single informational website, send very few daily messages, and have no plans to launch additional ventures, a bundled web hosting email account avoids an extra service subscription.
• Native support for per-domain cryptographic signing: If your web hosting control panel already gives you isolated, dedicated IP addresses, generates unique per-domain DKIM keys automatically, and delivers strong inbox placement, separating your mail will yield fewer functional improvements.
• Restricted nameserver management: If your website host controls your domain's nameservers and will not grant access to edit individual MX, TXT, or CNAME records, decoupling your services is impossible without first transferring DNS authority to an external provider.

Most operators make this transition when forced by an external trigger: a hosting invoice increase, persistent deliverability drops, or the launch of a new LLC that requires its own professional address right away. If your current bundled setup delivers your mail reliably, keep it in place until an operational milestone justifies the migration.

A Pre-Move Checklist for the Multi-Domain Operator

Before modifying records in your DNS zone file, verify each operational item on this checklist:

• □ Map nameservers and zone authority: Confirm whether your DNS is managed directly at your domain registrar or hosted externally by your web platform.
• □ Audit incoming routing: Inventory all active operational addresses (e.g., alex@brand.com, billing@brand.com, support@brand.com) to ensure matching mailboxes or aliases exist at your new email host.
• □ Draft SPF string adjustments: Prepare your unified SPF record string. Keep essential transactional services (such as transactional delivery relays) alongside your new provider's mechanism, while omitting obsolete shared-hosting entries.
• □ Set up DKIM selectors: Add the new DKIM selector TXT records generated by your dedicated mail provider while retaining existing selectors until the migration is finished.
• □ Verify DMARC monitoring: Confirm your domain publishes a basic DMARC policy at _dmarc.yourdomain.com so you receive visibility into any authentication failures during the cutover window.
• □ Record your rollback data: Document your original MX records, host priorities, and TXT strings in a secure document. Do not terminate legacy mail accounts until your new configuration has received live mail cleanly for seven consecutive days.

Frequently Asked Questions

Can you host email and website separately?

Yes. Web hosting and email hosting operate over completely independent internet protocols. Your website relies on A, AAAA, or CNAME records pointing to a web server IP address, while incoming mail routes exclusively through DNS MX records. You can host web assets with any infrastructure provider while routing business messages through an independent email service.

Can I host my email with one company and my website with another?

Yes. This is standard infrastructure practice. Point your domain's nameservers to your registrar or a specialized DNS host, keep your site's web records directing traffic to your web host, and point your domain's MX, SPF, and DKIM records to your chosen dedicated email provider.

Will moving my email break my website?

No. Updating email routing records (MX, SPF, DKIM, DMARC) does not affect web traffic. Your website will only encounter issues if you accidentally change its A, AAAA, or root CNAME records, or if your site relies on local unauthenticated scripts to send contact form submissions directly through the web host's internal mail server.

Do I need to change my nameservers to separate email from web hosting?

No, provided you have access to edit individual DNS records within your current nameserver manager. However, if your web host manages your nameservers and locks down MX or TXT editing, you will need to point your authoritative nameservers back to your domain registrar or to an independent DNS provider.

What happens to email sent during the MX switchover?

If you lower your DNS TTL values to 300 seconds ahead of the migration, zero messages should be lost. During DNS propagation, sending servers will deliver messages either to your previous mail server or to your new email platform based on cached DNS records. As long as mailboxes are active on both platforms during the transition window, every message will be accepted cleanly.

Before you touch a single record, run each domain through our free domain health check at /tools/domain-health to inspect your SPF, DKIM, DMARC, and MTA-STS configurations without an email gate, so you know exactly what is already broken and what the move needs to fix.