Step-by-step: fix “email sent as another user” using Google Workspace SMTP Relay + PostMaster
A) Google Workspace (Admin Console) — set up SMTP Relay Open: Admin Console → Apps → Google Workspace → Gmail → Routing → SMTP relay service → Add Setting. D...
A) Google Workspace (Admin Console) — set up SMTP Relay
-
Open: Admin Console → Apps → Google Workspace → Gmail → Routing → SMTP relay service → Add Setting.
-
Description:
PostMaster SMTP Relay. -
Allowed senders: Only addresses in my domains.
-
Authentication:
-
✅ Only accept mail from the specified IP addresses (add your PostMaster public outbound IP(s)).
-
☐ Require SMTP Authentication (leave unchecked).
-
-
Encryption: ✅ Require TLS encryption.
-
Save.
Also check DNS & security (strongly recommended)
-
SPF (domain DNS TXT):
v=spf1 include:_spf.google.com ~all -
DKIM: Admin Console → Apps → Google Workspace → Gmail → Authenticate email → select domain → Generate new record, publish the TXT in DNS, then Start authentication.
-
DMARC (optional but recommended, domain DNS TXT):
(Adjust policy later to
rejectwhen you’re confident.)
Why IP-based relay (no per-user auth)?
Because your gateway (PostMaster) sends for many users. If you auth with one mailbox (e.g.,dcf@…), Gmail rewrites the envelope sender to that user → replies go to the wrong inbox. IP-based relay preserves each user’s From/Return-Path properly.
B) PostMaster (Mail Server) — map fields to your UI
Mails → Outgoing → Primary
-
Enabled: ✅
-
SMTP Host:
smtp-relay.gmail.com -
Port:
587 -
SSL Enabled: set to Always (your UI uses this to permit TLS)
-
TLS Support: ✅ (check it; this forces STARTTLS on 587)
-
User Authentication: unchecked (relay is IP-based; no username/password)
-
Auth Type: leave at Plain (ignored since auth disabled)
-
Username / Password: blank
Outgoing Mail – Advance Settings (unchanged unless you need them):
-
Pause Mode Settings: leave default/off.
-
Connections:
Max Clients (Relay) = 1–5(start with 1). -
Socket Timeout: 300 sec (defaults are fine).
SMTP Sender Masking
-
Enabled: ✅
-
Mode: All Mails
-
Email Address: leave blank (so each message uses each user’s own From).
Outgoing Mail – POP Before SMTP
-
Use POP Before SMTP: unchecked/disabled (not needed; you’re IP-authenticated at Google).
Save / Confirm changes.**
C) Outlook (end-user profiles)
For each user (e.g., abc@xyz.com):
-
Account type: Microsoft 365/Google via OAuth or standard IMAP/POP for incoming only.
-
Outgoing (SMTP) in Outlook should point to PostMaster, not directly to Gmail.
-
From address = the user’s own mailbox (
abc@xyz.com). -
Do not reuse
dcf@xyz.comcredentials anywhere. -
Avoid “Send As” or “On behalf of” unless it’s intentional and permissioned.
D) Testing (prove it works)
-
Send a mail from abc@xyz.com to an external mailbox (e.g., Gmail/Outlook.com).
-
In the recipient mailbox, open Show original / View message source and verify:
-
From: abc@xyz.com -
Return-Path: abc@xyz.com(or a Google bounce alias for the same user) -
Authentication-Results:showsspf=passanddkim=pass(after DKIM is live).
-
-
Reply from the recipient — it should go back to abc@xyz.com, not
dcf@xyz.com. -
In Google Admin → Reports → Email Log Search, confirm messages are accepted via SMTP relay from your PostMaster IP.
E) Common pitfalls & quick fixes
-
Still shows dcf@… as sender
→ You’re still usingsmtp.gmail.comwith auth somewhere. Change tosmtp-relay.gmail.com:587and disable auth on PostMaster. -
Relay rejected
→ Wrong/changed public IP. Verify the egress IP of PostMaster and add it to the allow list in the SMTP relay setting. -
No TLS
→ Port/checkbox mismatch. Use 587 + STARTTLS (TLS Support checked). -
SPF softfail
→ SPF record missing_spf.google.com. -
Some devices can’t do TLS/auth (legacy scanners, etc.)
→ Keep the same relay but add their source IPs to the allowed list. Use port 587 with STARTTLS if possible; if truly incapable, consider a dedicated smart host inside your LAN that can up-convert to TLS.
Full Article (Shareable Guide)
Subject
Stop Sender Mix-ups in Google Workspace: A Complete PostMaster + SMTP Relay Setup to Ensure Replies Reach the Right Inbox
Overview
Organizations that run a local mail gateway (like PostMaster) and Google Workspace often see a subtle but damaging issue: users send as abc@yourdomain.com, but recipients receive mail as dcf@yourdomain.com. Replies route to the wrong person, conversations split, and customers get confused.
This happens when your gateway authenticates to Gmail with one user’s mailbox (dcf@…) and sends mail for many users. Gmail correctly rewrites the envelope sender to the authenticated account — so replies follow that identity.
The fix is to use Google Workspace SMTP Relay with IP-based authentication and to configure your gateway to preserve each user’s From address (SMTP Sender Masking). This guide shows every screen and value you need.
1) Prerequisites
-
Google Workspace Super Admin access.
-
Your PostMaster server’s public outbound IP.
-
Ability to edit your domain’s DNS (TXT records for SPF/DKIM/DMARC).
2) Configure Google Workspace SMTP Relay
-
Admin Console → Apps → Google Workspace → Gmail → Routing → SMTP relay service → Add setting.
-
Description:
PostMaster SMTP Relay. -
Allowed senders: Only addresses in my domains.
-
Authentication:
-
✅ Only accept mail from the specified IP addresses → add your PostMaster public IP.
-
☐ Leave Require SMTP Authentication unchecked.
-
-
Encryption: ✅ Require TLS encryption.
-
Save and note the server name you’ll use: smtp-relay.gmail.com.
SPF, DKIM, DMARC (deliverability & trust)
-
SPF:
v=spf1 include:_spf.google.com ~all -
DKIM: enable per domain in Admin Console and publish DNS TXT; then Start authentication.
-
DMARC: start with
p=quarantine, move top=rejectlater.
3) Configure PostMaster (SMTP Smart Host)
Outgoing → Primary
-
Enabled: ✅
-
SMTP Host:
smtp-relay.gmail.com -
Port:
587 -
SSL Enabled: Always
-
TLS Support: ✅
-
User Authentication: unchecked
-
Auth Type: Plain (ignored when auth off)
-
Username / Password: blank
SMTP Sender Masking
-
Enabled: ✅
-
Mode: All Mails
-
Email Address: blank (so each message uses the sender’s address)
POP Before SMTP
-
Disabled
Connection limits/timeouts: defaults are fine; increase Max Clients if throughput is low.
Rationale: With IP-based relay and no per-user authentication, Gmail accepts mail from your gateway on behalf of any
@yourdomain.commailbox — and it will not rewrite the sender identity. Sender Masking ensures the From and envelope sender carry the correct user.
4) Outlook Profile Guidance
-
Each user’s account identity must be their own (
abc@yourdomain.com). -
SMTP in Outlook should aim at PostMaster (which then relays to Google), not
smtp.gmail.com. -
Do not reuse shared credentials (
dcf@…) anywhere. -
Only use “Send As / Send on behalf” when officially granted — and expect replies to follow that identity.
5) Validation & Troubleshooting Workflow
-
Send test from
abc@yourdomain.comto external mailbox. -
Inspect headers at the recipient:
-
From:=abc@yourdomain.com -
Return-Path:=abc@yourdomain.com(or Google alias for the same) -
Received:showssmtp-relay.gmail.comwith TLS. -
Authentication-Results:showsspf=pass(after DNS TTL) anddkim=pass(after DKIM live).
-
-
Reply from recipient and confirm it lands in abc@yourdomain.com.
-
If rejected:
-
Verify the public IP in the relay allow list matches the actual egress IP.
-
Ensure TLS is on (587 + STARTTLS).
-
Confirm Allowed senders is set to Only addresses in my domains.
-
Check Google Admin → Email Log Search for the exact error.
-
6) Security & Policy Tips
-
Restrict the relay to only your IPs; never open relay to the world.
-
Enforce Require TLS (already enabled).
-
Rotate/monitor gateway IPs (if you change ISP/NAT, update the relay setting).
-
Implement DMARC reports (RUA) to monitor spoofing attempts.
-
Keep PostMaster patched; limit concurrent connections if you see throttling.
7) FAQ
Q: Can I keep using smtp.gmail.com with app passwords?
A: Not for a multi-user gateway. That method binds all traffic to the authenticated mailbox and causes the identity mix-up you observed.
Q: Can scanners/copiers use this relay?
A: Yes — add their source IPs to the same SMTP Relay and send via smtp-relay.gmail.com:587 with STARTTLS (no auth).
Q: We host multiple domains.
A: Add each verified domain in Workspace; keep Allowed senders: Only addresses in my domains. Ensure SPF/DKIM/DMARC for each domain.
Q: We still see occasional replies going to the wrong user.
A: Check if anyone is using an old profile that still points to smtp.gmail.com with dcf@… credentials; migrate them to the gateway profile.
8) Final Checklist (1-minute audit)
-
Google SMTP Relay exists with Allowed senders = Only addresses in my domains
-
Only accept mail from specified IPs = your PostMaster public IP(s)
-
Require TLS checked
-
PostMaster uses
smtp-relay.gmail.com:587, TLS on, no auth -
SMTP Sender Masking = Enabled (All Mails)
-
SPF includes
_spf.google.com; DKIM enabled; DMARC set -
Outlook sends to PostMaster; no shared mailbox credentials anywhere
#GoogleWorkspace, #Gmail, #SMTPRelay, #EmailAdmin, #PostMaster, #SysAdmin, #ITSupport, #EmailRouting, #SPF, #DKIM, #DMARC, #DNS, #Deliverability, #EmailSecurity, #STARTTLS, #TLS, #Outlook, #AppPasswords, #SenderMasking, #ReturnPath, #EnvelopeSender, #MailGateway, #SmartHost, #EmailServer, #NAT, #PublicIP, #Allowlist, #EmailHeaders, #EmailLogs, #Troubleshooting, #Compliance, #PhishingDefense, #ScannerRelay, #CopierEmail, #AdminConsole, #EmailFlow, #MXandSPF, #DKIMKeys, #DMARCReports, #MessageTrace, #ITPlaybook, #HowToGuide, #StepByStep, #BestPractices, #NetworkSecurity, #Identity, #ITOps, #WorkplaceIT, #CustomerSupport, #NoMoreMixups
Was this guide useful?
Your answer helps us keep BISONKB accurate and practical.