What a free consumer address costs you
Nobody has ever lost a job because their email address ended in gmail.com. That is the honest version. What happens instead is quieter and harder to measure: a slightly higher rate of second opinions, a slightly lower rate of replies, and a slow accumulation of small operational problems that only becomes obvious when you try to hand something over to somebody else.
Three separate things are going wrong at once, and it helps to see them as three rather than as one vague credibility issue.
A quote for a large job arriving from a free address invites a second opinion the same quote from your own domain does not.
Costs you close rateA free account belongs to the person who created it. When they leave, the business loses years of correspondence.
Costs you continuityNo billing address, no support address, no address for a new hire, without opening another account nobody checks.
Costs you structureThe control problem is the one that actually bites. A free consumer account is registered to a person, secured by that person's phone number, and recoverable only by that person. If a partner leaves, if an office manager moves on, if somebody loses the phone that had the two factor codes on it, the business is locked out of its own correspondence with no mechanism for getting back in. There is no administrator to call because there is no administrator. This is the same argument as keeping ownership of your domain and hosting accounts, applied to the one asset that holds every conversation you have ever had with a customer.
There is also a search and trust angle worth a sentence. Your email address appears on your Google Business Profile, on directory listings, on invoices, on vehicle wraps, and in every quote you send. Consistency across those places is part of how a local business establishes it is a real, findable operation, which is a theme running all the way through local SEO and your Google Business Profile. An address on your own domain reinforces the same name every time it appears. A free address just points at a platform.
Your options and what they actually cost
There are four realistic routes, and the right one depends on how many mailboxes you need and whether you also want documents, calendars, and shared drives. Prices below are typical published rates as of 2026 on annual commitments, and they move, so treat them as ranges rather than quotes.
| Option | Typical cost | Best for | The catch |
|---|---|---|---|
| Google Workspace | ~$7 to $22 per user per month | Teams already living in Gmail, Docs, and Drive | Per user pricing adds up as you hire |
| Microsoft 365 Business | ~$6 to $13 per user per month | Anyone who needs desktop Office apps anyway | Admin console is deep and not always friendly |
| Independent mail hosts | Free to ~$8 per user per month | Small teams that only need mail done well | Weaker document and calendar integration |
| Mailboxes bundled with web hosting | Usually included | Very small operations on a tight budget | Weakest on reliability, spam filtering, and search |
Google Workspace and Microsoft 365 are the default answers for a reason. Both handle authentication setup with a guided wizard, both have real administrator controls so you can reset a departing employee's password and read their mailbox, both have solid migration tooling, and both have spam filtering good enough that you stop thinking about it. Between them, pick on the rest of the suite rather than the mail: if your team is already in Excel and Teams, Microsoft; if they are already in Docs and Meet, Google.
Independent providers such as Zoho, Fastmail, and Proton are legitimate options that small businesses overlook. Zoho has a genuinely free tier for a small number of users on a single domain, which is a real answer for a two person operation. Fastmail and Proton sit around five to eight dollars per user and do mail well without pretending to be an office suite. The tradeoff is integration: if you later need shared calendars and documents, you will be assembling that from separate tools.
The number that matters
Cost is per mailbox, not per address. Aliases are free on essentially every mainstream provider, so a two person business with fourteen addresses pays for two mailboxes. A lot of owners overestimate this cost by a factor of five because they count addresses. Budget roughly one hundred and fifty to four hundred dollars a year for a small team and treat it as infrastructure, not a subscription to trim.
The one option to be careful with is mailboxes bundled free with cheap shared web hosting. They work, right up until they do not. Shared hosting mail servers get onto blocklists because of what other customers on the same server are sending, storage quotas are small, search across a large mailbox is slow or absent, and there is rarely a real administrator layer. It also welds your email to your web host, which is exactly the problem the next section is about. If cost is the binding constraint, a free tier at a real mail provider beats bundled hosting mail on every axis. There is more on what hosting should and should not be responsible for in the hosting cost guide.
Email and your website are separate systems
This is the single most useful thing to understand, and almost nobody explains it. Your website and your email are two different services that happen to share a domain name. They do not need to live at the same company, and in most cases they should not.
Your domain name has a settings file attached to it, held wherever you registered the domain. That file is a set of signposts. One type of signpost tells web browsers which server to load your pages from. A completely different type tells mail servers where to deliver mail addressed to your domain. They are independent, and pointing one somewhere new does not affect the other.
In plain English
The public address book for your domain. It holds every signpost that tells the internet where each of your services lives.
The signpost that sends web visitors to the server holding your website.
The signpost that sends mail to your mail provider. Changing this is what actually moves your email.
A place to publish short public notes about your domain. All three email authentication records live here.
How long other servers are allowed to remember an answer before checking again. Lower it before a change so the change spreads fast.
Separating the two removes the most common reason a small business ends up stuck with a host it dislikes. When mail and website live at the same provider, changing web hosts means moving mailboxes at the same time, and the fear of losing email is what keeps people on hosting they outgrew four years ago. Split them and each move becomes a small, boring job that can be done on its own.
The arrangement worth aiming for is three separate relationships: your domain registrar holds the domain and the settings file, a real mail provider handles mailboxes, and a real web host runs the site. Nobody in that arrangement can hold the others hostage. Our managed hosting starts at $60/mo flat and deliberately does not include mailboxes, for exactly this reason: hosting your site and hosting your mail are different jobs and binding them together helps nobody but the provider.
Keep the registrar separate too
Register your domain somewhere neutral rather than through your web host or your designer's account. The domain is the thing that points at everything else, so whoever controls it controls your website, your email, and your ability to move either one. It should be in an account owned by the business, with the business's billing card on it.
SPF, DKIM, and DMARC in plain English
Email was designed in an era when nobody expected people to lie about who they were, so anyone can send a message claiming to come from your domain. Three add on records fixed that, badly named and universally required. Since February 2024, Google and Yahoo have required all three from bulk senders, and Microsoft applied comparable rules to Outlook.com in 2025. Below the bulk threshold they are not mandatory, but the same filters weigh them, so mail without them is meaningfully more likely to land in spam.
A public list of which servers are allowed to send mail using your domain name.
One record, max 10 lookupsA tamper-evident signature on every message, checkable against a key you publish.
2048-bit key recommendedTells receivers what to do when the other two fail, and asks them to report back.
Start at p=noneSPF is a note published in your domain's settings listing the servers permitted to send as you. When a receiving server gets a message claiming to be from your domain, it checks whether the sending server is on the list. There are two rules worth knowing. You may only have one SPF record for a domain, so if you add a second the whole thing fails rather than merging. And the record may trigger at most ten lookups when it is evaluated, which sounds generous until you add a mail provider, a newsletter tool, an invoicing service, and a booking system and quietly blow past it. Free checkers will tell you your lookup count in seconds.
DKIM attaches a cryptographic signature to each outgoing message. Your mail provider signs with a private key it holds, and publishes the matching public key in your domain settings so any receiver can verify the signature. It proves the message was genuinely sent by an authorised system and was not altered on the way. Your provider generates this for you. Your only job is pasting the record they give you into your domain settings and then confirming it in their console.
DMARC ties the first two together. It publishes a policy saying what a receiver should do with a message from your domain that fails both checks, and it asks receivers to send you reports about who is sending as you. The policy has three settings and the order matters enormously.
- p=none · monitor only, delivery unchanged
- p=quarantine · failures go to spam
- p=reject · failures are refused outright
Start at p=none. It changes nothing about delivery and simply turns on the reports. Read them for a few weeks and you will find every system that sends mail as you, including several you forgot about. Authorise the legitimate ones in SPF and DKIM, then move to p=quarantine and watch again. Only then move to p=reject. Going straight to reject before inventorying your senders is the classic way to silently kill your own invoice emails, and because rejected mail is refused rather than bounced back to you, you may not discover it for weeks.
Two related points. Correct authentication is also an anti fraud measure: with DMARC at reject, a scammer cannot send a convincing invoice that appears to come from your domain, which is the same class of problem covered in website security basics. And if you eventually want your logo displayed beside your messages in supporting mail clients, that requires DMARC at quarantine or reject first, so the work is not wasted.
Setting it up in the right order
Every horror story about lost email comes from doing these steps in the wrong sequence. Almost everything below can be done safely while your existing email keeps flowing normally. Only one step actually changes delivery, and it comes near the end.
-
Confirm you control the domain 30 min
Log into the registrar account and check the domain is registered to the business, with the business's billing card, an address someone monitors, and auto renew turned on. If you cannot log in, fix that before anything else. Nothing downstream works if you do not control the settings file.
-
Pick a provider and create the mailboxes 1 hour
Sign up, add your domain, and complete the ownership verification the provider asks for. This is usually a single record you publish in your domain settings, and it has no effect on delivery. Create one mailbox per person who needs to send mail. Do not create a mailbox for every address you want to receive at; those become aliases in a later step.
-
Publish SPF and DKIM before the cutover
Add your new provider to the SPF record and publish the DKIM key they give you. Both can coexist with your current setup, so publishing them early costs nothing and means authentication is already in place the moment mail starts flowing. If you already have an SPF record, edit it rather than adding a second one.
-
Import the old mail hours to days
Every serious provider has a migration tool that copies messages, folders, and often contacts and calendars across. Run it before the cutover so the new mailbox is already populated on day one. A large mailbox can take a day or more, which is another reason not to leave it until the switch.
-
Lower the TTL a day ahead 5 min
Drop the time to live on your MX records to a short interval, such as five minutes, at least a day before you switch. That tells other mail servers to stop caching the old answer for hours at a time, so when you flip the switch it takes effect in minutes rather than most of a day.
-
Change the MX records
This is the moment mail actually moves. Replace the existing MX entries with the ones your new provider specifies, exactly as given, including priority numbers. Send a test message from an outside account within a few minutes and confirm it arrives. Then set the TTL back to a normal value.
-
Publish DMARC at p=none
Add the DMARC record with the monitoring policy and a reporting address you will actually read. Then leave it alone for a few weeks while the reports accumulate. This is the step nearly everyone skips, and skipping it is why so many small businesses never tighten the policy.
-
Keep the old mailbox alive for a month
Do not cancel anything immediately. Some senders will keep the old routing cached, and some services still have the old address on file. Monitor the old mailbox for two to four weeks, forward anything that arrives, and only then shut it down. Wait for a full billing cycle with no traffic before deleting it.
If you are doing this alongside a new site, it belongs on the same run sheet as the redirects and the analytics, not in a follow up you never get to. The website launch checklist covers the rest of that sequence, and there is a useful rule buried in both: change one system at a time and confirm it works before touching the next.
Addresses, aliases, and who gets what
Once mail is flowing, the question becomes structure. The mistake here is not technical. It is building an address scheme around the people who work there today rather than around the jobs that need doing, which means every departure breaks something.
One per person who sends mail, in a consistent format. Pick firstname or firstname.lastname and never mix the two. Consistency is what makes an address guessable, and guessable addresses get used.
Addresses for jobs rather than people: info, billing, support, careers. They cost nothing, they can point at whoever currently does that job, and they survive staff changes without anyone updating a printed invoice.
When two or more people need to see and answer the same stream, use a proper shared mailbox rather than forwarding to several inboxes. Forwarding to three people means either three replies or none, and nobody can tell which happened.
Set up your mail client so replies to a role address go out from that address, not from the personal mailbox behind it. Otherwise a customer who wrote to billing gets a reply from a person's name and loses the thread.
When someone leaves, convert their mailbox to an alias pointing at whoever takes over rather than deleting it. Deleted addresses bounce, and bouncing a customer's email is a worse look than a slightly delayed reply.
Two structural choices worth deciding once. First, avoid a catch-all address, however appealing the safety net sounds. A catch-all accepts mail for every address at your domain including ones that have never existed, which is precisely what spammers rely on when they send to dictionary lists of common names. Explicit aliases give you the same coverage without the volume, and if you are worried about a common misspelling of your domain or a name, add a specific alias for that misspelling.
Second, decide where mail from your website goes before you build the site. A quote request, a booking confirmation, and a support question are three different streams that usually want three different destinations, and wiring them up is much easier at build time than afterwards. This is worth thinking about alongside how leads actually arrive from your website and, if you take appointments, alongside booking integration.
One privacy note. Every address you publish on your site becomes a record you are collecting mail into, and the retention of that mail is a real question under the state privacy laws. It is covered properly in the website privacy requirements guide, but the short version is that a form inbox nobody has cleared since 2019 is a liability rather than an archive.
Mail your website sends is a separate problem
Your mailboxes are for mail humans send. Your website also sends mail: contact form notifications, quote confirmations, booking receipts, password resets. That is a different system with different failure modes, and it is the single most common source of the complaint that starts with I never got the form submissions.
The classic setup fails for two reasons at once, and both are fixable in an afternoon.
- The form sends through the web server's built in mail function. That mail leaves from your web host's IP address, which is almost never listed in your SPF record and carries whatever reputation the other sites on that server have earned. Receiving servers see unverified mail from an unfamiliar source, which is exactly the shape of spam.
- The From address is set to whatever the visitor typed. The message then claims to come from a domain you do not control and cannot authenticate for, so it fails DMARC alignment at the receiver. This one feels helpful when you build it and is the reason the mail disappears.
- Send through an authenticated mail service instead. Use a proper sending service with credentials, or your mail provider's authenticated relay. The mail then leaves from a server your SPF record already authorises and arrives signed.
- Set From to your own domain and Reply-To to the visitor. The message authenticates correctly because it genuinely comes from you, and hitting reply still goes straight to the customer. You lose nothing and gain delivery.
- Consider a subdomain for automated mail. Sending bulk or automated messages from a subdomain keeps their sending reputation separate from your personal mail, so a bad month for your newsletter does not affect whether your quotes arrive.
- Store the submission as well as emailing it. Mail is not a database. If the notification is lost, the enquiry should still exist somewhere you can look at it. A record written to your own system before the email goes out costs almost nothing and turns a lost lead into a delayed one.
There is a build quality dimension here that is easy to miss. A page builder plugin that handles your contact form is another vendor deciding how your mail is sent, and its defaults are usually the two failure modes above. When we build a site the form is wired through an authenticated service, the submission is stored as well as emailed, and the addressing is set up to authenticate correctly on the first send. That is part of what custom PHP development buys you over an assembled stack, and it is a recurring theme in the WordPress versus custom comparison. Builds start at $1,200 for a single page and $2,800–$5,000 for a small multi page site, with the full breakdown on pricing and in the cost guide.
What breaks business email
Business email fails in a small number of predictable ways. Every one of them is preventable, and every one of them is usually discovered weeks after it starts, because undelivered mail is invisible from the sending end.
Auto renew was off, or the card on file expired, or the renewal notice went to an address nobody reads. The website goes down and the email stops at the same moment, which is how most owners find out. Turn auto renew on, keep a current card on the registrar account, and point the notices at an address a human checks.
Somebody adds a new tool, follows its setup guide, and publishes a second SPF record instead of editing the existing one. Two records is a permanent fail, not a merge. Every SPF change means editing the one record you already have.
You accumulate a mail provider, a newsletter tool, an invoicing service, and a booking system, and quietly pass ten lookups. Everything after the limit fails. A free checker reports your count in seconds, and the fix is usually removing services you no longer use.
The policy tightens before the senders are inventoried, and legitimate mail from your invoicing or booking system starts being refused. Because refusal happens at the receiver, you get no bounce and no warning. Always spend weeks at monitor-only first.
Forwarding a message to another address can break the original authentication, so the forwarded copy fails checks it would have passed. This is why a proper shared mailbox beats a chain of forwards, and why forwarding to a personal free account is a poor substitute for a real mailbox.
DMARC reports pile up unread in an inbox nobody opens, so the first sign of trouble is a customer phoning to ask why you never replied. Somebody has to own this, whether that is you once a quarter or a maintenance arrangement that checks it for you.
None of these are hard to fix. They are hard to notice, which is a different problem and an argument for putting a recurring check on the calendar: domain expiry date, SPF lookup count, DMARC reports, and a test send from an outside account to confirm your mail still lands in the inbox rather than the spam folder. Fifteen minutes, twice a year. That kind of scheduled check is part of what website maintenance includes, and if you would rather not own it, our maintenance plans cover the domain and DNS side of it.
The bigger point is that email is infrastructure rather than a tool. It is the channel every quote, invoice, and customer question travels through, and it is worth roughly the price of a couple of coffees per person per month to have it owned by the business, authenticated properly, and set up so that a staff change does not cost you an archive. Most small businesses spend more than that on things that generate far less. If you want a second opinion on how yours is set up, get in touch and I will look at the records and tell you what is actually wrong.
Key takeaways
- A free consumer address costs you three separate things: perceived scale, control of the account when someone leaves, and the ability to add role addresses as the business grows.
- Cost is per mailbox, not per address. Aliases are free everywhere, so a two person business with fourteen addresses pays for two mailboxes, typically one hundred and fifty to four hundred dollars a year total.
- Your website and your email are separate systems sharing a domain name. Keep them at different providers so changing one never forces you to move the other.
- SPF lists who may send as you, DKIM signs each message, DMARC says what to do when both fail. All three are effectively required now, and Google, Yahoo, and Microsoft all enforce them for bulk senders.
- Start DMARC at monitor only. Read the reports for weeks, authorise every legitimate sender you find, then tighten. Jumping straight to reject silently kills your own invoice email.
- Do the whole setup in order and change the MX records last. Everything before that step can be done while your current email keeps flowing normally.
- Skip the catch-all address. It accepts mail for addresses that never existed, which is exactly what spam dictionary attacks rely on. Explicit aliases give the same coverage without the volume.
- Your website's mail is a separate problem. Send it through an authenticated service, set From to your own domain and Reply-To to the visitor, and store submissions as well as emailing them.
Business email questions
Does it really matter if I use a Gmail address for my business?
It matters more than most owners want it to. A free consumer address does three things against you at once. It signals scale, because a quote for a ten thousand dollar job arriving from a free address invites a second opinion in a way the same quote from your own domain does not. It signals impermanence, because anyone can create one in ninety seconds and abandon it just as fast. And it quietly caps what you can build, since you cannot create a billing address, a support address, or an address for a new hire without opening another free account and hoping somebody remembers to check it. There is also a control problem underneath the branding problem. A free account belongs to whoever created it, which is usually a person rather than the business. When that person leaves, or forgets the recovery details, the business loses years of correspondence. Email on a domain you own is transferable, delegable, and survives staff turnover.
What does business email actually cost?
Between nothing and about twenty five dollars per person per month, and most small businesses land near the bottom. Google Workspace and Microsoft 365 both start in the range of six to eight dollars per user per month on an annual commitment, and their mid tiers run to roughly twelve to twenty two dollars per user for larger storage, meeting tools, and administrative controls. Zoho Mail has a genuinely free tier for a small number of users on one domain and paid plans around a dollar or two per user. Fastmail and Proton sit around five to eight dollars per user. Mailboxes bundled with cheap web hosting cost nothing extra but are usually the weakest option on reliability, spam filtering, and search. The number that matters is per mailbox rather than per address, because aliases are free on essentially every provider. A two person business with a dozen forwarding addresses pays for two mailboxes, not fourteen. Budget roughly one hundred and fifty to four hundred dollars a year for a small team, and treat it as infrastructure rather than a subscription to be trimmed.
Do I have to host my email with the same company that hosts my website?
No, and you usually should not. Web hosting and email hosting are separate services that happen to share a domain name. Your domain's DNS settings point them in different directions: the A record sends web visitors to your web server, and the MX records send mail to your mail provider. Those can be two completely different companies and neither one needs to know about the other. Splitting them is normal, not exotic. It means you can change web hosts without touching your email, and change email providers without touching your website, which removes the single most common reason a small business ends up stuck with a host they dislike. The practical arrangement most small businesses want is a real mail provider for mailboxes and a real web host for the site, with the domain registrar as the neutral place where both are pointed. Bundling everything with one provider looks simpler on day one and becomes the thing holding you hostage on day nine hundred.
What are SPF, DKIM, and DMARC and do I need all three?
They are three DNS records that together tell receiving mail servers whether a message claiming to come from your domain is genuine, and yes, you need all three. SPF is a public list of the servers allowed to send mail as your domain. DKIM adds a cryptographic signature to each message so the receiver can verify it was not altered and did come from an authorised sender. DMARC ties the two together: it tells receivers what to do when a message fails both checks, and it asks them to send you reports about who is sending mail as you. Since February 2024, Google and Yahoo have required all three from bulk senders, and Microsoft applied comparable requirements to Outlook.com in 2025. The practical effect for a small business is simpler than the acronyms suggest. Without them, your mail is more likely to land in spam and anyone can forge your domain in a phishing email. With them correctly configured, your legitimate mail is trusted and forgeries get rejected before they reach the recipient.
Why does my website contact form email go to spam?
Almost always for one of two reasons, and usually both. The first is that the form is sending through the web server's built in mail function rather than an authenticated mail service. That mail leaves from your web host's IP address, which is not listed in your SPF record and carries whatever reputation the other sites on that server have built. Receiving servers treat it as unverified mail from an unfamiliar source, which is exactly what spam looks like. The second is that the form sets the From address to whatever the visitor typed. That makes the message claim to be from a domain you do not control and cannot authenticate for, so it fails DMARC alignment at the receiver. The fix is the same in both cases. Send through an authenticated service, set the From address to your own domain, and put the visitor's address in Reply-To so hitting reply still works. Form mail that is set up this way is ordinary authenticated mail and lands normally.
How do I move my email to a new domain without losing messages?
Set everything up before you change the routing, and change the routing last. Create the mailboxes at the new provider, verify domain ownership, publish the SPF and DKIM records, and send test messages while your old email keeps flowing normally. None of that touches live delivery. Then import your old mail, since every serious provider has a migration tool that copies messages, folders, and often contacts and calendars from the old mailbox. Do the import before the cutover so the new mailbox is already populated when it goes live. Lower your DNS time to live value to a short interval a day ahead, then switch the MX records. Mail arriving during the changeover goes to whichever server the sender's provider has cached, which is why keeping the old mailbox alive and monitored for two to four weeks afterwards matters. Do not delete the old account until a full billing cycle has passed with no traffic to it.
Should I use a catch-all address so I never miss anything?
No. A catch-all accepts mail sent to any address at your domain, including addresses that have never existed, which sounds like insurance and works out as a spam magnet. Spammers routinely send to dictionary lists of common names at a domain, and a catch-all accepts every one of them. Worse, accepting mail for addresses that do not exist and then bouncing or discarding it can hurt your domain's sending reputation over time. The better arrangement is explicit aliases for the addresses you actually use, which cost nothing on every mainstream provider, plus a small number of role addresses like info, billing, and support. If you are worried about typos in an address printed on a vehicle or a business card, add a specific alias for the likely misspelling rather than opening the door to everything. That gets you the safety net without the spam volume.
What is DMARC p equals reject and should I turn it on?
It is the strictest of the three DMARC policy settings, and it instructs receiving servers to reject outright any mail claiming to be from your domain that fails authentication. It is where you want to end up, but not where you should start. Begin at p equals none, which changes nothing about delivery and simply asks receivers to send you aggregate reports. Read those reports for a few weeks and you will discover every service sending mail as you: your mail provider, your newsletter tool, your invoicing software, your booking system, the form on your website. Authorise the legitimate ones, then move to p equals quarantine, which sends failures to spam rather than rejecting them, and watch again. Only then move to reject. Jumping straight to reject before you have inventoried your senders is the classic way to silently kill your own invoice emails, and because they are rejected rather than bounced back to you, you may not find out for weeks.