How to forward your domain email to Gmail and keep the original sender

Quick answer for forward domain email to gmail

To forward domain email to Gmail and keep the original sender, pick a forwarder that does not rewrite Header From. Point MX at that operator. Map hello@ to your Gmail. Delete leftover hosts. Probe from another mailbox. Open the message. The From should still be the stranger who wrote it, not a restamped forwarder identity.

Custom domain Gmail is the store. Email forwarding to Gmail is the hop. Gmail send as is unrelated to keeping the inbound author. People mix those sentences and then “fix” inbound by pasting SMTP passwords.

SRS on the envelope is the allowed rewrite. It exists so SPF at the next hop can pass for the bounce path. It is not a license to change the visible author. RFC 5321 describes the envelope. The header block is what Gmail shows.

If your old registrar forwarder rewrote From, moving to MailerZ is a header fix as much as an MX fix. Prove it with a unique subject and a screenshot of From, not with a self-send.

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

Support tickets say “we lost the customer’s address.” Often the address is still in Reply-To or the body, but From was rewritten so Gmail threaded the mail as the forwarder. Keeping the original sender restores reply behavior humans expect.

Some hosts rewrite From to survive DMARC at Gmail. That is a trade: delivery versus identity. MailerZ takes the other trade: intact From, SRS on envelope. Inbox placement is still Gmail’s. No SLA.

Leftover MX means some copies still hit the rewriter. You will see two behaviors and call it flaky Gmail. It is two operators.

Criteria: do you need the real author visible, do you have one MX set, and will you probe from outside Gmail.

Technical mail flow for forward domain email to gmail

Sender → MX → MailerZ accepts alias → SRS on envelope → Gmail destination. Header From is copied through. Authentication-Results at Gmail describe the hop Gmail received.

If a previous hop already rewrote From, MailerZ cannot un-rewrite history. You can only stop doing it on your MX.

Reply from Gmail without send-as uses the Gmail identity. That does not change the inbound From you just preserved. It changes what the customer sees on the way out. Pay if that matters.

DMARC alignment on inbound is about the sender’s domain versus their DKIM/SPF. Your forwarder should not become the Header From.

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

The setup is the inbound cut plus a From check. Skip SMTP until From is honest.

1. Screenshot From on a current forwarded message if you still have one.
2. Verify the domain on MailerZ. Create the printed aliases.
3. Publish one MX set. Delete leftover forwarding MX.
4. Send from a second provider. Open Gmail. Read Header From.
5. Compare Message-ID and Subject to what you sent.
6. Only then decide on send-as.
7. Hold unknowns. Do not catch-all-forward to “see everyone.”
8. Re-test after any host change that might restore a From rewrite.

Failure modes and proof

From shows the forwarder. You are not on MailerZ yet, or leftover MX still wins.

From is correct in one client and wrong in another: two MX paths.

Self-send shows your Gmail as From. That test never left Google.

People reply and you answer as Gmail. Inbound From was fine. Outbound identity is a different hop.

Spam folder with intact From. Placement is not identity. See the spam article when you write it — until then, do not rewrite From to “fix” spam.

MailerZ workflow and product boundary

MailerZ exists to keep the original sender visible while Gmail stores the copy. Delivery history shows the hop. Recovery windows are 14/90 days, not an archive.

We will not rewrite From to chase a Primary tab. We will not claim SOC 2.

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

email forwarding to gmail

Free is enough to prove intact From. Solo starts send-as. A suite does not automatically keep From intact if you still run a rewriting forwarder beside it.

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

Show a founder the From line before and after the cut. That screenshot sells the hop better than a feature list.

IMAP hosts that rewrite From to the mailbox user are a different product. You left that product when you chose forwarding.

ARC is not something this article invents as a MailerZ badge. If Gmail shows authentication results, read them. Do not invent ARC claims.

Keep Reply-To only if the sender set it. Do not stamp your own Reply-To to “help.”

Agencies: per-domain From proof. One client’s rewriter is not a house default.

If WHOIS or invoices must stay private, that is not a From-header job.

Message-ID staying stable helps threading. We do not rewrite it.

Date headers stay. Do not “fix timezone” at the forwarder.

MIME stays. Attachments should arrive as sent.

If a vendor insists they “must rewrite From,” they are selling a different hop. Walk away or accept the identity loss.

Longer operator notes

Why From rewrites feel helpful and then hurt

A host rewrites Header From so DMARC at Gmail “passes” for the forwarder. Delivery can improve for some streams. Identity dies. Replies go to the forwarder. Threads look like your vendor wrote the customer. You then ask for a via fix and a spam fix and a new vendor. The original mistake was restamping the author.

MailerZ takes the other side: keep Header From, SRS on the envelope only. Inbox placement remains Gmail’s. If a sender is already toxic, intact From will not wash them. If your old host restamped From, moving MX is how you stop adding a second lie.

Show a founder two screenshots: From before the cut and From after. That pair is the product demonstration. Feature adjectives are not.

Reply behavior after an intact inbound

When From is the customer, Reply in Gmail goes to the customer. When From was the forwarder, Reply goes into a hole or a ticket nobody owns. Keeping the original sender is an operations control, not a cosmetic.

What you send back is a different hop. Without paid send-as, the outbound From is Gmail. The customer now has both strings. That is not an inbound From failure. Decide send-as separately after the inbound From is honest.

Do not stamp Reply-To to “help” unless the sender set it. Do not rewrite Date, Message-ID, or MIME. Those fields are how threading and attachments survive. We do not touch them.

Two operators, two From stories

Leftover MX means some senders still hit the rewriter. You will get tickets that say “sometimes From is right.” That is not Gmail being moody. That is two paths. Delete the leftover. Wait for TTL. Probe again from a second provider.

Registrar forwarding products are frequent rewriters. Turn them off on the authoritative zone, not on a courtesy panel at a registrar whose NS already left.

If a vendor says they must rewrite From, they are selling a different hop. Either accept identity loss or leave. Do not run them beside MailerZ “for safety.” Safety is a saved old MX set, not two live primaries.

Agencies: accept a zone only when an external probe shows the original author. Do not accept a zone because the plugin is green.

Legal sometimes asks whether we hide the sender. No. Hiding the destination from the sender is an alias job. Hiding the sender from you would be a broken support desk. This article is the second sentence: you should see who wrote.

Authentication-Results in Gmail are worth reading once you can open them. They describe the hop Gmail got. They are not a MailerZ badge. Do not invent ARC claims.

More operational detail

Header checklist you can print

After the probe, confirm Header From, Subject, Date, Message-ID, and that attachments open. If any of those changed, you are not on a non-rewriting hop — or you are not looking at the copy that came through MailerZ. Leftover MX can deliver a rewritten copy beside an intact one. That is the “sometimes” ticket.

Reply-To should change only if the sender set it. BCC should not appear as To. Those are other classes of broken forwarders. We do not do those either.

If a CRM restamps From after Gmail, that is a CRM problem. Do not rip MX to fix a zap.

Teach support to read From before they ask for a mailbox. Half of “we lost the customer” tickets are rewritten authors.

DMARC failures at Gmail on inbound are usually the sender or a rewrite. Your domain’s SPF does not authenticate a stranger. Stop publishing more SPF includes to “fix inbound spam.”

Agencies: refuse a zone whose current forwarder will not show an original From on a probe. You will inherit their rewrite and their tickets.

Personal privacy aliases are a different aisle. This page is business-domain forwarding into Gmail with a visible author. Do not mix SimpleLogin-style masks into this MX set.

When you cut, tell the founder the first inbound From they should see is a stranger, not the forwarder logo.

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

A support week after a From rewrite

A shop used a registrar forwarder that restamped Header From as noreply@forwarder. Gmail threaded everything as the vendor. Replies went nowhere useful. DNS “looked fine” because MX pointed at that forwarder on purpose. Forward domain email to Gmail and keep the original sender means leaving that product, not adding a second MX beside it.

They screenshot a current From. They cut to MailerZ on the authoritative nameservers. They delete the registrar product. They probe from a second provider. The new From is the customer. Message-ID and Subject match what was sent. Attachments open. Envelope SRS may have changed the bounce path. People do not see that. People see the author.

Some mail still looks rewritten for two days. TTL and a leftover host on a second view explain it. They do not add a third vendor. They wait, look up again, probe again. The “sometimes” ticket dies when only one operator remains.

Outbound is still Gmail until they pay for send-as. Customers who get a reply from a personal Gmail now know the store. That is a separate decision. Intact inbound From did not fail. The From on the way out is a different hop. Solo exists when that hop matters.

They refuse the next host who says they must rewrite From to pass DMARC. That host is selling delivery theater. MailerZ will not restamp the author to chase a Primary tab. Placement stays Gmail’s. No SLA.

Support now reads From before they ask for a mailbox. Half of “lost customer” tickets were rewritten authors. That sentence is why this article is not the receive-hello@ article and not the via article. It is the header article.

Operator brief

A longer operator brief for forward domain email to gmail

Teams that bookmark How to Forward Your Domain Email to Gmail and Keep the Original Sender 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 forward domain email to 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 forward domain email to 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 forward your domain email to gmail and keep the original sender. 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 forward domain email to 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 forward domain email to 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 Forward Your Domain Email to Gmail and Keep the Original Sender 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 forward domain email to gmail stays a runbook instead of an incident.

A second worked pass for forward domain email to 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 forward domain email to 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. Ten 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 forward domain email to gmail?

Use a forwarder that does not rewrite Header From, publish one MX set, delete leftover hosts, and prove From with an external probe. MailerZ rewrites only the envelope with SRS.

Does this require a new mailbox?

No. Gmail remains the store.

Will it work with Gmail or Outlook?

Yes as destinations. This page is the Gmail From-check. Outlook shows the same Header From on the copy.

What DNS records are involved?

MX and verification TXT. Sending records if you also send. Leftover MX undoes the From proof.

What should I test before production?

External probe. Confirm Header From, Subject, and Message-ID. Do not self-send.

Key takeaways

• Header From is the original sender.
• SRS is envelope-only.
• Leftover MX can restore a rewriter.
• Self-send lies.
• Send-as is outbound.
• Free can prove inbound From.
• No inbox SLA.
• No From rewrite to chase spam.

Conclusion and next action

Keep the author. Cut leftover MX. Probe from outside Gmail. Pay later if you must send as the domain.

Next action: one unique subject from a second provider, then read From. Start free on one domain.

Sign in if From is still restamped — leftover host is the first suspect.

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