What the bounce says
Exact wording as it appears in the rejection or NDR. Placeholders such as x.x.x.x and example.com stand for your own address and domain.
553 5.7.1 <user@example.com>: Sender address rejected: not owned by user user2@example.com 553 5.7.1 Sender address rejected: not owned by user
The submission server knows who authenticated and will not let that account send as an address it does not own. This is a deliberate control against internal spoofing; the fix is to send from an address the account owns or to grant it the right to use the other one.
Most common causes
- The client authenticated as one user but sends as another address
- An alias is not registered as an allowed sender for the account
- A shared mailbox or group address is used without Send-As rights
- The application uses a From address on a different domain
What to verify next
- Send from the address that matches the authenticated account
- Register the alias or grant Send-As permission
- For applications, use a dedicated account that owns the From address
- Check Postfix smtpd_sender_login_maps if you run the server
Login-to-sender mapping
Servers maintain a map from login to permitted sender addresses. Postfix calls it smtpd_sender_login_maps; hosted providers implement the same idea as aliases and Send-As permissions. When MAIL FROM is not in the account’s allowed set, the message is refused with this code.
Common triggers: sending as a shared address, using an alias that was never registered, applications using a generic From address under a personal account.
- MAIL FROM must be in the account’s allowed set.
- Aliases and shared addresses need explicit permission.
- Applications should have their own account.
Fix on the account
Add the address as an alias for the account or grant Send-As. For applications, create a dedicated account whose primary address is the one it sends from.
For administrators
Keep the mapping strict; it prevents a compromised account from impersonating others. Extend it deliberately per address rather than disabling the check.
Best diagnostic path
Mail Failure Doctor
Classify the complete rejection and preserve provider-specific diagnostic context.
Open analysis → Live analysisEmail Dependency Discovery
Map applications and devices that depend on a relay or submission path before changing it.
Open analysis → Live analysisEmail Infrastructure Digital Twin
Map the domain’s public mail infrastructure and provider relationships before remediation.
Open analysis →Known limits
- Wording differs by provider; the underlying control is the same.
- Some providers check the visible From as well as MAIL FROM.
Common questions
I own both addresses.
The server does not know that until the alias is registered on the account you log in with.
Should the check be disabled?
No. It stops internal spoofing. Register the addresses instead.
Is this related to SPF?
Not directly. It is a submission-time permission check, before any DNS-based authentication.
Why the exact message matters
The same status family can be triggered by different conditions, and providers frequently add diagnostic text that narrows the issue. Use the complete rejection text rather than treating the numeric code as a complete diagnosis.
Provider reference
For the provider-defined meaning and current requirements, review Postfix: smtpd_sender_login_maps.