SMTP Relay: How It Works, How to Set It Up, and How to Troubleshoot It

SMTP relay is the service that accepts an outbound message from your application, CMS, device, or mail client and delivers it onward through the email ecosystem. It is one of the most widely supported ways to send transactional email, especially when existing software already knows how to speak SMTP.

For developers, SMTP can feel deceptively simple: enter a host, port, username, and password, then send. In production, reliable SMTP relay also depends on TLS, authenticated submission, sender-domain authentication, correct envelope addresses, bounce handling, and a disciplined approach to diagnosing delivery failures.

What is SMTP relay?

SMTP stands for Simple Mail Transfer Protocol. It is the protocol used to submit, relay, and transfer email between systems. An SMTP relay is the mail service that receives your message from an authorized sender and forwards it toward the recipient's mail server.

In a typical transactional-email setup, your application does not run its own internet-facing mail transfer agent. Instead, it connects to a provider's SMTP endpoint using credentials. The provider authenticates the connection, evaluates the message, queues it if necessary, and attempts delivery to the recipient domain's mail exchanger (MX).

A basic path looks like this:

1. Your application creates an email message.
2. Your SMTP library connects to an authenticated submission server.
3. The SMTP relay accepts the envelope sender, recipients, headers, and message body.
4. The relay looks up the recipient domain's MX records.
5. The relay connects to the receiving mail system and attempts delivery.
6. The receiving server accepts, defers, or rejects the message.

The word “relay” is important. Your app is usually not connecting directly to gmail.com, outlook.com, or a recipient's private mail server. It submits mail to a relay that is designed to handle outbound delivery, IP reputation, retries, TLS negotiation, queue management, and feedback signals.

SMTP submission versus SMTP relay

People often use the terms interchangeably, but there is a useful distinction:

• SMTP submission is the connection from a mail client or application to its outbound mail service. This connection normally requires authentication and encryption.
• SMTP relay is the onward transfer of accepted mail between mail systems until it reaches the receiving server.

For an application developer, “SMTP relay” generally refers to the complete provider-operated service: you submit a message to its SMTP server, and it relays the message to recipients.

Why authenticated relay matters

An open relay accepts messages from anyone and forwards them anywhere. That behavior was once common, but it is now a major abuse vector and should never be used. Modern providers require authentication, apply sending limits, monitor abuse, and restrict the domains or identities a customer can use.

Authentication protects both sides. The provider can associate traffic with your account, while you avoid relying on an unauthenticated server that can be abused, blocklisted, or shut down.

How an SMTP relay session works

SMTP is a command-and-response protocol. A client opens a TCP connection, identifies itself, learns which extensions the server supports, authenticates, defines an envelope, transfers the message contents, then closes the session.

A simplified SMTP conversation may resemble this:

S: 220 smtp.provider.example ESMTP ready
C: EHLO app.example.com
S: 250-smtp.provider.example
S: 250-STARTTLS
S: 250-AUTH PLAIN LOGIN
S: 250 SIZE 52428800
S: 250 8BITMIME
C: STARTTLS
S: 220 Ready to start TLS
<the client negotiates TLS>
C: EHLO app.example.com
S: 250-AUTH PLAIN LOGIN
S: 250 SIZE 52428800
C: AUTH PLAIN <base64-encoded-credentials>
S: 235 2.7.0 Authentication successful
C: MAIL FROM:<bounce@example.com>
S: 250 2.1.0 OK
C: RCPT TO:<customer@example.net>
S: 250 2.1.5 OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: Product Team <updates@example.com>
C: To: Customer <customer@example.net>
C: Subject: Your receipt
C: Message-ID: <unique-id@example.com>
C: MIME-Version: 1.0
C: Content-Type: text/plain; charset=UTF-8
C:
C: Thanks for your order.
C: .
S: 250 2.0.0 Queued as abc123
C: QUIT
S: 221 2.0.0 Bye

This transcript reveals a critical operational point: a 250 after DATA generally means the relay accepted and queued the message. It does not necessarily mean the recipient saw it in their inbox. The relay may still encounter a temporary deferral, a permanent rejection, spam filtering, or downstream routing problems after accepting it from your application.

The SMTP envelope is not the visible message header

SMTP carries two related but different layers of addressing:

• The envelope sender, sent with MAIL FROM, is used for delivery notifications and SPF evaluation. It is often called the return path or bounce address.
• The envelope recipient, sent with RCPT TO, determines where the server attempts delivery.
• The visible From: and To: headers are part of the message content and are what recipients see in their mail client.

For example, a message may have this combination:

MAIL FROM:<bounces@bounce.example.com>
RCPT TO:<alex@recipient.net>
From: Billing <billing@example.com>
To: Alex <alex@recipient.net>
Reply-To: support@example.com

That configuration can be legitimate. However, the visible From domain, the SPF-authenticated envelope domain, and the DKIM signing domain should be designed to align under your DMARC policy. Using unrelated domains casually can damage trust and cause authentication failures.

SMTP relay configuration: host, port, TLS, and credentials

Every provider publishes its own SMTP hostname, supported ports, credential format, and authentication requirements. Do not guess these values; use the provider's current documentation. A typical configuration needs the following fields:

SMTP host: smtp.provider.example
Port: 587
Encryption: STARTTLS
Username: provider-issued SMTP username
Password: provider-issued SMTP password or SMTP token
From address: notifications@example.com

The exact labels differ between frameworks. One library may call encryption STARTTLS, another may use tls, secure, or requireTLS. The important detail is how the connection is secured, not the label in a particular interface.

Which SMTP port should you use?

The correct choice depends on what your provider supports and what your network permits, but these ports have distinct roles:

Port 587 is the conventional submission port and is usually the first choice for applications using STARTTLS. Port 465 is commonly used when the provider specifies implicit TLS, meaning the TLS handshake begins before SMTP commands are exchanged. Port 25 is primarily used for mail server-to-server communication and is frequently blocked by cloud hosts, ISPs, and corporate networks to limit abuse.

Port 2525 is widely offered as a practical fallback, but it is not a universal standard. Treat it as a provider-specific option rather than an assumption.

STARTTLS versus implicit TLS

These terms describe two different connection patterns:

• STARTTLS: Connect in plaintext, issue EHLO, confirm the server advertises STARTTLS, then upgrade the same connection to TLS.
• Implicit TLS: Start TLS immediately when connecting, commonly on port 465.

A frequent setup failure occurs when an application uses implicit TLS settings on port 587, or tries STARTTLS against an endpoint that expects immediate TLS. The symptoms can include connection resets, handshake failures, unreadable server responses, or timeouts.

When the configuration screen asks for “SSL,” “TLS,” or “STARTTLS,” confirm how the chosen library maps those options. In Node.js libraries, for example, secure: true commonly means implicit TLS, while secure: false with TLS upgrade support is commonly used for STARTTLS. Verify the library's current documentation before copying a configuration pattern.

Use credentials created for SMTP, not a personal mailbox password

A provider may use an account-level username and password, an SMTP-specific credential, or a generated token. Use the mechanism it documents. Do not expose credentials in source code, browser-side JavaScript, mobile applications, screenshots, or unencrypted configuration files.

Store SMTP credentials in a secrets manager or environment variables. Give production, staging, and development separate credentials where possible. This makes revocation safer and makes it easier to trace unexpected sending.

A safe environment-variable pattern looks like this:

SMTP_HOST=smtp.provider.example
SMTP_PORT=587
SMTP_USER=your-smtp-username
SMTP_PASS=your-smtp-password
SMTP_FROM="Example App <notifications@example.com>"

Do not log SMTP_PASS, authorization strings, raw AUTH commands, or full message content containing personal data.

Sending through SMTP relay in application code

SMTP is especially useful when your application framework already supports it. Most mature ecosystems have SMTP-capable libraries, including Nodemailer for Node.js, Python's smtplib, Jakarta Mail for Java, Rails Action Mailer, Django's email backend, and many CMS plugins.

The library handles MIME formatting, attachment encoding, multiline bodies, SMTP commands, and connection management. Your job is to configure it correctly, construct a compliant message, and observe what happens after handoff.

Example: Node.js with Nodemailer

This generic example uses environment variables rather than hard-coded secrets:

import nodemailer from 'nodemailer';

const transporter = nodemailer.createTransport({
  host: process.env.SMTP_HOST,
  port: Number(process.env.SMTP_PORT || 587),
  secure: false, // Usually false for port 587 + STARTTLS
  auth: {
    user: process.env.SMTP_USER,
    pass: process.env.SMTP_PASS,
  },
  requireTLS: true,
});

const result = await transporter.sendMail({
  from: process.env.SMTP_FROM,
  to: 'customer@example.net',
  subject: 'Reset your password',
  text: 'Use this link to reset your password: https://app.example.com/reset',
  html: '<p>Use this link to reset your password: <a href="https://app.example.com/reset">Reset password</a></p>',
});

console.log({
  messageId: result.messageId,
  accepted: result.accepted,
  rejected: result.rejected,
  response: result.response,
});

The accepted array in a client-library result normally tells you that the configured relay accepted particular recipients during submission. It should not be treated as proof of final inbox placement.

Message construction details that prevent avoidable failures

A well-formed transactional message should include:

• A valid, verified From: address using a domain you control.
• A recognizable sender display name.
• A meaningful Subject: line.
• Both plain-text and HTML bodies for messages that use HTML.
• A unique Message-ID header, usually generated by the library or relay.
• A working Reply-To: address when replies should reach a person or support queue.
• Valid absolute URLs using HTTPS where appropriate.
• A clear reason the recipient is receiving the email.

Avoid putting a recipient list in To: while actually delivering the same message broadly through BCC. For transactional email, generate recipient-specific messages and pass each address explicitly. This improves privacy, observability, personalization, and bounce handling.

SMTP versus a REST email API

SMTP relay and a REST API both solve the problem of handing email to a sending platform. Neither is automatically better in every architecture.

SMTP is often the practical choice when you need compatibility with legacy applications, appliances, WordPress plugins, ERP systems, or frameworks configured around SMTP. A REST API is often easier when you want structured request validation, idempotency patterns, first-class templates, metadata, tags, batch operations, or richer event correlation.

A transactional email platform may support both REST API sending and SMTP relay. That gives teams a useful migration path: keep older systems on SMTP while new services use the email API reference and setup guides where structured API calls fit better.

DNS authentication for SMTP relay

SMTP credentials authorize your application to use a relay. DNS authentication proves, or helps prove, that the sending infrastructure is permitted to send mail for your domain. These are separate requirements.

A relay can accept your message successfully while recipients still filter or reject it because SPF, DKIM, DMARC, or domain alignment is missing or misconfigured.

SPF: authorize senders in DNS

Sender Policy Framework (SPF) is a TXT record that tells recipient systems which sending sources are authorized to send mail using an envelope-sender domain.

A generic SPF record looks like this:

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

The syntax is real, but spf.provider.example is only a placeholder. Your provider must give you the exact include: mechanism or sending IP addresses to publish. Do not substitute a made-up include domain.

Important SPF rules:

• Publish one SPF record per domain. Multiple separate v=spf1 TXT records can cause SPF PermError.
• Merge all authorized senders into that single record. If Google Workspace, a help desk, and a transactional relay all send with the same envelope domain, they may all need mechanisms in the same SPF policy.
• Use ~all or -all deliberately. -all is a hard fail for unlisted senders; ~all is a soft fail. Your authentication strategy and DMARC rollout should guide the choice.
• SPF has a DNS lookup limit. Long chains of nested include: mechanisms can exceed it and break evaluation.

SPF checks the domain used in the SMTP envelope sender, not necessarily the visible From header. That difference is why DKIM and DMARC matter.

DKIM: sign mail cryptographically

DomainKeys Identified Mail (DKIM) adds a digital signature to the message. The public key is published in DNS, and receiving systems use it to validate that the signed portions of the message were not altered after signing and that the signer controls the relevant domain.

A generic DKIM record has this shape:

selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

The selector, key type, and public key value must come from your provider. Many providers use CNAME records for DKIM delegation instead of publishing a long TXT key directly. A delegated setup could look like this:

selector1._domainkey.example.com. 3600 IN CNAME selector1.provider.example.

Do not modify or truncate a provider-generated key. DNS dashboards sometimes wrap long TXT values visually; that does not always mean you should add quotation marks or split the record manually. Follow the DNS host's format requirements while preserving the exact published value.

DMARC: require alignment and receive reports

DMARC builds on SPF and DKIM. It lets a domain owner publish a policy for mail using that domain in the visible From header, and it requires alignment between the From domain and either a passing SPF domain or a passing DKIM signing domain.

A conservative monitoring record might look like this:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

This record asks receivers to take no enforcement action (p=none) while aggregate reports are sent to the rua mailbox. Relaxed alignment is represented by adkim=r and aspf=r; strict alignment uses s instead.

A mature rollout normally proceeds in stages:

1. Publish p=none and inspect aggregate reports.
2. Identify legitimate sources that are failing alignment.
3. Correct SPF, DKIM, and From-domain configuration.
4. Move to p=quarantine after you understand the traffic.
5. Consider p=reject when you are confident that authorized mail passes.

DMARC reports are XML files and can be difficult to interpret manually. Reporting services can aggregate them, but even basic analysis is valuable: look for unfamiliar IP addresses, unexpected services, and authentication failures involving your domains.

Why domain alignment affects deliverability

Imagine an email that visibly comes from billing@example.com, but its SPF result passes only for mailer.other-domain.net and DKIM signs with provider-mail.example. SPF and DKIM may each pass independently, yet DMARC can still fail if neither authenticated domain aligns with example.com under the applicable alignment mode.

This is a common source of confusion. “SPF passed” is not the same as “DMARC passed.” Review the full authentication result, including the visible From domain, envelope domain, DKIM d= domain, and alignment status.

Deliverability: acceptance is not inbox placement

A functioning SMTP relay connection is only the first layer of email delivery. Recipient systems evaluate the message, the sending domain, the sending IP, the recipient's engagement history, and their own anti-abuse policies.

A 250 response from your relay tells you it accepted the message for processing. A later provider event showing “delivered” generally means the receiving server accepted it. Neither status guarantees that the message landed in the primary inbox rather than spam, promotions, quarantine, or another folder.

Factors that influence delivery

Deliverability is affected by several interacting signals:

• SPF, DKIM, and DMARC authentication and alignment.
• Sender-domain and sending-IP reputation.
• Complaint rates and spam reports.
• Hard bounces, invalid-address rates, and repeated delivery attempts to bad recipients.
• Recipient engagement and message relevance.
• Content that resembles phishing, malware, deceptive offers, or unsolicited bulk mail.
• Link domains, redirects, image hosting, and landing-page reputation.
• Consistent traffic patterns versus sudden unexplained spikes.
• Correct reverse DNS and TLS for systems directly operating outbound IP addresses.

For transactional mail, relevance is a strength. Password resets, receipts, verification emails, security alerts, and requested notifications are usually expected by the recipient. But a transactional classification does not excuse weak authentication or poor recipient hygiene.

Test the entire message, not only the connection

A successful telnet, OpenSSL, or application connection test verifies only that you can reach and authenticate to the SMTP endpoint. It does not validate DNS alignment, content rendering, spam filtering, or downstream delivery.

Use a layered test process:

1. Send to an inbox you control at a major mailbox provider.
2. Inspect message headers for SPF, DKIM, and DMARC results.
3. Confirm that the visible From address and links render correctly.
4. Send a test to a service such as mail-tester.com and review its findings.
5. Use DNS tools such as MXToolbox to inspect published records, propagation, syntax, and common configuration problems.
6. Review provider message events, bounce reasons, and suppression behavior.

A free address-validation tool can also help catch obvious address errors before a send; for example, use an email address verification tool as an early screening step. Verification is not a substitute for permission, engagement, or bounce processing, but it can reduce preventable invalid-recipient attempts.

SMTP status codes and what they mean

SMTP servers respond with three-digit reply codes. The first digit provides the broad outcome:

• 2xx: Success.
• 3xx: More information or another command is needed.
• 4xx: Temporary failure; retry may succeed later.
• 5xx: Permanent failure; retrying unchanged mail to the same recipient is usually not useful.

Many responses also contain enhanced status codes such as 5.1.1 or 4.7.0. These provide more specific diagnostic context, although wording and exact subcodes can vary across receiving systems.

Common SMTP relay and delivery responses

The text after the code often contains the most actionable detail. Preserve it in structured logs, but redact secrets and unnecessary personal information.

Hard bounces, soft bounces, and retries

A hard bounce is generally a permanent failure, such as an invalid mailbox. A soft bounce is generally temporary, such as a mailbox being unavailable, a receiving server being busy, or a temporary policy deferral.

Do not retry every failure forever. A good retry policy uses exponential backoff, jitter, a maximum retry window, and per-recipient safeguards. Repeated attempts to invalid addresses hurt reputation and waste sending capacity.

For example, an application might retry certain 4xx results after increasing delays, while immediately suppressing 5.1.1 mailbox-not-found responses. The exact behavior should be based on the relay's event data and the recipient server's response, not just a simplistic “4xx equals retry, 5xx equals never retry” rule.

Troubleshooting SMTP relay problems systematically

SMTP problems are easier to solve when you determine which stage is failing: network connection, TLS negotiation, authentication, sender authorization, message acceptance, or recipient delivery.

Connection failures

Typical symptoms include ETIMEDOUT, ECONNREFUSED, socket errors, or a connection that never reaches the server greeting.

Check these items:

• Confirm the hostname exactly matches the provider documentation.
• Confirm the port is correct for the intended TLS mode.
• Check outbound firewall, VPC security-group, container-network, and corporate proxy rules.
• Test whether your cloud host blocks outbound port 25.
• Try the provider-supported fallback port only if its documentation offers one.
• Confirm that DNS resolution works from the production environment, not merely from your laptop.

A useful TLS diagnostic command for a STARTTLS endpoint is:

openssl s_client -starttls smtp -connect smtp.provider.example:587 -crlf

For an implicit-TLS endpoint on port 465, use:

openssl s_client -connect smtp.provider.example:465 -crlf

These commands can show certificate details and the server greeting. Do not type production authentication secrets into a shared terminal session or paste them into support tickets.

TLS failures

If the network connection opens but TLS fails, common causes include a port/mode mismatch, an outdated TLS library, certificate-validation problems, a proxy intercepting encrypted traffic, or a client configured to accept only obsolete ciphers.

Do not “fix” certificate failures by disabling verification in production. That can expose SMTP credentials and message contents to interception. Instead, update the operating system trust store, runtime, library, or network configuration as appropriate.

Authentication failures

A 535 error often means invalid credentials, but not always. It can also result from using an API key where SMTP credentials are required, copying whitespace into a secret, selecting an unsupported authentication mechanism, or attempting SMTP AUTH before STARTTLS when the provider requires encryption.

Work through this checklist:

1. Generate or retrieve the current SMTP-specific credential.
2. Confirm the correct username format; it may not be an email address.
3. Confirm the correct password or token is deployed to the active environment.
4. Verify the port and TLS mode.
5. Rotate the credential if exposure or configuration drift is suspected.
6. Check that your account is allowed to send and is not suspended or restricted.

Sender-domain errors

A relay may reject a message because the From address or envelope sender does not belong to a verified domain. This is deliberate: allowing arbitrary unverified From domains would enable spoofing.

Check that the domain is verified, its required DNS records are published, and the sender address uses the verified domain exactly. A subdomain such as mail.example.com may require separate verification from example.com, depending on the provider and DNS setup.

Recipient rejections

When the provider accepts a message but the receiving mail server rejects it, inspect the complete downstream response. A 550 5.1.1 usually points to an invalid address. A 554 5.7.1 may indicate content, authentication, reputation, or policy concerns. A 421 or 451 may be temporary throttling or a short-lived receiving-server issue.

Do not assume every 5.7.1 response means your content contains a forbidden word. Modern mailbox filtering considers the combined identity, technical authentication, traffic patterns, links, recipient behavior, and abuse signals.

Operational practices for reliable SMTP sending

SMTP relay is dependable when it is treated as production infrastructure rather than a hidden utility. The best practices below reduce operational surprises.

Separate transactional and promotional traffic

If possible, separate operational messages from marketing sends by stream, domain, subdomain, or provider configuration. A password reset is fundamentally different from a newsletter. Mixing them can make it harder to monitor performance and can expose critical mail to reputation damage caused by less-engaged campaigns.

A sensible pattern is to use a dedicated subdomain such as notify.example.com or mail.example.com for application-generated mail while keeping the primary corporate domain for person-to-person communication. The right choice depends on brand, authentication architecture, and existing mail systems.

Make sending idempotent

Network failures create ambiguity. Your application may time out after the SMTP server accepted a message but before it returned a response. Blindly retrying can send duplicates.

Use application-level idempotency controls. For example, store a durable event ID for each password reset, receipt, or alert; mark it as submitted only after a known outcome; and design a reconciliation process for uncertain sends. Include a business identifier in metadata or headers where your provider and privacy requirements permit it.

Track the lifecycle after submission

The application should distinguish between these events:

• Message created.
• Submission attempted.
• Relay accepted the message.
• Provider queued or processed it.
• Receiving server accepted it.
• Message bounced, was deferred, or was suppressed.
• Recipient engaged, where applicable and privacy-compliant.

This model prevents a common support mistake: calling a message “delivered” merely because the app did not throw an SMTP exception.

Protect recipients and your reputation

Only send to people who should receive the message. For transactional workflows, that means tying each send to a clear user action, account state, purchase, security event, or notification preference.

Maintain suppression lists for hard bounces, unsubscribes where applicable, and known complaints. Honor opt-outs promptly for non-essential mail. Avoid repeatedly sending to addresses that have permanently failed.

Set alerts and useful logs

Monitor connection errors, authentication failures, acceptance rates, bounce categories, deferrals, complaint signals, and sudden changes in volume. Alert on meaningful deviations, such as a rapid increase in 535 errors after a credential rotation or a spike in 5.1.1 failures after an import.

Logs should include timestamps, environment, provider message identifiers, recipient-domain categories, response codes, and internal event IDs. Be deliberate about data minimization: email content and full addresses may be sensitive and should not be retained indiscriminately.

When SMTP relay is the right choice

SMTP relay is usually a strong fit when your software already supports SMTP, when you need a low-friction migration away from a local mail server, or when a third-party product exposes only SMTP settings.

Common uses include:

• Password resets and email verification.
• Purchase receipts and invoices.
• Account, security, and login alerts.
• Contact-form notifications.
• CMS and ecommerce-platform messages.
• Monitoring alerts and device notifications.
• Legacy applications that cannot easily make HTTP requests.

A REST email API may be a better fit when your application needs detailed structured responses, richer message metadata, asynchronous batch workflows, template rendering controlled from code, or easier integration with modern observability tooling. The important decision is not protocol loyalty; it is choosing a sending path that your team can secure, monitor, and maintain.

SMTP relay checklist

Before sending production traffic, verify the following:

• The SMTP hostname, port, and TLS mode match your provider's current documentation.
• SMTP credentials are stored as secrets and are not embedded in code.
• Production and non-production environments use different credentials.
• The From domain is verified with the sending service.
• SPF is published as one valid TXT policy for the relevant envelope-sender domain.
• DKIM records are published exactly as supplied by the provider.
• DMARC is published and reports are monitored during rollout.
• The visible From domain aligns with a passing SPF or DKIM identity.
• Messages include usable plain-text and HTML alternatives where appropriate.
• Hard bounces and unsubscribes are suppressed.
• Temporary failures have bounded retry behavior with backoff.
• Provider event data and application logs are monitored after submission.
• Test messages have been checked in real inboxes and with deliverability tools.

Conclusion

SMTP relay remains a practical, interoperable way to send application email. It lets almost any framework, CMS, device, or legacy system hand outbound mail to specialized infrastructure without operating a public mail server itself.

The connection settings are only the start. Production-quality SMTP relay requires the correct port and TLS mode, authenticated credentials, verified sender domains, SPF/DKIM/DMARC alignment, meaningful monitoring, bounce-aware retry logic, and responsible recipient practices. When those pieces work together, SMTP becomes a dependable transport layer for the messages users rely on most.

FAQ

What is an SMTP relay server?

An SMTP relay server accepts outbound email from an authorized application or mail client and forwards it toward recipient mail servers. Most transactional email providers operate SMTP relay infrastructure so customers do not have to run their own public mail server.

Is SMTP relay the same as an SMTP server?

Not exactly. An SMTP server can receive, submit, relay, or deliver mail depending on its role. An SMTP relay specifically forwards accepted outbound mail onward, typically after authenticating the sender.

Should I use port 587 or 465 for SMTP relay?

Use the port and encryption mode your provider documents. Port 587 with STARTTLS is a common submission configuration. Port 465 normally uses implicit TLS. Do not combine port 587 with implicit-TLS settings unless the provider explicitly instructs you to do so.

Why does SMTP say my email was accepted but the recipient did not receive it?

Acceptance means your relay accepted the message for processing, not that it reached the inbox. The provider may later encounter a bounce, deferral, spam filter, recipient-side rule, or delivery policy rejection. Review downstream delivery events and message headers.

Do I need SPF, DKIM, and DMARC when using SMTP relay?

Yes. SMTP authentication authorizes your application to submit through the relay, while SPF, DKIM, and DMARC help receiving mail systems authenticate your domain and evaluate alignment. They are essential for modern deliverability and anti-spoofing protection.