SMTP error code · permanent failure (5xx)
SMTP error 553 5.7.1: sender address rejected, not owned by user
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 17, 2026
553 5.7.1 means the mail server refused your From address: you authenticated as one account but set a sender address that account doesn't own, or you tried to relay without logging in at all. It's a permanent, sender-side rejection: make your SMTP login match your sender address and the mail goes through.
553 5.7.1 at a glance | |
|---|---|
| Code | 553 5.7.1 |
| Class | Permanent (5xx): the message was refused and will not retry |
| Category | Policy |
| Side at fault | Sender |
| Auth-related | Yes (SPF/DKIM/DMARC) |
What the bounce actually says
The exact wording varies by provider. These are the documented strings, verbatim. Match yours to pin down which variant you hit.
Hosting.XYZ and other Postfix-based mail hosts
553 5.7.1 5.7.1 <admin@example.com>: Sender address rejected: not owned by user mail@example.comSource: hosting.xyz
Namecheap Private Email (anti-spoofing filter)
553 5.7.1 host mx1.privateemail.com [198.187.29.233]: 553 5.7.1 <user@domain.com>: Sender address rejected: not logged inSource: www.namecheap.com
Standard meaning of the 5.7.1 status code (no vendor wording)
553 5.7.1 Delivery not authorized, message refusedSource: datatracker.ietf.org
Why you're seeing 553 5.7.1
Unlike most bounce codes, 553 5.7.1 usually comes from the server you send through, not the one you send to. Submission servers enforce a simple ownership rule: the account you authenticate with must own the address you put in MAIL FROM. In Postfix this is reject_sender_login_mismatch backed by smtpd_sender_login_maps; hosting providers ship the same idea as an anti-spoofing filter, and some, like Namecheap Private Email, also enforce it at the receiving MX for domains they host, which is where the not logged in variant above comes from. It exists for a good reason: without it, any authenticated mailbox could impersonate any other user, and an unauthenticated connection could use the server as an open relay. RFC 3463 defines the 5.7.1 status as "delivery not authorized, message refused": the server understood you fine, it just refuses to send as an identity you haven't proven you own.
Likely causes, ranked
| Likely cause | What's happening |
|---|---|
| Your From address doesn't match your SMTP login | The most common trigger. A mail client, script, or app authenticates as one mailbox but sets MAIL FROM to a different address: a colleague's mailbox, an alias, or another domain entirely. The bounce text names both: the rejected sender in angle brackets and the account you actually logged in as. |
| SMTP authentication is off, so the server sees a relay attempt | One source of the `not logged in` wording (the other is the anti-spoof filter below). The client connects without authenticating, often on port 25 with SMTP AUTH disabled, or with credentials that silently stopped working after a password change. Accepting that mail would make the server an open relay, so it refuses. |
| Your domain's own mail host rejects outside mail claiming to come from it (anti-spoof filter) | Some providers run the ownership check on the receiving side too. Namecheap Private Email's Anti-Spoof Filter, for example, rejects any message arriving at its MX (`mx1.privateemail.com`) that claims to be from a domain it hosts but didn't come through its own servers. That's the `not logged in` bounce quoted above. It fires even on legitimate mail: a newsletter ESP, a CRM, or another provider sending as your domain to a recipient on the same host. |
| You're sending as an alias the server hasn't mapped to your account | You legitimately send as sales@ or a shared mailbox, but the server's sender-ownership map (`smtpd_sender_login_maps` in Postfix, "send as" settings in hosting panels) only lists your primary address. The server can't tell an unauthorized colleague from an unlisted alias. |
| A third-party app injects mail through your host with your address | A CRM, invoicing tool, printer, or scan-to-email device is pointed at your provider's SMTP server with stale or borrowed credentials, then sends as an address those credentials don't own. Devices configured years ago are the usual suspects. |
| Someone else is spoofing your address | If the bounce is for a message you never sent, a spammer used your address in MAIL FROM somewhere else and a rejection notice found its way back to you. The server that returned `553 5.7.1` did its job. Your job is making sure every receiver can reject those forgeries too, which is what SPF and DMARC are for. |
How to fix 553 5.7.1
Check who's authorized to send as your domain
Run your domain through the free SPF checker below. This bounce is an ownership check at your submission server; SPF is the same check run by every receiving server on the internet. If the server you're sending through isn't in your SPF record, fixing the login mismatch can just move the problem one hop downstream: receivers that check SPF and enforce DMARC may reject or junk the same mail.
Run the check now
Enter the sending domain and the check runs instantly on the next page. Free, no signup.
Make your From address match your SMTP username
In the failing client, script, or device, set both the visible From and the envelope sender to the mailbox you authenticate as. In PHPMailer and similar libraries that means
FromandSenderequal to the SMTP username, not a display alias.Turn SMTP authentication on and use port 587
If your variant says
not logged in, enable SMTP AUTH with the full mailbox address as the username, on submission port 587 (or 465 with TLS). Unauthenticated relay on port 25 is exactly what this rejection is built to stop, so no client tweak talks the server out of it. One exception: if the bounce names the recipient domain's own mail host (likemx1.privateemail.com) and you sent through a different service on purpose, it's an anti-spoof filter, not an authentication problem; see the anti-spoof step below.Authorize aliases and shared senders on the server side
If you genuinely send as another address, grant it properly: add the alias to your account's allowed senders in the hosting panel, or map it to your login in
smtpd_sender_login_mapson a self-hosted Postfix. For an alias or shared mailbox on the provider's own servers, don't disable the anti-spoofing filter to make it work; that reopens impersonation for every mailbox on the server.Sending through an external service? Adjust the provider's anti-spoof filter
If your domain's mailboxes live at a provider like Namecheap Private Email but the failing mail goes out through an ESP, a CRM, or another host, the provider's anti-spoof filter will bounce it at the provider's own MX. Two clean fixes: route that mail through the provider's authenticated SMTP instead, or, if sending via the external service is deliberate, disable the provider's anti-spoof filter for the domain per its documentation (Namecheap: uncheck the Anti-Spoof Filter box for the domain) and let a correct SPF, DKIM, and DMARC setup do the anti-spoofing job for every receiver, not just this one.
Give third-party apps their own authenticated identity
Point each CRM, billing tool, and scan-to-email device at credentials that own the address it sends as, or let the service send from its own infrastructure and add it to your SPF record with your domain as the aligned sender. Verify the result at /tools/spf and /tools/dkim after every change.
If you never sent the bounced mail, check your DMARC policy
Bounces for mail you didn't send mean your address is being forged elsewhere. Run your domain through the DMARC checker at /tools/dmarc: aggregate reports will show every source using your domain, and a policy of
p=rejecttells every receiver to refuse the forgeries the way this server just did.
Related free tools: DMARC checker · DKIM checker · Email security score
Authentication is the fix, not a workaround
Every path out of 553 5.7.1 runs through the same three DNS records: SPF, DKIM, and DMARC. Mailbox providers no longer treat them as best practice; they're the entry ticket, and a domain that drifts out of alignment starts bouncing again without anyone changing a thing on your side.
The durable fix is enforcement: publish correct records, watch the DMARC reports for senders you missed, and move the domain to p=reject so receivers drop spoofed mail instead of bouncing yours.
Enforce it — don't just monitor it
Palisade's AI agent takes domains all the way to enforcement: hosted SPF, DKIM, DMARC, and MTA-STS records, DMARC reports monitored continuously, and policies advanced to p=reject automatically. Your first domain is free, and the full product is open for 15 days, no card.
Free 15-day trial · No credit card · Your own domain free forever (NFR)
Why it matters for MSPs
Every MSP fleet is full of devices and line-of-business apps that authenticate as one mailbox and send as another: the scan-to-email copier sending as office@, the ticketing system sending as support@, the invoicing tool a client set up in 2019. Each one is a 553 5.7.1 ticket waiting for a password change or a host migration, and the same unanswered question (who may send as this domain?) is what keeps client domains spoofable on the open internet. Palisade answers it once per domain: it hosts and manages the SPF, DKIM, and DMARC records, surfaces every sending source in the DMARC reports so unauthorized senders show up before they bounce, and executes enforcement to p=reject automatically. Native ConnectWise, HaloPSA, and Autotask integrations put the findings in your existing workflow, and your own MSP domain is a free NFR domain: prove it on yourself before rolling it out to clients.