Host your website at Lizard Hill while keeping email, calendars, and collaboration with Google Workspace, Exchange Online, Microsoft 365, or another provider.
Your website and email do not have to be hosted by the same company. Lizard Hill can host your website while your existing provider handles mailboxes, calendars, collaboration, and other licensed services. Those subscriptions and administration remain separate; a Lizard Hill hosting plan does not include Google Workspace or Microsoft 365 licenses.
Before changing anything
Keep the current email service active. Save the existing DNS zone and confirm where its authoritative nameservers point. DNS records belong at that active DNS provider, which may be your registrar, Cloudflare, or Lizard Hill—not necessarily the company hosting your website. Record the Lizard Hill website address from your welcome email and the exact mail records shown in your email provider's admin console.
| Record or setting | What to do |
|---|---|
| Website A/AAAA and www | Point only the necessary website records to your assigned Lizard Hill server. Review an old AAAA record so IPv6 visitors do not reach the previous host. |
| Email MX | Keep your external provider's exact destinations and priorities. Do not replace them with Lizard Hill's default mail destination. |
| SPF, DKIM, and DMARC | Preserve valid authentication records, authorizing only services that actually send your mail. Publish one SPF TXT policy per hostname, not competing SPF records. |
| Verification, Autodiscover, and collaboration | Retain required TXT, CNAME, and SRV records for the services you use. Use your provider's current account-specific values. |
| DirectAdmin Local Mail Server | Turn it off for a domain whose mailboxes are entirely hosted externally. This setting is separate from public DNS. |
1. Choose your DNS approach
Keep your existing DNS provider: change the website's required A/AAAA and www records there, leaving working email and collaboration records intact. A hosting move does not require a registrar or nameserver transfer.
Move DNS to Lizard Hill: recreate the complete zone in DirectAdmin before changing nameservers. Check mail authentication, verification, collaboration, and other subdomains—not just the website. Confirm the prepared zone is complete before the switch. Retain a rollback copy and allow cached records to expire.
2. Use the right provider records
Google Workspace
Use the values in your Google Admin console. Google's current setup documentation uses smtp.google.com for the new single-MX arrangement. Older working ASPMX records are still supported: moving only the website is not a reason to replace them. Keep Google's domain verification and configured Gmail authentication records. Do not mix Google's MX destinations with Lizard Hill mail records unless your mail administrator has designed a supported routing setup.
Microsoft 365 and Exchange Online
In the Microsoft 365 admin center, review Settings → Domains and the domain's DNS requirements. Use its exact MX target, Autodiscover CNAME, verification TXT, and tenant-specific DKIM CNAME values. Do not guess the tenant portion of a mail.protection.outlook.com destination or copy another organization's DKIM targets. Preserve records needed for your actual collaboration and identity services; a website move does not relocate Teams, SharePoint, OneDrive, or mailboxes.
Other hosted mail or Exchange services
The same pattern applies: obtain the exact records from that provider or your mail administrator. Custom Exchange, hybrid deployments, filtering gateways, and split delivery need their own routing plan. Do not apply a generic Google or Microsoft template to them.
3. Tell DirectAdmin that mail is external
- Sign in to the server assigned in your welcome email and select the correct domain.
- Open MX Records, usually under Email Manager. Skin wording can vary.
- Uncheck Local Mail Server or Use this server to handle my e-mails and save. Do this only when the domain's mailboxes are fully external.
- Keep the external MX records correct in the active DNS zone. If DirectAdmin also maintains a zone for this domain, keep its mail records consistent to avoid confusing local lookups. Review the actual public records after the change.
Changing MX alone does not necessarily stop a website on the hosting server from delivering mail locally. Conversely, switching off local delivery does not change public DNS or transfer any mailbox data. DirectAdmin mailboxes, forwarders, catch-all rules, and webmail are not a way to administer Google or Microsoft mailboxes. Never delete existing local messages just to switch routing; retain them until any needed migration is complete.
4. Configure website forms and notifications
Incoming MX records do not configure outgoing WordPress mail. Use an application integration supported by your provider: for example, OAuth-based Google/Microsoft sending, an approved authenticated relay, or a separate transactional email service with domain verification. Follow the provider's current security and sending limits. Do not disable MFA or tenant security controls to make a password-only plugin work.
Use an authorized domain address as the form's From address and the visitor's address as Reply-To. Store credentials privately. If the website sends through another service, review its DKIM and SPF requirements alongside the existing provider; do not add a second SPF record. An email provider's successful inbox delivery is not guaranteed just because DNS is correct.
5. Test before cancelling anything
- Check the website and free SSL certificate with automatic renewal from another network.
- Send to your domain from an unrelated external mailbox, then reply. Confirm delivery in the external provider's inbox.
- Submit a real test contact form and check its intended recipient, spam folder, application logs, and provider message trace if available.
- Verify SPF/DKIM/DMARC results for the actual sending service and check Outlook Autodiscover or other required client setup.
- Check calendars and collaboration sign-in separately. Keep existing subscriptions and backups until validation is complete.
Mail works externally but website forms disappear? Check DirectAdmin's local-mail setting, the site's sending integration, and the real recipient address. Email stopped after a nameserver change? Compare the new authoritative zone with the saved original, especially MX and authentication records. Ask support with the domain, approximate test time, and error message—never passwords, private keys, or recovery codes.
This guide describes website hosting with external email. Migrating mailboxes or combining local and external recipients under one domain is a separate task. See the website migration checklist for the wider cutover sequence.
Official references
Google Workspace MX setup and legacy records · Microsoft 365 domain DNS setup · Microsoft 365 external DNS and SPF guidance · DirectAdmin remote email · Exchange Online sending and authentication · Google Workspace application sending
