How to receive hello@yourdomain.com in a free Gmail account

Quick answer for receive custom domain email in gmail

Create hello@ as a named alias. Map the free Gmail you already read. Verify the domain. Publish MailerZ MX. Delete leftover suite MX. Send a unique subject from a mailbox you do not own. Open Gmail. That is receive custom domain email in Gmail.

Custom domain Gmail does not require a paid Gmail plan. Consumer Gmail works as a destination. Google Workspace is a different product if you still publish their MX.

Email forwarding to Gmail is this hop. Gmail send as is not required to receive. Founders skip receive and fight SMTP first. Reverse that.

Free holds unknown recipients. info@ will not arrive unless you created it. Print only names you mapped.

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

hello@ is printed on a landing page before MX is honest. Ads run. Mail vanishes at leftover Google. The founder thinks Gmail blocked a stranger.

People create hello+team@ and expect plus addressing on a custom domain. That is a Gmail-mailbox feature. On your domain, the full local-part must exist or be held.

Two founders share one hello@ destination without a reply owner. Both answer as personal Gmail. The receive hop worked. The social contract failed.

Criteria: is hello@ created, is MX one operator, did an external probe land, and do you need send-as at all.

Technical mail flow for receive custom domain email in gmail

RCPT TO hello@yourdomain → alias match → Gmail destination. Header From is the stranger. SRS may rewrite the envelope.

If hello@ is not created, Free holds the message in the store. It does not invent a mailbox.

Gmail labels are Gmail. Primary versus Promotions is not MX.

Replies without send-as leave as the Gmail address. Customers then learn the store. Pay if that is unacceptable.

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.

gmail send as

Treat hello@ as inventory. Write it down. Then click.

1. Add domain and verify TXT.
2. Create hello@. Map free Gmail.
3. Publish MX. Delete leftovers.
4. External probe with unique subject.
5. Confirm From and history.
6. Decide send-as separately.
7. Add billing@ or support@ only if printed.
8. Review leftover MX after DNS changes.

Failure modes and proof

Leftover MX.

hello@ never created.

Self-send green, world red.

Catch-all flood into the same Gmail.

SMTP on Free.

MailerZ workflow and product boundary

Free is built for this exact hello@ story. Three aliases. Hold unknowns. 14-day store. No send-as. Upgrade when From must travel.

Not IMAP. Not Workspace. Not an SLA.

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

email forwarding to gmail

$0 to receive hello@. $40/year Solo to send as hello@. A Workspace seat is the wrong invoice for one printed string.

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

Put hello@ on the site only after the probe. That one delay saves a week of “did you get my email.”

If you already printed it, cut MX the same day you create the alias.

A second destination for a cofounder is optional. Name who answers.

Do not use the Gmail address on the homepage “until DNS works.” That leak is permanent.

Abuse@ and postmaster@ are later articles. hello@ is the brochure name.

Agencies: per-client hello@, per-client Gmail or a shared ops inbox you can remap.

If Gmail is full, that is a quota problem at Google, not MailerZ inbound.

Filters that archive hello@ make you think receive failed. Search the unique subject.

Mobile Gmail shows the same Header From. If it differs, you have two paths.

Keep the verification TXT. Deleting it later can break dashboard checks depending on product state — follow the dashboard, not a blog screenshot.

Longer operator notes

Why hello@ is inventory

hello@ is not a vibe. It is a local-part you created or you did not. On Free, unknown names are held. If you printed hello@ and created info@, the brochure address is the one that fails. Read the list. Create the printed name. Map the free Gmail. That is the whole receive story.

Plus addressing on your Gmail account does not create hello@ on the domain. sales+launch@gmail.com is a mailbox feature. hello@yourdomain is a named alias. Do not mix the vocabularies in a ticket.

Three aliases fit Free. If the site also prints support@ and billing@, that is the Free budget. A fourth printed name is a plan conversation or a shorter site. Do not enable catch-all to paper over a fourth string you refuse to create.

When to put hello@ on the homepage

After the external probe lands in Gmail and MailerZ history shows the hop. Not after verify TXT turns green. Not after you “added MX” in the wrong panel. After the stranger path.

If hello@ is already on ads, cut MX the same day you create the alias. Every hour of leftover Google is a customer you will not see. Save the old MX set first so you can roll back a bad Friday.

Do not put the personal Gmail on the homepage “temporarily.” Scrapers keep it forever. The alias was supposed to hide that string.

Sharing hello@ without a fight

Two founders can both receive if you add a second destination on purpose and write who answers. Two founders both sending as personal Gmail is a different mess. Receive can be shared. Reply ownership should not be.

Filters that auto-archive hello@ make you think receive failed. Search the unique subject before you rip MX.

If Gmail is over quota, Google will refuse or delay. That is not leftover MX. Check the store. Free MailerZ inbound cannot enlarge a Gmail quota.

Abuse@ and postmaster@ are operational names you should add when you are ready. They are not hello@. Do not skip hello@ because a checklist mentioned postmaster first.

Agencies: a shared ops Gmail as destination during build is fine if you remap to the client before launch. Forgetting the remap is how you read their customers for a year.

Consumer Gmail is a valid destination. You do not need a paid Google account to receive hello@. You need an honest MX set. Workspace MX leftover will still steal the copy even if you “only wanted forwarding.”

Solo exists when hello@ must also send. Do not point WordPress at MailerZ SMTP on Free. The receive article ends at the inbound probe unless you explicitly start the send-as week.

More operational detail

Copy for the homepage after proof

After the probe, print hello@yourdomain — not the Gmail string, not a plus tag, not a form-only promise if people still write email. If you also have a form, the form is a later SMTP article. hello@ inbound is this one.

If marketing wants five public names, you are off Free or you shorten the site. Do not silently catch-all. Held unknowns are safer than a flood in the same Primary tab as invoices.

A misspelled helo@ during launch is a leftover you can promote after you see it in hold. That is inventory. It is not a reason to forward all unknowns forever.

Mobile users who “never got hello@ mail” often have a filter or a full inbox. Search All Mail for the unique subject before you accuse MX.

If you share Gmail with a spouse, say that out loud. Destination risk is part of alias security. hello@ into a shared consumer inbox is a choice.

Do not create hello@ on two forwarders. One MX set. One map.

International senders still need the same cut. There is no regional MX exception in this product story.

When hello@ is boring for a month, you can talk send-as. Boring is the goal.

MailerZ Free remains 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 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 or POP. Mail Box is portal webmail, not SOC 2, not ISO 27001, not HIPAA, not an inbox-placement promise.

A complete worked story

Launch day without printing too early

A founder wants hello@ on the ads that go live Friday. It is Wednesday. They still have leftover Google MX. The correct move is to slip the ads or to finish the cut, not to print the personal Gmail “for 48 hours.” Scrapers will keep the Gmail string for years. Receive custom domain email in Gmail is supposed to hide that string.

They create hello@ on Free, map consumer Gmail, cut MX, and get a colleague to send a unique subject Thursday morning. History is populated. Gmail has the message in All Mail, not lost in a filter. Thursday afternoon the ads can print hello@. That is the only honest Friday.

If they also printed support@ without creating it, those leads sit in hold. They open the store, create support@, and map it. They do not turn on catch-all forward because Friday feels late. Held leftovers are kinder than a spam flood in the same tab as invoices.

Two founders share hello@ as destinations. They write that A answers. B reads. If both send as personal Gmail, customers see a mess. Receive can be shared. Reply ownership should not be. Send-as waits until they pay.

Consumer Gmail quota is their problem if the inbox is full. MailerZ inbound cannot enlarge Google’s store. Search the unique subject before ripping DNS. Filters that archive hello@ are also their problem. MX did not fail.

Free remains one domain, ten aliases, unknown held, no send-as. hello@ plus two other printed names is the budget. A contact form that must send as hello@ is a later paid week. This article ends at receive unless they explicitly start that week.

Operator brief

A longer operator brief for receive custom domain email in gmail

Teams that bookmark How to Receive hello@yourdomain.com in a Free Gmail Account 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 receive custom domain email in gmail 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 receive custom domain email in gmail. 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 how to receive hello yourdomain com in a free gmail account. 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 receive custom domain email in gmail 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 receive custom domain email in gmail 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 How to Receive hello@yourdomain.com in a Free Gmail Account 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 receive custom domain email in gmail stays a runbook instead of an incident.

A second worked pass for receive custom domain email in gmail: 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 receive custom domain email in gmail 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@.

FAQ

What is the safest way to handle receive custom domain email in gmail?

Create hello@ as a named alias, publish one MailerZ MX set, delete leftover hosts, and probe from another mailbox. Do not rely on catch-all. Free cannot send as hello@.

Does this require a new mailbox?

No. Consumer Gmail is enough as a destination.

Will it work with Gmail or Outlook?

Yes. This page uses Gmail as the example store.

What DNS records are involved?

TXT verify, MailerZ MX, leftover MX gone. Sending records only if you also send.

What should I test before production?

Unique subject from an unrelated provider into hello@. Confirm it is not held as unknown.

Key takeaways

• hello@ is a named alias.
• Free Gmail can be the destination.
• One MX set.
• External probe.
• Free has no send-as.
• Hold unknowns.
• Do not print before proof.
• No suite required.

Conclusion and next action

Receive hello@ in free Gmail by mapping a name, cutting leftover MX, and proving a stranger can reach you.

Start free on one domain. Sign in if hello@ already exists and the lookup still shows Google.

Pay only when replies must say hello@.

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