Docker Mailserver “sender address rejected: not owned by user”

Your mail client authenticates successfully, but Postfix refuses the message with 553 5.7.1 Sender address rejected: not owned by user, reject_sender_login_mismatch, or a similar sender-login mismatch. That is not another bad-password error. Docker Mailserver is enforcing a relationship between the authenticated account and the address used to submit the message.

The common case is simple: the client logs in as [email protected] but sends with an envelope sender such as [email protected]. With SPOOF_PROTECTION=1, Docker Mailserver allows an account to send as its own address or an authorised alias; it does not give every authenticated account permission to impersonate every hosted address.

Keep spoof protection. Fix the identity mapping or the client’s sender selection instead of disabling the check for every mailbox.

What the rejection proves

This error appears after several earlier boundaries have already worked:

• the client reached an SMTP service;
• TLS and SMTP AUTH completed far enough to identify a login;
• Postfix evaluated the message’s envelope sender;
• the effective sender-login map did not authorise that login for that sender.

If the log instead shows SASL authentication failed, use the SMTP authentication guide. If Postfix accepts the sender but refuses an external recipient with relay denial, use the relay access guide. Those failures belong to different policy stages.

1. Capture one transaction and its three identities

Start a short log view, submit one harmless message, then stop:

docker compose logs --since 5m --follow mailserver

Correlate the timestamp privately and record these values without publishing the complete log:

1. SASL login: the account that authenticated, often shown as sasl_username;
2. envelope sender: the address supplied with SMTP MAIL FROM and evaluated by sender restrictions;
3. header From: the author address readers see in the message.

The envelope and header addresses often match, but they are separate fields. Postfix’s sender-login restriction evaluates the SMTP envelope sender. Changing only a display name does nothing; changing the visible From address may or may not change the envelope sender, depending on the client.

2. Check the client’s outgoing identity

Mail applications can store several identities against one SMTP account. A user may choose “Billing” in the compose window while the outgoing server still authenticates as their personal mailbox. Web applications can also set a configurable From address while using a different SMTP username.

Inspect the narrowest relevant settings:

• outgoing server login is the complete intended mailbox address;
• the selected sender address has no typo, stale domain, or unexpected plus tag;
• the app is not overriding the envelope sender separately from the header From;
• a reply-to address is not being confused with a sending identity;
• the client is not reusing another saved SMTP account.

If the user does not need to send as the second address, select the authenticated mailbox as From and use Reply-To only when there is a genuine reply-routing need.

3. Confirm spoof protection and effective Postfix policy

Check the Compose model without printing unrelated environment values, then read only the relevant effective Postfix parameters:

docker compose config | grep -E '^[[:space:]]*- SPOOF_PROTECTION='

docker compose exec mailserver postconf \
  smtpd_sender_login_maps \
  smtpd_sender_restrictions

Docker Mailserver documents SPOOF_PROTECTION=1 as denying forged sender addresses: each account may send as its own address or an alias assigned to it. Under the hood, Postfix uses sender-login lookup tables together with a sender-login mismatch restriction. Inspect the generated settings, but make persistent changes through supported DMS configuration—not by editing generated files in a running container.

4. Decide whether the second address is an alias or a separate account

Use an alias when several addresses intentionally belong to one mailbox and one person or application is authorised to send as each of them. Use a separate account when the identity needs its own password, mailbox, access lifecycle, audit boundary, or ownership.

Aliases are primarily recipient-routing records, but DMS also uses supported alias configuration to permit associated sender identities when spoof protection is enabled. Alias direction therefore matters: the alias address points to the real account that owns it.

5. Add or verify the alias through Docker Mailserver

For the default file provisioner, list the supported account and alias configuration:

docker compose exec mailserver setup email list
docker compose exec mailserver setup alias list

If [email protected] should belong to [email protected], add it in that direction:

docker compose exec mailserver setup alias add \
  [email protected] [email protected]

Wait for DMS change detection or follow the reload procedure documented for your pinned image. Then verify the effective lookups rather than assuming the source file was loaded:

docker compose exec mailserver postmap -q \
  [email protected] /etc/postfix/virtual

The exact table path depends on the provisioner and DMS version. The official account-management guide gives /etc/postfix/virtual as the file-provisioner example. LDAP deployments need a correctly scoped sender query such as the supported LDAP_QUERY_FILTER_SENDERS flow, not edits to the file-provisioner maps.

6. Do not use these tempting workarounds

• Set SPOOF_PROTECTION=0: DMS warns that this allows any logged-in user to forge any sender address. It turns one missing mapping into a server-wide permission change.
• Add every address as an alias to one super-account: this removes useful separation and makes credential compromise more damaging.
• Trust a broad Docker network: network relay permission is not sender ownership and can introduce an open-relay path.
• Modify generated main.cf: recreation can discard the edit and leave the declarative configuration lying about production.
• Test with a plus-tagged From address: DMS explicitly says extension-delimiter addresses cannot send when spoof protection is enabled.
• Assume DKIM grants sender permission: DKIM signing happens later; it does not authorise the SASL login to claim an envelope sender.

7. Verify both allowed and denied cases

A useful repair proves the positive path without erasing the control:

1. Authenticate as the real account on port 587 with STARTTLS or 465 with implicit TLS.
2. Send from the account’s primary address and confirm acceptance.
3. Send from the newly authorised alias and confirm acceptance.
4. Follow each queue ID to a final status=sent or preserve the next exact error.
5. At a mailbox you control, verify the intended visible From address and SPF/DKIM/DMARC results.
6. Try one harmless, unauthorised sender identity and confirm Postfix still rejects it.
7. Confirm inbound mail to the alias reaches the intended mailbox if receiving there is part of the design.

That final negative test matters. “Mail sends now” is not sufficient evidence if the fix silently let every authenticated user impersonate every address.

Compact diagnosis order

1. Match one submission attempt to one redacted Postfix transaction.
2. Compare SASL login, envelope sender, and header From.
3. Check the client or application’s selected outgoing identity.
4. Inspect SPOOF_PROTECTION, smtpd_sender_login_maps, and sender restrictions.
5. Model the address as the correct account or an alias pointing to its owner.
6. Apply the change through the provisioner supported by the pinned DMS image.
7. Verify primary and alias sending, final delivery, inbound alias routing, and rejection of an unauthorised sender.

Authoritative references: Docker Mailserver’s account-management overview explains accounts, aliases, submission, and supported sender identities; its environment reference documents SPOOF_PROTECTION; and Postfix documents smtpd_sender_login_maps and sender-login mismatch restrictions. Match commands and map paths to the DMS version and provisioner you actually run.