Field note · 11 min read
Per-User vs. Per-Domain Email Pricing: Why Solo Operators Overpay
Per-user seats and per-domain plans solve different problems. Here is how each model bills, and why a solo operator running several domains often pays less on a flat per-domain plan.
If you own several domains, a per-domain email plan is almost often cheaper than a per-seat plan. When business email pricing models explained plainly are set side by side, seat-based providers bill for each human user, while per-domain providers bill for the domains or mailbox pools you actually route. If you are a single operator running two, five, or ten commercial entities, paying for seats forces you to buy separate human licenses for entities that only you manage.
Consider five domains. On a standard per-seat suite, you pay recurring subscription fees for every billable user. Seats multiply costs. If each domain requires its own standalone mailbox identity, your total expense multiplies across every commercial entity you operate. On a flat plan designed for multiple entities, you pay a predictable fee structured around your domain count instead of individual headcount. The trade-off is direct: per-domain plans drop team collaboration tools, file-sharing suites, and shared calendars. If you work alone, you are paying for those tools without using them.
How the two business email pricing models actually work
The email industry relies on two primary monetization architectures. Each model solves an entirely different operational problem.
The per-user model charges for each billable seat. Each seat receives its own login credentials, dedicated storage allotment, and personal calendar. If you run multiple entities, this architecture offers two paths. You can purchase a separate paid seat for every domain, or you can attach secondary domains as aliases to a single primary seat. An alias sends and receives under an alternate address, but it shares the underlying primary user identity. When you attach secondary domains as simple aliases inside legacy suites, outbound messages frequently default to the primary domain's signing identity. That setup exposes your parent entity or breaks your cryptographic alignment.
The per-domain model charges a flat rate for a set number of domains or a shared mailbox pool. Instead of metering individual people, the system meters domains, overall storage, or message throughput. Each custom domain maintains its own distinct cryptographic keys and signatures. One inbox holds everything. A single operator checks one inbox to view incoming mail across all brands while sending replies that reflect the exact domain of the recipient's inquiry.
Solo operators often survive on a third, fragmented path. They stitch together Gmail send-as aliases with low-cost mail relays or alternate mailboxes on services like Migadu, Purelymail, Zoho Mail, and Fastmail. While this approach keeps software subscriptions low, it splits billing across multiple providers, duplicates DNS configuration panels, and makes message authentication difficult to maintain.
To choose an approach, consider how email providers define basic terms on their pricing pages:
- Seat: A single human user account with its own billing charge and sign-in credentials.
- Mailbox: A storage container that holds incoming and outgoing messages.
- Alias: An alternate routing address that delivers mail into an existing mailbox without generating a separate login.
- Domain: A distinct DNS root requiring dedicated mail records.
- Send cap: A monthly or daily limit on outbound messages enforced to protect provider deliverability.
- Storage tier: A metered gigabyte quota that limits accumulated attachments and message archives.
Vendors use storage tiers and collaboration suites to justify recurring per-seat fees. If nobody else works at your company, team chat and shared drive allowances add complexity without delivering value.
Per-user vs per-domain email cost: the arithmetic at 2, 5 and 12 domains
When you evaluate per-user vs per-domain email cost, the financial difference grows as you register more businesses, side projects, or client stores.
The following table illustrates the structural cost difference between standard seat-based models and FolioInbox flat per-domain plans for a single operator.
| Domains Managed | FolioInbox (Per-Domain Model) | Per-Seat Model Approach |
|---|---|---|
| 2 Domains | Folio Solo: $2.99/mo ($35.88/yr billed annually) or $3.50 monthly | Standard office suites charge per human license for each independent inbox identity. |
| 5 Domains | Folio Studio: $12/mo ($144/yr billed annually) or $15 monthly | Requires purchasing five separate user seats or resorting to shared alias routing. |
| 12 Domains | Folio Holding Co.: flat annual or monthly subscription tier | Requires twelve distinct user seats to maintain isolated sender identities. |
At 2 domains, the math is relatively close. If you manage a consulting LLC and an exploratory side project, paying for two separate seats on an office platform creates an ongoing recurring bill. Many operators keep their existing suite at that stage because migrating DNS records feels unnecessary for a modest price difference.
At 5 domains, the per-domain plan pulls ahead. An operator running five stores or brands needs five standalone sending identities. Under seat-based billing, maintaining independent mailboxes requires buying separate human licenses for entities only you operate. In comparison, a dedicated flat plan covers up to ten domains under a single predictable subscription. The cumulative annual savings grow as your portfolio expands.
At 12 domains, seat-based billing fails single operators. Squeezing twelve entities into one seat creates delivery failures, mixed customer threads, and accidental replies sent from the wrong brand. Under Folio Holding Co., an operator manages unlimited domains with a monthly cap of 30,000 sends on a single flat subscription.
The hidden line items in seat-based plans add further friction. Upgrading an inbox's capacity often forces you into an enterprise tier across all seats. Providers also cap the number of secondary domain aliases an individual seat can attach. When aliases fail, misaligned email headers harm your domain's reputation with downstream mail filters.
What the cheap paths actually cost you: aliases, shared seats and stitched hosts
Many portfolio founders try to avoid per-seat fees by hacking together low-cost workarounds. These methods reduce upfront expenses, but they create technical weaknesses in your email delivery chain. Aliases break easily.
The most common shortcut uses Gmail's "Send mail as" feature. An operator forwards inbound messages from a registrar to a personal consumer inbox, then configures an external SMTP connection to send replies. Because outbound messages route through intermediate mail servers, maintaining strict authentication is difficult. The technical specifics of these routing failures are documented in our review of anti-spoofing controls and header authentication.
Running secondary domains as simple aliases under a single Google Workspace seat causes a similar identity problem. Mail sent via an alias often preserves the primary account holder's name or domain in the raw message headers. Savvy clients or vendors who inspect email headers can see the parent domain name. Additionally, changes to user settings or signature templates apply universally, making it easy to send an e-commerce customer support reply with your executive consulting signature.
A third workaround involves combining several niche hosts. You might host three domains on Migadu, two on Purelymail, and one on Fastmail. Each service is individually capable, but managing three providers leaves you with three renewals, three billing systems, and three DNS panels. A single expired credit card can quietly take an entire business offline.
These configuration issues ultimately break DMARC alignment, defined under RFC 7489. DMARC evaluates whether the domain shown in the visible "From" header matches the domain authenticated by SPF and DKIM. If an alias routes a message through an unaligned server, the SPF check fails. If your signing key does not match the sender header, the DKIM check fails. When both checks fail, major mailbox providers send your message to the spam folder or reject it outright, as outlined in the Google Email Sender Guidelines.
The criteria that actually matter when you compare email hosting for solopreneurs
Evaluating email hosting for solopreneurs requires looking beyond the features pitched to enterprise procurement teams. If you run your companies alone, prioritize technical independence and maintenance overhead.
- Cost per domain: The subscription should scale with your entities, not your headcount. Flat per-domain pricing ensures a new project does not trigger a permanent seat charge.
- Independent DKIM signing: Every single domain must have its own isolated DKIM key and custom signature. Downstream mail servers inspect these cryptographic signatures to confirm authenticity.
- Predictable send caps: Single operators do not send cold mass blasts from their primary accounts, but they need enough transactional volume for day-to-day operations. Look for clearly defined limits, such as FolioInbox's monthly caps of 1,000 sends on Solo, 6,000 on Studio, or 30,000 on Holding Co. Attachments are subject to size limits per message, with overall storage included across all plans.
- Fast DNS onboarding: Entering MX, SPF, DKIM, and DMARC strings manually for ten domains takes hours. FolioInbox streamlines this with a single-screen setup that uses Domain Connect to publish DNS records automatically at supported registrars.
- Transparent evaluations: 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.
- Sign-in security: Managing a dozen passwords for a dozen accounts creates vulnerabilities. FolioInbox uses passkeys or magic links for account access, eliminating passwords entirely.
Legacy vendors emphasize gigabyte storage pools, shared calendars, and real-time document editing. These features are valuable for corporate teams, but solo operators rarely use them for commercial correspondence.
Where per-seat pricing is still the right answer
Per-domain email hosting is not the ideal solution for every operational model. Seat-based pricing remains the better choice in several distinct scenarios:
If you actively use an integrated productivity suite, paying for a per-seat license makes operational sense. If your business depends on Google Docs, shared Drive folders, Sheets integrations, and Google Meet for your daily routine, paying for that workspace seat covers both your email and your office software.
If you operate exactly one business on one domain, the financial advantage of a per-domain plan is minimal. Shifting your DNS records and moving your archive to save two or three dollars a month may not justify the effort.
If your legal or regulatory obligations require zero-knowledge or end-to-end encryption, you need a specialized provider. 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. Providers like Proton Mail build their architecture entirely around client-side private keys. If you handle sensitive health or financial data that mandates end-to-end encryption, select a host designed specifically for that standard.
Finally, if you manage staff who need to collaborate on customer inquiries, a single-operator inbox will not work. Folio has no shared or team inboxes, message assignment or internal notes. Solo has no seats. The platform is designed strictly for an individual operator managing multiple business entities from one login. If your business requires shared conversation queues, collision detection, and internal discussion threads among multiple employees, choose a per-seat collaborative platform. That path is real, and if it works for you, take it.
What breaks during the move, and how to sequence it
Migrating domains between email providers often causes temporary deliverability problems if records are updated in the wrong sequence. Follow this technical progression to avoid dropping messages:
First, lower your DNS Time to Live (TTL). At least 24 hours before updating your mail records, log into your registrar or DNS host and drop the TTL values on existing MX, TXT, and CNAME records to 300 seconds (5 minutes). This ensures downstream mail servers fetch your new routing information quickly once you make the switch.
Second, publish your new DKIM records before touching your MX records. Add the new TXT or CNAME selector provided by your incoming mail platform while the old host is still receiving mail. This prevents outbound messages from failing cryptographic validation during the migration window.
Third, adjust your SPF record carefully. A domain must never have more than one SPF TXT record. If you publish two records simultaneously, recipient mail servers will invalidate both and reject your mail. Do not create a second record. Edit your existing TXT entry to include the new provider's mechanism. Keep the old provider's include mechanism active during the switch so outgoing messages authenticate regardless of which server sends them. Also verify that your record does not exceed the limit of 10 DNS lookups specified by RFC 7208 Section 4.6.4.
Fourth, update your primary MX records. Point your MX records to your new host. Keep your old host active for another 48 hours to collect any straggling messages sent by remote servers that cached your old TTL settings.
Fifth, configure your DMARC policy. If you do not have an existing policy, set your record to v=DMARC1; p=none; to receive aggregate reports without blocking mail. Once your authentication reports verify that both SPF and DKIM pass across all sending sources, update your policy to p=quarantine or p=reject.
Finally, review your transport layer settings. If your domain previously published an MTA-STS policy under RFC 8461, ensure the new email platform maintains a valid inbound TLS configuration to avoid delivery rejections. Our guide to inbound TLS configuration covers the required record formats in detail.
This technical sequence is critical for operators facing firm migration deadlines. For instance, an operator moving five domains off AWS WorkMail before an end-of-support cutover must sequence DNS updates so that neither inbound mail nor automated transactional receipts bounce during the transition window.
Frequently asked questions
What is the difference between per-user and per-domain email pricing?
Per-user pricing charges a recurring subscription fee for each human team member or mailbox seat. Per-domain pricing charges a flat fee based on the number of domains managed, regardless of how many aliases or separate brands you run from that single operator account.
Can I use email aliases instead of paying for extra domains?
You can create aliases, but simple alias routing often breaks DKIM cryptographic alignment or exposes your primary company address in message headers. Outbound replies sent from aliases on standard office suites frequently use the primary domain signature, which confuses recipients and damages email deliverability.
Do per-domain email services support team collaboration?
No. Per-domain services are designed for single operators managing multiple entities. Folio has no shared or team inboxes, message assignment or internal notes. If your company employs staff who need shared customer support queues, ticket assignment, or internal comments, a per-user suite is the right tool.
How does Folio handle DKIM signing across multiple brands?
Folio generates independent DKIM keys and distinct signatures for each connected domain. Every outbound email is signed directly by the domain shown in the "From" line, preserving strict DMARC alignment across all your projects.
What happens during DNS migration if I switch providers?
During migration, you lower your DNS TTL values to five minutes, publish new DKIM records, update SPF TXT strings to include both services, and switch your MX records. Keeping the old mailbox active for 48 hours ensures no messages are dropped while external resolvers update their caches.
§ 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.