Can I remove the via label from emails my customers already received?

No. Gmail shows it to the reader, and Google states that a recipient cannot turn it off. Once you authenticate with your own domain, new messages stop carrying it, but messages already delivered keep whatever they were sent with.

Does the via label mean my email went to spam?

Not on its own. It reports which domain was authenticated, not a filtering decision. It usually sits next to a real deliverability problem though, because the same mismatch is what makes DMARC fail.

We only send from Google Workspace. Why does ours say gappssmtp.com?

Because no DKIM key was ever generated for your domain. Google signs with a default key on a gappssmtp.com domain until you publish your own. Generating the record in the Admin console and adding the TXT record to your DNS is the fix.

Gmail via label: why it appears and how to remove it

The screenshot usually comes from whoever sends the invoices. It is their own invoice email, opened in Gmail on a phone, and next to their company name sits a small extra fragment: their name, then the word via, then a company their customer has never heard of. Sometimes it is the marketing platform. Sometimes it is a string ending in gappssmtp.com. The question attached to it is always a version of the same one: does this make us look like a scam?

Nobody at the business changed anything. The invoice is real, the mail is arriving, and no filter has blocked it. Gmail is simply telling the recipient something the sender never meant to say. Here is what the label reports, how we confirm the cause in about ten minutes, and the DNS work that removes it.

What Gmail is reporting when it prints via

Gmail shows via and a website name next to the sender's name when the domain a message was sent from does not match the domain in the From: address. Google's help page uses the everyday version of the example: mail that looks like it came from an address at one domain, but was handed to Gmail by a different service. The label is not a spam verdict and it is not a warning. It is a disclosure.

Two details decide how seriously to take it. The recipient cannot switch it off, because Google shows it so the reader knows where messages come from, which means asking customers to ignore it is not an option. And the same label appears on mail sent to a Google Group from a domain that publishes a DMARC policy of p=quarantine or p=reject, which is a separate cause with a separate answer.

So treat the label as a symptom. The condition underneath it is that the identity you authenticated with and the identity you display to customers are not the same identity.

Mailed by and signed by, the two rows underneath

Open the message in Gmail on a computer and expand the details beneath the sender. You get up to two rows, and Google is direct about how to read them: a message is authenticated if you see a mailed-by header with the domain name and a signed-by header with the sending domain. If a question mark sits beside the sender's name instead, the message is not authenticated at all, which means Gmail does not know whether it came from whoever it appears to come from.

Those two rows map onto the two authentication methods:

mailed-by is the domain Gmail used for the SPF check. That is the envelope sender, also called the return path or the bounce address. It is not the address your customer reads.
signed-by is the domain in the DKIM signature, the value of the d= tag defined in RFC 6376.

When either of those domains belongs to someone else, Gmail has authenticated someone else, and it says so on the envelope your customer opens. That is the entire mechanism.

The three setups where we find it

A Workspace tenant that never published its own DKIM key

This one surprises owners most, because the mail is leaving Google's own servers. If you do not set up a DKIM key for your domain, Google signs outgoing messages with a default key whose domain ends in gappssmtp.com instead of yours. That was still the documented behaviour when we checked the Admin Help page on 7 October 2026. The signature is valid and the mail is properly signed. It is just not signed as you. Messages sent from servers that are not Google's are not covered by that default key at all.

A platform still sending on its own domain

Marketing tools, CRMs, help desks, invoicing software and store platforms all ship with a shared sending domain so a new account works on the first day. Until someone finishes the domain authentication step inside that product, the d= value stays theirs. If this is your case, our notes on Mailchimp, HubSpot and Klaviyo and on SendGrid, Mailgun and Amazon SES list the exact records each product asks for.

Mail to a Google Group from a domain at quarantine or reject

Here the label is a side effect of doing the right thing. A group rewrites or relays the message, so the sending domain stops matching the From: domain, and Gmail discloses it. Nothing in DNS needs fixing. The group's own forwarding settings are the place to look, and the label on internal list mail is not worth chasing.

What we check first, in order

We ask for one message a real recipient received, forwarded as an attachment or pasted as its original source. A screenshot is not enough, because the answer is in the headers. Then we read three things before anyone touches DNS.

The Authentication-Results line: which identity passed, and which domain it belonged to.
The d= value in the DKIM-Signature header, compared against the From: domain.
The Return-Path, compared against that same From: domain.

A message carrying the problem looks like this:

Authentication-Results: mx.google.com;
       dkim=pass header.d=mailer.sendingplatform.example;
       spf=pass smtp.mailfrom=bounces.sendingplatform.example;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yourcompany.com

Both checks pass. Neither one passed for you. DMARC fails as a result, and Gmail prints the disclosure. If you want the same reading on your own message without waiting for us, paste the headers into the analyzer above, or work through how to read email headers at your own pace.

The fix, by setup

For Google Workspace, the record comes from the Admin console: open Apps, then Google Workspace, then Gmail, choose Authenticate email, pick the domain, and generate a new record. The default selector prefix is google, which is the recommended one. Publish what it gives you as a TXT record and then turn on authentication in the console.

google._domainkey.yourcompany.com.   TXT   "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

For a third-party platform, Google's instruction for anyone sending through a bulk mailing vendor or affiliates is to publish an SPF record that includes the IPs the vendor sends from, and to sign messages with a DKIM signature associated with your domain. In practice that means completing the product's domain authentication so the d= value becomes a name under your domain, and setting a custom return path or custom bounce domain wherever the product offers one, so the SPF identity lines up too. Aligning one of the two is enough for DMARC. Aligning both is what clears the label and survives a provider changing its defaults.

Count your lookups while you are in there. Every vendor include spends part of the ten-lookup SPF budget, and a record that already sits at the limit will break quietly when you add another sender.

Why this is more than a cosmetic problem

Google's sender guidelines ask for SPF and DKIM, a DMARC record whose policy may be p=none, and that the From: domain align with either the SPF domain or the DKIM domain. RFC 7489 calls that identifier alignment, and it is the pass condition for DMARC. Senders above 5,000 messages a day to Gmail accounts have had to meet those requirements since 1 February 2024.

An unaligned d= is therefore the same defect that makes DMARC fail, and a domain whose real mail fails DMARC can never be moved to p=reject without losing invoices. The via label is simply the only part of that defect your customers can see. Fixing the label and fixing the authentication are the same job.

What we watch after the change

DNS first: the TXT record has to be visible publicly, not just saved in the panel. Then a test message to a Gmail address, checking that signed-by now reads your domain and that dmarc=pass appears in the headers. Then the aggregate reports for a week or two, because a business usually has more senders than it remembers, and the reports are where the forgotten printer, the accounting software and the old newsletter tool show up. Only after that does raising the policy make sense.

How Guanacos Tech helps

We take this as one scoped piece of work: find every system sending as your domain, align the ones that should, shut the door on the ones that should not, and leave you with records you can explain to whoever manages your DNS next. How we work sets out how an engagement runs. The commercial point is simple enough: a customer who stops to ask whether an invoice is genuine is a customer who has not paid it yet. Our email deliverability consulting for small business page is the place to start. A 30-minute call is enough to tell you which of the three setups above you are in and what the fix involves.

Why Gmail shows via next to your company name, and how to stop it