How to Set Up Custom Domain Email Without a Website

How to set up email on a domain with no website

The order matters more than the speed. Prepare the destination first, then switch incoming mail, then tighten policy once you have seen real traffic.

1. Register or reuse a domain. Any registrar works. If the registrar offers free "email forwarding", leave it off for now, because it usually publishes its own MX records, which would compete with your host's.
2. Choose an email host. Decide between hosting (the provider stores your mail and sends as your domain) and forwarding (it redirects mail to an inbox you already have). The comparison below covers both.
3. Verify ownership. Most hosts ask for a TXT record that proves you control the domain. Add it exactly as given; DNS editors differ on whether the host field takes "@", a blank, or the full domain.
4. Publish MX. Replace the old host's MX records with the ones your new host lists. Cached answers can continue routing to the old host until their time-to-live expires, so keep the old service available during the transition.
5. Publish one SPF record per hostname. Follow your host's envelope-sender or bounce-domain instructions. If multiple services use the same envelope-sender domain, combine their authorizations in one SPF record; do not add a second SPF record at that name. Check the SPF lookup limit before adding includes.
6. Publish DKIM. Copy the selector and TXT key or CNAME records your host generates for each domain. Separate keys let you rotate a domain's signing credentials independently; they do not guarantee reputation isolation when domains share sending infrastructure.
7. Start DMARC at monitoring. Publish a policy of p=none with a reporting address, read the reports for a week or two, and move to quarantine or reject only once every legitimate sender passes.
8. Test both directions. Send to and from an outside account, including a reply. Inspect the receiving service's authentication results on a direct outgoing test before diagnosing any forwarded copy; the walkthrough below explains pass results and alignment.

Folio's setup page names your DNS provider, lists each record with a copy button and turns each one green as it resolves. At Cloudflare, Route 53 and GoDaddy it can publish the records for you. Whatever host you choose, the free domain health check reads MX, SPF, DKIM and DMARC from public DNS so you can confirm the result. For the settings behind each record, see email DNS and server settings for multiple domains.

Worked DNS example: an email-only domain

ILLUSTRATIVE — not a working DNS zone. Do not paste these records into your DNS settings. Imagine Alex wants alex@studio.example, hosted by a fictional mail provider. The reserved .example and .test names below are for explanation, not real services. Replace every name, target, selector and key with the exact records issued by your host.

In an editor that appends the zone name, selector1._domainkey becomes selector1._domainkey.studio.example. In an editor that wants a full name, enter that full name instead; avoid accidentally doubling the domain. Cloudflare's email-record guide explains why the real values must come from your mail provider.

After entering your real records, query the actual names. These read-only command examples use the same fictional domain and are not expected to return a working setup:

dig MX studio.example
dig TXT studio.example
dig TXT selector1._domainkey.studio.example
dig TXT _dmarc.studio.example

Compare the returned answers with your provider's setup screen, including any CNAME delegation it uses for DKIM. A DNS lookup shows published configuration, not whether an outgoing message was signed or delivered. For Folio-specific instructions, use adding a domain.

Verify the message, not just the DNS records

Send a direct test from your real domain to an external account you control and reply back. In Gmail on the web, open the message menu and choose Show original; Google's full-header instructions cover where to find it. Inspect the Authentication-Results added by that receiving service, not an arbitrary header supplied by the sender. RFC 8601 explains this trust boundary.

ILLUSTRATIVE — not a captured delivery result. This simplified header uses reserved domains and represents one possible direct-test result, not evidence that Folio or any other provider delivered a message:

From: Alex <alex@studio.example>
Authentication-Results: receiver.test;
    spf=pass smtp.mailfrom=studio.example;
    dkim=pass header.d=studio.example;
    dmarc=pass header.from=studio.example

• SPF pass: the connecting server was authorized for smtp.mailfrom, the SMTP envelope-sender domain. SPF pass for an unrelated provider domain does not, by itself, authenticate the visible From domain.
• DKIM pass: a signature verified using the signing domain in header.d. For DNS troubleshooting, find the actual signature's s= selector and d= domain; the domain health check accepts a selector or DKIM-Signature header to avoid guessing the selector.
• DMARC pass: at least one passing SPF or DKIM identity aligns with the visible From domain (header.from). Exact domain matches align; relaxed alignment can also accept the same organizational domain. Check the configured alignment mode before treating a subdomain match as sufficient.

Forwarding changes the path. A forwarded copy can show spf=fail because the forwarder is not an authorized server for the original envelope sender, while an unchanged, aligned DKIM signature can still make DMARC pass. A rewritten envelope sender can pass SPF for the forwarder's domain without aligning with the original From. ARC can carry earlier authentication results, but receivers decide whether to trust it; it is not a blanket fix or an automatic DMARC pass.

If the direct test fails, compare the actual envelope domain and DKIM selector with your host's instructions before changing DNS. If only the forwarded copy fails, inspect the forwarder's handling first; the forwarding troubleshooting guide explains that path. Do not weaken DMARC or add a forwarder to your SPF merely to make a forwarded third-party message pass. A passing test is not proof of inbox placement, future delivery or every sending service's configuration.

Email hosts compared for a domain with no website

These options can handle email for a domain that has no site, but forwarding is not mailbox hosting. They differ in what they charge for: the account, each user, or nothing at all because they only forward.

Sources: Purelymail pricing, Migadu pricing, Forward Email pricing, Fastmail pricing, Google Workspace pricing and Folio pricing. Zoho Mail Lite is listed at $1 per user per month on annual billing; confirm the current figure on Zoho's own page. The cheapest row is not automatically the right one: a $19 plan that allows 20 sends a day is a different product from one that allows thousands.

If more than one person needs a mailbox, per-user prices multiply while account-priced hosts do not. If one person runs several domains, the question becomes whether replies leave from the right address without manual switching. That is the case Folio is built for, and the custom domain email without Google Workspace guide compares it with the alternatives in more depth.

Forwarding or hosting when there is no website

Forwarding is the lightest option. Mail sent to you@yourdomain.com is passed on to an inbox you already use, often for free. It fits a domain that mostly receives: a holding address, a domain you are reserving, or a contact address you check rarely.

Forwarding has two weaknesses. First, it does not send. Replying "as" the domain needs an authenticated sending service, and the convenient Gmail route is closing: Google says third-party "Send as" support ends in January 2027. Second, forwarded mail can fail SPF at the final inbox, because the forwarder, not the original sender, is now delivering it; forwarded mail landing in Gmail spam explains why and how to diagnose it.

Hosting stores mail at the provider and signs your outgoing messages with your domain's own DKIM key. It costs more than free forwarding, but it is the setup that lets you reply from the domain you were written to. The trade-offs are laid out in email forwarding vs. email hosting.

Mistakes that break email on a domain with no website

• Leaving the registrar's forwarding MX in place. A web parking page alone does not route mail, but bundled forwarding often adds MX records. Mixing hosts' MX records can route messages to the wrong service; MX priority is not a mailbox-mirroring feature.
• Publishing two SPF records at the same name. SPF returns a permanent error if more than one SPF record is found there. Merge legitimate sender authorizations into one record for that envelope-sender domain.
• Copying someone else's DKIM records. Use the selector and key or CNAME targets your host issued for your domain. A selector name can be reused by different domains; copying a tutorial's name and key does not configure your host's signing.
• Jumping straight to p=reject. A strict DMARC policy before every sender is aligned can block your own invoices or calendar replies. Start with p=none and read the reports.
• Assuming "no website" means "no DNS". Registrars sometimes hide DNS settings until you enable them, or default to their own name servers. Make sure you are editing the zone the internet actually reads.

If you are running several brands, repeat the setup per domain rather than sharing one record set: adding multiple domains to one inbox walks through the per-domain records, and a professional email address for an LLC covers the single-entity case.

Does a domain without a website hurt deliverability?

Not by itself. Receiving servers decide on authentication results, the sending domain's and server's reputation, message content and how recipients react. The major providers' published sender requirements centre on SPF, DKIM, DMARC, valid DNS and low complaint rates; a homepage is not one of the listed checks. A brand-new domain does start with no sending history, so build volume gradually and avoid sending bulk mail from a domain you also use for correspondence.

A website can still help people. A client who types your domain into a browser and sees an error may wonder whether the business is real. If that matters, a single static page or a redirect to a profile you already have is enough, and adding one later only means adding web records; your mail records stay exactly where they are.

Frequently Asked Questions

Do I need web hosting to get a custom email address?

No. You need a registered domain and an email host. Web hosting is a separate service that you can add, change or never buy without affecting email.

Can I buy a domain just for email?

Yes. Registrars sell domains with no website attached. After registration, publish your email host's MX, SPF, DKIM and DMARC records and the domain is ready for mail.

What happens if someone visits my email-only domain in a browser?

They see the registrar's parking page or a "site can't be reached" error, depending on the records you leave in place. Neither affects mail. Add a simple page or a redirect later if you want visitors to land somewhere.

How long does DNS take for a new email domain?

New records are often visible within minutes, but caches can hold old values for as long as the previous record's time-to-live. Plan for a few hours, keep the old mail service available during the change, and test before relying on the new setup.

Can I add a website later without breaking email?

Yes. Add the web records your site host gives you and preserve the mail records. Use A/AAAA or your DNS provider's supported apex alias feature at the root: a normal CNAME cannot coexist with MX and TXT at the same name. A www CNAME at its own name is a separate matter.