TL;DR
Permanent AUTH refusal: the chosen mechanism is weaker than server policy allows for that user. Switch to a stronger allowed mechanism before retrying. A policy mismatch, not a deliverability collapse, but fix it before submission works again. Do not retry unchanged.
What this code means
Selecting a mechanism the server rates below the strength required for that user account is what code 5.7.9 reports when AUTH returns registry pattern X.7.9. The enhanced status register records a permanent refusal for this session detail under class 5. The standard expects a retry with a different, stronger mechanism; the numeric reply alone does not name an allowed alternative, prove wrong credentials, or mark the recipient mailbox address as invalid.
Provider examples
554 5.7.9 This mail has been blocked because it failed authentication checks against the sending domains DMARC policy.smtp;554 5.7.9 Message not accepted for policy reasons. See https://postmaster.yahooinc.com/error-codesTechnical meaning
As a response to the AUTH command, X.7.9 means the selected authentication mechanism is weaker than server policy permits for that user. The standard says the client should retry with a new mechanism; code 5.7.9 applies this detail in permanent class 5.
Delivery status
The leading digit 5 denotes a permanent failure of the current attempt. Repeating the attempt without changing the mechanism does not resolve the stated mismatch; the code alone does not identify an allowed mechanism, confirm incorrect credentials, or establish that the recipient address is invalid.
- Class
- Permanent failure
- Retry
- Do not retry unchanged
- Suppression
- Check the full context
Retry decision
Operational guidance: stop automatic and manual retries with the same mechanism. Make a new, controlled attempt only after confirming and configuring another mechanism that complies with server policy; check suppression again before sending.
Suppression decision
Operational guidance: do not automatically add an address or domain to a suppression list based on 5.7.9 alone. Inspect the complete response, account or service scope, AUTH policy, and event history, then make the suppression decision according to the confirmed cause and applicable policy.
Common causes
- The client selected an authentication mechanism for the user that was weaker than server policy permits.
Diagnostic steps
- Inspect the raw SMTP response or attempt report and confirm that the enhanced code is exactly 5.7.9, that the basic reply is in the 5xx class, and that the code was returned to the AUTH command; retain the complete response text.
- Correlate the response with the attempt time, authenticating user, client, server endpoint, and selected mechanism; use available logs and policy to identify the refused mechanism and an allowed alternative instead of inferring them from the code alone.
- Stop unchanged retries; before a new, controlled attempt, confirm the configuration change and new mechanism, check suppression again, and compare the result.
Actions by owner
Sender
- Do not make further manual attempts without a change; give the administrator the complete response, attempt time, and account used without disclosing credentials.
Sender administrator
- Retain the complete response and inspect the client configuration, selected mechanism, account, and server endpoint for the specified attempt.
- Configure only a confirmed mechanism that complies with server policy, check suppression again, and make one controlled attempt instead of repeating the unchanged AUTH request.
Recipient administrator
- If you manage the server that returned the code, inspect its logs and the AUTH policy applied to the specified user and mechanism.
- Correct the policy only if it does not match the intended configuration; otherwise give the sender administrator safe information needed to select an allowed mechanism.
Provider
- If you operate an authentication service involved in the attempt, inspect its logs and policy for the specified time, user, and mechanism.
- Correct a confirmed problem in the managed layer or identify the permitted corrective path without requesting disclosure of credentials; do not trigger automatic suppression from the code alone.
Sources
These sources define what this enhanced status code means, mainly through the IANA registry and related RFCs. When provider examples appear on the page, they come from that provider's published documentation. Follow the links to read the original wording in context.
- SMTP Enhanced Status Codes — IANA registry of enhanced mail system status codes.
- RFC 5248 — A Registry for SMTP Enhanced Mail System Status Codes — Creates and governs the IANA enhanced status code registry.
- RFC 2034 — SMTP Service Extension for Returning Enhanced Error Codes — Defines how SMTP returns enhanced status codes to clients.
- RFC 4954 — SMTP Service Extension for Authentication — SMTP AUTH extension and related reply status codes.
- smtp-codes (community corpus) — Community-maintained reference of provider SMTP responses, pinned locally as evidence.
- SMTP Field Manual (community corpus) — Community-maintained reference of provider SMTP responses, pinned locally as evidence.
Last verified:
