Gmail mailed-by, signed-by and via: which ESP sent it?

Open any newsletter in Gmail on desktop and click the small arrow under the sender's name. Two lines in that panel, mailed-by and signed-by, name the domains that handled the message. Most people searching for the meaning of Gmail's mailed-by and signed-by labels want to know whether an email is safe. We read the same panel for a different reason. On a competitor's newsletter it usually tells you which ESP sent it, in two clicks, with no trip through Show original.

What mailed-by and signed-by mean in Gmail: the short answer

Mailed-by is the domain in the message's Return-Path, the bounce address, and Gmail shows it when that domain passes SPF. Signed-by is the d= domain from the DKIM signature. "via" appears when the domain the message was sent from doesn't match the domain in the From address. If any of them reads sendgrid.net, amazonses.com or mcsv.net, you have your ESP.

That covers most newsletters. The rest of this piece is about where each label comes from, which of them our own detector reads and which it ignores, and why a well-run sender's labels go blank on you.

Where Gmail shows mailed-by and signed-by

Not in Show original. On desktop, open the message, then (in Google's words) "below the sender's name, click the Down arrow." The panel lists from, to, date and subject, then mailed-by, signed-by and a security line. On Android, Google's help page has you tap View details, then View security details. The raw source has more, but for a first read this panel is faster.

Google treats the panel as a safety check. A domain next to mailed-by and the sending domain next to signed-by mean the message is authenticated. A question mark next to the sender's name means it isn't. That's a weaker test than it sounds, because a phisher who owns a lookalike domain can pass SPF and DKIM without trouble. Authentication proves which domain stands behind the mail. It says nothing about whether that domain is honest.

One practical note. The panel describes one message, not one company. Plenty of brands send campaigns from one platform and receipts from another, so a password reset and a newsletter from the same company can show different domains here. Check the newsletter.

Mailed-by is the Return-Path, and that's what we read

Under RFC 5321, the sending server announces a bounce address in the SMTP MAIL FROM command, and the receiving server writes it into a Return-Path header at final delivery. Failed deliveries go there, so it has to point at whoever processes bounces. For most newsletters that's the ESP, not the brand. Gmail checks that domain against SPF, and when it passes, the domain shows up as mailed-by.

The Return-Path is also one of two fields our platform detector treats as high-confidence evidence. The other is Message-ID. Our rules look for these domains in the bounce address: sendgrid.net for SendGrid, amazonses.com for Amazon SES, createsend.com for Campaign Monitor, klaviyomail.com for Klaviyo, hubspotemail.net for HubSpot, mktomail.com for Marketo, appboy.com for Braze (its name before the 2017 rebrand), and anything containing "mailgun". A domain match there, or a proprietary header like SendGrid's X-SG-EID, gets a high-confidence label. When the only clue left is the List-Unsubscribe domain, we call it medium.

The rules run in a fixed order and the first match wins, with Mailchimp checked first. Amazon SES gets one extra check the others don't: if the topmost Received header mentions both "ses" and amazonaws.com, that counts too. For the full per-platform table, including the non-Return-Path signals, see how to tell which email platform a newsletter uses.

Signed-by is the DKIM d= domain

Every DKIM-signed message carries a DKIM-Signature header. RFC 6376 calls its d= tag the signing domain identifier: the domain that takes responsibility for the message and whose DNS holds the public key. Gmail shows that domain as signed-by. The s= tag beside it is the selector, which tells the receiving server which key to fetch, at selector._domainkey.domain.

Our own ESP rules ignore the DKIM signature entirely. A separate metrics step pulls the dkim=pass or dkim=fail result from the Authentication-Results header, but that tells you whether the signature checked out, not who signed it. So in our workflow signed-by is a manual signal. It's still worth reading by hand, because it sometimes names the platform when the Return-Path has been rebranded.

The selector can still give the platform away. When a brand authenticates its own domain, the selector record in DNS is often a CNAME that points straight back at the ESP. We checked live DNS while writing this: k2._domainkey.mailchimp.com is a CNAME to dkim2.mcsv.net, and s1._domainkey.twilio.com resolves to a host under sendgrid.net. Signed-by says the brand, and the DNS behind it says the platform. How to find what ESP a company uses walks through the selector method step by step.

What "via sendgrid.net" tells you

Google's help page is plain about it. You see "via" and a website name next to the sender when the domain the message was sent from doesn't match the domain in the From address. Recipients can't remove it. Senders can, and Google gives three steps: an SPF record that includes the vendor's servers, a DKIM signature associated with your own domain, and a From domain that matches the domain you authenticate with.

On newsletters, the name after "via" is usually the ESP's shared domain. Word to the Wise described the same behaviour in 2011, when Gmail began showing authentication data to recipients: if an ESP signs with its own domain, Gmail shows the signer next to the sender's address. Fifteen years on, the label still works the same way.

This is the same mismatch DMARC cares about. RFC 7489 requires the From domain to match either the SPF-authenticated domain or the DKIM d= domain, and relaxed alignment lets a subdomain like news.brand.com count for brand.com. Google has required that alignment from bulk senders, those sending more than 5,000 messages a day to Gmail, since February 2024. Our bulk sender requirements breakdown has the rest of that rulebook.

So here's how we read it. On your own newsletter, "via" is a fix-this-week item. It usually means your mail authenticates as the ESP rather than as you, and at bulk volume that's a DMARC problem long before it's a cosmetic one. On a competitor's newsletter, it tells you the ESP and that nobody finished domain authentication. That's common on smaller programs and on brands mid-migration, when the new platform is live but the DNS work isn't done. If a competitor's label flips from one ESP's domain to another, read how to tell if a brand switched ESP.

The better the sender, the less Gmail shows

This is the catch. A sender that has done the setup properly points its Return-Path at its own subdomain and signs DKIM with its own domain. Both labels then show brand.com, there's no "via", and the panel tells you nothing about the platform. That's the point of the setup. It also means the competitors most worth studying, the ones with a deliverability person on staff, are the ones this trick fails on.

So you fall back on what Gmail doesn't put in the panel. Proprietary headers don't change when a sender authenticates its own domain, and our rules check SendGrid's X-SG-EID and Mailchimp's X-MC-User alongside the bounce domain. The List-Unsubscribe endpoint is hard to rebrand, and Gmail's one-click unsubscribe requirement means bulk senders can't drop the header. Our detector rates a List-Unsubscribe-only match as medium, because a generic-looking endpoint isn't always what it seems. Brevo's list-unsubscribe.me is in our rules for exactly that reason. Then there's DNS. The bounce subdomain's SPF record has to authorize the platform's servers, and the selector CNAME, where there is one, usually points home.

Doing this by hand for one competitor takes a couple of minutes. Doing it every week for twenty is where a tracker earns its keep, since Newsletrix records the detected platform on every issue it ingests. If you're comparing trackers, here's how Newsletrix compares with Sendview.

The Mailchimp exception: mcsv.net

Mailchimp is the platform people meet most often in this panel, as "via mcsv.net". Mailchimp's own help center says the sender address is based on its sending servers and usually contains mcsv.net, mcdlv.net, mailchimpapp.net or rsgsv.net. None of those say Mailchimp, which is why so many people end up searching for them.

Our detector doesn't match any of those four domains. It catches Mailchimp through its own headers, X-MC-User and X-Mailchimp, or mailchimp.com in the Return-Path or Message-ID. That holds up because Mailchimp stamps X-MC-User on campaign mail. But it's a gap: a Mailchimp message without those headers, with only mcsv.net in the bounce address, would slip past our high-confidence rules. We'd rather say so than pretend the rule set is complete.

DNS is clearer. Mailchimp's SPF include is servers.mcsv.net, which the ESP Checker maps to Mailchimp, and its domain authentication asks for two DKIM CNAME records plus a DMARC TXT record. Once a brand finishes that setup, Mailchimp says the extra "via" information goes away. The bounce address is a separate matter, so read mailed-by on its own instead of assuming it moved too. For how the three records fit together, see SPF, DKIM and DMARC explained.

Next time a competitor's issue lands, click the arrow before you read the copy. A shared ESP domain is your answer, so note it and move on. Their own domain in both lines is information too: someone on their team cared enough to set it up, and the SPF record is where you go next.

Frequently asked questions

What does mailed-by mean in Gmail?

Mailed-by shows the domain of the message's Return-Path, the bounce address the sending server gives in the SMTP MAIL FROM command (RFC 5321). Gmail displays it when that domain passes SPF. On a newsletter it is often the ESP's bounce domain, such as sendgrid.net or amazonses.com, unless the sender has set up its own bounce subdomain.

What does signed-by mean in Gmail?

Signed-by shows the d= domain from the message's DKIM signature, the domain that vouches for the message under RFC 6376. If it shows the brand's own domain, the sender has set up DKIM for that domain. If it shows a platform domain like mcsv.net or sendgrid.net, the ESP signed on the sender's behalf.

Why does Gmail say 'via sendgrid.net' next to the sender?

Google shows 'via' and a domain when the domain the message was sent from does not match the domain in the From address. 'via sendgrid.net' means SendGrid's shared domain authenticated the message instead of the sender's own domain. It tells you the ESP is SendGrid and that the sender has not finished domain authentication.

How do I remove 'via' from my newsletter in Gmail?

Google lists three steps: publish an SPF record that includes your ESP's servers, sign with a DKIM key associated with your own domain, and make sure the From domain matches the domain you authenticate with. In practice that means finishing your ESP's domain authentication setup, which usually adds DKIM CNAME records to your DNS. Recipients cannot remove the label themselves.

What does a question mark next to the sender mean in Gmail?

Google says a question mark next to the sender's name means the message is not authenticated, and advises care before replying or downloading attachments. On a newsletter you subscribed to, it usually points to a missing or broken SPF or DKIM record on the sender's side rather than a fake sender, but check the From address before you click anything.

Related reading