Custom domain email in Gmail without Google Workspace is a delivery job, not a suite job. You keep the inbox you already search. You publish one MX set so hello@yourdomain lands there. You delete leftover Workspace or host MX. You prove inbound from a mailbox that is not Gmail. Send-as is a second, paid hop. This page is not the send-as-only walkthrough that already lives on the site.
Quick answer for custom domain email gmail without google workspace
Use a custom domain in Gmail without Workspace when the job is identity plus an inbox you already trust. Add the domain on MailerZ. Publish a verification TXT. Create named aliases such as hello@. Publish only the MailerZ MX set. Delete leftover Google, Microsoft, Cloudflare routing, or registrar MX. Send a uniquely titled message from an unrelated provider. Confirm Header From and delivery history in Gmail.
Do not buy Workspace because a homepage needs hello@. Workspace is a hosted mailbox, Calendar, Drive admin, and a per-user invoice. MailerZ is not that product. Compare pages exist. This article is the keep-Gmail path.
Gmail send as is optional. Email forwarding to Gmail is the inbound half. If you only need to receive, Free is enough: one domain, three aliases, unknown recipients held, no send-as. If customers must see the domain on replies, upgrade and attach Send mail as using the dashboard SMTP pair.
This is a different article from the existing send-as guide. Here the first success is a stranger’s message arriving in Gmail with the original Header From intact. Outbound comes after that proof.
MailerZ Free is one domain, three aliases, one seat, a 14-day store, send-as disabled, SMTP and API disabled, and unrouted mail held or rejected only. Solo is $40 per year only. Starter is $8 monthly or $80 yearly. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm numbers on MailerZ pricing. Limits are not an inbox-placement promise.
Google’s own Send mail as steps live in Google Gmail Help — Send mail from a different address. Workspace as a product is described on Google Workspace — product overview. Transport still follows IETF RFC 5321 — Simple Mail Transfer Protocol.
custom domain gmail: the real decision
Founders treat Workspace as the only way to look like a company. They pay per seat for people who only needed a printed role. Custom domain Gmail is cheaper and calmer when Calendar is already on personal Gmail and nobody needs an admin console.
The second failure is leftover Workspace MX after a “trial.” Senders still hit Google. Your new aliases never run. The suite invoice can be gone and the MX still answers.
The third failure is printing hello@ before the probe. Marketing goes live. Customers write. Mail sits at the old host. You blame Gmail filters. The lookup still shows aspmx.l.google.com.
Decide with tests: can you list printed names, can you show one MX operator, can you prove inbound from another mailbox, and do replies need the domain From. If the last answer is no, stay on Free.
| Need | Keep Gmail + MailerZ | Buy Workspace |
|---|---|---|
| Searchable archive you already have | Yes | A second store |
| hello@ on a domain you own | Named alias + MX | User mailbox |
| Calendar + admin + Drive | No | Yes |
| Send as the domain | Paid SMTP + Send mail as | Native |
Prove inbound from another mailbox before you print hello@ on a homepage.
Start free — one domainTechnical mail flow for custom domain email gmail without google workspace
A sender looks up MX for your domain, offers RCPT TO hello@yourdomain, and transfers content. MailerZ accepts a named alias and forwards a copy to the Gmail address you verified. Gmail stores the message. Header From stays the original author so DKIM still describes that author.
SRS may rewrite the envelope return path so bounces can travel. That is not a From rewrite. If a forwarder rewrites Header From, Gmail’s spam systems see a broken authentication story. MailerZ does not do that.
Gmail does not need MX on your custom domain for this split. If Google MX remains, Google is still the inbound operator. Custom domain Gmail without Workspace fails quietly that way.
Outbound: Gmail Send mail as uses authenticated SMTP on a paid plan. Free cannot finish that hop. Unauthorized send is 550.
MailerZ is inbound MX plus authenticated SMTP from Secuno LLC. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME are never rewritten. Not Google Workspace, not IMAP, not webmail, not an open relay. Unauthorized send is SMTP 550 / 550 5.7.1. Leftover MX is a hard stop. Self-send from Gmail to the same Gmail account can hide routing errors. Not SOC 2, not ISO 27001, not HIPAA.
gmail send as
Do inbound before you open Gmail’s Send mail as dialog. A green SMTP plugin does not prove hello@ receives.
- Write whether you only receive, or also send as the domain.
- Add and verify one domain. Publish the TXT the dashboard shows.
- Create hello@ and at most two other printed names on Free.
- Publish MailerZ MX. Delete leftover suite and registrar MX.
- Probe from a mailbox that is not this Gmail account.
- Confirm Header From and delivery history.
- If send-as is required, upgrade, create the SMTP credential, follow Google’s Send mail as help.
- Re-check MX after any host or Cloudflare change.
Failure modes and proof
Self-send from Gmail to hello@ that also lands in that Gmail. Google can short-circuit. The path you care about never ran.
Leftover aspmx records. Public lookup is the proof, not the MailerZ dashboard alone.
Registrar forwarding still on. Two operators. Split mail.
Send mail as on Free. It will not complete. Upgrade first.
Asking for guaranteed Primary tab. Inbox placement is Gmail’s decision. MailerZ is not an SLA.
Leftover MX is the usual ghost. Check a public lookup before you blame Gmail.
Open leftover MX troubleshootingMailerZ workflow and product boundary
MailerZ keeps Gmail while you use a professional domain. You map aliases. You inspect hops. You recover inside 14 days on Free or 90 on paid. You add send-as when you pay.
It will not become Workspace. It will not host IMAP. It will not promise SOC 2. If you need a hosted login per person, buy the suite.
Related pages: email forwarding, send and reply, compare Google Workspace, and docs.
email forwarding to gmail
Free proves receive. Solo at $40 per year is the usual send-as start for one founder domain. A Workspace seat per teammate is the expensive alternative when you only needed three roles.
Time on leftover MX costs more than Solo. Finish the cut.
MailerZ Free is one domain, three aliases, one seat, a 14-day store, send-as disabled, SMTP and API disabled, and unrouted mail held or rejected only. Solo is $40 per year only. Starter is $8 monthly or $80 yearly. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm numbers on MailerZ pricing. Limits are not an inbox-placement promise.
Field notes you can reuse
If a contractor still has the old Workspace password, leftover MX is not your only problem. Revoke the suite. Then delete MX.
Plus tags on the Gmail account are not custom-domain aliases. Print hello@ on the domain you own.
Unknown recipients are held on Free. Do not enable catch-all forward to hide a missing list.
Outlook can be a destination too. This article is the Gmail path. Interface labels differ.
Document the Gmail destination in the same runbook as MX. When someone leaves, remap, do not reprint the website.
Hacker News threads about “just use forwarding” skip leftover MX. Do not copy that skip.
If legal wants an archive, the 14-day store is not it. Gmail is the archive you already have.
Two personal Gmail accounts as destinations for one alias is fan-out. Name the reply owner.
DKIM for outbound is published when you send. Inbound authentication is the sender’s problem plus your From-intact copy.
Quarterly, look up MX. That habit prevents the next silent split.
Longer operator notes
What “without Workspace” actually saves
Workspace is a hosted login, a calendar system, Drive administration, and a bill that grows with heads. Using a custom domain in Gmail without that suite saves the seats you would have bought for people who only needed a printed role. It does not save you from DNS. It does not save you from leftover aspmx records after a Workspace trial you forgot to finish. The money you did not spend on seats is easily burned on a week of missing hello@ mail.
If every person on the team needs a private store, sharing controls, and an admin who can reset a password, you are not the reader for this keep-Gmail path. Buy the suite. Publish their MX. Stop reading forwarding articles as if they were a discount Workspace. The compare page exists so that sentence has a home.
If the team is you, a contractor, and a brochure site, Free can prove receive. Solo at $40 per year is the usual send-as start. Starter, Business, and Agency exist when domains, aliases, and send ceilings grow. Confirm pricing. Those numbers are not a Primary-tab warranty.
Worked week for a single founder
Monday: screenshot current MX. If Google is there, write “leftover” on the ticket before you create anything. Tuesday: verify the domain, create hello@ and billing@, publish MailerZ MX, delete leftover hosts. Wednesday: send a unique subject from a mailbox that is not this Gmail. If history is empty, you still have leftover MX or the wrong nameserver panel. Thursday: only if inbound is honest and you need branded replies, upgrade and attach Send mail as. Friday: put hello@ on the site. Not before Wednesday’s probe.
That week is boring on purpose. The exciting week is the one where ads ran on Tuesday and MX was still Google. Do not do the exciting week.
If a contractor still has a Workspace password, revoke it at the suite, then delete MX. Order matters. An old login plus leftover MX is two ways for mail to bypass your new map.
How this page differs from the send-as guide
The site already has a send-as walkthrough for Gmail. This Master Roadmap row is the receive-first story: can a stranger reach Gmail through your domain without you buying Workspace. If you only read the send-as page, you will paste SMTP on day one and never prove hello@. If you only read this page, you might never attach Send mail as. Read both when both hops matter. Do not merge them into one sloppy checklist.
Hacker News threads about forwarding skip leftover MX and self-send. Treat those threads as topic discovery, not a runbook. Cite Google’s Send mail as help for clicks. Cite RFC 5321 for envelope versus headers.
Unknown recipients stay held on Free. Do not enable catch-all forward so that every guessed name lands in the same Gmail you just cleaned up. Promote a real leftover to a named alias. That is inventory, not a wildcard religion.
Outlook can be a destination if you mapped it. This article stays on Gmail because that is the search. Interface labels on Outlook vary by version. Do not pretend one screenshot covers both.
Document the Gmail destination next to the MX screenshot. When you leave a company or sell a brand, remap or delete MX. Do not leave hello@ pouring into a personal archive you no longer watch.
Quarterly, look up MX from two public views. That habit is the whole reliability story a small team can actually run. It is not an uptime badge. We do not sell those.
More operational detail
Nameserver panel before Gmail settings
Look up NS before you open Gmail. If Cloudflare answers, edit Cloudflare. If the registrar still answers, edit the registrar. A Workspace MX deleted in the wrong panel is still live. Custom domain email in Gmail without Google Workspace fails that way more often than it fails because Gmail “blocked forwarding.”
Save the old MX set. Junior operators skip this and cannot roll back. The migration planner exists so the screenshot has a home. Preference numbers are an order, not load balancing. Google at 10 and MailerZ at 20 means Google still wins.
Two public lookups after the cut. TTL lies. One clean view is not a ship decision. Then the external probe. Then, and only then, think about Send mail as.
If legal asks for an archive, Gmail is the store you already have. The 14-day Free window is recovery for hops MailerZ saw. It is not eDiscovery. Do not sell it as hold.
If a teammate needs Calendar delegation and Drive, that teammate is a suite seat. Do not invent a forwarding feature to avoid the invoice. Split the people who need mailboxes from the roles that need routes.
Document who owns hello@ replies. A mapped destination without an owner becomes a black hole with perfect MX.
Re-read leftover MX after any host invoice change. Canceling Workspace does not delete MX. People assume it does. It does not.
Start free on a domain you can break if this is your first cut. Production brochure domains are the wrong classroom.
MailerZ Free remains one domain, three aliases, one seat, a 14-day store, send-as disabled, SMTP and API disabled, and unrouted mail held or rejected only. Solo is $40 per year only. Starter is $8 or $80. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm MailerZ pricing. Unauthorized send is 550 / 550 5.7.1. Leftover MX is a hard stop. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME are never rewritten. Not Google Workspace, not IMAP, not webmail, not SOC 2, not ISO 27001, not HIPAA, not an inbox-placement promise.
A complete worked story
A full inbound-then-outbound story you can copy
Imagine a two-person studio that already lives in Gmail. They bought a domain last year, clicked a registrar “email forwarding” toggle, and printed hello@ on a landing page. Some mail arrived. Some did not. A Workspace trial leftover MX still answered a subset of senders. They believed Gmail was flaky. The public lookup showed two operators. Custom domain email in Gmail without Google Workspace starts when they treat that lookup as the product, not the inbox.
They add the domain to MailerZ, publish the verification TXT on the nameservers that actually answer — Cloudflare, not the registrar preview — and create hello@ plus billing@. They screenshot the old MX set. They publish only MailerZ MX. They delete the registrar toggle and the leftover aspmx hosts. They wait through TTL. They check two public views. Then a colleague at another company sends a uniquely titled message. MailerZ history shows the hop. Gmail shows the original Header From. Only then do they put hello@ back on the site.
A week later they want replies to show the domain. They upgrade to Solo at $40 per year, create the SMTP credential, and follow Google’s Send mail as help. They send outward to the same colleague. They do not use the Gmail password. They do not self-send. They revoke the credential when a contractor laptop is retired. That is the whole keep-Gmail path: receive first, send second, leftover MX never as backup.
If they had needed Calendar delegation and Drive for five staff, they would have bought Workspace and stopped reading this page. The compare route exists for that fork. Mixing suite MX with MailerZ MX is how the story fails. Priority is not load balancing. A higher preference MailerZ host does not share traffic with a leftover Google host that still accepts mail.
Unknown names stay held on Free. When a customer writes helo@ by typo, they open the store, promote a named alias if it matters, and leave the rest held. They do not enable catch-all forward because the launch felt scary. Three aliases were enough. A fourth printed name would have been a plan conversation or a shorter homepage.
Quarterly they look up MX again. Canceling an old host invoice never deleted records by itself. That review is the reliability practice a two-person studio can actually run. It is not an uptime badge and not SOC 2.
FAQ
- What is the safest way to handle custom domain email gmail without google workspace?
- Keep Gmail as the store. Verify one domain, publish one MailerZ MX set, delete leftover Workspace or host MX, and prove inbound from another mailbox. Add paid Send mail as only if replies must show the domain.
- Does this require a new mailbox?
- No. MailerZ is not IMAP. Gmail remains the archive. Buy Workspace only if you need hosted logins, Calendar admin, and Drive.
- Will it work with Gmail or Outlook?
- This article is the Gmail path. Outlook can be a destination with a mapped address. Send-as uses Gmail Send mail as or a manual Outlook SMTP identity on a paid plan.
- What DNS records are involved?
- Verification TXT, one MailerZ MX set, leftover MX removed. SPF, DKIM, and DMARC if you also send as the domain. Gmail MX should not remain on the custom domain.
- What should I test before production?
- A uniquely titled message from an unrelated provider into hello@. Confirm Header From and history. Do not email yourself from the same Gmail account.
Key takeaways
- Keep Gmail. Move MX. Do not buy a suite for hello@.
- Leftover Google MX is a hard stop.
- Prove inbound from another mailbox.
- Free has no send-as.
- Header From stays original on inbound.
- Send mail as is a later paid hop.
- Not an inbox SLA and not SOC 2.
- This page is not the send-as-only guide.
Conclusion and next action
Using a custom domain in Gmail without Workspace means one inbound operator, a short named list, and a probe that did not start in that Gmail account. Pay only when the From must travel.
Next action: verify one domain, cut leftover MX, send a unique subject from another provider. Start free when you can look up an honest MX set.
Sign in if the domain is already here and mail is still missing — then leftover cache or the wrong nameserver panel is the ticket.
Keep Gmail
Start free with one domain and prove inbound first.
Cut leftover MX. Probe from another mailbox. Pay later if the From must travel.
Review quarterly, or sooner if Gmail, Workspace, or MailerZ scope changes. Author: MailerZ editorial, Secuno LLC.