SMTP library guides for Java, Node, PHP, Python, Ruby, and C#

Choose the SMTP guide for your language, then check your provider's host, port, authentication and TLS settings. The guides below cover sending messages and checking what reaches the recipient inbox.

Quick answer

Use SMTP when you need standards-based transport compatibility across providers and existing mail workflows.

Use API delivery when you need richer payload controls, stronger idempotency semantics, and simpler observability.

Most teams use both:

1. SMTP for legacy or standards-driven integrations.
2. API delivery for newer product flows and tighter release automation.

Language guides

Pick your stack and follow the implementation guide:

• Node SMTP guide
• Python SMTP guide
• PHP SMTP guide
• Java SMTP guide
• Ruby SMTP guide
• C# SMTP guide

Each guide includes a sending example, configuration checks and common errors to investigate.

SMTP settings and transport defaults

Setting	Recommended default	Why it matters
Submission port	587	Best default for authenticated SMTP submission
Alternate TLS port	465	Useful for implicit TLS environments
Auth	required	Prevents unauthorized relay use
TLS mode	STARTTLS or implicit TLS	Protects credentials and message transport
Retry policy	queue with backoff	Reduces transient-failure drop risk
Bounce handling	centralized and monitored	Protects sender reputation

For deeper port troubleshooting and protocol detail:

• What are SMTP ports
• SMTP authentication
• STARTTLS verification

API vs SMTP decision framework

Decision factor	SMTP	API
Provider portability	strong	medium
Advanced payload controls	medium	strong
Operational observability	medium	strong
Existing system compatibility	strong	medium
CI-friendly test ergonomics	medium	strong

If your team is modernizing delivery architecture, use SMTP alongside these MailSlurp API workflows:

• Send email API
• Email API overview
• Email integration testing

Gmail SMTP server and app configuration checks

Gmail and Microsoft 365 have their own SMTP settings and account policies. Once you've configured the connection, use MailSlurp to check that a message sent by your application reaches the expected inbox.

Use MailSlurp when you need to confirm:

• SMTP host, port, TLS, and auth mode are correct in each environment
• test messages arrive in a controlled inbox
• headers show the expected sender identity
• SPF, DKIM, and DMARC pass for the sending domain
• retries and bounce handling do not hide delivery failures

Production checklist for SMTP implementations

Before release, confirm:

1. Sender domains pass SPF, DKIM, and DMARC checks.
2. Credentials are stored in environment variables, not source control.
3. Port and TLS settings are validated in each environment.
4. Retry, timeout, and backoff policies are explicit.
5. Bounce and complaint events are monitored with ownership.
6. Templates are validated in real inbox tests.
7. Dark mode and client rendering checks are part of release gates.
8. Rollback path exists for template or transport regressions.

Two-week rollout plan

Week 1: implementation baseline

1. Implement SMTP send path with secure transport defaults.
2. Add authentication checks (SPF, DKIM, DMARC) for active domains.
3. Add deterministic inbox assertion tests for one critical journey.

Week 2: release hardening

1. Add deliverability and spam diagnostics to CI.
2. Add retry and incident ownership playbooks.
3. Run canary release validation before each production rollout.

Helpful references:

• SPF checker
• DKIM checker
• DMARC checker
• Email deliverability test

Common SMTP failure patterns

530 authentication required

Usually caused by missing auth credentials, wrong submission endpoint, or TLS mismatch.

See: SMTP 530 troubleshooting

550 rejected recipient

Often caused by invalid mailbox, sender-policy misalignment, or anti-spam enforcement.

See: Fixing SMTP 550 errors

Delayed or queued delivery

Usually caused by rate limits, remote deferrals, or retry policy gaps.

See: What does queued mean

Build once, test continuously

Do not treat SMTP setup as a one-time config task. Treat it as a tested delivery path:

• validate each send path in CI
• assert real message receipt in test inboxes
• audit headers and auth verdicts before production rollouts

For workflow-level validation, use:

• Email Sandbox
• Email testing tools
• Email testing checklist

If you are ready to implement this in production, start with free sign-up and then use pricing or sales support based on team scale and compliance needs.