You can send email from a domain without hosting a mailbox when the public From is a named alias and the store stays Gmail or Outlook. Receive on MX. Send on authenticated SMTP from an approved identity. Free has no send-as. Do not buy a Workspace seat to host a string. Do not point a form at a random relay and hope. Prove inbound first, then attach the dashboard SMTP pair, then prove Header From on a third mailbox.
Quick answer for send email from domain without mailbox
Hosting a mailbox means IMAP, a login, and a store on the mail host. Sending from a domain without that store means someone else keeps the archive—usually Gmail or Outlook—while SMTP submits mail as hello@yourdomain.com. MailerZ is that split: inbound MX plus paid authenticated SMTP. Header From on inbound stays the original sender. Envelope SRS may rewrite the return path on forwards. Outbound From must be an identity you were allowed to use. Unauthorized send gets 550. The product is not an open relay and not webmail.
Send email from domain without mailbox setup: verify the domain, create the alias you will send as, publish exclusive MX, probe inbound, upgrade off Free, copy host, port, and encryption from the dashboard, attach SMTP in the client, send to a mailbox you do not own. Best practice is the same order every time. Skipping inbound proof is how leftover MX and a pretty From coexist with silent inbound failure. See send and reply and the Gmail path already shipped on send as your custom domain from Gmail without Workspace.
ImprovMX’s SMTP pages are useful competitor research for the same class of job. They are not MailerZ documentation: ImprovMX SMTP. Google’s send-as help is the client side: Google Gmail Help — Send mail from a different address.
Free is one domain, three aliases, 14-day store, send-as disabled, SMTP and API disabled. Solo is $40 per year, 15 aliases, 90-day store, 100 outgoing, 5 send-as per hour. Starter is $8 or $80 with 200 outgoing and 10 per hour. Business is $19 or $190 with 400 and 15. Agency is $39 or $390 with 800 and 25. Confirm on MailerZ pricing. Those ceilings are not an inbox-placement SLA.
If every human needs Calendar, Drive, and a lockable hosted store, buy Workspace or Microsoft 365. If you only need the domain on the envelope and in From, you do not host a mailbox. You host DNS and a route.
The user problem and the decision criteria
Founders buy seats because the registrar sold “email hosting” next to the domain. They wanted hello@ on invoices. They got an empty webmail they never open, plus leftover MX when they later forward to Gmail. The job was send email from a domain without a mailbox. The purchase was a mailbox they ignore.
| Question | If yes | If no |
|---|---|---|
| Is Gmail or Outlook already the archive? | Forward inbound. Add paid SMTP for From. | You may be shopping for hosting. |
| Must recipients see the domain on replies? | Paid send-as. Free cannot finish this. | Inbound-only may be enough. |
| Is this a website form or app? | Authenticated SMTP from an approved From. Not a mailbox. | A person can use Gmail Send mail as. |
| Do you need IMAP on the domain host? | Buy hosting or a suite. MailerZ will not be it. | Keep the existing inbox. |
| Is leftover MX still published? | Stop. Sending will not fix missing inbound. | Continue the SMTP attach. |
| Is the From a named alias you created? | Allowed identity on paid SMTP. | Catch-all and guessed names do not send. |
Technical mail flow
Inbound and outbound are different SMTP conversations. IETF RFC 5321 — Simple Mail Transfer Protocol still applies to both. A customer sending to you looks up your MX. MailerZ accepts a named alias, stores required content, returns 250, and forwards to Gmail. A you-sending-as-the-domain conversation starts in Gmail or an app, authenticates to MailerZ SMTP, and offers an approved From. The receiver of that message looks up your SPF, DKIM, and DMARC, not your IMAP.
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 outbound texts. Publish them for the domain you send as. A pretty From with Gmail’s servers still doing the send is how custom From reverts to @gmail.com. The received copy tells the truth. Open it on a third mailbox.
MailerZ does not rewrite outbound Header From to “help” you. You must submit the identity you were approved for. Unhosted domains and unauthorized recipients get 550 / 550 5.7.1. That is the open-relay refusal. It is not leftover inbound policy. Keep those tickets separate.
Recovery storage is 14 days on Free and 90 days on paid. It is a failed-hop window, not a hosted mailbox and not a seven-year archive. If you need lockable storage on the domain host, you are back to buying IMAP.
Outbound history should show the destination response for the send you just did. If history is empty and the third mailbox has nothing, the client never reached MailerZ. If history shows 550, read the enhanced status before you rotate passwords. If history shows 250 and the third mailbox has the alias From, inbound leftovers are a separate conversation. Do not debug catch-all hold in a send-as ticket.
SRS on inbound forwards does not replace outbound SPF. Operators paste an SRS explanation into a send-as outage and waste an hour. Inbound envelope rewrite keeps forwarded mail aligned with the forwarder’s domain. Outbound send-as needs your domain’s records to match the MailerZ sending hosts the dashboard names. Two mechanisms. Two checklists.
Gmail, Outlook, websites, and other clients
Gmail Send mail as attaches an SMTP username, password, host, and port. Treat the identity as the alias, not as a second Gmail user. After you send, the received Header From must be the alias. If it is still @gmail.com, the composer lied or SMTP was not used. Google Gmail Help — Send mail from a different address is the Google article. MailerZ is not Workspace. You are not adding a hosted user.
Outlook desktop often needs a manual SMTP identity. IMAP or the Microsoft account still reads the destination inbox. Outgoing uses MailerZ. Mixing Microsoft’s SMTP with a MailerZ From is how authentication fails. Microsoft Learn — Send email from a device or app using Microsoft 365 is device/app SMTP on Microsoft’s side—useful contrast, not MailerZ’s host. Copy MailerZ’s pair from the dashboard.
Website contact forms and WordPress need the same paid SMTP, a named From that exists as an alias, and a destination that is not a loop. This is still send email from a domain without a mailbox. It is not a campaign sender. Hourly and monthly send-as limits apply. Purchased lists and cold blasts are out of scope. See features for the product surface, not for a bulk SKU that does not exist.
Apple Mail and Thunderbird follow the same split: read from Gmail/IMAP you already have, send through MailerZ SMTP as the alias. Two servers. One leftover MX hard stop. Do not add a third MX “for sending.” Sending does not use your MX as the submission host.
Plus tags and disposable From values are not this job. You cannot authenticate as a domain you do not control. Privacy masks on a provider domain send as that provider. Brand From requires your zone, your records, and an approved identity.
Shared mailboxes at the destination do not change SMTP. If hello@ lands in two Gmail accounts, only the person whose client has SMTP attached will send as the alias. The other person will reply as @gmail.com unless they also attach send-as. That is expected. MailerZ does not log into Gmail and rewrite the composer. Train the people who reply, or accept inbound-only for the second destination.
Password managers should store the SMTP credential next to the dashboard login, not in a Slack screenshot. When you rotate, update every client: Gmail send-as, Outlook, WordPress, cron jobs. A stale client will 550 and look like an outage. The printed From stays the same through a rotation. That is another reason the identity is the alias, not the password.
Testing from Linux with a submission tool is optional and only useful if you already know the dashboard pair. The proof that matters for production is still a received message in a third mailbox with the alias in Header From. Do not treat a successful AUTH as the end of the job. AUTH means the password worked. It does not mean DMARC will pass or that inbound MX is exclusive.
Step-by-step send email from domain without mailbox setup
Name the From alias before you buy SMTP
hello@orbilling@, not a mystery string. Create it. Map a verified destination. Free allows three aliases. Count before you print.Publish exclusive MX and prove inbound
Delete leftover Google, Microsoft, registrar, or host MX. Probe from another mailbox. Confirm Header From and history. Self-send lies.
Upgrade off Free when From must travel
Solo at $40 per year is the first send-as card for one person. Starter and above raise hourly and monthly ceilings. Confirm live numbers on pricing.
Publish SPF, DKIM, and DMARC as the dashboard shows
Do not paste a blog’s generic SPF and call it done. Wrong includes break the domain you already send from.
Copy host, port, and encryption from the dashboard
STARTTLS and implicit TLS are different pairs. Mixing them fails before a message exists. Do not guess 587 versus 465 from memory.
Attach SMTP in one client and send to a third mailbox
Not your Gmail. Not the destination. A third inbox. Read the received From, Return-Path, and Authentication-Results.
Keep catch-all out of send-as
Unknown leftover policy does not mint From identities. Harvested names cannot send. Create the alias if it must reply.
Failure modes and proof
| What you see | Likely cause | Proof to collect |
|---|---|---|
| Received From is @gmail.com | SMTP not attached, or Gmail kept the default identity. | Received copy. From selector. Plan send-as. |
| SMTP 550 / 5.7.1 | Unauthorized From, unhosted domain, or open-relay refusal. | Exact response. Approved identity list. |
| Auth failed in the client | Wrong host/port/TLS pair, or still on Free. | Dashboard pair. Plan card. |
| Inbound missing after send-as works | Leftover MX. Different hop. | Public MX from two resolvers. |
| Self-send empty | Gmail short-circuit. | Third mailbox. |
| Hourly 550 or defer | Send-as ceiling on the plan. | Solo 5/hr, Starter 10, Business 15, Agency 25. |
| Form mail loops | Destination is the same alias. | Map the form To a real inbox, From a named alias. |
| DMARC fail on the received copy | Records missing or send still via Gmail servers. | Authentication-Results. DNS as published. |
Proof is the third-mailbox copy plus the SMTP response plus public MX. Do not send SMTP passwords to support. Inbox placement is not proof the From is correct. A spam folder on the third mailbox is their filter, not a MailerZ SLA.
MailerZ workflow and product boundary
MailerZ is a custom-domain email delivery layer operated by Secuno LLC. Site: mailerz.net. App: mail.mailerz.net. Positioning: authenticated SMTP from verified domain identities around the inbox you already use. Product after the reader understands they do not need IMAP for a From string.
What MailerZ does
- Accept inbound aliases on verified domains.
- Preserve Header From on the forward. Envelope SRS only.
- Paid SMTP from approved identities.
- Hold unknowns on Free. Optional paid catch-all forward.
- 14- or 90-day recovery store. Delivery history.
What MailerZ does not do
- Host IMAP or webmail.
- Offer send-as on Free.
- Send as harvested leftover names.
- Rewrite header From, Subject, Date, Message-ID, body, or MIME.
- Promise inbox placement, uptime SLAs, or review counts.
- Claim SOC 2, ISO 27001, or HIPAA. Security.
- Act as an open relay or campaign sender.
Cost, alternatives, and trade-offs
A hosted mailbox per role is the expensive way to get a From string. Consumer Gmail plus MailerZ Solo at $40 per year is the cheap way when one person already lives in Gmail. Workspace is correct when the team needs the suite. It is incorrect when you only needed send email from a domain without a mailbox.
| Approach | You get | You give up |
|---|---|---|
| MailerZ inbound + paid SMTP | Domain From. Existing archive. History. | You operate DNS. Free has no send-as. |
| Gmail only, no SMTP | Speed. | Recipients see @gmail.com. |
| Workspace seat per role | IMAP and the suite. | Per-user cost you may not need. |
| Random SMTP vendor + some MX | A From that may send. | Split brain. Leftover MX. Two bills. |
| Cloudflare routing only | Inbound in that DNS. | Not MailerZ send-as or stored hops. Cloudflare — Email Routing documentation |
Annual Starter, Business, and Agency include two months free versus monthly. Solo has no monthly option. Seats operate the router. They are not extra From identities. Alias count is what mints names you can send as. Three on Free—but Free still cannot send. Fifteen on Solo. Plan the names and the send-as card together.
Website SMTP uses the same ceilings. A contact form that mails you ten times a day fits Solo. A newsletter does not belong here. If the honest job is campaigns, buy a campaign vendor. Do not lean on MailerZ hourly send-as until it 550s and then call it an outage.
Time is a line item. An hour to prove inbound and attach SMTP is cheaper than a year of unused hosted mailboxes. Leftover MX after a failed hosting trial costs more than Solo. Budget the third-mailbox probe as required, not optional polish.
Agencies should copy one send-as runbook per client domain: named From, dashboard pair, third-mailbox proof, leftover MX screenshot. Do not share one SMTP password across ten brands. Seats exist so operators can change routes. Identities exist per domain. Agency at $39 or $390 raises domain and send ceilings. It does not make MailerZ a mailbox host. Clients who need IMAP still buy a suite. Clients who need a footer From do not.
Personal domains follow the same tests with less theater. you@yourname.com into consumer Gmail, Solo for send-as, SPF/DKIM/DMARC as shown, third-mailbox proof. Do not buy Workspace for a personal site unless you want the suite. Do not use a plus tag as the public From. Do not send as a disposable domain you do not own.
Hourly limits are a design constraint, not a bug. Solo’s 5 send-as per hour is enough for a human answering customers. It is not enough for a misconfigured form in a retry loop. If a plugin retries on every page view, you will hit the ceiling and think SMTP is down. Cap the form. Log the 550. Fix the loop. Then decide whether Starter’s 10 per hour is the next card.
Display names are not identities. You can set the friendly name to “Ava at Acme” while From remains hello@acme.com. Receivers and filters care about the address and the signatures. Do not “fix” a revert-to-Gmail problem by changing only the display name. The received Header From is the artifact. If it is Gmail, SMTP did not carry the alias.
FAQ
What is the safest way to send email from a domain without a mailbox?
Prove inbound first: named alias, exclusive MX, probe from another mailbox. Then use a paid plan and authenticated SMTP from an approved From identity. Attach that SMTP in Gmail Send mail as, Outlook, or an app. Free has no send-as. MailerZ is not IMAP and not an open relay.
Does this require a new mailbox?
No. The store stays Gmail or Outlook. MailerZ accepts MX and, on paid plans, sends SMTP. You do not get a MailerZ webmail login. Hosting is a different purchase when you need a stored seat and Calendar.
Will it work with Gmail or Outlook?
Yes. Inbound aliases land in those inboxes. Outbound uses Gmail Send mail as or a manual Outlook SMTP identity with the dashboard host, port, and encryption pair. Copy the pair. Do not invent settings. Free cannot finish send-as.
What DNS records are involved?
Verification TXT, one MX set, leftover host MX removed, plus SPF, DKIM, and DMARC for the sending domain. Send-as without those records still submits to SMTP and still fails authentication at the receiver.
What should I test before production?
Inbound probe from an unrelated provider. Then send outward through MailerZ SMTP to a third mailbox you do not own. Confirm the received Header From is the named alias, not @gmail.com. Self-send hides both hops.
Key takeaways
- Send email from a domain without a mailbox means SMTP From plus an inbox you already have.
- MailerZ is not IMAP. Gmail or Outlook stays the store.
- Free has no send-as. Solo at $40 per year starts it.
- Prove inbound and exclusive MX before you attach SMTP.
- Copy the dashboard host, port, and encryption pair. Do not invent ports.
- Prove Header From on a third mailbox. Self-send lies.
- Catch-all does not create send-as identities.
- Unauthorized From gets 550. Not an open relay.
- Header From on inbound stays the original sender. Envelope SRS only.
- MailerZ is not SOC 2 and not a bulk sender.
- Display names are not identities. The received Header From is the artifact.
- Form retry loops will burn hourly send-as ceilings. Cap the plugin.
- Rotate SMTP credentials when a contractor leaves. Keep the printed From.
- Cut leftover MX before send-as. Dual MX plus a pretty From is the usual false all-clear.
Conclusion and next action
You do not host a mailbox to own a From string. You verify a domain, name an alias, receive in Gmail, and send through paid SMTP as that alias. Hosting remains the right buy for IMAP and the suite. It is the wrong buy for a footer address.
Next action: add one domain, create the From alias, prove inbound from another mailbox, then upgrade and send to a third inbox. If the received From is the alias, you are done. If it is Gmail, the composer is still sending as itself. If SMTP returns 550, read the status before you rotate passwords. If inbound is still missing, stop send-as work and clean leftover MX. The two hops fail independently and they are fixed independently.
Keep a one-page runbook next to the dashboard: alias list, plan send-as ceilings, dashboard host and port pair, date of last third-mailbox proof, and the public MX set. When a contractor leaves, change destinations and rotate SMTP credentials. The printed From stays. That is the whole point of sending from a domain without hosting a mailbox: the identity is the route, not the laptop.
If you already hosted mail on the domain and you are leaving that host, do not keep the old MX “as backup.” Sending through MailerZ while inbound still splits is how customers swear they mailed you and you swear SMTP works. Cut MX exclusively, prove inbound, then attach send-as. The order is the product. Reverse it and you will debug the wrong hop for a week.
Legal and finance From values deserve the same proof as hello@. An invoice that shows @gmail.com after a quarter of branded mail is a trust event. Create billing@, attach SMTP for the person who sends invoices, and prove the received copy once per quarter when you refresh DNS. Do not wait for a customer to screenshot the From.
Ready to send as the domain
Start free with one domain and prove inbound first.
Free receives. Solo starts send-as. Sign in if the domain is already there.
Review quarterly, or sooner if SMTP limits or client send-as steps change. Author: MailerZ editorial, Secuno LLC.