You set up Gmail to send from your business address. Looks fine on your end. Then a client replies and you spot it: their email shows your message as coming from you@gmail.com on behalf of you@yourcompany.com. Not a great look when you’re trying to look like a real company.
The good news is this is a five-minute fix. The better news, and the part most guides skip, is that there’s a difference between hiding the label and actually sending mail that authenticates and lands. We’ll do both.
Quick answer
To remove Gmail’s “on behalf of” message when you send from a custom domain:
- In Gmail, go to Settings → See all settings → Accounts and Import → Send mail as, and edit (or add) your custom address.
- Choose Send through your own SMTP server and point it at an authenticated relay for that domain. With SMTP2GO, that’s
mail.smtp2go.com, port 587 with TLS (or 465 with SSL), plus your SMTP username and password from Sending → SMTP Users. - Verify the address with the code Gmail emails you.
- Send a test, open Show original, and confirm SPF, DKIM, and DMARC all pass.
That’s the whole job. The rest of this page is the why, the decisions you’ll hit along the way (the “Treat as an alias” checkbox trips up almost everyone), and what to do when it doesn’t behave.
What “on behalf of” actually means
Every email carries a From header (the address you want people to see) and, sometimes, a separate Sender header (the account that actually pushed the message out the door). When those two match, nobody notices anything.
They stop matching when you tell Gmail to send as you@yourcompany.com but let Google’s servers do the sending. Gmail can’t honestly claim the message originated from your domain, so it adds a Sender header pointing back at your Gmail account. Per the rules that govern email headers (RFC 5322, if you want the bedtime reading), some mail clients render that mismatch out loud. Outlook is the usual culprit. It shows yourcompany.com on behalf of gmail.com and, honestly, it makes you look like you’re spoofing yourself.
Google says as much in its own Workspace admin documentation: routing a user’s mail through an outbound gateway for their domain “can also prevent the appearance of ‘on behalf of’ addresses in the From field.” So the fix isn’t a trick. It’s sending the message the way the receiving server expects: through a server that’s actually allowed to send for your domain.
That server is the SMTP relay. And once your mail goes out through one that’s authenticated for yourcompany.com, the Sender header lines up with From, and the label has nothing left to flag.
When this fix works, and when it won’t
Worth knowing before you start, because there’s one scenario that wastes an afternoon.
This works great when the address you want to send from is on a custom domain you control: you@yourcompany.com, a shared support@ or billing@ mailbox, that kind of thing. That’s the common case, and it’s exactly what an SMTP relay is for.
It does not work when you’re trying to send from one Gmail (or Workspace) address as another Gmail-hosted address. Google routes both through the same servers no matter what, and it disabled the external-SMTP option for that situation years ago. If both addresses end in @gmail.com, there’s no SMTP server to swap in. (This is the thing the long Stack Exchange threads eventually figure out, usually after a lot of shouting at Google.)
And if you’re on Google Workspace, your admin may need to allow per-user outbound gateways before you can point an individual user at an external SMTP server at all. That’s a setting on the admin side, not something you can flip from your own inbox. We cover the Workspace path in the Google Workspace setup guide.
Before you start
A short checklist, because a couple of these stop people cold halfway through:
- Access to the Gmail account you’re configuring.
- Access to the inbox at the sending address. Gmail emails a verification code there. If you can’t receive mail at
you@yourcompany.com, set up forwarding or a mailbox first. - An SMTP2GO account (the free plan sends 1,000 emails/month, which is plenty for Gmail’s web interface) and an SMTP user created under Sending → SMTP Users.
- DNS access for your domain, ideally, so you can add SPF and DKIM records. You can do the visual fix without this, but you shouldn’t, and the authentication section below explains why.
One thing you don’t need: MX record changes. SMTP2GO handles outbound only, so your existing inbound mail keeps flowing through whatever mailbox provider you already use. Nothing about your incoming email changes.
Set it up with SMTP2GO
Here’s the short version. For the click-by-click walkthrough with current screenshots, follow the Gmail setup guide, which stays matched to Gmail’s interface.
- In Gmail, open Settings (the gear icon), then See all settings.
- Go to the Accounts and Import tab and find the Send mail as section. Click edit info next to your address, or Add another email address if it isn’t there yet.
- Enter your name and the custom address you want recipients to see. (Hold on the “Treat as an alias” checkbox for a second — see the next section, it matters.) Click Next Step.
- Choose Send through your own SMTP server and enter the settings below.
- Click Add Account, then check the sending inbox for Gmail’s verification email and enter the code.
Your SMTP settings:
| Setting | Value |
|---|---|
| SMTP server | mail.smtp2go.com |
| Port (TLS) | 587 (recommended for Gmail’s dialog) |
| Port (SSL) | 465 |
| Fallback ports if your network blocks 587 | 2525, 8025, 80, 25 |
| Username | Your SMTP2GO SMTP username (Sending → SMTP Users) |
| Password | Your SMTP2GO SMTP password |
| Security | Secured connection using TLS |
| Authentication | Required |
Quick note from experience: Gmail’s dialog likes the standard secure ports, so start with 587 over TLS. If a corporate or campus network swallows 587, drop to 2525, which is open at almost every location SMTP2GO sees. Wrong username or password gives you a 535 incorrect authentication data error, so copy and paste the credentials rather than retyping them.
Should you check “Treat as an alias”?
This is the one checkbox guides give you a flat rule for, and the flat rule is wrong about half the time. Some how-tos say always check it. At least one university help desk says always uncheck it. They’re both right, for their scenario. Here’s the actual decision.
| Your situation | Treat as an alias? | Why |
|---|---|---|
Your own alternate address, same identity (e.g. you@yourcompany.com for the personal you) | Check it | Gmail treats it as another hat you wear. Replies and sent mail stay in your one inbox. |
| Another person’s mailbox you’re sending for (a colleague, your boss) | Uncheck it | Leave it checked and Gmail starts pulling their incoming mail into your inbox. Almost never what you want. |
A shared or group address (support@, a Google Group) | Usually check it | Keeps replies routed to the address, so the team sees them. Confirm reply behavior with a test send. |
| Honestly not sure | Apply Google’s own test | “Same identity” → check. “Separate account or person” → uncheck. |
That’s the difference between competitors talking past each other and actually answering the question. If the address is just another face of you, check it. If it belongs to someone else or a team mailbox you’re standing in for, uncheck it and save yourself a flood of mail you didn’t ask for.
Do SPF, DKIM, and DMARC matter for this?
Yes. Swapping in an SMTP server removes the visual “on behalf of” label. It doesn’t, on its own, prove to the receiving server that you’re allowed to send for your domain. Those are two separate jobs. You can clear the label and still land in spam.
Here’s the failure mode in one real example: a user sending from a custom-domain alias had SPF passing and DKIM passing, but no DMARC record configured. The message still got tagged as “on behalf of” and flagged as suspicious, because the authentication chain didn’t fully line up. SPF and DKIM passing isn’t the finish line. DMARC alignment is.
So while you’re in there, set up three records for your domain:
- SPF tells receivers which servers may send for you. SMTP2GO walks you through it; see what an SPF record is.
- DKIM adds a cryptographic signature that proves the message wasn’t tampered with in transit. More in our DKIM deep dive.
- DMARC ties the two together and tells receivers what to do if something doesn’t match. Start with a monitoring policy (
p=none). Here’s what DMARC is and how it works.
SMTP2GO can add the DNS records for your sender domain automatically in a lot of cases, which removes the most common place people make a typo.
One more reason to do this now rather than later. Since February 2024, Gmail and Yahoo have required SPF, DKIM, and DMARC for anyone sending 5,000+ messages a day to personal inboxes, and as of November 2025 Gmail moved from soft deferrals to permanent rejections for non-compliant bulk mail. You’re probably nowhere near that volume through Gmail’s web interface. But the moment your sending grows, or you move this domain onto a real relay for app and transactional mail, those rules apply. Setting authentication up correctly today means you never have to scramble for it. (The full breakdown is in our Gmail and Yahoo inbox protection rules guide.)
How to verify it actually worked
Don’t trust “looks fine in my Sent folder.” Trust the headers.
Send a test to a Gmail account, and to an Outlook account if you can, since Outlook is the client most likely to show the label. In Gmail, open the message, click the three-dot menu, and choose Show original. You’re looking for three things: SPF, DKIM, and DMARC all reading PASS, the From showing your custom address, and no Sender header pointing back at your Gmail account. If you want to understand what you’re reading, our guide on email headers and why they matter breaks it down.
Then hit Reply on the test from the recipient side and confirm it goes where you expect. That single check catches most of the “wait, why am I getting their mail now” alias mistakes before a real client ever sees them.
Gmail SMTP vs Workspace vs SMTP2GO: which do you actually need?
No point pretending everyone needs the same thing. Here’s the honest version.
| Option | Best for | Trade-off |
|---|---|---|
| Gmail’s own SMTP | Sending as another Gmail/Workspace address you own, low volume | Doesn’t solve “on behalf of” for custom domains; same servers, same problem |
| Your mailbox host’s SMTP | A simple custom-domain mailbox you already pay for | Often weak logging, thin support, per-provider limits |
| Google Workspace | A team running its whole domain on Google | Paid, and overkill if you just need to send |
| SMTP2GO | A custom domain that needs to send reliably, with delivery logs, authentication help, and 24/7 support | You set up an account and credentials (about five minutes) |
If you’re sending as another address you genuinely own on the same Gmail account, Gmail’s built-in option might be all you need, and you should use it. The moment a custom domain is involved, or you care about whether mail actually lands, or you’ll eventually send from an app as well as from Gmail, an authenticated relay is the cleaner answer. That’s the gap SMTP2GO fills, and you can see how businesses use it as the relay behind Gmail and beyond.
FAQ
Why does Gmail show “on behalf of”?
Because the address in the From header doesn’t match the server that actually sent the message. When Gmail sends for a custom address using Google’s own servers, it adds a Sender header pointing at your Gmail account, and some clients (Outlook especially) display that mismatch as “on behalf of.”
How do I remove it?
Send through an SMTP server that’s authenticated for your domain. In Gmail’s “Send mail as” settings, choose to send through your own SMTP server (for example mail.smtp2go.com on port 587), verify the address, then confirm SPF, DKIM, and DMARC pass.
Does this work with a personal Gmail account?
Yes, as long as the address you’re sending from is on a custom domain you control. It does not work for sending as one @gmail.com address from another, because Gmail routes those through the same servers and offers no external SMTP option.
Does it work on Google Workspace?
Yes, but your admin may need to allow per-user outbound gateways first. Until that’s enabled, individual users can’t point “Send mail as” at an external SMTP server.
Should I check “Treat as an alias”?
Check it when the address is another version of you. Uncheck it when it belongs to another person, otherwise you’ll start receiving their incoming mail in your inbox. For a shared or group address, usually check it and confirm reply behavior with a test.
Do I need SPF, DKIM, and DMARC?
For the label to disappear, the SMTP change is often enough. For the mail to actually reach inboxes and not look suspicious, yes. Removing the label and passing authentication are two different jobs, and you want both.
Do I need to change my MX records?
No. SMTP2GO handles outbound mail only, so your inbound email keeps using your existing mailbox provider. Your MX records stay exactly as they are.
Why do recipients still see my Gmail address after I set this up?
Usually one of two things: the SMTP server didn’t save in Gmail’s settings, or DNS authentication isn’t aligned yet. Open a test message, click “Show original,” and check for a leftover Sender header pointing at gmail.com.
What SMTP server and port should I use for SMTP2GO?
mail.smtp2go.com. Use port 587 with TLS in Gmail’s dialog, or 465 with SSL. If your network blocks 587, fall back to 2525, which is open almost everywhere.
Can I use this to send bulk email?
Not through Gmail’s web interface, which caps daily sends. For lists, app mail, or transactional email, send through SMTP2GO directly rather than routing through Gmail, and keep your authentication and complaint rate clean.
Does this affect where replies go?
It can, and that’s why the alias checkbox matters. Always send a test, hit reply from the recipient’s side, and confirm the reply lands where you intend before you rely on it.
Ready to make your custom address look the part?
Point Gmail at an authenticated SMTP server, set your DNS records once, and the “on behalf of” label is gone for good (along with a chunk of your spam-folder risk). Start a free SMTP2GO account, create an SMTP user, and follow the Gmail setup guide from there.
About the author
Charlie Abrahamson
Charlie is CEO and co-founder of SMTP2GO. He started the company in 2006 after a trip to Argentina left him locked out of his own email (every internet café and local ISP blocked his attempts to send). Twenty years later, SMTP2GO delivers email for businesses around the world from its Christchurch, New Zealand base. Charlie has personally configured SMTP relays, debugged deliverability incidents, and led migrations for senders ranging from small businesses to enterprises moving off AWS SES, SendGrid, Mailgun, and Postmark. SMTP2GO is ISO 27001 certified, GDPR compliant and an M3AAWG member.
