Use it for email only

What running a domain for email only means

You point the domain's mail records at an email provider and never build a website. you@yourname.com works. https://yourname.com shows nothing, or a holding page, or a redirect. This is completely normal and fully supported, and it surprises people more often than it should.

It works because web and mail are separate services delivered by separate DNS records. A domain needs A, AAAA or CNAME records to serve a website and MX records to receive mail; neither depends on the other. A domain with MX records and no A record receives mail perfectly well and produces a browser error for anyone who visits it.

Be clear about what this is. Email-only is a use case, not an investment strategy. It fits a brand that has not launched, a personal domain you intend to keep for life, and an acquired variant that redirects to your main site while its mail lands in your main inbox. It does not fit speculative inventory, where a mailbox subscription adds cost and live mail adds friction to the eventual sale.

The four records, defined

Four DNS records do all the work. Three of them exist to prove that mail claiming to come from your domain really does.

MX (Mail Exchanger) — a DNS record telling the rest of the internet which mail servers accept mail for your domain, and in what priority order. Without at least one MX record, mail either fails or, under legacy fallback rules, gets attempted against the domain's A record. This is the only record strictly required to receive mail (reference).

SPF (Sender Policy Framework) — a TXT record listing which servers are authorised to send mail claiming to be from your domain; receivers check the sending IP against that list. Published as a single TXT record beginning v=spf1, specified in RFC 7208.

DKIM (DomainKeys Identified Mail) — a cryptographic signature your provider adds to outgoing headers, verified against a public key you publish at selector._domainkey.yourdomain.com. It proves the message was not altered in transit and came from an authorised sender (RFC 6376).

DMARC (Domain-based Message Authentication, Reporting and Conformance) — a TXT record at _dmarc.yourdomain.com telling receivers what to do when a message fails both SPF and DKIM alignment: p=none to monitor, p=quarantine to send to spam, p=reject to refuse outright. It also sets where aggregate reports go (RFC 7489).

A fifth record is worth knowing even though an email-only domain must not use it. Null MX (RFC 7505) is a single MX record with priority 0 and a target of . — it declares that a domain accepts no mail, so senders fail fast rather than retrying for days. That is for the names you are not using for mail.

Setting it up, in order

The sequence matters, because doing it out of order is how people lose mail.

1. Choose a provider and add the domain to it.
2. Publish the provider's MX records at whichever DNS host is authoritative — registrar DNS, Cloudflare, Route 53.
3. Publish the provider's SPF TXT record. One per domain — if you already have one, merge the includes rather than adding a second.
4. Publish the provider's DKIM public key or keys at the selector they specify.
5. Publish a DMARC record at p=none with a reporting address. Read the aggregate reports until every legitimate sender passes cleanly, then tighten to p=quarantine, then p=reject.
6. Optionally add a web record — an A or CNAME to a holding page, or a 301 redirect. Mail works without it.

One warning on step 6: some registrars offer a one-click "forward this domain" feature that rewrites the DNS zone wholesale, MX records included. Check that whatever redirect you use leaves mail routing alone.

What it costs in 2026

Mailbox pricing is per user almost everywhere, which is what makes the one exception interesting.

• Google Workspace — Business Starter at $8.40 per user per month billed monthly or $7 annual (30 GB), Business Standard at $16.80 or $14 (2 TB), Business Plus at $26.40 or $22 (5 TB). Google renders prices client-side, so the dollar figures come from EmailToolTester's 2026 breakdown; the storage tiers are confirmed on Google's page.
• Microsoft 365 — Business Basic moving from $6 to $7 per user per month and Business Standard from $12.50 to $14, both effective 1 July 2026, as published by a Microsoft partner.
• Fastmail — Standard at $5 per user per month annually is the entry point for custom-domain email. Fastmail's own plan page indicates the cheaper Basic tier does not support custom domains.
• Zoho Mail — the Forever Free plan covers five users with 5 GB each on one custom domain, with two binding limits: no IMAP, POP or ActiveSync, and selected data centres only. Mail Lite adds those protocols at around $1 per user per month, Mail Premium around $4, per G2's listing.
• Migadu — Micro at $19 per year, and this one changes the arithmetic: Migadu bills flat per account, not per mailbox, with "unlimited mailboxes and addresses" per account. For an email-only domain with a handful of addresses, that is less per year than many .com renewals.

Free options have a place. Registrar-level forwarding — Cloudflare Email Routing, Porkbun, Namecheap — gives you receiving for nothing. What it does not give you is sending: replies come from your Gmail address unless you configure send-as, and forwarding can break SPF and DKIM alignment on relayed messages. Fine for a placeholder, not fine for a brand you intend to launch, because you will migrate later and mail migrations are painful.

Deliverability: what is documented and what is not

Three separate problems get conflated in most writing on this. Keep them apart.

New-domain reputation. Receiving systems assign reputation to sending domains and IP addresses. A domain with no sending history is unknown, and unknown skews toward suspicion: a brand-new domain suddenly emitting volume is exactly what a throwaway spam domain looks like. The standard mitigation is domain warm-up: start with low volume to engaged recipients and ramp gradually (warm-up guidance).

Missing or broken authentication. Without correct SPF, DKIM and DMARC, your mail fails alignment checks at the major receivers and is far more likely to be filtered. This is the part entirely within your control.

The "no website" claim. You will read repeatedly that having no website hurts inbox placement. No major mailbox provider publishes anything of the sort. What is documented as driving reputation is authentication, sending history, recipient engagement and complaint rates (Postmark's guide). Put up a one-page site anyway — it helps human recipients confirm you are real — but do it for that reason, not for a filtering penalty nobody has demonstrated.

On policy, there is a documented pattern worth copying. M3AAWG's Parked Domains Best Common Practices sets out the anti-spoofing configuration for domains that do not send mail: an SPF record authorising nothing (v=spf1 -all), DMARC at p=reject, and a null MX where the domain will not receive mail either. The distinction matters here: you are receiving, so you need real MX records and must not publish a null MX. But if the domain never sends, publish SPF -all and DMARC p=reject anyway, and apply the full parked-domain pattern to every other name you own.

Buying a domain that already has a past

A domain bought on the aftermarket or caught from the drop may carry history you did not create: an entry on a domain blocklist, poor reputation at the major receivers, or a Google manual action predating your purchase.

Run these checks before you commit the domain to email:

• Query the major blocklists and domain blocklists for the name.
• Check the Wayback Machine for what the domain used to host.
• Verify the domain in Google Search Console and look for manual actions.
• Once you have sending volume, watch reputation tooling such as Google Postmaster Tools.

Recovering a burned domain is slow and sometimes impossible. If the history looks bad and email is the primary use case, a different domain is almost always cheaper than remediation.

What it does to resale value and to a future handover

Running email on a domain has no effect on its intrinsic resale value. Buyers pay for the string and the extension. Use does not make a name more valuable.

There is a small positive on inbound inquiries if you also publish a holding page or a redirect, because the domain resolves and a curious buyer sees something. There is a clear negative on transaction speed: a domain carrying live mail is painful to hand over. You must migrate mailboxes, warn correspondents, and accept that anything sent to the old addresses lands with the buyer. Build a transition window into any such sale.

The sharper risk is a described account-takeover vector. Sell a domain that has been receiving your mail and the new owner can publish a catch-all MX record, then receive password resets, invoices and confidential correspondence addressed to your old mailboxes. Migrate every account, service and vendor off the domain before transfer.

When this is right, and when it is a bad idea

Email-only is right when:

• You have bought a domain for a brand that has not launched and want the professional address working from day one.
• It is a personal domain — firstname@lastname.com — where you want a durable address you control and never intend to build a site.
• You want a redirect plus email combination: the domain 301-redirects to your main site while its mail lands in your main inbox — the sensible default for acquired brand variants and misspellings.
• You are preserving continuity on a shut-down business so old correspondence still reaches someone.

It is the wrong call when:

• The domain has a spam or abuse history. Do not build your professional identity on a burned asset.
• You are treating email as a substitute for a business presence. Recipients who look you up and find nothing are not reassured, whatever the spam filters think.
• It is speculative investment inventory. Paying for a mailbox on a name you intend to flip adds cost and adds friction to the sale. Put a for-sale lander on it instead.
• You are planning cold outreach from a brand-new domain with no warm-up. That is the fastest way to burn a domain's sending reputation permanently.

Common mistakes

1. Publishing two SPF records. Only one v=spf1 TXT record is valid per domain; a second causes a permanent error and can fail every SPF check. Merge the includes.
2. Skipping DMARC entirely, which leaves the domain freely spoofable by anyone who wants to impersonate you.
3. Jumping straight to p=reject without reading aggregate reports at p=none first, which silently kills legitimate mail from systems you forgot about: billing, CRM, form handlers.
4. Forgetting DKIM key rotation, or leaving a stale selector after switching providers.
5. Deleting the old provider's MX records before the new one is verified, opening a gap in which mail simply bounces.
6. Using registrar forwarding as a business mailbox, then discovering you cannot send from the address.
7. Cold-emailing from a brand-new domain with no warm-up period.
8. Transferring the domain without migrating accounts off it first.
9. Leaving your non-mail domains unprotected — no null MX, no SPF -all, no DMARC p=reject — so the rest of your portfolio stays spoofable.

Frequently asked questions