Field note · 11 min read
How to Buy an Email Domain Without Buying a Seat You Don't Need
Buying the domain is the easy half. This walks through the registrar decision, the DNS records that make mail work, and how to pick hosting priced per domain rather than per seat — with the arithmetic shown.
To learn how to buy an email domain without overpaying, treat the process as two distinct purchases: register the domain name at an independent registrar, then connect it to a mail host that bills per domain instead of charging for unused employee seats. If you operate three or four separate business entities by yourself, buying per-user seats from Google Workspace or Microsoft 365 forces you to pay for extra humans that do not exist.
Two purchases solve this problem. When you know how to buy an email domain the right way, you keep your domain registration independent, control your DNS zone directly, and avoid paying monthly seat charges across every new brand or LLC you register. This guide walks through the exact registration sequence, the DNS records required to keep messages out of the spam folder, and the economics of running multiple domains under one operator account in 2026.
The short answer: two purchases, not one
A domain name and an email mailbox are completely separate technologies sold by separate systems. When you search for how to buy an email domain, registrars often blur this distinction to cross-sell bundled packages at checkout. In technical terms, the purchase divides into two layers:
- Domain registration reserves your chosen character string with an ICANN-accredited registrar, giving you administrative ownership and control of the zone file.
- Email hosting provides the mail transfer agent infrastructure, server disk storage, and web interfaces that process incoming and outgoing messages.
The registrar controls where traffic goes by hosting your DNS zone file. The mail host handles delivery, cryptographic signing, and mailbox storage. You can purchase both services from a single vendor, or you can register the name at one company and point its records to another. Separating these two purchases protects your infrastructure.
Buy the domain name first. Verify access to the DNS editor, and then select your email hosting service. When buyers reverse this order by signing up for email hosting first, they frequently end up with domains locked inside restrictive proprietary site builders where basic DNS edits require support tickets.
A standard .com registration costs an annual fee. Email hosting adds a separate recurring cost. If you manage multiple brands, paying that hosting fee per user seat creates compounding expenses that do not match the needs of a single operator.
Step 1: register the name at a registrar you can leave
When you register a domain, technical control is your primary objective. Marketing homepages often highlight steep discounts on the first year of registration. A domain that costs a small promotional fee for year one often renews at three or four times that amount. Before you enter payment details, locate the registrar's published renewal price sheet. The renewal price is the operational expense you will carry for the life of that entity.
Look for three operational criteria when selecting a registrar:
- Select a registrar with direct zone management so you can add individual MX, TXT, CNAME, and A records without upgrading to higher subscription tiers.
- Confirm Domain Connect support so compatible mail providers can publish your mail routing and cryptographic records automatically through an authenticated handshake.
- Verify standard transfer policies that permit moving your domain to another registrar using an authorization code once the ICANN 60-day transfer lock expires.
Registrars enforce a standard 60-day lock on registered domains under the ICANN Transfer Policy. Beyond that initial window, transferring your domain to an alternate registrar requires only an authorization code and an unlocked status in your dashboard. Avoid services that impose manual review delays or offboarding fees.
For founders managing multiple corporate entities, organization at the registrar level prevents identity confusion later. Register each domain under the legal entity that operates it, or maintain an internal registry record tracking which corporate card and login identity owns which asset. Mixing personal and business registrations under unmonitored accounts creates administrative debt when an entity is sold, audited, or dissolved.
Step 2: decide whether email hosting comes included
When shopping for domain registration, you will frequently see offers to buy domain name with email as a packaged bundle. Registrar checkouts regularly present promotional banners claiming email hosting included at no extra charge. Before accepting these packages, check the underlying specifications.
When a registrar states that email hosting is included, it typically refers to one of two mechanisms:
- Simple alias forwarding redirects inbound mail to an external personal inbox, but sending outbound replies from that external account breaks SPF and DKIM authentication against your domain.
- Promotional mailboxes often impose storage limits or share outbound mail IP addresses with other senders.
When you reply from your personal inbox using an alias, outgoing messages fail authentication against your custom domain because the receiving server detects that the email originated from consumer webmail infrastructure instead of an authorized mail gateway. That mismatch routes messages to spam.
The operational trap of bundled mailboxes is account fragmentation. If you run four business lines and use the bundled mailbox from your registrar for each, you end up with four disparate logins, four isolated address books, and zero consolidated search capabilities. You spend your workday logging in and out of different webmail windows.
If you need reliable deliverability and professional sender identity across several entities, purchase standalone email hosting that provisions separate DKIM keys, distinct outbound signatures, and modern SPF records for each custom domain you operate.
Step 3: publish the records that make mail work
Configuring email on a custom domain requires publishing four core DNS records. Each record handles a distinct phase of routing, sender authorization, and cryptographic verification.
Mail exchanger record
The MX record tells the internet which mail servers accept inbound messages for your domain. An MX entry points to a hostname (such as mail.example.com), not an IP address, and carries a numerical priority value. Lower numbers represent higher priority. When a remote server attempts to deliver an email to your domain, it queries your DNS zone for the MX record to find the receiving mail gateway.
Sender policy framework record
Published as a DNS TXT record at your domain's apex as specified in IETF RFC 7208, SPF lists the authorized IP addresses and third-party mail systems permitted to send messages using your domain in the Return-Path address. Remote mail servers inspect this record during the SMTP handshake to determine if the sending server is legitimate.
A classic syntax mistake is publishing multiple SPF records. The SPF standard allows only one valid SPF TXT record per domain. If your DNS contains two separate records starting with v=spf1, receiving servers encounter a PermError and will drop your messages or flag them as spam. If you use both a transactional mail service and a primary mailbox provider, combine them into a single TXT entry:
v=spf1 include:_spf.folioinbox.com include:sendgrid.net ~allDomainKeys identified mail record
DKIM provides cryptographic proof that an email was legitimately transmitted by the domain owner and that message contents were not modified in transit. Your mail server generates a private key that signs outgoing headers and a public key that you publish to your DNS zone as a TXT record under a specific selector subdomain, such as selector1._domainkey.yourbrand.com.
Formatting errors are common here. DKIM public keys are lengthy cryptographic strings. If you paste the key with an accidental trailing space, a newline character, or missing quotes, the DNS entry will fail public key decryption tests. The entry will appear to exist in your registrar's dashboard, but every outgoing message will fail DKIM verification at the recipient server.
Domain-based message authentication
DMARC ties SPF and DKIM together. It tells receiving mail servers what policy to enforce if an incoming email claiming to come from your domain fails both SPF and DKIM checks. In accordance with the underscore node naming rules outlined in IETF RFC 8553, your DMARC policy is published as a TXT record specifically at the _dmarc label (e.g., _dmarc.yourbrand.com).
Start in monitor mode. When deploying a new domain, do not start with a strict rejection policy so you can observe legitimate mail flows without dropping customer correspondence:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourbrand.comOnce you verify that your legitimate systems pass DKIM and SPF alignment, you can tighten your policy tag from p=none to p=quarantine or p=reject.
Transport security and reporting
Once your primary records are active, you can deploy modern transit encryption safeguards. As defined in IETF RFC 8461, SMTP MTA Strict Transport Security (MTA-STS) allows a domain to declare that sending mail transfer agents must use TLS encryption with valid public certificates when delivering inbound mail. Paired with TLS Reporting (TLS-RPT), MTA-STS protects your business communications against downgrade and adversary-in-the-middle attacks on the open internet.
DNS changes take time. Propagation takes anywhere from a few minutes to several hours depending on the Time to Live (TTL) values assigned to existing records. You can inspect your records without setting up an account using the free domain health check, which validates your live SPF, DKIM, DMARC, and MTA-STS records with no email address required to view the report.
Step 4: choose hosting priced per domain, not per seat
The standard software billing model charges per user seat. If you run an organization with ten employees using email, paying monthly per-user fees matches your headcount. But if you are a solo operator running five brands, an LLC, a consulting entity, and two digital stores, per-seat pricing turns against you.
A standard per-user productivity suite charges every account as if it were a separate person. Running five distinct business domains with dedicated accounts forces you to buy separate user licenses every month, multiplying your annual software overhead even though only one person writes the emails.
Aliases hide real problems. Attaching secondary domains as aliases to a single seat consolidates billing, but it introduces deliverability and branding flaws:
- Secondary domain aliases often share the primary domain's DKIM identity or route through generic outbound gateways, which causes recipient clients to display security warnings.
- Unified signature management breaks down, forcing you to swap signature footers manually every time you switch sending identities.
- An authentication failure or delivery complaint against one brand damages the sender reputation of every other domain linked to that root account.
If you genuinely require an integrated office platform with collaborative spreadsheets, shared cloud file drives, and video conferencing rooms, a per-seat productivity suite is the correct purchase. However, if your business operations require standalone, authenticated email identities for your commercial entities, you should choose a provider that charges per domain instead of per user.
Several providers focus on multi-domain architecture for individual operators, including Migadu, Purelymail, Zoho Mail, Fastmail, and Forward Email. These services vary in how they structure domain limits, storage pools, and sending volume. Below is an architectural overview comparing modern multi-domain email hosting models against FolioInbox.
| Provider / Architecture | Billing Structure | Target Use Case | DKIM Architecture |
|---|---|---|---|
| FolioInbox | Flat plan fee per domain tier: Solo ($2.99/mo annually or $3.50/mo), Studio ($12/mo annually or $15/mo), Holding Co. ($29/mo annually or $39/mo) | Solo operators managing 2 to 10+ distinct brands from a single interface | Separate 2048-bit DKIM key and distinct custom signature isolated per domain |
| Google Workspace / Microsoft 365 | Per-user seat billing; secondary domains handled primarily as account aliases | Corporate teams requiring synchronized office documents, video calls, and group permissions | Requires complex alias configuration or separate paid seats for full cryptographic isolation |
| Migadu | Storage and system resource consumption model | Technical administrators wanting custom mailbox allocations across multiple owned domains | Per-domain DNS configuration with dedicated server signing keys |
| Purelymail | Resource-usage billing based on raw data transfer and combined storage volumes | Cost-sensitive self-service users with variable sending loads | Standard multi-domain DNS setup with manual TXT key management |
| Fastmail | Per-user account tiers with native multi-domain mapping capabilities | Individual power users seeking independent calendar, contact, and email sync | Automated or manual DNS records covering secondary domain domains |
Before purchasing any email hosting service, review its capability constraints. FolioInbox is designed specifically for single-operator portfolio management, which means its capabilities reflect distinct boundaries:
- Folio has no shared or team inboxes, message assignment, or internal notes. Solo, Studio, and Holding Co. are built strictly for a single operator.
- 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 proprietary, hosted service; its source code is not public. Folio is a fully hosted service and cannot be self-hosted or run on your own servers or infrastructure.
- Folio has no free plan. New accounts get a 14-day evaluation: 100 sends on one domain, 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.
Frequently asked questions
Can I buy a domain name from one company and email hosting from another?
Yes. Domain registration and email hosting are independent services. You register your domain name at any ICANN-accredited registrar, access the registrar's DNS management console, and point your MX, SPF, DKIM, and DMARC records to your email host. This split keeps administrative control of your domain independent of your mail server provider.
What happens when a registrar includes free email hosting?
Free email offered at registrar checkout is usually simple forwarding or a restrictive promotional mailbox. Forwarding sends incoming mail to a personal inbox, but replies sent from that inbox lack valid DKIM and SPF records for your custom domain, causing them to land in spam.
Why should a solo founder avoid per-seat email suites?
Per-seat suites bill on headcount. If you run three LLCs, a personal brand, and a retail store, a per-user provider charges you for five separate accounts every month, multiplying your software expense even though only one person writes messages. A host that charges flat rates per domain eliminates this overhead.
How long does DNS propagation take after publishing email records?
DNS propagation typically completes within a few minutes to several hours. The exact time depends on the Time to Live (TTL) values set on your existing records. Lowering your TTL to 300 seconds before making changes reduces propagation delays when moving to a new email service.
Do secondary domain aliases share sender reputation?
Yes. When you map secondary domains as aliases under a single mailbox in a standard suite, outgoing messages often pass through the same generic signing gateway. An authentication failure, high spam rate, or blacklist entry affecting one entity can degrade the delivery rate of every other domain connected to that account.
§ Related guides
- Best email hosting for multiple websites Compare pricing, domain limits, authentication, and inbox workflow for several websites.
- Stop email spoofing How Folio files unverifiable senders before they reach the inbox.
- DMARC reports across every domain See failing sources, pass rates, and when to tighten policy.
- Free email domain health check Check MX, SPF, DKIM, and DMARC before changing providers.
§ Sources & further reading
§ Google Search
Make Folio a preferred source.
If you read Folio often, add it as a preferred source. Google can then mark our writing as preferred in Top Stories, AI Overviews, and AI Mode for you.
Change or remove it any time in Google’s source preferences.