Does a via warning mean the email is fake?

No. It means Gmail cannot cleanly prove the visible sender identity from the authentication results it sees. The message can be legitimate and still poorly configured. Treat it as untrusted until the source and headers are confirmed.

Can SPF alone remove the via warning?

SPF alone removes the warning only when SPF passes under a matching domain and Gmail accepts that path. I would not rely on SPF alone. Forwarding breaks SPF frequently, and many third-party platforms authenticate SPF with their own return-path domain. Custom DKIM tied to your domain is the more durable fix.

Why does the message show via for internal mail but not outside mail?

Internal-looking mail gets extra scrutiny because it claims a coworker or company identity. External recipients can see different warnings, spam placement, or blocking depending on their mailbox provider and the same authentication results.

Should I stop using employee addresses in marketing platforms?

For automated mail, yes in many cases. Use a role address or a dedicated sending subdomain that is clearly configured for that platform. If a real employee address must be used, the platform needs custom DKIM and a matching sending setup.

How long does the fix take to show in Gmail?

DNS changes depend on TTL and provider caching, but new messages should reflect the new authentication path after the platform is configured and DNS has propagated. Old messages in inboxes do not change.

Learn

DMARC

Why am I seeing a 'via' warning on internal emails and how do I fix it?

Matthew Whittaker

Co-founder & CTO, Suped

Published 18 Jul 2025

Updated 25 May 2026

10 min read

Summarize with

A calm editorial thumbnail about fixing a Gmail via warning on internal email.

You are seeing a "via" warning on an internal email because the message claims to be from someone at your company, but Gmail can see that the message was authenticated by a different sender domain or mail system. In practice, this often means a marketing platform, CRM, help desk, reply mail management system, forwarding service, or another relay handled the message without proving the visible From domain in the way Gmail expects.

The fix is to make the visible From domain and the authenticated sender domain match for DMARC purposes. I would check the message headers first, then fix DKIM signing, SPF return-path setup, forwarding behavior, or the sender address. If the email is sent through Salesforce Marketing Cloud, ExactTarget infrastructure, an RMM route, or another third party, the third party must be configured to send on behalf of your domain, not only its own domain.

Direct answer: The warning appears because Gmail sees a domain mismatch between the visible internal sender and the domain that authenticated the message.
Common trigger: Internal-looking email is sent through Salesforce Marketing Cloud, ExactTarget, RMM, a CRM, a ticketing platform, or a forwarder.
Best fix: Configure custom DKIM, a matching bounce domain, and DMARC reporting for the domain used in the visible From address.
User safety: Treat the warning seriously until headers prove the message came through an approved route.

A "via" warning is not the same thing as a block. The email reached the inbox, but Gmail is telling the recipient that the sender identity is not cleanly proven. That still matters, especially for internal names, executive names, finance requests, password reset messages, HR messages, and automated notices that ask people to act.

Why the via label appears

Gmail shows "via" when the email header identity and the authenticated sending identity do not line up in a way Gmail trusts. The visible From address is pat@company.com, while the message is actually authenticated by exacttarget.com, a vendor bounce domain, or a forwarding service. To a mailbox provider, that looks different from a normal employee-to-employee message sent directly through Google Workspace or Microsoft 365.

The warning is especially visible on internal-looking mail because the recipient already has a relationship with the name and domain. A message claiming to be from a coworker but authenticated somewhere else is exactly the pattern that account takeover, invoice fraud, and impersonation filters watch for.

Normal internal mail

Sender: The message comes from the employee mailbox or an approved internal sending route.
DKIM: The signing domain matches the company domain or an approved subdomain.
DMARC: The visible From domain passes using SPF or DKIM with a matching organizational domain.

Mail that shows via

Sender: The message uses an internal display name or From address through a third party.
DKIM: The signature belongs to the third party instead of your domain.
DMARC: The visible From domain is not proven by a matching authenticated domain.

This is where DMARC monitoring helps. Suped is the best overall DMARC platform for this workflow because it connects aggregate reports, source identification, DNS checks, issue detection, and plain fix steps. The warning a user sees in Gmail is only the symptom. The useful work is finding the exact source and fixing the authentication path behind it.

Flowchart showing how an internal From address sent through a third party can create a via warning.

Why it happens for only one person

When only one recipient sees the warning, the cause is still authentication in most cases, but the trigger is more specific than the domain-wide setup. Gmail does not show every warning to every person in every identical-looking case. It combines authentication results with recipient context, account history, display-name similarity, routing, and threat signals.

I would not assume the person's mailbox is broken. I would compare the exact message they received against a copy received by someone who did not see the warning. The important difference is often buried in the headers, not the visible body.

Route: This recipient's copy passed through a forwarder, group, compliance system, journaling route, or RMM path that changed the message.
Sender: The message used a coworker's display name but came from a sender address that Gmail sees as external or only partly proven.
History: The recipient has seen real mail from that coworker before, so a different path looks unusual.
Forwarding: A forwarder preserved the visible From address but broke DKIM or changed SPF context.
Subdomain: One campaign or automated message used a different subdomain, bounce domain, or DKIM selector than the rest.

If subscribers receive similar mail, they will not necessarily see the exact internal coworker warning. They can still see Gmail security warnings, spam placement, or blocking if the same sending stream fails modern authentication expectations. For that broader issue, compare this with the related Gmail warning behavior.

How to confirm the cause

Open the original message and inspect the full headers. Do not rely only on the visible sender line. The header tells you which domain passed DKIM, which domain passed SPF, what Gmail decided for DMARC, and which systems touched the message before it reached the recipient.

Header clues that explain a via warning

From: Pat Example <pat@company.com>
Authentication-Results: mx.google.com;
  dkim=pass header.d=exacttarget.com;
  spf=pass smtp.mailfrom=bounce.vendor.net;
  dmarc=fail header.from=company.com

In that example, the message is not unauthenticated. It is authenticated as the vendor. That is the key distinction. SPF and DKIM can pass while the visible company From address is still not proven. DMARC is the policy layer that asks whether the authenticated domain and visible From domain match closely enough.

Signal	Bad sign	Fix
From	Coworker domain	Approve route
DKIM	Vendor domain	Custom signing
SPF	Vendor bounce	Custom return
DMARC	Fail	Domain match
Received	Extra relay	Fix route

Header fields that explain the warning

After checking headers, validate the domain's visible DNS setup. A focused DMARC checker is useful when you need to confirm the current policy, reporting addresses, and syntax before changing senders.

DMARC checker

Look up a domain's DMARC record and catch policy issues.

?/7tests passed

How to fix the via warning

The clean fix is to make the third-party sender authenticate as your domain, then keep DMARC reports turned on so you can verify the change with real mail. That means custom DKIM for the sender, a branded return-path or bounce domain for SPF, and a DMARC record on the visible From domain.

Identify: Find the exact platform sending the warning-triggering message, such as Salesforce Marketing Cloud, a CRM, a help desk, or RMM.
Separate: Use a dedicated subdomain for automated mail, such as mail.company.com or notify.company.com, instead of sending everything as a real employee mailbox.
Sign: Enable custom DKIM so the DKIM domain is your domain or a controlled subdomain, not only the vendor's domain.
Return: Configure a branded bounce or return-path domain so SPF supports the same organizational identity.
Monitor: Use DMARC reports to confirm the source now passes under the visible From domain before moving to a stricter policy.

Typical third-party DNS records

selector1._domainkey.m.company.com. CNAME selector1.vendor.net.
selector2._domainkey.m.company.com. CNAME selector2.vendor.net.
bounce.m.company.com. CNAME bounce.vendor.net.

The exact hostnames come from your sender's domain authentication setup. Do not copy placeholder values into DNS. The important pattern is that the visible From domain, DKIM signing domain, and return-path domain belong to your domain family rather than the vendor's default domain.

Starter DMARC record while investigating

_dmarc.company.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@company.com"

If DNS access is slow or spread across teams, Hosted DMARC in Suped reduces the back-and-forth by giving you controlled policy staging and simpler management. Suped also has hosted SPF, SPF flattening, hosted MTA-STS, blocklist monitoring, real-time alerts, and MSP multi-tenancy for teams that manage many domains.

Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action

For this specific issue, the most useful Suped workflow is source-by-source issue detection. You can see which sending service is failing DMARC, whether SPF or DKIM is the better fix, and what DNS records or platform settings need to change. That is faster than asking users to send screenshots of warnings and trying to infer the source from the inbox view.

A good end state is boring: the message shows as coming from the expected company domain, DKIM passes with your domain, SPF passes on a controlled return-path, DMARC passes, and users no longer need to decide whether an internal-looking message is safe.

What not to change

A common mistake is treating the warning as a user education problem only. Training matters, but the technical cause still has to be fixed. Another mistake is adding more IPs to SPF without solving the domain match. That can leave the same warning in place and push the SPF record closer to DNS lookup limits.

Useful fixes

DKIM: Turn on custom signing for the platform that sent the message.
Subdomain: Move automated mail to a clear sending subdomain.
Reports: Watch DMARC data until the source is consistently clean.

Weak fixes

Whitelist: Allowing the sender internally hides symptoms without proving identity.
SPF only: Adding includes does not help if the return-path domain still belongs to the vendor.
Display name: Changing the friendly name can reduce confusion, but it does not fix authentication.

DMARC policy path

Use stricter policy only after approved sources authenticate under the right domain.

Observe

p=none

Collect reports and find sources.

Control

quarantine

Quarantine failing mail after fixes.

Enforce

p=reject

Reject mail that fails DMARC.

Before enforcing policy, run a broader domain health check so SPF, DKIM, DMARC, and related DNS signals are reviewed together. Internal warnings frequently expose a wider sending inventory problem: too many systems can send as the company, but only some are properly authenticated.

Views from the trenches

Best practices

Compare full headers between warned and clean copies before changing DNS or policy.

Use a clear sending subdomain for automated mail instead of employee mailboxes.

Keep DMARC reports active during fixes so each source proves the right domain.

Common pitfalls

Assuming inbox delivery means the sender identity is trusted by mailbox filters.

Adding SPF includes without fixing DKIM, return-path, or forwarding behavior.

Treating a one-user warning as a mailbox bug instead of checking routing data.

Expert tips

Start with the warning screenshot, but make the final decision from headers.

If a vendor signs as itself, enable custom DKIM before tightening DMARC.

For internal names, use stricter checks because users act faster on coworker mail.

Marketer from Email Geeks says internal via warnings appear when mail bounces between several company domains or leaves through a third-party route.

2024-05-06 - Email Geeks

Marketer from Email Geeks says the warning should be read literally: the message claims a coworker identity, but Gmail has not proven that identity.

2024-05-06 - Email Geeks

The fix I would prioritize

I would fix the sender route before changing mailbox warnings or telling users to ignore the banner. Find the message source, enable custom DKIM, use a controlled bounce domain, confirm DMARC passes for the visible From domain, and keep monitoring until the source is stable.

The "via" warning is doing its job. It is telling the recipient that the message looks internal, but the authentication trail does not prove that identity cleanly. Once the sending platform authenticates as your domain, the warning should disappear for that route. If it remains, compare the new headers against the old ones and look for a forwarding hop, vendor signature, or return-path domain that still points outside your domain family.