Custom Domain + Gmail

Why Gmail shows “via” on forwarded mail and how to avoid it

via is Gmail’s UI, not an MX record. Do not rewrite From to hide it. Prove the hop. Do not promise it will never appear.

MailerZ editorial · Secuno LLC17 min read

Gmail shows “via” on forwarded mail when Gmail’s interface decides a message arrived through another hop. It is a client label, not a DNS type. You reduce surprises by keeping Header From intact, using one MX operator, and not rewriting the author. You cannot buy a guarantee that Gmail will never display via. MailerZ does not promise that, and this page will not invent an SLA.

Gmail forwarded email via: UI label versus intact Header From
via is a Gmail sentence. From is a header.

Quick answer for gmail forwarded email via

Treat gmail forwarded email via as a display question. Read Header From first. If From is the original author and MX is one operator, you did the honest work. If From was rewritten by an old forwarder, fix that. Email forwarding to Gmail should not restamp the author.

Custom domain Gmail still stores the copy. Gmail send as does not remove via on inbound mail. Those are opposite directions.

Avoid leftover MX so Gmail does not see two personalities for the same printed address.

Do not file a ticket asking us to “turn off via.” We do not control Gmail’s UI. We control headers we do not rewrite and MX you publish.

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. 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

Founders see via and assume customers see a scam. Sometimes customers see a normal From. Check the actual header before you panic-buy Workspace.

Hosts sell From-rewrite as the via fix. You trade identity for a label. Authentication suffers. Spam can get worse.

Self-send never shows the via story the world sees.

Criteria: is From intact, is MX single, did an external probe match, and are you asking for a UI promise we cannot give.

via versus things you control
ThingWho owns itYour move
via labelGmail UIDo not chase with From rewrite
Header FromYour forwarder policyKeep original
MX setYour DNSOne operator
Inbox tabGmailNo SLA

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

Start free — one domain

Technical mail flow for gmail forwarded email via

Gmail receives a forwarded copy, evaluates authentication, and may annotate the hop in the UI. That annotation is not an MX preference number.

SRS on envelope is visible to mail systems, not always to humans. via is the human sentence Gmail chose.

Outbound send-as does not edit inbound via on old threads.

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, not webmail, 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.

Forward path Gmail may annotate
One operator and intact From is the control you actually have.

gmail send as

You do not configure via. You configure MX and a non-rewriting forwarder.

  1. External probe.
  2. Read From.
  3. Read authentication results if you can.
  4. Public MX lookup.
  5. Delete leftovers.
  6. Do not enable a rewriter.
  7. Do not promise via will vanish.
  8. Document what customers actually see on a real inbound.

Failure modes and proof

From rewrite “fix.”

Leftover MX.

Ticket: remove via.

Self-send.

Inbox SLA request.

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

Open leftover MX troubleshooting

MailerZ workflow and product boundary

We keep Header From intact. We may SRS the envelope. We do not control Gmail labels. We do not claim via never appears.

Not SOC 2. Not an inbox promise.

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

What not to do: From rewrite to hide via
Hiding via by restamping From breaks authentication.

email forwarding to gmail

Free can prove From. Paying more does not purchase a via-off switch. Workspace can still show hop UI depending on how mail arrived.

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. 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 legal the header, not a marketing sentence about via.

If a client demands “no via,” write that Gmail owns the label. Sell intact From instead.

Mobile and desktop Gmail can word the hop differently. Check both if the ticket is heated.

A mailing list via is a different via. Do not mix list-id tickets with MX tickets.

Do not add ARC claims we do not publish as a product badge.

Spam folder plus via is two issues. Split the ticket.

Agencies: screenshot From, not the via chip, as the acceptance test.

If via appeared after a host move, leftover MX is still the first lookup.

Customers who forward to you from their own Gmail add another hop you do not own.

Quarterly, re-read Google’s help. UI copy changes. Our header policy does not chase it.

Longer operator notes

What you can say to a nervous founder

via is a Gmail sentence about a hop. Header From is who wrote the mail. Customers usually see From. If From is the customer or the vendor who wrote, you did the honest work. If you restamped From to hide via, you taught Gmail a stranger authored the thread. That is worse than a chip.

We will not promise the chip never appears. Google changes UI. We do not control it. Anyone who sells “via removal” as a feature is selling a From rewrite or a lie. Ask which.

Desktop and mobile can word the hop differently. If the ticket is heated, screenshot both plus the header. Argue from the header.

List-id via versus MX via

Mailing lists add their own via stories. Do not mix a newsletter hop with your domain MX ticket. Split the Message-ID and the List-Id. Your leftover MX will not explain a Google Group.

Customers who forward to you from their Gmail add a hop you do not own. You cannot MX that away. You can still keep From intact on your segment.

Authentication-Results are more useful than the chip. Read them. Do not invent ARC as a MailerZ badge.

Procurement language

If a security questionnaire asks “will Gmail show via,” answer that Gmail owns display, MailerZ does not rewrite Header From, and leftover MX is treated as a stop. Point at /security for controls. Do not invent SOC 2 to make the row green.

Agencies: acceptance test is Header From on an external probe, not absence of via. Write that in the SOW or you will inherit a UI argument forever.

Do not file “remove via” as a Sev-1. File leftover MX or a From rewrite if those exist. If they do not, the ticket is education.

Send-as will not edit via on old inbound threads. Opposite direction. Say it twice on the call.

If via appeared after a DNS change, look at NS and leftover hosts before you open Gmail settings. The chip is downstream of the hop.

Spam plus via is two issues. Placement is Gmail. Identity is From. Split them or you will rewrite From to “fix spam” and make both worse.

More operational detail

Language for sales and support

Sales may say “customers see your author.” Support may say “Gmail may still annotate a hop.” Both can be true. Do not let sales promise no via. Do not let support rewrite From to make sales true.

If a competitor screenshot shows no via, they may be rewriting From, running a suite, or using a different Gmail experiment. Do not copy a screenshot as physics.

Internal forwards inside Gmail add more via stories. Those are Google-to-Google. They are not your MX.

Print this for the next onboarding: acceptance = Header From on an external probe. via is informational. Spam is a third ticket.

If a founder is embarrassed by via on a screenshot in a pitch deck, change the screenshot to a header view. Pitch the author, not the chip.

Do not add a CNAME or a vanity MX to “look native.” Native is leftover suite MX and a split.

Revisit Google’s UI copy quarterly. Our header policy stays: no From rewrite.

If via is the only complaint and From is intact, close the ticket as education. Offer leftover MX audit if they have not done two public views.

MailerZ Free remains one domain, three 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, not webmail, not SOC 2, not ISO 27001, not HIPAA, not an inbox-placement promise.

A complete worked story

A pitch-deck argument you can end

A founder is embarrassed by a via chip on a screenshot. They want From rewritten so the chip dies. That is the worst trade in this cluster. Customers read From. Gmail owns the chip. MailerZ will not restamp the author to decorate a slide. Change the screenshot to a header view. Pitch the original sender.

Sales language: customers see the author we did not rewrite. Support language: Gmail may still annotate a hop. Write both in the SOW. If sales promised no via, you inherited a UI argument you cannot win. Fix the SOW, not the headers.

A competitor slide with no via may be a suite, a rewrite, or a Gmail experiment. It is not physics. Do not copy it into leftover MX.

List-id via from a newsletter is a different ticket. Internal Gmail forwards are a different ticket. Your MX via story, if it exists, is still diagnosed with leftover hosts and From, not with a CNAME that “looks native.”

Acceptance test remains Header From on an external probe. via absence is not a pass. Spam is a third ticket. Split them or you will rewrite From to “fix” all three and break authentication.

Procurement that asks about via gets: Gmail owns display; we do not rewrite Header From; leftover MX is a stop; controls are on /security; we are not SOC 2. Close the row without a badge.

Operator brief

A longer operator brief for gmail forwarded email via

Teams that bookmark Why Gmail Shows via on Forwarded Mail and How to Avoid It 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 gmail forwarded email via 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 not a hosted mailbox, not IMAP, not webmail, 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 gmail forwarded email via. 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 why gmail shows via on forwarded mail and how to avoid it. 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 gmail forwarded email via 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 gmail forwarded email via 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 Why Gmail Shows via on Forwarded Mail and How to Avoid It 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 gmail forwarded email via stays a runbook instead of an incident.

A second worked pass for gmail forwarded email via: 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 gmail forwarded email via 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 gmail forwarded email via?
Keep Header From intact, publish one MX set, and prove inbound from another mailbox. Do not rewrite From to hide Gmail’s via label. MailerZ does not control that UI.
Does this require a new mailbox?
No.
Will it work with Gmail or Outlook?
via is a Gmail display. Outlook has its own hop wording. Headers are the shared truth.
What DNS records are involved?
MX and leftover removal. via is not a record you publish.
What should I test before production?
External probe. Screenshot Header From. Do not treat via absence as the pass test.

Key takeaways

  • via is Gmail UI.
  • Keep Header From.
  • One MX set.
  • No From rewrite.
  • No via SLA.
  • Send-as is outbound.
  • External probe.
  • No SOC 2 story.

Conclusion and next action

Do not hunt a via toggle. Hunt leftover MX and From rewrites. Prove inbound. Leave Gmail’s adjectives to Gmail.

Start free and run the From probe. Sign in if From is already intact and the argument is only the chip. If procurement still wants a via-off switch, give them the header policy and the security page — not a From rewrite and not a badge we do not have.

Fix the hop, not the adjective

Start free and prove Header From on an external probe.

Do not rewrite From to chase a Gmail label.

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