Custom Domain + Gmail

Custom domain email for Gmail: MX, alias, SMTP and reply flow explained

MX, alias, SMTP, and Reply are four decisions. Fix the layer that failed.

MailerZ editorial · Secuno LLC17 min read

Custom domain Gmail MX SMTP alias is four layers. MX decides who accepts inbound. An alias decides which local-parts exist and where they go. Authenticated SMTP decides who may send which From. Gmail Reply decides whether the customer sees the domain or your personal address. MailerZ runs the first three when you configure them. Gmail owns the fourth. Leftover MX and self-send tests make all four look broken.

Four layers: MX, alias, SMTP, Reply
One customer email touches all four.

Quick answer for custom domain gmail mx smtp alias

Publish one MailerZ MX set. Create named aliases. Probe inbound from another mailbox. If a From must travel, pay, copy host port TLS, and attach Gmail Send mail as. That is custom domain Gmail MX SMTP alias as a working system.

Custom domain Gmail is the store. Authenticated SMTP is outbound. Gmail send as is the UI that uses that SMTP. An alias is inbound only.

Free completes MX plus alias. Free cannot complete SMTP. Solo starts send-as.

Header From on inbound is never rewritten. Envelope SRS may change. Reply is a new message.

MailerZ Free is one domain, ten 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

Teams paste SMTP into Gmail before MX exists. They send fine and receive nothing.

They create aliases and never attach send-as. Customers get personal Gmail on Reply.

They enable catch-all and call it an alias strategy.

Criteria: name the failed layer before you open three dashboards.

Layer versus symptom
LayerIf it failsFirst proof
MXNobody arrivesPublic lookup
AliasOne name missingNamed list + hold
SMTP550 or no FromPlan + credentials
ReplyCustomer sees GmailSend mail as UI

Prove inbound from another mailbox before you print hello@ on a homepage.

Start free — one domain

Technical mail flow for custom domain gmail mx smtp alias

Inbound: lookup, accept, map, second SMTP to Gmail. Outbound: Gmail to MailerZ SMTP to the internet. Reply chooses which outbound identity.

Catch-all is not a layer. It is an unknown policy on the alias layer.

SPF DKIM DMARC belong beside SMTP, not beside MX inbound.

Two destinations are a copy on the alias layer. They do not fix Reply.

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 or POP, 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.

Leftover MX skips alias and SMTP
If Google still answers, layers two through four never run.

authenticated smtp

Stand up inbound, then outbound, then the Gmail UI.

  1. Verify the domain. Publish MailerZ MX. Cut leftovers.
  2. Create printed aliases. Probe each.
  3. Decide which Froms reply as the domain.
  4. Upgrade if any From must travel.
  5. Copy host, port, TLS. Create the identity.
  6. Attach Send mail as. Send to another mailbox.
  7. Confirm Reply uses that identity.
  8. Document the four layers in the runbook.

Failure modes and proof

SMTP first, MX never.

MX perfect, Reply personal.

Catch-all as alias.

One password in Gmail, WordPress, and a ticket.

Self-send on every layer.

Leftover MX is the usual ghost. Check a public lookup before you blame Gmail.

Open leftover MX troubleshooting

MailerZ workflow and product boundary

MailerZ implements MX, alias, and SMTP. Gmail implements Reply. Related: email forwarding, send and reply, docs, compare Google Workspace.

Unauthorized send is 550 / 550 5.7.1. Not an open relay.

Related pages: email forwarding, send and reply, compare Google Workspace, and docs.

Reply without send-as
Inbound can be perfect. The customer still sees Gmail.

gmail send as

Free is two inbound layers. Paid is the SMTP layer. Workspace bundles all four plus Calendar. Buy the bundle only if you need the suite. Confirm pricing.

Debugging all four at once costs more than Solo.

MailerZ Free is one domain, ten 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

Write the layer name on the ticket before screenshots.

Plus tags are not aliases.

Outlook Reply is a manual SMTP identity.

Agencies: per-domain SMTP.

Hold unknowns so the alias layer stays printable.

Delivery recovery is hop-three evidence.

Routing lab is hop-one practice.

This page is the map. Other posts are single-layer drills.

Deeper field notes for custom domain gmail mx smtp alias

Four layers, four failures

Custom domain Gmail MX SMTP alias is four decisions that people collapse into one settings page. MX says who accepts inbound for the domain. An alias says which local-parts you will accept and where they go. SMTP says who may send as which From. Reply flow says what the human clicks when they hit Reply in Gmail. Break any layer and the others look haunted.

MX without aliases: the operator accepts the connection and then holds or rejects the unknown. Alias without MX: you have a map nobody can reach because leftover Google still answers. SMTP without an inbound alias: you can invent a From Gmail will not receive on the way back. Reply without send-as: the customer sees your personal Gmail. Fix the layer that is actually wrong.

MX in one paragraph you can reuse

A sender’s resolver asks for MX on your domain. It tries hosts in preference order. The first host that accepts the message wins. Priority is not load balancing. A leftover Workspace host with a better preference eats the copy. Publish one MailerZ MX set. Delete leftover hosts. Verify on more than one public view because TTL lies. Save the old set before you delete.

Alias in one paragraph you can reuse

RCPT TO hello@yourdomain is a local-part plus a domain. A named alias matches and forwards to a destination mailbox. Catch-all is a policy for leftovers, not a brochure feature. Free allows three named aliases. Hold unknowns on everyday production. Plus tags on @gmail.com are Gmail’s feature, not your domain’s. MailerZ will not strip plus tags on your domain the way Gmail does on gmail.com.

SMTP in one paragraph you can reuse

Authenticated SMTP is a second hop. Copy host, port, and TLS together from the dashboard. Set From to an identity you created. Free has no send-as. Solo starts that hop at $40 per year. Unauthorized send is 550 / 550 5.7.1. Do not paste a Gmail password into WordPress. Do not mail SMTP secrets to support. Send a 550 line, a timestamp, and a Message-ID.

Reply flow in Gmail

When a forwarded message lands, Reply uses Reply-To if present, else Header From. It does not automatically send as hello@yourdomain. That requires Send mail as with the SMTP pair. If you skip it, you reply as the Gmail address. Customers then write the Gmail next time and your domain branding dies in one thread. That is not an MX failure.

“Send mail as” and “when replying, use the same address” are Gmail UI choices. They are not MailerZ settings. MailerZ approved the From. Gmail still has to use it. If the From reverts, check the identity, the SMTP secret, and whether you are on Free.

How the four layers show up in one customer email

A buyer writes hello@. MX delivers to MailerZ. The hello alias forwards to Gmail. You read it. You click Reply. If send-as is attached, the buyer sees hello@ in their inbox. If not, they see you@gmail.com. If leftover MX was still Google, they wrote a Workspace user you already deleted and you never saw the thread. One story, four layers.

SPF, DKIM, DMARC sit beside SMTP

Inbound forward uses SRS on the envelope so Gmail’s SPF check can pass for the hop. That is not your domain’s outbound SPF. When you send as the domain, publish the sending records MailerZ shows. DMARC on the domain without outbound alignment is a later fight. Do not paste random include: mechanisms from a blog. Confirm the live dashboard.

A complete worked story

A thread that blamed Gmail for leftover MX

A founder could send as hello@ from Gmail and could not receive. Support asked for MX. Google was still the better-preference host. SMTP and Reply were fine. Alias existed. Layer one was the ghost. They deleted leftover MX, waited, probed from Outlook, and the same Gmail identity started receiving. They had been about to recreate SMTP credentials.

A week later Reply showed the personal Gmail on a customer thread. Layer four. They had never checked “treat as an alias” and “reply from the same address.” Four layers, two weeks, two different bugs. The map would have saved the first week.

Operator brief

A longer operator brief for custom domain gmail mx smtp alias

Teams that bookmark Custom Domain Email for Gmail: MX, Alias, SMTP and Reply Flow Explained usually arrive after a missed invoice, a form that never notified anyone, or a migration that looked clean in one resolver. The useful brief is still boring. Name the store. Name the printed local-parts. Name the nameservers that actually answer. Publish one MailerZ MX set. Delete leftover hosts. Probe from a mailbox that is not the destination. Only then talk about custom domain gmail mx smtp alias as a send-as, catch-all, or comparison problem.

MailerZ remains inbound MX plus authenticated SMTP around Gmail or Outlook. Envelope SRS only. Header From, Subject, Date, Message-ID, body, and MIME stay intact. It is Mail Box portal webmail, not IMAP, not POP, and not an open relay. Unauthorized send is 550 / 550 5.7.1. Free cannot finish send-as: SMTP and API stay off. Solo is $40 per year when the domain From must travel. Starter is $8 or $80. Business is $19 or $190. Agency is $39 or $390. Unlimited is $99/month or $990/year. Confirm the live pricing page. Those numbers are ceilings, not an inbox-placement service-level agreement.

If leftover Google, Microsoft, Cloudflare routing, or registrar MX is still public, stop widening custom domain gmail mx smtp alias. The map you built never saw that copy. Priority numbers are an order, not load balancing. A higher preference host is idle while a leftover host still accepts mail. Save the old MX set before you delete anything. Check more than one public view because TTL lies.

Catch-all forward is not a safety feature for custom domain email for gmail mx alias smtp and reply flow explained. Hold unknowns on everyday production. Review the store. Promote a leftover only when a real person used it. Paid forward belongs to a dated cutover. Fan-out of unknowns into two inboxes trains two spam buttons. Plus addressing on Gmail is not a custom-domain unknown policy. MailerZ will not strip plus tags on your domain the way Gmail does on @gmail.com.

Send-as is a second hop. Creating an inbound alias does not approve outbound. Catch-all does not mint a From. Copy the dashboard host, port, and TLS pair together. Set From to an identity you created. Do not paste a Gmail password into a CMS, a cron file, or a ticket. Do not mail SMTP secrets to support. Send a 550 line, a timestamp, and a Message-ID. Rotate if a secret already leaked.

Self-send from Gmail to the same Gmail account can short-circuit. That green result is why people swear custom domain gmail mx smtp alias works while customers vanish. Use a second provider. Put a unique subject on the probe so delivery history is searchable. If Header From was rewritten by some other forwarder, authentication stories get noisier. MailerZ does not rewrite Header From on inbound.

Agencies should keep custom domain gmail mx smtp alias per client zone. Separate SMTP credentials. Do not pour every client into one catch-all because the spreadsheet got long. Agency plan capacity exists so you can hold more domains and aliases. It does not replace a named list. Offboard means delete MX you own, revoke SMTP, and stop forwarding leftovers into the agency inbox.

Legal and security questions have published answers on the security, privacy, terms, DPA, and subprocessors pages. MailerZ is not SOC 2, not ISO 27001, and not HIPAA. The 14-day Free store, the 90-day Solo–Agency store, and the 180-day Unlimited store are recovery windows for hops this layer saw. They are not an archive and not legal hold. If counsel wants eDiscovery, buy eDiscovery.

Comparisons only help after the hop is honest. Cloudflare Email Routing is inbound routing. A privacy-mask product hides a destination on a provider domain. A suite hosts mailboxes, Calendar, and admin. Proton-class mailboxes encrypt a store. MailerZ is the delivery layer when you already have Gmail or Outlook and you need a domain route you can prove. Cite the other product’s documentation. Do not invent feature parity.

When Custom Domain Email for Gmail: MX, Alias, SMTP and Reply Flow Explained is closed, the next physical action is a lookup and a probe, not another tab. Start free on one domain you can break. Sign in if the zone already lives here. Review quarterly, or sooner after a nameserver move, a plugin swap, or a staff departure. That is how custom domain gmail mx smtp alias stays a runbook instead of an incident.

A second worked pass for custom domain gmail mx smtp alias: write the last change on a sticky note before you open the dashboard. Nameserver move, leftover MX, new form plugin, contractor laptop, or a registrar forwarding toggle are the usual five. MailerZ history only shows hops that reached this layer. If the sticky note says leftover MX, you do not have a custom domain gmail mx smtp alias mystery. You have a split. Delete the leftover. Wait for TTL. Probe again.

A third worked pass: print the public list. If you cannot print it, you are not ready for production unknowns and you are not ready for a bigger alias ceiling. Unlimited aliases as marketing will not save a missing list. Three named aliases on Free are enough to stop printing a personal Gmail on a homepage. Grow the list when a real person used a leftover, not when a harvest guessed admin@.

More working detail

A four-line runbook you can paste into a ticket

Line 1: public MX hosts and who should own them. Line 2: printed aliases and destinations. Line 3: which Froms are approved for SMTP and which plan pays for them. Line 4: whether Gmail Send mail as is attached and whether Reply uses that identity. If a ticket cannot fill four lines, you are not debugging custom domain Gmail MX SMTP alias. You are guessing.

Most “it used to work” stories change one line and then poke the other three. A nameserver move changes line 1. A staff departure should change line 2 and line 3. A Gmail UI reset changes line 4. MailerZ history helps line 3’s inbound cousin — hops that reached this layer — and does not rewrite line 4 for you.

WordPress, cron, and a ticket desk are extra SMTP clients on line 3. Each needs the same From discipline. Each can 550 independently. Do not share one password across all three plus Gmail. Rotate if chat already has the secret. Do not mail the secret to support. Send the 550, the timestamp, and the Message-ID.

DMARC reporting can tell you who is sending as the domain besides MailerZ. That is line 3 visibility, not an inbox SLA. If a leftover host still sends, fix that host. Do not widen catch-all because a report looks busy.

When you teach a new teammate, walk one real message through the four lines instead of touring every dashboard. The map sticks. The dashboards do not.

One more working distinction

Why Gmail “via” is not an SMTP layer failure

A via line is often a header story from some other hop, not proof MailerZ SMTP is down. Check whether inbound Header From was rewritten by a leftover registrar forwarder still in the path. MailerZ does not rewrite Header From. If via appears only on outbound, look at the Send mail as identity and the SMTP pair, not at MX. Mixing those screenshots in one ticket is how four layers become one myth.

FAQ

What is the safest way to handle custom domain gmail mx smtp alias?
Treat MX, alias, SMTP, and Gmail Reply as four layers. Publish one MX set, create named aliases, probe inbound, then attach paid SMTP and Send mail as only for Froms that must travel.
Does this require a new mailbox?
No. MailerZ is Mail Box portal webmail (Inbox, Sent, New email). It is not IMAP or POP. Gmail or Outlook remains the store unless you separately buy a hosted mailbox product.
Will it work with Gmail or Outlook?
Yes for inbound when the destination is a verified mailbox. Branded replies need paid send-as plus Gmail Send mail as or a manual Outlook SMTP identity. Free has no send-as.
What DNS records are involved?
A verification TXT, one MailerZ MX set on the authoritative nameservers, leftover host MX removed, and SPF, DKIM, and DMARC if you also send as the domain.
What should I test before production?
Send a uniquely titled message from an unrelated provider into each named alias. Confirm Header From and delivery history. Do not email yourself from the same Gmail account.

Key takeaways

  • Four layers.
  • Name the failure.
  • MX first.
  • Alias is inbound.
  • SMTP is outbound.
  • Reply is Gmail.
  • Free has no SMTP.
  • No leftover MX.

Conclusion and next action

Explain custom domain Gmail as MX, alias, SMTP, and Reply. Fix one layer at a time. MailerZ runs the first three. Gmail runs the fourth.

Start free to prove inbound. Sign in if SMTP 550 is the current layer.

Fix the layer that failed

Start free on inbound. Pay when a From must travel.

Do not debug Reply when leftover MX is the ghost.

Review quarterly, or sooner if Gmail, Workspace, or MailerZ scope changes. Author: MailerZ editorial, Secuno LLC.