SMTP Error 553: Mailbox Name Not Allowed. Invalid Address and "Sender Not Owned by User"

The SMTP standard defines 553 as "requested action not taken: mailbox name not allowed", with the example of an incorrect mailbox syntax. In real life the code is used for a group of problems about names: the address is written in a form the server will not accept, the sender address is not one the logged-in account may use, or the server refuses to handle a domain. It is the reply that a contact form plugin gets when the From address is not allowed, that a script gets when it writes an address with a stray space, and that an application gets when it sends as [email protected] through a server that knows the account only as [email protected]. The good news is that 553 is nearly always a configuration problem on the sending side, and the fix is a matter of correcting an address or aligning the sender with the account. This guide shows the common variants, what each means, and how to fix them in applications, WordPress and mail servers.

Which address was refused?

An SMTP session names two addresses before the message is sent: the sender in MAIL FROM and the recipient in RCPT TO. The reply tells you which one was refused only through its text or through the point in the conversation where it appeared. A 553 after MAIL FROM concerns the sender. A 553 after RCPT TO concerns the recipient. Read the full reply and the log of the session. If you cannot see the session, many libraries expose a debug level that prints it; for the manual method, see how to test an SMTP connection.

The common variants

Cause 1: invalid address syntax

Addresses come from forms, spreadsheets and databases, and they arrive with problems: leading or trailing spaces, a comma or semicolon at the end, two addresses in one field, non-ASCII characters in the domain, missing parts or a display name that has not been separated from the address, for example Alex Smith <[email protected]> placed in a field where only [email protected] belongs. Servers differ in how strict they are, so an address that works for one recipient fails for another. The fix is to validate and normalise addresses before sending: trim spaces, lower-case the domain, split lists and reject anything that does not parse. Patterns and their limits are discussed in email regex validation, and the broader checks in email validation before sending. Handle internationalised addresses on purpose: if the domain is in non-Latin script, convert it to its ASCII form (Punycode) unless the receiving server supports the SMTPUTF8 extension.

Cause 2: the sender is not owned by the authenticated user

This is the most frequent 553 on shared hosting and mail platforms. The server checks that the address in MAIL FROM (and often the From header) belongs to the account that logged in. Typical situations:

• A website logs in as [email protected] but uses [email protected] as the sender. The server sees a mismatch.
• A plugin is set to use the visitor's address as the From. The visitor is not an account on the server, so the check fails.
• A user sends as a shared address, such as sales@, that has not been granted to them as a "send as" alias.
• The domain is not yet added or verified in the sending service, so any address in it is "not owned".
• A script runs under a different system user than the one the mail server expects, and the local sender name does not match.

Fix it by sending from an address that the account owns or has been given permission to use. In sending services this usually means verifying the domain or the single address first; see verifying your sending domain. Put the visitor's address in Reply-To, not in From. For forms, this is also the right design for deliverability and authentication; the explanation of how the sender, the envelope and Reply-To differ is in Return-Path vs From.

Cause 3: relaying or domain restrictions

Some servers use 553 for the case that other servers report as "relay access denied". The text will say "relaying disallowed" or mention allowed recipient hosts. The cause is the same: the client is not authenticated or trusted for the domain it is sending to. Turn on SMTP authentication, use the correct submission server and port, and make sure TLS is active first; see SMTP 530 5.7.0.

Fixes by platform

WordPress and contact-form plugins

Set the "From email" in your SMTP plugin to an address on the domain you have verified, and do not let the form plugin override it with the visitor's address. Add the visitor's address as the reply-to header. If the plugin has a "force from address" option, enable it. The full setup is in the WordPress SMTP guide.

Applications and libraries

Separate three values in your code: the envelope sender, the From header and the Reply-To. Use one fixed, authenticated address for the first two and the user's address only for the third. In PHPMailer that is setFrom() with the fixed address and addReplyTo() with the visitor; in Nodemailer it is from and replyTo; in Django it is from_email and reply_to. See the guides for PHP, Node.js and Django.

Postfix and other servers you run

Postfix can enforce sender ownership with smtpd_sender_login_maps together with reject_sender_login_mismatch. When it rejects a user, the reply is "Sender address rejected: not owned by user". To fix it, add the address to the map for that login, or change the sender in the client:

# /etc/postfix/main.cf
smtpd_sender_login_maps = hash:/etc/postfix/sender_logins
smtpd_sender_restrictions =
    reject_sender_login_mismatch,
    permit_sasl_authenticated

# /etc/postfix/sender_logins
[email protected]      [email protected], [email protected]

# then
sudo postmap /etc/postfix/sender_logins && sudo postfix reload

The left side is the sender address, and the right side lists the logins allowed to use it. This is a useful control on a server that many users or sites share, because it stops one account from sending as another.

A diagnosis checklist

1. Find out whether the sender or the recipient was refused, using the session log or the text.
2. Print the exact addresses that your code passes to the library, with visible delimiters, to find spaces and control characters.
3. Compare the From address with the account you authenticate as. Are they the same domain? Is the address verified?
4. Check that the sender domain exists in DNS and has MX or address records.
5. Check authentication and TLS settings if the text mentions relaying or login.
6. Resend a single test message to a mailbox you control, with a fixed sender, and confirm that it works before re-enabling your application.

Preventing 553 errors

Validate every address on entry, normalise it before use and store a clean version. Use a single, verified sender identity per application and put user addresses in Reply-To. Verify new sending domains before launching a feature that uses them. Log the full SMTP reply for every failure, with the addresses involved, so that a 553 can be traced in minutes. And handle it as a permanent failure: do not retry the same message unchanged, because it will fail the same way.

References and further reading

• RFC 5321: Simple Mail Transfer Protocol
• RFC 3463: Enhanced Mail System Status Codes
• Postfix documentation: SMTP Access Control