# Why Gmail shows "via" next to your sender name, and what fixes it

> Gmail shows "via" when the sending domain does not match your From domain. Recipients cannot hide it; you remove it by authenticating your own domain.

- Published: 2026-11-03
- Author: Koltrix Team
- Category: Deliverability
- Source: https://koltrix.com/blog/why-gmail-shows-via-next-to-your-sender-name-and-what-fixes-it

When Gmail prints "Jane Doe via some-service.com" instead of plain "Jane Doe", it is telling the reader that the message was handled by a domain other than the one in the From address. You cannot remove it from the receiving side, and the fix is on the sending side: make the message authenticate as your own domain.

Most of the advice you will find on this was written years ago for a different Gmail. This post explains what the label means today, which two checks decide whether it appears, and how to confirm it is gone.

## What does "via" next to a sender name mean in Gmail?

The "via" label means the domain a message was sent from does not match the domain in its From address. [Google's help page](https://support.google.com/mail/answer/1311182) lists that mismatch as the trigger, gives a message routed through another service as the example, and states plainly that "you can't remove the 'via' next to someone's name." Google also notes it appears when a message from a domain with a `p=reject` or `p=quarantine` DMARC policy is delivered through a Google Group, where the group's name appears with "via".

So the label is not an error and not a spam verdict. It is a disclosure. It does tell a careful reader that the mail left through someone else's infrastructure, which is why a recipient who sees an unfamiliar name after "via" may be suspicious.

## Which domains does Gmail compare?

Gmail compares your From domain with the domains that SPF and DKIM actually validated. Those two domains are different things, and that is the whole trick.

| Check | Domain it proves | Where you see it in Gmail "Show original" |
| --- | --- | --- |
| SPF | The envelope sender (Return-Path) domain is allowed to use the sending IP | `SPF: PASS with domain ...` |
| DKIM | The domain in the signature's `d=` tag signed the message | `DKIM: 'PASS' with domain ...` |
| What readers see | "mailed-by" is the SPF domain, "signed-by" is the DKIM domain | In the message details dropdown |

If you send from `jane@yourcompany.com` through a provider and the message is signed with `d=yourcompany.com`, the signing domain matches the From domain and the label stays away. If the only valid signature is `d=provider-mail.net` and the Return-Path is also the provider's, nothing ties the message to `yourcompany.com`, so Gmail shows "via provider-mail.net".

This is the same idea as DMARC alignment, covered in [DMARC alignment: relaxed vs strict](/blog/dmarc-alignment-relaxed-strict). If you want the full picture of the three standards first, start with [SPF, DKIM and DMARC in plain English](/blog/spf-dkim-dmarc-in-plain-english).

## What actually removes the "via" label?

Authenticate the message with a DKIM signature on your own domain; that is the dependable fix. A matching SPF domain helps, but SPF alignment alone depends on a custom Return-Path, which many senders do not set up, so DKIM is the lever to pull first.

1. **Find who really sends the mail.** Open one affected message in Gmail, choose "Show original" and read the `Authentication-Results` header. Note the `header.i` or `d=` value on the DKIM line and the `smtp.mailfrom` value on the SPF line.
2. **Enable custom domain authentication at the sender.** In the sending service's domain settings, add your domain and publish the DKIM records it gives you (usually CNAME or TXT records at a selector such as `s1._domainkey.yourcompany.com`). The mechanics are in [DKIM for third-party senders](/blog/dkim-for-third-party-senders).
3. **Set a custom Return-Path if the service offers it.** This moves the SPF-checked domain to a subdomain of yours, such as `bounces.yourcompany.com`. The background is in [From, Reply-To, envelope sender and Return-Path explained](/blog/from-reply-to-envelope-sender-return-path-explained).
4. **Send a new test message** after DNS has propagated, and read "Show original" again. You want `DKIM: 'PASS'` with your domain, and "signed-by" showing your domain in the details dropdown.

Messages sent before you made the change keep their old headers, so an old thread will still show "via". Judge the fix on a fresh send.

## Why do I still see "via" after adding DKIM?

If "via" persists after DKIM is set up, one of these is usually the cause, in rough order of how often it happens:

| Symptom | Likely cause | Fix |
| --- | --- | --- |
| `DKIM: 'PASS' with domain provider.net` | Your records are not live, or the service signs with its own key | Re-check the selector records; confirm the service uses your domain's key |
| Two DKIM signatures, one yours | Yours may be failing while the provider's passes | Read each signature's result in Show original and fix the failing one |
| Looks fixed in tests, "via" in one app | A second system also sends as your domain (helpdesk, billing, CRM) | Authenticate each system separately |
| Message sent through a Google Group | The group re-sends it; Google lists this as a case | Not something your DNS can change |
| The reader's client, not Gmail | Different clients show their own labels | See the next section |

Each system that sends as your domain needs its own signing set up. One authenticated tool does not cover the others, which is why a domain can look right in the marketing tool and wrong in the support desk.

## Is "on behalf of" the same thing?

No. "On behalf of" is a different label, mostly seen in Outlook, and it is driven by a different header. A mail client or service can add a `Sender` header (defined in [RFC 5322](https://www.rfc-editor.org/rfc/rfc5322)) that names the actual submitter when it differs from the From address. Some clients render that as "Sender on behalf of From". Authenticating your domain does not remove it; you remove it by not setting a different `Sender`, or by sending from the mailbox you want to show. If your team uses delegated or "send as" access, check which permission is in use, because "send on behalf" and "send as" behave differently in Microsoft 365.

## What about mail sent from your own mailboxes?

Mail written in a mailbox on your own domain, with DKIM signing for that domain, has the sending domain and From domain in agreement, so there is nothing for Gmail to flag. In Koltrix, each connected domain is signed with its own 2048-bit DKIM key, which is why people sending from their Koltrix address do not hit this label; the reasoning is in [why Koltrix signs each domain with its own DKIM key](/blog/why-koltrix-signs-each-domain-with-its-own-dkim-key). The same applies to the transactional email API and SMTP relay when you send from a verified domain. Check your domain's status in the dashboard before blaming a recipient's client.

## A ten-minute checklist

- Open a real message in Gmail and read "Show original": note the SPF and DKIM domains.
- List every tool that sends mail as your domain, not just the main one.
- For each tool, publish its DKIM records and, if offered, a custom Return-Path.
- Send a fresh test to a Gmail address and confirm "signed-by" shows your domain.
- Add or keep a DMARC record so you can read reports about the sources you missed.

## Bottom line

"Via" is Gmail showing that the sending domain and your From domain are not the same. Google says you cannot hide it on the recipient side, so the answer is to authenticate every system that sends as your domain with your own DKIM key, then verify on a fresh message. Do that and the label disappears for the senders you control.