5.7.4

Enhanced Status Code 5.7.4: Security Features Not Supported

Permanent failure Medium severity Security RFC 3463
What it means

Enhanced Status Code 5.7.4 means “Security Features Not Supported.” The message asked for a security feature the receiving server cannot provide, so it was refused rather than delivered without it. Usually an unsupported SMTP extension or authentication mechanism.

At a glance
Code5.7.4
Bounce typeHard (permanent)
SeverityMedium
CategorySecurity
What to doSuppress the address; do not retry
StandardRFC 3463
What it looks like in your mail logs 
550 5.7.4 Security features not supported: the requested SMTP extension is not implemented here

What does 5.7.4 mean?

Enhanced status code 5.7.4 means security features are not supported. RFC 3463 defines it as a message containing security features, such as secure authentication, that could not be supported on the delivery protocol. The receiver is not rejecting your identity or your content, it is saying it cannot honour a guarantee the sending side asked for.

In modern practice this appears in two shapes. The first is an SMTP extension the receiver does not implement: a sender asks for something in the MAIL FROM or RCPT TO parameters and the receiver has no support for it. REQUIRETLS is the clearest example, which is why 5.7.30 exists as a more specific code for that case. The second is an authentication mechanism mismatch, where a client insists on a SASL mechanism the server does not offer.

Because both sides have to agree, this is a negotiation failure rather than a fault at either end, and it usually appears immediately and consistently for a given destination rather than intermittently. If it started suddenly, something changed in what your client is requesting, or the receiver retired support for a mechanism it previously offered.

How 5.7.4 plays out

Your server attempts delivery
The recipient server returns a permanent 5.7.4 rejection
This is a hard bounce: the message will not be accepted as sent
Suppress the address and fix the root cause before resending

Where 5.7.4 sits: soft vs hard bounce

Soft bounce (4xx) Hard bounce (5xx)
NatureTemporaryPermanent
SMTP class4xx5xx
What to doLet it retrySuppress the address
Recoverable?OftenNo
5.7.4 is✓ this code

Common causes of 5.7.4

  • The sender requested an SMTP extension the receiving server does not implement
  • A required TLS guarantee could not be honoured by the next hop
  • The client insisted on a SASL authentication mechanism the server does not offer
  • A security parameter was supplied on MAIL FROM or RCPT TO that the receiver rejects
  • The receiving server was upgraded and dropped support for a mechanism it once offered
  • A relay in the path strips or refuses the extension being negotiated

How to fix 5.7.4

  • Read the EHLO response from the destination and confirm which extensions it actually advertises
  • Stop requesting extensions the destination does not advertise
  • If the requirement is TLS related, check 5.7.30 which covers REQUIRETLS specifically
  • Allow a broader set of SASL mechanisms rather than pinning one
  • Test the conversation manually so you can see exactly which command is refused
  • Check whether a relay or gateway in the path is altering the negotiated capabilities

Frequently asked questions

What does SMTP error 5.7.4 mean?
It means the message requested a security feature the receiving server cannot support, so it refused rather than delivering without that guarantee. RFC 3463 describes it as security features such as secure authentication that could not be supported on the delivery protocol. It is a capability mismatch, not a judgement about you.
How do I find out which feature is unsupported?
Connect to the destination manually and read its EHLO response, which lists every extension it advertises. Compare that against what your MTA is requesting. The mismatch is usually obvious once both lists are side by side, and it is far quicker than reading configuration files at either end.
Is 5.7.4 related to TLS?
Sometimes. If your side requires TLS and the next hop cannot provide it, that is the specific case RFC 8689 assigns to 5.7.30, so look there first. 5.7.4 covers the broader class of any security feature the receiver cannot honour, including authentication mechanisms that have nothing to do with transport encryption.
Should I retry after 5.7.4?
No. Capability mismatches do not resolve with time; the receiver will refuse the same request identically on every attempt. Change what you are requesting, or route that destination through a path that supports it.
Why did this start after a server upgrade?
Because upgrades remove old mechanisms as well as adding new ones. A receiver that retires an obsolete SASL mechanism or an old TLS version will start refusing clients that still insist on it. Check the release notes for the version that was deployed and compare against what your client pins.

Related bounce codes

5.7.30 REQUIRETLS Support Required 5.7.5 Cryptographic Failure 5.7.0 Other Security or Policy Status 5.7.8 Authentication Credentials Invalid 504 Command Parameter Not Implemented

Sources & further reading

RFC 3463 · The standard that defines this reply code IANA registry · The authoritative list of enhanced status codes and their meanings
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes