SMTP, or Simple Mail Transfer Protocol, is the internet standard used to submit, relay, and deliver outgoing email. When an app sends a password reset, receipt, newsletter, or alert, SMTP defines the server conversation that transfers that message toward the recipient’s mail provider. It is an email transport protocol—not a deliverability score or an inbox-placement guarantee.

What is SMTP?

SMTP stands for Simple Mail Transfer Protocol. It is the set of rules that email systems use to send a message from one system to another over a network. An application, such as an ecommerce store or SaaS product, can connect to an SMTP server and hand it an outbound message. That server then determines where the message should go and relays it to the recipient domain’s mail infrastructure.

SMTP is foundational because email is not sent directly from your application code to a person’s inbox. Instead, it passes through a chain of systems: a sending application or mail client, a mail submission server, one or more mail transfer agents, and the recipient’s mail server. SMTP provides the common language for much of that handoff process.

The protocol’s original purpose is straightforward: transfer mail reliably across independently operated systems. Modern email sending has added encryption, authentication, message-size negotiation, internationalized addresses, delivery-status notifications, and other extensions, but SMTP remains the transport layer underneath those capabilities. (rfc-editor.org)

For developers, SMTP is commonly one of two ways to send programmatic email. The other is an HTTP-based email API. Both routes can use the same underlying email infrastructure, but SMTP is particularly useful when an existing application, framework, plugin, printer, CRM, or legacy system already knows how to talk to an SMTP server.

Why SMTP matters for email deliverability

SMTP itself does not decide whether a message lands in the inbox, spam folder, promotions tab, or is rejected. Recipient mailbox providers make those decisions using many signals, including authentication, sender reputation, recipient engagement, message content, complaint behavior, and technical compliance.

However, SMTP is the channel through which several deliverability-critical events happen. A flawed SMTP connection can prevent sending entirely. A rejected recipient command can expose an invalid address. A temporary response can indicate throttling or a reputation-related deferral. And a message accepted over SMTP can still later be filtered away from the inbox.

That distinction matters:

  • SMTP acceptance means the receiving server accepted responsibility for the message at a particular handoff.
  • Delivery usually means the recipient mail system accepted the message for the intended mailbox.
  • Inbox placement means the recipient can see it in the primary inbox or another visible folder.
  • Engagement means the recipient opens, reads, clicks, replies to, saves, or otherwise values the email.

A successful SMTP response is therefore necessary for normal delivery, but it is not the same as a positive inbox-placement result. Teams that treat every 250 response as proof that a campaign performed well can overlook spam-folder placement, delayed delivery, and subscriber dissatisfaction.

SMTP also affects operational reliability. Transactional email often has a narrow usefulness window: a login code may expire in minutes, an order confirmation should arrive immediately, and a security alert is most valuable when it is timely. SMTP delays, retries, and connection failures can turn a technically valid email program into a poor product experience.

How SMTP works: the basic email journey

An SMTP transaction is a structured conversation between an SMTP client and an SMTP server. The client may be your application, a mail client, or an email service provider acting for your application. The server receives the message, applies its policies, and may relay it onward.

A simplified journey looks like this:

  1. Your application creates a message with headers, a body, recipients, and attachments if needed.
  2. The application connects to an SMTP submission server using credentials or another approved authentication method.
  3. The SMTP server verifies the connection and accepts the envelope sender and recipient addresses.
  4. The server accepts the message content and queues it for delivery.
  5. The sending infrastructure looks up the recipient domain’s mail routing information, commonly using DNS MX records.
  6. A receiving mail server accepts, temporarily defers, or rejects the message.
  7. The recipient provider applies authentication checks, anti-abuse controls, and mailbox filtering before making the message available to the recipient.

The process is store-and-forward rather than a live end-to-end chat. If the recipient’s server is temporarily unavailable, an SMTP server can queue the message and retry later. That resilience is one reason SMTP has remained central to global email for decades.

SMTP submission versus SMTP relay

It helps to separate message submission from message relay.

Message submission is the handoff from an application or mail user agent to a sending service you trust. This connection normally requires authentication and encryption because the client is asking the service to send mail on its behalf. The internet standard for message submission describes port 587 as the normal submission port, while port 25 remains associated with server-to-server relay. (rfc-editor.org)

Message relay is the server-to-server transport phase. A sending mail server locates the destination domain’s mail exchange and tries to transfer the message. Unlike an authenticated application-to-provider submission connection, inter-server delivery on the public internet has to operate across many independent systems with varying policies and capabilities.

This is why developers should not assume that opening an SMTP connection on port 25 from an application server is the right way to send production email. Port 25 may be restricted by hosting providers, lacks the submission-specific expectations of authenticated sending, and is generally intended for mail transfer between servers rather than application submission.

The SMTP conversation, explained with real syntax

SMTP is a text-based protocol. The client sends commands, and the server returns numeric response codes plus human-readable text. A basic exchange can look like this:

S: 220 smtp.example.net ESMTP ready
C: EHLO app.example.com
S: 250-smtp.example.net
S: 250-STARTTLS
S: 250-AUTH PLAIN LOGIN
S: 250 SIZE 52428800
C: STARTTLS
S: 220 Ready to start TLS
[the connection is encrypted]
C: EHLO app.example.com
S: 250-smtp.example.net
S: 250-AUTH PLAIN LOGIN
S: 250 SIZE 52428800
C: AUTH PLAIN <credentials omitted>
S: 235 Authentication successful
C: MAIL FROM:<receipts@example.com>
S: 250 2.1.0 Sender OK
C: RCPT TO:<customer@example.net>
S: 250 2.1.5 Recipient OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: Example Store <receipts@example.com>
C: To: Customer <customer@example.net>
C: Subject: Your order receipt
C: Message-ID: <unique-id@example.com>
C:
C: Thanks for your order.
C: .
S: 250 2.0.0 Message accepted for delivery
C: QUIT
S: 221 2.0.0 Bye

The example is illustrative, not a template for logging into a live provider manually. In production, an SMTP library should handle the connection, TLS negotiation, encoding, line endings, MIME structure, and authentication details. Credentials should never be pasted into source code or application logs.

What the main SMTP commands do

EHLO identifies the client and asks the server which Extended SMTP, or ESMTP, features it supports. The server’s response may advertise capabilities such as STARTTLS, AUTH, message-size limits, delivery-status notifications, or command pipelining. EHLO superseded the older HELO command for extension-aware clients. (rfc-editor.org)

STARTTLS asks the server to upgrade the existing connection to Transport Layer Security. After a successful TLS negotiation, the client should issue EHLO again because the server may expose a different capability set on the encrypted connection. SMTP’s TLS extension exists to protect the session from eavesdropping and some active attacks. (rfc-editor.org)

AUTH authenticates the submitting client when the server supports SMTP authentication. The supported mechanisms vary by provider. The important operational rule is to use the provider’s documented secure method and avoid sending credentials over an unencrypted connection.

MAIL FROM sets the envelope sender, also called the return path. This address is where delivery failures and other automated responses may be directed. It is not necessarily the same thing as the visible From: header recipients see.

RCPT TO supplies one envelope recipient. A message can have multiple recipients, though many sending systems handle each recipient separately or in small groups to retain clearer delivery and engagement records.

DATA begins the message-content phase. The content includes headers such as From:, To:, Subject:, and Message-ID:, followed by the body. A line containing only a period ends the data block.

QUIT ends the session cleanly.

SMTP envelope addresses versus visible email headers

One of the most confusing SMTP concepts is that an email has both an envelope and headers. They can contain related but different addresses.

The envelope is used by mail systems during transport. MAIL FROM provides the envelope sender, and RCPT TO provides the envelope recipient. These values are not normally displayed as the message’s primary sender and recipient fields in an email app.

The headers are part of the message content. The visible From: address tells the reader who the email appears to be from. The Reply-To: header can direct replies somewhere else. The To: and Cc: headers describe intended recipients, but they are not the authoritative routing instructions once the SMTP envelope has been established.

This distinction has major deliverability implications. SPF evaluates whether the sending IP is authorized for the envelope sender’s domain. DKIM validates a cryptographic signature applied to selected message content. DMARC then evaluates whether the visible From: domain aligns with a passing SPF or DKIM identity.

For example, a message might use:

Envelope sender: bounce@mailer.example.com
Visible From: Billing Team <billing@example.com>
Reply-To: support@example.com

That can be valid, but the domains and authentication must be designed intentionally. If the visible From: domain is example.com while the authenticated identifiers belong only to an unrelated domain, the message may fail DMARC alignment and face filtering or rejection.

SMTP and sender authentication

SMTP moves a message, but it does not prove by itself that the visible sender is legitimate. Modern deliverability depends heavily on complementary authentication systems: SPF, DKIM, and DMARC.

SPF

Sender Policy Framework, or SPF, uses a DNS TXT record to declare which sending sources are permitted to send mail for a domain. A receiving server compares the connecting sender against that policy. Microsoft describes SPF’s core purpose as validating authorized email sources for a domain using DNS TXT records. (learn.microsoft.com)

A simplified SPF record might look like this:

example.com. TXT "v=spf1 include:provider.example -all"

Do not copy that record literally. The exact include value and policy depend on your email provider, other systems that send mail for the domain, and the domain’s existing DNS configuration. Publishing multiple SPF TXT records for one domain can cause evaluation problems, so changes should be planned rather than appended blindly.

DKIM

DomainKeys Identified Mail, or DKIM, adds a digital signature to a message. The recipient server retrieves the public key from DNS and checks whether the signed portions of the message remain valid. DKIM helps demonstrate that an authorized system signed the message and that the signed content was not modified in transit. (learn.microsoft.com)

DKIM is especially useful for mail flows where SPF can be fragile, such as forwarding. A forwarded message may originate from an IP address that was not in the original sender’s SPF record, which is expected behavior in many forwarding scenarios. (learn.microsoft.com)

DMARC

DMARC, or Domain-based Message Authentication, Reporting, and Conformance, builds on SPF and DKIM. It lets a domain owner publish a DNS policy describing how receivers should handle messages that fail the required authentication and alignment checks, while also supporting reporting.

A cautious starting record commonly uses monitoring mode:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Again, this is a simplified example, not universal production guidance. The reporting address must be able to receive and process aggregate reports, and you should review every legitimate sender before moving to stricter policies such as p=quarantine or p=reject.

Google’s sender guidelines require bulk senders sending more than 5,000 messages per day to Gmail accounts to use SPF, DKIM, and DMARC, as well as valid forward and reverse DNS for sending domains or IPs. Google also emphasizes making it easy for recipients to unsubscribe from marketing mail. (support.google.com)

Is SMTP a metric? How to measure SMTP performance instead

SMTP is a protocol, not a rate or score. There is no single “SMTP score” that tells you whether your email program is healthy.

Instead, measure the outcomes and response patterns generated during SMTP sending. The most useful operational metrics include:

  • Submission success rate: messages your application successfully hands to the SMTP provider divided by submission attempts.
  • Recipient acceptance rate: accepted recipients divided by attempted recipients at the receiving-server handoff.
  • Temporary deferral rate: recipients or messages receiving temporary, retryable responses divided by attempts.
  • Permanent rejection rate: recipients or messages receiving non-retryable rejections divided by attempts.
  • Hard-bounce rate: permanently undeliverable addresses divided by messages sent or delivered, according to your reporting convention.
  • Delivery latency: time from submission to final delivery event or final failure.
  • Complaint and unsubscribe rates: indicators of whether campaign recipients want the mail.

Worked numeric example: SMTP acceptance rate

Suppose a campaign attempts delivery to 20,000 recipients. During the first SMTP delivery attempt:

  • 19,100 recipients receive a 250 acceptance response.
  • 600 recipients receive temporary 4xx responses and enter a retry queue.
  • 300 recipients receive permanent 5xx rejections.

The initial recipient acceptance rate is:

19,100 accepted ÷ 20,000 attempted × 100 = 95.5%

The temporary deferral rate is:

600 deferred ÷ 20,000 attempted × 100 = 3.0%

The immediate permanent rejection rate is:

300 rejected ÷ 20,000 attempted × 100 = 1.5%

Those numbers are useful, but they still do not tell you inbox placement. The 19,100 accepted messages may be delivered to inboxes, spam folders, tabs, or recipient-side quarantine systems. The 600 deferred recipients may later succeed after retries, so they should not be counted as final failures until the retry process ends.

This is why teams should track SMTP events as a funnel rather than collapse every non-immediate result into “undelivered.”

Understanding SMTP response codes and errors

SMTP response codes are diagnostic signals, not just failure labels. The first digit is the most important starting point:

  • 2xx: successful completion or acceptance.
  • 3xx: more information is needed before the transaction can continue.
  • 4xx: temporary failure; retrying later may succeed.
  • 5xx: permanent failure for that transaction; retrying unchanged mail to the same destination usually will not help.

Enhanced status codes often add detail in the form X.Y.Z, such as 5.1.1 or 4.7.0. These extended codes were created to make delivery diagnostics more specific and machine-readable than basic SMTP codes alone. (rfc-editor.org)

Common SMTP outcomes

250 2.0.0 generally indicates that the server accepted the message. Acceptance is good, but it is not a guarantee of inbox placement or even immediate delivery to the final mailbox.

421 often indicates that a service is unavailable or a connection is being closed temporarily. It can arise during throttling, maintenance, connection limits, or reputation-related traffic controls.

450, 451, and 452 are common temporary-failure patterns. The message may be deferred because the recipient system is busy, a mailbox is temporarily unavailable, a rate limit has been reached, or the receiving provider wants the sender to retry later.

550 is a broad permanent-failure family. It may appear for an address that does not exist, a policy rejection, failed authentication, blocked content, or other non-retryable reasons. Always read the full enhanced code and provider text rather than assuming every 550 means “bad address.”

553 and 554 can also indicate permanent rejections. Yahoo, for example, documents that permanent errors can result from invalid addresses, failed DMARC or DKIM checks, policy issues, and suspicious behavior. (senders.yahooinc.com)

Why retries matter

A temporary SMTP response should trigger a measured retry strategy, not an immediate resend storm. Repeated rapid attempts can worsen throttling and look abusive. A sensible mail system queues deferred messages, spaces retries over time, uses exponential backoff where appropriate, and stops after a defined expiry period.

The exact retry schedule depends on message type. A receipt may remain useful after a delay, while a one-time login code may expire before the receiving system becomes available. For time-sensitive flows, the right fix may include a product fallback—such as a new code request path—rather than simply extending SMTP retries forever.

Common SMTP problems and their causes

SMTP failures can occur before the message reaches the provider, during authenticated submission, during server-to-server relay, or after the recipient provider receives it. Diagnose the stage first; otherwise, a DNS fix may be attempted for an application credential problem, or a content rewrite may be attempted for a connection timeout.

Connection and TLS failures

A connection timeout, refusal, or TLS handshake error usually points to network configuration, the wrong host or port, a firewall rule, an unsupported TLS version, certificate validation issues, or a mismatch between implicit TLS and STARTTLS expectations.

For authenticated message submission, port 587 with STARTTLS is a common standards-based configuration. Implicit TLS submission on port 465 is also standardized, and RFC 8314 notes that correctly configured port 587 STARTTLS and port 465 implicit TLS can provide equivalent security properties. (rfc-editor.org)

Do not disable certificate verification just to make a connection succeed. That can expose credentials and message data. Instead, verify the provider hostname, supported connection mode, and your runtime’s trusted certificate store.

Authentication failures

SMTP authentication failures may be caused by an incorrect username, expired password, revoked API-derived SMTP credential, unsupported authentication mechanism, or an attempt to authenticate before TLS when the server requires encryption.

Use a distinct credential for each environment where possible. A production service should not share a secret with local development, a staging environment, and a contractor’s testing script. Rotate credentials after exposure, store them in a dedicated secret manager, and make application logs redact authorization values.

Invalid or stale recipient addresses

A 5.1.1-style mailbox failure often means the mailbox does not exist, but providers can vary in how they report address problems. High invalid-address rates commonly come from old lists, typos at signup, purchased lists, unchecked import files, or customers entering an address incorrectly during checkout.

The best fix is preventive: validate format at collection time, confirm consent where appropriate, suppress addresses after permanent failures, and use an address-quality check before high-value or high-volume sends. For list cleaning or signup validation, a free email address verification tool can help catch obvious address problems before they become bounces.

Throttling and reputation-related deferrals

A sudden increase in 4xx deferrals can happen when volume rises too quickly, a new IP or domain has little sending history, recipients are not engaging, complaints increase, or the message pattern resembles unwanted bulk mail.

The fix is rarely “retry faster.” Slow down, stabilize volume, segment to recently engaged recipients, remove inactive and invalid addresses, honor unsubscribes promptly, and avoid abrupt campaign bursts. New sending domains and IPs should establish reputation gradually, especially when sending marketing mail at scale.

Authentication and alignment failures

Messages may be rejected or heavily filtered when SPF, DKIM, or DMARC are missing, broken, or misaligned. Common causes include adding a new email provider without updating SPF, using a visible From: domain that DKIM does not align with, rotating a DKIM selector without publishing the public key, or allowing an outbound gateway to alter signed content.

Fixes should be tested using a controlled message sent to several mailbox providers. Inspect the received message headers for Authentication-Results, confirm that SPF and DKIM pass, and verify that DMARC passes for the visible From: domain. Microsoft notes that its inbound processing adds an Authentication-Results header that can show SPF, DKIM, DMARC, and composite-authentication outcomes. (learn.microsoft.com)

How to improve SMTP sending and deliverability

A reliable SMTP setup is equal parts application engineering, DNS administration, deliverability operations, and recipient-respectful marketing. The following priorities address the most common issues.

1. Use the correct SMTP connection settings

Use the SMTP host, port, TLS mode, and credentials specified by your sending provider. Prefer encrypted submission, validate the server certificate, and use an SMTP library rather than reimplementing MIME and protocol handling from scratch.

Keep configuration outside application code. Environment variables or a managed secret store are better than hard-coded credentials, and they make key rotation less disruptive.

2. Authenticate every sending domain

Configure SPF, DKIM, and DMARC for each domain that appears in the visible From: address or participates in sending. This includes transactional subdomains, marketing subdomains, customer-notification domains, and any white-labeled sending domains.

Start DMARC with monitoring if you do not have a complete inventory of legitimate senders. Review reports, identify unknown systems, correct alignment, and only then decide whether stricter enforcement is appropriate.

3. Keep transactional and marketing streams distinct

Password resets, account alerts, and receipts have different recipient expectations from newsletters and promotional campaigns. Separating streams by subdomain, sender identity, templates, and operational controls can make performance easier to understand and protects urgent mail from marketing-related reputation problems.

A transactional message should not quietly become a promotional bundle. Keep required service information clear and timely, and reserve marketing content for recipients who have actually opted in to receive it.

4. Design for valid recipients and permission

Do not use SMTP retries as a substitute for list hygiene. Collect addresses carefully, use double opt-in where it fits the program, capture consent records, process unsubscribe requests quickly, and suppress hard bounces.

For campaign mail, send first to people who have recently engaged. That approach reduces complaints and can provide stronger positive signals than repeatedly mailing a large inactive segment.

5. Monitor events at the right level

Track message IDs, recipient-level outcomes, SMTP response families, retry counts, final bounce classifications, complaint rates, unsubscribes, and latency. Segment the data by sending domain, stream, template, recipient domain, and application environment.

A spike in failures at one mailbox provider is different from a system-wide submission outage. Likewise, a specific template causing higher complaints is different from a DNS authentication failure affecting every message.

6. Treat content and infrastructure as connected

Strong authentication cannot compensate for unwanted email, and elegant content cannot compensate for a broken sending identity. Use clear sender names, recognizable domains, honest subject lines, accessible HTML, a plain-text alternative, and an easy path to unsubscribe from marketing messages.

Yahoo’s sender guidance emphasizes sending timely, relevant messages to active and engaged recipients, while its complaint feedback loop is tied to DKIM-signed mail. That is a useful illustration of the broader reality: authentication enables accountability, but audience quality determines whether recipients welcome the mail. (senders.yahooinc.com)

SMTP versus an email API

SMTP and an email API are not opposites in the deliverability sense. They are two interfaces for requesting an email send.

SMTP is broadly compatible. A CMS plugin, monitoring tool, ERP system, or older application may only support SMTP credentials and a host/port configuration. SMTP is also familiar to many programming languages and frameworks through well-tested mail libraries.

An email API uses HTTP requests, structured JSON payloads, API keys, and provider-specific endpoints. It can be easier to model advanced features such as templates, tags, idempotency, scheduling, webhooks, and detailed message metadata. It may also simplify debugging because request and response data fits ordinary API observability tooling.

Choose SMTP when compatibility and quick integration matter. Choose an API when your product needs richer programmatic controls or event handling. Many teams use both: SMTP for systems that only support SMTP and an API for new product services.

If you are deciding how to connect an application, review the available email API reference and setup guides alongside the configuration options your framework supports. The important point is not which interface sounds more modern; it is whether the interface is secure, observable, maintainable, and connected to a properly authenticated sending domain.

A practical SMTP troubleshooting workflow

When a message fails, avoid changing several variables at once. Work from the application outward.

  1. Confirm message creation. Verify the application generated a valid recipient, subject, sender, and body. Check that the intended environment is using the intended configuration.
  2. Verify SMTP submission. Confirm the hostname, port, TLS mode, and credentials. Look for connection, certificate, or authentication errors without exposing secrets in logs.
  3. Record the full SMTP response. Keep the numeric code, enhanced code, recipient domain, timestamp, and provider response text. The response context is more useful than a generic “send failed” label.
  4. Classify the result. Separate temporary 4xx deferrals from permanent 5xx rejections. Do not immediately suppress a recipient based on a single temporary condition.
  5. Check recipient-address quality. For permanent mailbox failures, stop sending to the address unless the recipient corrects it through a verified flow.
  6. Inspect authentication. Send a test message to a mailbox you control and inspect headers for SPF, DKIM, and DMARC results. Confirm alignment with the visible From: domain.
  7. Check reputation and campaign behavior. If the issue is throttling or filtering, review volume changes, complaint rates, engagement, targeting, and recent template changes.
  8. Make one measured change. Update the relevant setting, test with a small controlled group, and compare results before scaling.

This workflow prevents the common mistake of treating all SMTP errors as identical. A wrong password, an invalid mailbox, a temporarily busy receiving server, and a DMARC failure need entirely different fixes.

SMTP security considerations

SMTP was designed for interoperability, not for today’s threat environment. Secure sending requires more than making an outbound connection work.

Use TLS for authenticated message submission to protect credentials and content in transit between your application and the submission service. SMTP STARTTLS provides an upgrade path to a TLS-protected session, while modern standards also cover implicit TLS for submission. (rfc-editor.org)

Protect SMTP credentials as production secrets. Limit who can access them, rotate them regularly, and revoke them when an employee leaves or an integration is retired. Use separate credentials for separate applications so that a compromise can be contained without interrupting every sender.

Prevent open relay behavior. An open relay accepts unauthenticated mail and forwards it broadly, making it attractive to spammers and likely to damage the server’s reputation. Use authenticated submission for customers and internal applications, and configure relay permissions narrowly.

Finally, recognize the limits of opportunistic transport encryption between mail servers. STARTTLS can encrypt a connection when both sides negotiate it, but delivery may still prioritize interoperability unless additional policies are in place. SMTP extensions such as MTA-STS and TLS reporting exist to strengthen and observe transport security between mail systems. (rfc-editor.org)

The bottom line

SMTP is the protocol that gets an email moving. It is the practical bridge between your application and the global email ecosystem, handling submission, relay, response codes, retries, and the handoff to recipient mail systems.

But good SMTP connectivity alone does not create good deliverability. Reliable email requires secure submission, correct SPF/DKIM/DMARC authentication, accurate recipient data, respectful campaign practices, sensible retry logic, and monitoring that distinguishes acceptance from inbox placement.

Treat SMTP as both infrastructure and evidence. Configure it carefully, capture the responses it returns, and use those signals to improve the messages, sending identity, and recipient experience behind every send.

FAQ

What does SMTP stand for?

SMTP stands for Simple Mail Transfer Protocol. It is the standard protocol used to submit, relay, and deliver outgoing email between applications and mail servers.

Is SMTP the same as an email API?

No. SMTP is a mail transport protocol, while an email API is usually an HTTP interface for requesting sends. Both can send transactional and campaign email through the same provider infrastructure.

Does a 250 SMTP response mean the email reached the inbox?

No. A 250 response usually means the next receiving server accepted the message. The recipient provider can still filter the message into spam, another tab, quarantine, or a later stage of processing.

What is the best SMTP port for sending email?

For authenticated message submission, port 587 with STARTTLS is the normal standards-based choice. Port 465 is also used for implicit TLS submission when supported by your provider. Use the host, port, and TLS mode documented for your sending service. (rfc-editor.org)

Why does SMTP return a 4xx error?

A 4xx SMTP response usually indicates a temporary problem, such as a busy recipient server, a rate limit, or a transient policy condition. Queue the message and retry with controlled backoff rather than repeatedly resending it immediately.