Why Does My Email Say "via" Someone Else's Domain?
A customer sent you a screenshot of your last email. Under your name, in small grey text, Gmail printed via sendgrid.net. Your address sits right there in the From line. It’s your own domain. So why is Gmail telling people that somebody else sent this?
Gmail isn’t wrong. A sendgrid.net server really did hand over this message, and none of the hidden domains inside it matched yours. The “via” line is Gmail saying so out loud. And it’s easier to fix than it looks.
What the “via” line is
Every email carries two sender addresses. The From: header is the one your reader sees. The envelope sender is the one mail servers use. You find it in the headers as Return-Path:, and it belongs to the machine that carried your message. A third domain shows up too: the d= field of the DKIM signature. It names the domain that signed the message.
Google’s documentation states the rule plainly. Gmail shows “via” and a domain name next to the sender when the domain the message came from doesn’t match the domain in the From address. Line up either the envelope domain or the signing domain with your From domain, and the line goes away.
These are the headers of a message that shows via sendgrid.net, cut down to the two parts that matter:
Return-Path: <bounces+e81f-jane=example.org@sendgrid.net>
From: Ana <ana@example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=sendgrid.net; s=smtp1; ...
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of bounces+e81f@sendgrid.net
designates 198.51.100.24 as permitted sender)
dkim=pass header.i=@sendgrid.net
dmarc=fail (p=NONE dis=NONE) header.from=example.comRead those lines like a receiver does. SPF passed, but for sendgrid.net. DKIM passed, but for sendgrid.net too. The sender everyone can see is example.com, and nothing ties the two together. Gmail printed the honest summary of that mess under the sender name.
Do this: open one message that shows the marker, hit “Show original”, and find the Return-Path: line and the d= inside DKIM-Signature:. The domain you find there is the one in your “via” label. Now you know which platform sends your mail unaligned.
Why it matters
The line costs you twice.
First, the human cost. Gmail shows “via” so people can spot mail that claims one origin but arrives from another. That’s the shape most phishing takes. So Gmail just invited your reader to distrust the message. Replies drop. Nobody tells you why.
Second, the technical cost. When both the envelope domain and the signing domain belong to someone else, DMARC alignment fails. That’s exactly what the dmarc=fail line above records. Alignment, in one sentence: a message passes DMARC only if the domain that passed SPF or the domain that signed with DKIM matches the domain in the From line. We call that match alignment. Both of your checks currently run through someone else’s domain, and that one condition causes the marker and a chunk of spam placement. If your mail also lands in junk, start with the full spam diagnostic after you finish here.
Do this: treat the “via” line as an alignment bug you can see. The fix below also restores DMARC.
The three causes, ranked
Cause one: you never set up your platform to send as your domain
Most “via” lines come from this. Every ESP, invoicing tool, helpdesk, and course platform sends through its own gear by default. And by default, the envelope sender and the DKIM signature both name the platform’s domain.
The defaults look the same everywhere. Mailchimp signs with mailchimpapp.net until you authenticate the domain, which is the exact case the Mailchimp post walks through. Amazon SES uses an amazonses.com envelope until you set a custom MAIL FROM domain, and the SES post covers that one. SendGrid signs as sendgrid.net until you authenticate a sending domain. None of this is the platform acting up. You just haven’t finished the setup, and nobody warned you.
The tell: Return-Path: and d= both name the platform, and you never published DNS records for it. The email health check will show the missing records.
What to do: turn on the platform’s custom sending domain. The fix section below shows how.
Cause two: the setup is half done
The dashboard nags about DKIM records, so most people publish those. The return path subdomain is easy to skip. Sometimes the reverse happens: the envelope moved onto your domain, the DKIM CNAMEs never resolved, and the signature still names the platform.
Here’s why half works, for a while. The two alignment paths are alternates. Either one, lined up with your From domain, satisfies DMARC and removes the “via” line. Publish one set and skip the other, and everything works until the aligned half breaks. Then the marker comes back. No error anywhere. A DKIM selector rotation or an expired key on the ESP side does exactly that.
The tell: one of the two domains is yours and the other still names the platform. The SPF cousin of this state, where the record exists but lists the wrong senders, is in the SPF failure post.
What to do: publish everything the platform asked for, envelope subdomain and signature records together.
Cause three: a forwarder sent your message again
Sometimes your setup is fine and the marker is still honest. When a message goes through a mailing list or a company’s auto-forward, that machine sends it again under its own envelope. SPF and the original signature no longer match the new hop, so the recipient’s provider shows “via” the forwarding domain.
The tell: your own copy in Sent shows aligned domains, and the “via” domain is one you’ve never heard of. It often belongs to the recipient’s own employer or a list manager. Ask the person where the message landed.
What to do: nothing on your side fixes this one. The forwarder re-sent your mail, so that’s their action to fix. Check that your own headers line up, then treat the rest as information. This case is also why receivers built ARC, which carries alignment verdicts across hops. That’s the receiving side’s problem, not yours.
The fix
The steps are the same at every platform, though each one calls it something else. Mailchimp says authenticated domain. SendGrid says sending domain authentication. SES says custom MAIL FROM.
The platform hands you DNS records. A SendGrid-style set looks like this:
em123.example.com. CNAME u123.wl.sendgrid.net.
s1._domainkey.example.com. CNAME s1.domainkey.u123.wl.sendgrid.net.
s2._domainkey.example.com. CNAME s2.domainkey.u123.wl.sendgrid.net.The first entry moves the envelope onto your subdomain, so Return-Path: ends in em123.example.com and SPF aligns. The other two let the platform sign with your domain, so d=example.com shows up in the signature and DKIM aligns. For how to publish records like these, including the hostname quirks at different DNS providers, read the DKIM setup guide. We won’t repeat those steps here.
Once the records resolve, the headers tell the story clearly:
Return-Path: <bounces+e81f-jane=example.org@em123.example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...
Authentication-Results: mx.google.com;
spf=pass (... domain of bounces+e81f@em123.example.com ...)
dkim=pass header.i=@example.com
dmarc=pass (p=NONE dis=NONE) header.from=example.comBoth legs now name example.com. DMARC passes. Gmail has nothing to print after the sender name.
Do this: publish the full record set, wait out the TTL, and send a fresh test to the same mailbox that showed the marker.
Check that the fix worked
Paste the new message into the free header analyzer and check three things: the envelope domain, the d= domain, and the dmarc= verdict. All three should name your domain now, and the message should show no “via” line.
Then confirm the DNS from outside the platform’s dashboard. The email health check reads your records the way a receiver does, so it catches things like a CNAME pasted against the wrong hostname while the platform still says “pending verification”.
Both tools answer for one message, on one day, on one domain.
What the one-off check can’t see
This fix is a state, not an event. The alignment holds only as long as the records hold. Routine things break them quietly: a DNS migration drops the CNAMEs, a platform rotates its DKIM selectors, someone adds a new tool under your domain and it starts sending through its own default setup. Every one of those brings the “via” line back. None of them sends an error. You find out weeks later, from a customer’s screenshot.
So we built the watching part. LitInboxes re-checks your SPF, DKIM and DMARC records every six hours, stamps every change with a date so you can trace a break to the day it started, and alerts you when a record moves. You don’t have to remember to look. Email alerts are on every plan, and Slack, Discord and webhook alerts are on Pro. There’s a live demo if you want to see it first.
The checklist
- Open one message that shows the marker. Choose “Show original”.
- Find the domain in
Return-Path:and in the DKIMd=field. That’s your “via” domain. - Find the custom sending domain setting at that platform and start it.
- Publish every record it hands you. Yes, the envelope subdomain too.
- Wait out the DNS TTL. Send a fresh test to the same mailbox.
- Confirm with the header analyzer that both domains and the DMARC verdict now name your domain.
- Run the email health check to confirm the records from outside the platform.
- Put the records on a watch cycle, weekly by hand or with continuous monitoring. The marker comes back quietly when one breaks.
How to remove the "via" line from your emails
- Read the headers of one message that shows the markerOpen the message in Gmail, use the three-dot menu and choose Show original. Note which domain appears in Return-Path and in the DKIM-Signature d= field. That domain is the one Gmail prints after "via".
- Turn on the custom sending domain at your platformIn your sending platform, look for authenticated domain, custom domain, or dedicated sending domain, and start the setup for the domain in your From address. The platform hands you DNS records to publish.
- Publish the return path and DKIM recordsThere are normally two kinds: a subdomain for the envelope sender, often called return path or MAIL FROM, and one or two DKIM CNAMEs under _domainkey. Publish all of them, not just the DKIM set.
- Wait out the DNS TTL, then send a fresh testDNS changes need a new message to prove themselves. Old records sit in cache for a while, so test again after an hour, and use the same mailbox that showed the marker.
- Confirm the domains now line upRead the new message's headers: Return-Path and d= should name your domain, dmarc should read pass, and Gmail should show no "via" line under the sender name. The header analyzer lays this out in one view.
Frequently asked questions
Does the "via" line mean someone hacked my email account?
No. It means the machine that sent the message belongs to a different domain than the one in your From address. Any sending platform does this until you finish its setup. If you suspect a break-in, check the sent folder and your recent sign-ins instead.
Does "via" send my email to spam?
Not by itself. It's a display marker, not a verdict. But the condition behind it, a failure of both DMARC alignment paths, does hurt placement. Treat the marker as a symptom of that bigger problem.
"Via" still shows even with the records in DNS. Why?
Three possibilities: the DKIM CNAMEs resolved but the return path record didn't, the test message left before DNS finished spreading, or a forwarder or mailing list re-sent the message under a third domain. A fresh test to a direct address separates the first two from the third.
Can the recipient hide the "via" line?
No. Gmail builds it from the message's own authentication results, so only the sender can remove it, by lining up the sending domain with the From domain. No setting on either side hides it for unaligned mail.