SMTP authentication, also known as SMTP AUTH, is integrated to ensure that nobody sends emails using their servers. Requests from users who try to use a server's service without first authenticating their account will be denied.

For example, Google and other email service providers have such security mechanisms in place to guard against unauthorized access to their servers. What exactly is SMTP auth? Read on to learn more about SMTP authentication.

What is SMTP AUTH, and How Does it Work?

The service extension of the ESMTP is known as SMTP authentication or simply SMTP AUTH. It demands that an email sender's (client's) use of the email server be authorized. As a result, only users with permission can send messages.

The SASL mechanism is used for authentication. Servers typically employ the three most prevalent mechanisms: PLAIN, LOGIN, and CRAM-MD5.

After the SMTP handshake, the client uses the EHLO command to connect to the server. The response is code 250. Additional information, such as supported SASL mechanisms, is typically attached. Here is how the SMTP session looks:

This example uses MailSlurp email sandbox.

Let's try logging in using the LOGIN SASL.

  • The LOGIN command is sent by the client.
  • The servers reply with the 334 code and request the client's username and password.
  • If the process is successful, it issues a 334 code - Authentication successful.

Did POP-before-SMTP Get Replaced by ESMTP?

All modern mail servers employ SASL-based ESMTP authentication. This kind of SMTP authentication took the place of the outmoded POP-before-SMTP authentication. However, some older servers still contain the latter. The plan is to connect the user back to SMTP after they have successfully authenticated at the POP3 service of the same server.

SASL Authentication Mechanisms

It is the responsibility of SMTP authentication mechanisms to determine, using various levels of security, whether the SMTP client is authorized. The server generally responds to the EHLO command by stating which SASL mechanisms it supports. Most servers enable the following choices:

PLAIN

The server asks the client to authorize using the username and password. This information is sent as a single Base64-encoded string.

Alternatively, the client can submit the credentials together with the AUTH PLAIN command in one single line:

LOGIN

The server requests authorization from the client using the username and password. In contrast to PLAIN, the username and password are sent one at a time, and the credentials are Base64 encoded.

CRAM-MD5

The server requests the client to use the password to finish a mathematical operation. The client response is a BASE64 encoded string with a username and a 16-byte digest in hexadecimal notation.

When compared to PLAIN and LOGIN, which only support plaintext authentication, CRAM-MD5 offers a higher level of security. A challenge-response model underlies the protocol.

Another SASL implementation that works with SMTP servers is NTLM. This authentication method uses a challenge-response process. It is frequently utilized in a few Microsoft products, including MS Exchange and the Integrated Windows Authentication mode. The server allows NTLM authentication as soon as the client sends the AUTH command. The client transmits NEGOTIATE_MESSAGE. The server replies with a CHALLENGE_MESSAGE to verify the client's identity. The client responds to the challenge by sending an AUTHENTICATE_MESSAGE with all the messages in Base64.

  • XOAUTH/XOAUTH2: This is a fundamental authentication method
  • GSSAPI: The network authentication protocol Kerberos almost exclusively uses the Generic Security Service Application Program Interface or GSSAPI. Authentication using GSSAPI or Kerberos looks like this: For the session, the client and server agree on a shared secret key, cipher, and hash.
  • The server gives out a host key.
  • The client verifies itself

The SSL connection is required for plaintext mechanisms. Unencrypted credentials can be sent with no issues. All non-plaintext SASL mechanisms do not require SSL/TLS encryption.

SMTP AUTH Listening Ports

This is the standard SMTP AUTH port. It is also referred to as the message submission port. 587 denotes the use of authentication and is connected to submission servers or mail submission agents (MSAs).

In some circumstances, SMTP AUTH can also be used on this port. The message relay port is designated as 25.

Code 535: Authentication Failed and Other SMTP AUTH Errors

Both positive and negative responses to the AUTH command are possible from the SMTP server. Examples of positive response codes;

  • 334: This code implies that the requested security measure is approved.
  • 235: This code implies that the authentication is successful.

The most frequent negative response is 535, which indicates that authentication failed. If you understand what led to this error, you'll probably be able to resolve it. Here are some errors leading to 535 errors.

  • Incorrect credentials: There is a problem with either the username or the password (or both). The username is typically the same as your email address. Additionally, your email account's password applies here as well.
  • Account disabled: There are many potential causes for this, including spam problems or unpaid invoices. You can resolve this by getting in touch with your mail service provider or an administrator.
  • SSL/TLS connection required: When an encrypted connection is necessary, some servers may reply with 535.
  • SMTP authentication is not enabled: Verify that SMTP AUTH is enabled both on your server and your client.
  • The authentication mechanism is not supported: Any of the server's authentication techniques cannot be used by the client. In this situation, use the server's default authentication method, which should be enabled.

Other than the 535 error, you may encounter other AUTH command errors, such as:

  • The 530 authentication issue, which typically necessitates the use of a (STARTTLS)[/blog/starttls-ssl-tls/) command
  • 538: An authentication mechanism is requested, but encryption is necessary
  • If you receive the error code 550, your email server needs SMTP authentication.

Conclusion

You can use SMTP authentication to safeguard your mail server against spoofing and phishing. But you must acknowledge that malware, DoS attacks, and other threats are all present at the same time.