How to send as your custom domain from Gmail without Workspace

Quick answer for send as custom domain gmail without workspace

The safest way to send as your custom domain from Gmail without Workspace is a layered setup, not a single Gmail toggle. Point the domain at a receiving service you control, forward into the Gmail account you already use, then add Gmail’s Send mail as feature with an authenticated SMTP credential for that same domain. MailerZ is one product that does that split: inbound MX plus paid send-as. It is not Google Workspace, not IMAP, and not an open relay.

People mix three jobs that look similar in the Gmail UI. Receiving mail for hello@yourdomain.com is an MX problem. Reading that mail is a mailbox problem. Sending so recipients see hello@yourdomain.com is an SMTP identity problem. Workspace solves all three by hosting the mailbox. You do not need that bundle if Gmail already stores the mail and you only need the public identity.

Google documents the client side of this as “Send mail from a different address.” The help article is the source for Gmail’s own labels and verification email; see Google Gmail Help — Send mail from a different address. That article does not choose a receiving stack for you. It assumes you already have a working address and an SMTP server allowed to send as that address.

MailerZ’s rule on inbound is narrow and easy to quote. Envelope MAIL FROM:<> handling can use Sender Rewriting Scheme so bounces stay coherent. Header From is never rewritten. Subject, Date, Message-ID, body, and MIME stay as received. If a forwarder rewrites the visible From, filters and replies get worse. If you need that distinction in product language, start with custom-domain email forwarding.

Free cannot finish the outbound half. 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. Paid plans add send-as within published hourly and monthly limits. 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 before you quote them; they are plan limits, not an inbox-placement promise.

The user problem and the decision criteria

The usual complaint is simple. Customers write to a domain address. The founder lives in Gmail. Replies leave as @gmail.com, or Gmail shows a “via” identity, or the cheap forwarder rewrites the sender so threads look broken. Buying Workspace for one person can feel like renting an office to store a backpack.

That complaint showed up in public threads for years. One Hacker News discussion on domain forwarding, spam classification, and Workspace cost is a useful snapshot of the pain, not a product review: Email forwarding for your domain. Treat forum comments as anecdotes. Treat RFCs and provider help pages as the rules.

Decide with criteria you can test, not adjectives.

A custom domain in Gmail without Workspace is a good fit when the domain is an identity, Gmail is the working surface, and you can tolerate published send limits. It is a poor fit when every teammate needs a managed mailbox, when legal holds require a hosted archive you control, or when you want MailerZ to promise that Gmail will place mail in the Primary tab. No forwarder controls that last part.

If you are comparing the suite itself, read MailerZ versus Google Workspace. The short version: Workspace is a productivity suite with hosted mail. MailerZ is a delivery layer around an inbox you already own.

Technical mail flow

Internet mail is a sequence of SMTP conversations, not a single “email pipe.” IETF RFC 5321 — Simple Mail Transfer Protocol is the transport standard. A sending server looks up MX, connects, offers a return path in MAIL FROM, names recipients in RCPT TO, and then transfers content. Those envelope commands are not the same object as the header block people see in Gmail.

Inbound: how a message reaches Gmail

A customer sends to hello@yourdomain.com. Their server asks DNS for MX. If MailerZ MX is the published answer, the message arrives at MailerZ. The edge checks that the domain is verified and that the recipient matches an alias, a route, or an intentional catch-all rule. Unknown addresses on Free are held. Paid plans can forward unknown recipients when you enable that behavior. Holding unknown mail is the safer default.

MailerZ stores required content and metadata before it returns SMTP 250. Acceptance is not the same as “Gmail already has it.” After storage, MailerZ forwards to the destination you verified. The visible From stays the original sender. The envelope return path may be rewritten with SRS so bounce handling does not impersonate that sender. Delivery history records the destination response. Gmail can still file the message in spam, promotions, or a filter. That is Gmail’s decision.

Outbound: how Gmail send-as leaves the domain

When you reply, Gmail needs an outgoing server allowed to use your domain identity. You add MailerZ as that SMTP service: host, secure port, username, generated password, and the From address you approved. MailerZ authenticates the session, checks that the From identity is allowed, applies plan limits, and submits the message. Invalid credentials stop here. Unhosted or unauthorized recipients get SMTP 550. MailerZ is not an open relay.

SPF, DKIM, and DMARC do not “make mail inbox.” They help receiving systems evaluate authorization. Publish the records MailerZ shows. IETF RFC 7208 — Sender Policy Framework (SPF), IETF RFC 6376 — DomainKeys Identified Mail (DKIM), and IETF RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) are the primary documents if you want the protocol text. Alignment still depends on the visible From domain matching what those records authorize.

What Gmail actually stores

After a successful forward, Gmail is the system of record for the copy you read. MailerZ recovery storage is 14 days on Free and 90 days on paid plans. That store exists so a failed hop can be inspected or retried during the window. It is not a second archive and not a compliance vault. If you need long-term legal hold, keep it in Gmail or another archive you already run.

Step-by-step setup and decision path

Do this in order. Skipping inbound and jumping to Gmail SMTP is the most common way to waste an afternoon. The field-level Gmail clicks live in the Gmail send-as documentation. This section is the decision path around those clicks.

1. Confirm the job is identity, not a suite

   If you need shared drives, admin-managed mailboxes, and Calendar as the company system of record, stop and buy the suite. If you need you@brand.com in a Gmail you already live in, continue.

2. Add one domain you control

   Use the root domain, not a mailbox and not https://. MailerZ gives a unique verification TXT. Publish it on the authoritative nameservers. Verify in the dashboard. Receiving and sending stay off until that check passes.

3. Create the alias and destination

   Map hello@, you@, or a role address to the Gmail inbox that should receive it. Complete destination verification if asked. Do not point a destination back at the same alias. Loops look like “mail vanished” and waste support time.

4. Publish MX and delete leftover MX

   Copy the exact MX hosts and priorities from the dashboard. Then look at the public MX set. Old Google, Microsoft, or host records sitting beside MailerZ split inbound traffic. Treat leftover MX as a hard stop until those records are gone. Query from more than one resolver if you can. Propagation is a cache problem, not a progress bar.

5. Prove inbound from a different mailbox

   Send a uniquely titled message from an unrelated provider. Open Gmail. Confirm the visible sender is the original person, not a rewritten relay identity. Open MailerZ delivery history and read the destination response. If you email yourself from the same Gmail account, Gmail can short-circuit the path and you will debug a ghost.

6. Upgrade only when you need send-as

   Free stops here. That is intentional. When you need replies to leave as the domain, move to Solo or another paid plan, then create the SMTP credential in the dashboard. Copy host, port, encryption mode, username, and generated password. Do not paste your Google account password into that form.

7. Add Gmail Send mail as

   In Gmail on the web: Settings → See all settings → Accounts and Import → Send mail as → Add another email address. Enter the display name and the custom-domain alias. Use MailerZ SMTP. Keep “Treat as an alias” enabled for a normal personal identity. Confirm Google’s verification message after it forwards through MailerZ. Then compose a new message, open the From selector, and choose the domain address.

8. Send to a second external inbox

   The outbound test must leave Gmail and land somewhere you can inspect headers. Check the visible From. Check that a reply returns to the alias and lands in Gmail. Check MailerZ history for the outbound SMTP result. Inbox placement on the far side is still their filter.

Failure modes and proof

Most “Gmail send-as is broken” reports are a missing inbound proof, leftover MX, or a credential pasted into the wrong field. Work the evidence, not the feeling.

Proof is a pair of artifacts: a destination inbox screenshot or header block you sanitized, and the MailerZ event with timestamp plus remote response. Do not send SMTP passwords to support. Do not publish verification tokens. If you open a body for break-glass recovery, expect an audit row. That is a control, not a marketing badge.

Inbox placement is not proof of a correct setup, and a spam folder is not proof of a broken one. Gmail can accept a message and still hide it. MailerZ can record “delivered” when the destination SMTP server said yes. Those statements can both be true. If you need diagnostic DNS reads, use troubleshooting and DNS diagnostics and the public lookup tools. Those tools are DNS-only. They do not grab SMTP banners or invent a score.

MailerZ workflow and product boundary

MailerZ is a custom-domain email delivery layer operated by Secuno LLC. Point MX at MailerZ. Mail for a hosted, verified domain can land in Gmail or Outlook. Paid plans add authenticated SMTP so the same domain can send and reply. The live site is mailerz.net. The app is mail.mailerz.net.

The send-and-reply product surface is documented on send and reply as your domain. You connect SMTP once, then choose the verified identity in Gmail or Outlook. Recipients should see the domain address, not a MailerZ mailbox, because MailerZ is not hosting a mailbox.

What MailerZ does in this workflow

• Accept inbound mail for verified domains and configured recipients.
• Preserve Header From on the forward into Gmail.
• Hold or forward unknown recipients according to plan and settings.
• Store messages for 14 days on Free or 90 days on paid plans for recovery and evidence.
• Send through authenticated SMTP from approved identities on paid plans.
• Record delivery history for inbound and outbound hops.
• Surface leftover MX and other DNS problems as diagnostics, not as a guaranteed health score.

What MailerZ does not do

• Replace Gmail or Outlook with IMAP or webmail.
• Rewrite header From, Subject, Date, Message-ID, body, or MIME.
• Offer send-as on Free.
• Promise inbox placement, uptime SLAs, or review counts.
• Claim SOC 2, ISO 27001, or HIPAA. Those certifications are not held. Controls and wording live on Security and Trust Center.
• Act as an open relay. Unauthorized send gets 550 / 550 5.7.1.
• Send newsletters, purchased lists, or cold blasts. Use a dedicated campaign platform.

Aliases are addresses and routes, not extra Gmail accounts. Catch-all is a policy, not a feature to turn on because it sounds complete. Multi-domain use is a plan-capacity question: Free is one domain. Solo is three domains; Starter, Business, and Agency raise the domain and alias ceilings. Migrations are a DNS cutover plus a two-direction test, not an IMAP export. If you are leaving another forwarder, start with the migration planner and keep a rollback MX plan until the external test passes.

Cost, alternatives, and trade-offs

Workspace pricing is a per-user suite cost. Google’s current packaging lives on the Google Workspace — product overview page and changes. Do not treat a blog number as Google’s price list. The comparison that matters is economic shape: you pay per hosted user for a suite, or you pay a delivery layer while Gmail remains the seat you already have.

MailerZ Free is the right first purchase when you only need to prove inbound. It is the wrong plan if the acceptance test includes “recipient sees my domain on the reply.” Solo exists for one person who needs more aliases, 90-day store, catch-all forwarding, and 5 send-as messages per hour with 100 outgoing per month. Starter, Business, and Agency raise domains, seats, aliases, and send ceilings. Annual Starter, Business, and Agency billing includes two months free relative to paying monthly for a year. Solo has no monthly option.

Cloudflare Email Routing is inbound routing. It is not this article’s product and it does not become MailerZ leftover-MX handling, stored failed hops, or authenticated send-as because a blog post mentioned it. Read their docs if that is the stack you actually run. ImprovMX is the closest commercial class for forwarding; compare current plans on the site rather than memory.

FAQ

Key takeaways

• Sending as a custom domain from Gmail without Workspace is an MX plus SMTP job, not a Gmail theme.
• Keep Gmail as the mailbox. Do not look for IMAP on MailerZ.
• Header From stays the original sender on inbound. Envelope SRS is the rewrite that is allowed.
• Leftover MX is a hard stop. Split records lose mail in a pattern that looks random.
• Test inbound from a different mailbox. Self-send lies.
• Free has no send-as. Add a paid plan before Gmail SMTP will have a legal identity to use.
• Workspace is the right buy when you need the suite. It is optional when you only need the domain identity.
• Delivery history is evidence. Inbox tabs are Gmail’s.
• MailerZ is not SOC 2 and not a bulk sender. Quote those boundaries out loud.

Conclusion and next action

If you came here to send as your custom domain from Gmail without Workspace, the path is narrower than the forums make it sound. Keep the inbox. Take the domain through verification, MX, leftover cleanup, and an external inbound probe. Only then attach Gmail Send mail as to authenticated SMTP. That order prevents the two classic failures: a verification email that never arrives, and a From address that still says gmail.com because the outgoing server was never the one you thought.

MailerZ fits when you want that split with delivery history and a recovery window you can actually see. It does not fit when you need a hosted mailbox for every user, a certified compliance report, or campaign-scale sending. Start on Free if you only need to watch inbound. Move to Solo or another paid plan when the From identity has to leave the building as your domain.

Next action: add one domain, create one alias, and send a uniquely titled message from a mailbox that is not the destination. When that lands, configure send-as and repeat the test outward. The MailerZ documentation has the field maps. The register path is one domain, not a suite migration.

Published 9 September 2026. Review quarterly, or sooner if Gmail’s Send mail as flow, MailerZ plan limits, or DNS guidance changes. Author: MailerZ editorial, Secuno LLC.