SMTP 501 5.7.1: sender not authorized, or policy rejection

501 5.7.1 is a permanent failure combining a parameter-syntax base code with a policy enhanced status. In practice, this pairing most often shows up when a sending client attempts to relay through a server it is not authorised to relay through, or when a MAIL FROM address does not match the authenticated identity the server expects (a common anti-spoofing check). The server is saying: the command's parameters are not something I will accept, specifically because of a policy restriction, not a pure syntax problem - which is the detail that should tell you to look at your authentication and relay configuration rather than at the literal formatting of the command you sent, since no amount of correcting syntax alone will resolve a rejection whose actual cause is a policy decision about who is allowed to send as whom.

Who is at fault

This is a sender-side configuration fault - almost always a relay or authentication-identity mismatch. The sending client is either trying to use a mail server as an open relay (which almost no modern server permits) or is authenticated as one identity while trying to send MAIL FROM a different, unauthorised domain. This check exists specifically to prevent one authenticated account from spoofing mail as a

different organisation through a shared submission server, which is why providers enforce it

strictly even for seemingly legitimate use cases like a marketing platform sending on behalf of

multiple client domains, where the convenience of one shared credential has to give way to

verifiable per-domain authorisation. Most reputable email platforms document exactly how to add a

verified sending domain through their own interface, typically involving a DNS TXT or CNAME record

proving ownership, and that process is worth completing once per domain rather than working around

it per message. If you run a platform that needs to send as many different client

domains through one set of submission credentials, the correct approach is to register each

domain explicitly as an authorised sender identity with your provider or relay, rather than

relying on an unverified mismatch between the authenticated account and the MAIL FROM address.

The exchange

220 mx.example.com ESMTP
EHLO mail.yourdomain.com
250-mx.example.com
250 AUTH LOGIN PLAIN
AUTH LOGIN
...
235 2.7.0 Authentication successful
MAIL FROM:<sender@someotherdomain.com>
501 5.7.1 Sender address rejected: not owned by user

The account authenticated as a user on yourdomain.com but tried to send as someotherdomain.com - a mismatch most mail servers explicitly block to prevent spoofing.

How Gmail, Microsoft 365 and Yahoo word the same condition

Note Microsoft 365 and Yahoo both escalate this to a permanent 550/553 rather than 501 - the base code used for this policy violation varies more across providers than most, since it depends on where in each server's processing pipeline the check happens.

Diagnostic commands

$ swaks --to recipient@example.com --from sender@someotherdomain.com \
  --server smtp.yourprovider.com --auth LOGIN \
  --auth-user sender@yourdomain.com --auth-password '***'
<~  501 5.7.1 Sender address rejected: not owned by user

Confirm the --from address matches the authenticated account's own domain; if it does not, you have reproduced the exact mismatch causing the rejection.

The ordered fix

1. Confirm the MAIL FROM address matches the domain of the authenticated sending account. Most SMTP relays enforce exactly this check.
2. If you need to send on behalf of another domain, set that up explicitly as an authorised "send as" identity with your provider rather than relying on a mismatched MAIL FROM.
3. Check your sending application's configuration for a hardcoded or incorrect "from" domain that does not match its SMTP credentials.
4. Re-test with `swaks` using matched credentials and from-address before resuming.
5. If using a shared sending platform, confirm the domain is verified and authorised within that platform's sender settings.

What not to do

• Do not try to work around the relay restriction by switching to an open or misconfigured relay - that is the exact open-relay/spoofing risk the rejection exists to prevent, and using one will tank your reputation elsewhere.
• Do not retry unchanged. The mismatch between authenticated identity and MAIL FROM domain will reproduce the rejection every time.
• Do not treat this as a recipient-side issue. The recipient and their mailbox are never evaluated; the session fails on your own sender authorization.
• Do not disable SPF/DKIM on the domain thinking that will "fix" the mismatch - authentication records are unrelated to this specific relay-authorization check.

Testing for this before it affects production sending

Before deploying any new sending integration, run a single test message through it using the exact

"send as" address you intend to use in production, and confirm the response is 250, not 501 5.7.1.

This is a five-second check that catches a relay-authorization mismatch before it affects a real

batch, and is particularly worth doing whenever an integration is reconfigured to send on behalf of

a different domain than the one it was originally set up with.

MailPilot's sending connections always use the authenticated mailbox's own address as the envelope sender, which avoids exactly this class of mismatch that triggers relay and sender-authorization rejections.