SMTP 553 Sender Address Rejected: Causes and Fixes

A 553 reply means your mail server or relay refused the message because of the address in the sender field. It is a permanent (5xx) failure, so the sending server will not retry. The most common wording is 553 5.7.1 Sender address rejected: not owned by user, but you will also see 553 5.1.8 Sender address rejected: Domain not found and plain 553 Relaying disallowed.

Unlike a 550 reply, which usually comes from the recipient's server judging your reputation, a 553 usually comes from the server you are submitting to. The check happens at the MAIL FROM step, before any message body is sent. That makes it fast to diagnose: the answer is almost always in how the From or envelope address compares with the account you logged in with.

What the three common variants mean

• Not owned by user. You authenticated as one account but tried to send as another address. Postfix does this when smtpd_sender_login_maps and reject_sender_login_mismatch (or reject_authenticated_sender_login_mismatch) are configured and the login does not map to that sender.
• Domain not found. The server tried to resolve the domain of your sender address and failed. Typos, a missing domain, or a DNS outage cause it. Postfix's reject_unknown_sender_domain produces this style of message.
• Relaying disallowed or sender not allowed. The server only accepts mail from addresses it hosts, or from verified sender identities you have registered with a provider.

Providers phrase this differently. Some transactional services answer with a 550 and text saying the From address is not a verified sender; the fix is the same as below.

Fix 1: send from an address your account owns

Check the exact MAIL FROM and the From header your application sends. Frameworks often set the envelope sender from a default config value while you log in with another account.

## Postfix: see what the log recorded
sudo grep -i "sender address rejected" /var/log/mail.log | tail -n 5

On a hosted mailbox provider, use the mailbox address itself or an alias that the provider lists for that account. Add the alias in the admin panel first, then retry.

Fix 2: correct the Postfix login map (self-hosted)

If you run Postfix and the user legitimately needs to send as several addresses, map them:

## /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
alerts@example.com   deploy-user
billing@example.com  deploy-user

Then run sudo postmap /etc/postfix/sender_logins && sudo postfix reload. Restriction order matters, since Postfix evaluates them left to right and stops at the first match.

Fix 3: confirm the sender domain resolves

For the "Domain not found" variant, confirm the domain after the @ exists and has working DNS. Use the DNS Checker for A and MX records, and the MX Lookup to see whether it can receive mail at all. Servers commonly require an A or MX record for the sender domain. If the domain is brand new, wait for propagation (see how long DNS propagation takes). If your own resolver is failing, test with dig +short MX example.com @8.8.8.8 to separate a local resolver issue from a real DNS problem.

Fix 4: verify the sender with your relay provider

Hosted relays commonly ask you to verify either a single address or the whole domain before they allow it as a sender. The usual route is a confirmation email for one address, or DNS records for a domain. Add those records and wait until the provider's dashboard shows the identity as verified. The Email DNS Checker shows whether your SPF, DKIM and DMARC records are in place, which providers often check at the same time. Our transactional email DNS checklist lists what to publish.

Fix 5: check submission port and authentication

If you submit on port 25 without logging in, many servers treat you as an anonymous relay and refuse a sender they host. Submit on 587 with STARTTLS (or 465 with implicit TLS) and authenticate. Test reachability with the Port Checker and review SMTP 535 authentication failed if login itself fails.

Verify the fix

Send a test using the exact same account and From address your application uses, then watch the log for status=sent. Send to an external address as well, and run the Email Deliverability Test to make sure the message authenticates once it leaves your server.

Next steps

• Read email bounce codes explained to decode other 5xx replies.
• Compare with SMTP 550 5.7.1 message rejected, which is a receiver-side policy block.
• Fix open-relay style rejections in SMTP relay access denied 554.
• Set up authentication with the SPF, DKIM and DMARC guide.
• Check your SPF with the SPF Record Checker.

FAQ

Is a 553 error a temporary problem?

No. Any 5xx reply is a permanent failure for that message, so the sender will not retry. Correct the sender address or the account settings and send again.

What is the difference between 553 and 550?

Both are permanent, but 553 generally points at an invalid or disallowed mailbox name or sender address, while 550 is a broader "action not taken" reply covering policy blocks and unknown recipients. Always read the text after the code.

Why does it work from my mail client but not my website?

The client likely sends as the account you log in with, while the website sets a different From or envelope address. Align the application's sender setting with an address that account may use.

Does adding SPF fix a 553?

Not by itself. SPF is checked by the receiving server against your sending IP; a 553 from your own submission server is about whether you may use that sender address.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.