A practical guide to the domains behind Gmail’s via label, aligned DKIM and SPF, third-party senders, forwarding, and the headers that reveal the real problem.
You send a message from [email protected], open it in Gmail, and see an extra identity beside the sender: “via vendor.example.” The email may still be legitimate and delivered, but the interface is telling the recipient that the visible From identity and the infrastructure Gmail authenticated do not form the clean, direct relationship it expected.
The fix is not merely to add any DKIM signature. The useful goal is aligned authentication: a passing SPF or DKIM identity connected to the domain in the visible From address. For modern bulk sending, configure SPF, DKIM, and DMARC together, then inspect a real received message to confirm the domains—not just the green checkmarks.
What Gmail’s via label is telling the recipient
Google says Gmail can display “via” and another domain when the domain a message was sent from does not match the domain in the From address. Gmail may also expose an unfamiliar sender’s full address beside the display name. These interface cues help recipients inspect who actually handled a message instead of relying on the display name alone.
The label is not an SMTP error, a blocklist listing, or proof that the message is malicious. It is an identity cue. A wanted email can arrive with “via,” and an authenticated malicious email can arrive without it. Still, an unexplained provider domain can confuse customers, weaken brand recognition, and reveal that your authentication is not configured around your own domain.
Northstar via bulk-vendor.exampleThe message claims Northstar in From, while Gmail exposes a different authenticated or sending domain.
NorthstarDKIM signs with an aligned Northstar domain and DMARC passes for the visible From identity.
Northstar via Customer GroupGoogle Groups and other intermediaries can add their own visible routing context even when the original sender is legitimate.
The five domains hiding behind one From line
Recipients may see one display name and address, but receivers evaluate several identities. The domains can be identical, related subdomains, or completely different. Troubleshooting starts by naming each one precisely.
Display name Northstar
Visible From [email protected]
DKIM domain d=mail.northstar.example
SPF domain bounce.mail.northstar.example (Return-Path / MAIL FROM)
Sending hostname outbound-17.vendor.example (PTR / EHLO)
Reply-To [email protected]
DMARC author domain: northstar.example- Visible From: the author address a recipient normally sees and the identity DMARC protects.
- DKIM d= domain: the domain taking responsibility for the cryptographic signature.
- SPF domain: normally the Return-Path or envelope MAIL FROM domain checked against the connecting IP.
- Sending hostname: the server identity used in SMTP and reverse DNS; it does not need to equal the visible From domain.
- Reply-To: the address that receives responses; useful for workflow, but not an authentication identity for DMARC.
A third-party hostname is normal. Email providers need their own infrastructure domains for server identity, routing, and operations. The trust problem appears when neither SPF nor DKIM creates an authenticated identity aligned with the domain the recipient sees in From.
DKIM alignment is the cleanest common fix
DKIM adds a cryptographic signature containing a signing domain in its d= tag and a selector in its s= tag. Your provider signs with a private key; receivers fetch the public key from selector._domainkey.your-domain and verify the signed headers and body.
For sender identity, configure the provider to sign with a domain you control. Under relaxed DMARC alignment, d=mail.northstar.example aligns with a visible From domain of northstar.example because both share the same organizational domain. Strict alignment would require an exact match.
BEFORE
From: Northstar <[email protected]>
DKIM-Signature: ... d=vendor.example; s=shared1; ...
Authentication-Results: dkim=pass
Result: valid signature, but no DKIM alignment with northstar.example
AFTER
From: Northstar <[email protected]>
DKIM-Signature: ... d=mail.northstar.example; s=eb2026; ...
Authentication-Results: dkim=pass header.d=mail.northstar.example;
dmarc=pass header.from=northstar.example
Result: valid and aligned identity- Create the DKIM DNS records exactly as your provider specifies—often CNAME records or a TXT public key.
- Use a selector dedicated to the sending service so keys can rotate independently.
- Enable the domain in the provider after DNS verification; publishing a record alone may not switch signing on.
- Use at least a 1024-bit DKIM key for Gmail and prefer 2048-bit keys when the DNS provider supports them.
- Send a new test after verification because old messages keep their original signatures.
SPF alignment can also make DMARC pass
SPF checks whether the connecting IP is authorized for the envelope domain, commonly shown as the Return-Path. If your provider supports a custom Return-Path such as bounce.mail.northstar.example, a passing SPF result for that domain can align with northstar.example under relaxed DMARC.
A custom Return-Path is useful for alignment and branded bounce handling, but it does not replace DKIM. Forwarding commonly breaks SPF because the forwarder’s IP is not authorized by the original envelope domain. A DKIM signature often survives forwarding when intermediaries leave signed content intact.
PATH A — DKIM
DKIM pass: d=mail.northstar.example
From: northstar.example
Alignment: relaxed pass
PATH B — SPF
SPF pass: Return-Path bounce.mail.northstar.example
From: northstar.example
Alignment: relaxed pass
DMARC needs at least one aligned path.
Google requires SPF and DKIM for senders over its bulk threshold.DMARC is the result that joins the identities
DMARC evaluates the visible From domain against passing SPF and DKIM identities. One aligned pass is enough for DMARC to pass. The policy record also lets the domain owner request aggregate reports and express a handling preference for messages that fail.
In 2026, DMARC is standardized in RFC 9989, which replaced RFC 7489. Aggregate reporting is now specified by RFC 9990. Older tutorials may still describe the core alignment correctly, but deployment advice using the removed pct tag is no longer current.
_dmarc.northstar.example. TXT
"v=DMARC1; p=none; rua=mailto:[email protected]"
Start with reports, inventory every legitimate sender, fix alignment,
then move controlled sending domains toward enforcement.A DMARC pass is broader than the Gmail UI label. Gmail controls its own rendering and can add contextual identity information for reasons such as group delivery. Configure authentication to meet the standards and protect the domain; do not treat the disappearance of one visual label as the only success criterion.
How to diagnose a real message in Gmail
Do not diagnose from DNS lookup tools alone. They confirm records exist but cannot prove which domain and selector a provider used on a particular message. Send a fresh message to Gmail, open the message menu, choose “Show original,” and inspect the received authentication results.
- Confirm the visible From address is the brand domain you intended.
- Find DKIM and record whether it passed; capture the header.d or d= signing domain.
- Find SPF and record whether it passed; capture the smtp.mailfrom or Return-Path domain.
- Find DMARC and confirm it passed for the header.from domain.
- Compare the organizational domains rather than merely looking for three PASS labels.
- Check whether a mailing list, group, gateway, or forwarder rewrote the message.
- Repeat with the exact production stream because marketing and transactional systems may use different settings.
Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=eb2026;
spf=pass smtp.mailfrom=bounce.mail.northstar.example;
dmarc=pass header.from=northstar.example
Look for the domains after header.i/header.d, smtp.mailfrom,
and header.from. Those values explain alignment.The message was not signedEnable signing in the provider and confirm the required DNS record resolves.
The signature is valid but not brandedVerify your sending domain and switch to a custom aligned DKIM identity.
The signature did not validateCheck selector records, key state, message modification, and whether the provider rotated keys.
Neither passing identity alignsConfigure aligned DKIM or a custom aligned Return-Path; do not change policy to hide the failure.
Why “I added the DNS record” may not be enough
DNS configuration is only one half of the path. The sending service must verify the record, associate it with the correct project or stream, and actually use the aligned identity when signing new messages.
- The record was added to the wrong DNS zone or hostname.
- A DNS dashboard automatically appended the root domain twice.
- The provider expects CNAME records but the user pasted their targets as TXT values.
- The selector published in DNS differs from the selector on the received message.
- Domain verification succeeded in one provider project while production sends use another.
- The template test tool and production API use different From domains.
- DNS has propagated, but the provider still needs a Verify or Enable action.
- The received test predates the configuration change.
Query the exact selector from the received DKIM-Signature header. If s=eb2026 and d=mail.northstar.example, the receiver looks under eb2026._domainkey.mail.northstar.example. A record at a similar but different name will not validate that signature.
Forwarding and message modification complicate the picture
Forwarding changes the connecting IP, so the original sender’s SPF authorization usually no longer describes the final hop. DKIM can survive, but mailing lists and gateways may add footers, rewrite subjects, transform bodies, or alter signed headers, causing verification to fail.
ARC can preserve an intermediary’s record of earlier authentication, giving the final receiver more context, but it does not make a broken DKIM signature pass or guarantee placement. When only forwarded mail shows the identity cue, compare it with a direct test before changing the primary sender configuration.
Sending on behalf of customers requires customer authentication
A multi-tenant application should not place a customer’s domain in From unless the customer has authorized and configured that domain. Your provider can sign with its own domain, but that does not create alignment or permission for the customer’s visible domain.
- Best: give every customer a domain-verification flow and sign with their aligned DKIM domain.
- Good fallback: send from a domain your platform owns and clearly identify the customer in the display name and message.
- Use Reply-To for the customer’s response address when appropriate; Reply-To does not need to match From for DMARC.
- Never use an unauthenticated customer or consumer mailbox address merely because the message should appear personal.
- Keep tenant domains and selectors isolated enough to disable or rotate one customer without affecting everyone.
From: Northstar through Acme Platform <[email protected]>
Reply-To: Northstar Support <[email protected]>
DKIM: d=notify.acme-platform.example
DMARC: pass for notify.acme-platform.example
The platform authenticates the domain it owns instead of spoofing the customer.A complete remediation checklist
- Inventory the visible From, DKIM d=, SPF MAIL FROM, sending hostname, and Reply-To domains.
- Verify a domain you control with every email provider and every production stream.
- Publish provider-issued DKIM records and enable custom-domain signing.
- Configure a custom Return-Path when the provider supports it.
- Publish DMARC reporting and confirm at least one authenticated path aligns.
- Meet Gmail’s current SPF, DKIM, DMARC, DNS, TLS, complaint, and unsubscribe requirements for your volume.
- Test a fresh direct message in Gmail and inspect Show original.
- Test forwarded, group, marketing, transactional, and support paths separately.
- Rotate DKIM keys on a documented schedule without deleting the old public key before old mail clears.
- Monitor authentication results after provider, DNS, domain, or infrastructure changes.
The best outcome is not simply a cleaner Gmail row. It is an identity system in which recipients see your brand, receivers authenticate a domain you control, DMARC connects those identities, and replies reach the team the sender name promises. When those layers agree, the missing “via” label is a useful side effect of a much stronger configuration.