If you are searching for an `smtp library` or a practical way to send mail over SMTP in your stack, start here.

This hub maps language-specific guides, transport settings, and reliability controls so you can move from local proof-of-concept to production release without guesswork.

## 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](/guides/smtp/node-send-email-smtp/)
- [Python SMTP guide](/guides/smtp/python-send-email-smtp/)
- [PHP SMTP guide](/guides/smtp/php-send-email-smtp/)
- [Java SMTP guide](/guides/smtp/java-send-email-smtp/)
- [Ruby SMTP guide](/guides/smtp/ruby-send-email-smtp/)
- [C# SMTP guide](/guides/smtp/csharp-send-email-smtp/)

Each guide covers minimal setup, secure defaults, common errors, and release validation handoff.

## 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](/blog/which-smtp-port-should-i-use/)
- [SMTP authentication](/blog/smtp-authentication/)
- [STARTTLS verification](/blog/how-to-test-if-mailserver-supports-starttls/)

## 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/send-email-api/)
- [Email API overview](/email/email-api/)
- [Email integration testing](/product/email-integration-testing/)

## Gmail SMTP server and app configuration checks

Teams often arrive here after searching for Gmail SMTP server settings, Office 365 SMTP settings, or a free SMTP server for testing. MailSlurp gives those teams a safer workflow: keep protocol configuration explicit, test the send path with real inbox assertions, and validate sender authentication before volume increases.

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

For Gmail or Workspace SMTP, verify the provider-specific settings separately, then use MailSlurp inboxes and deliverability checks to prove the message path behaves correctly.

## 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](/tools/spf-checker/)
- [DKIM checker](/tools/dkim-checker/)
- [DMARC checker](/tools/dmarc-checker/)
- [Email deliverability test](/testing/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](/support/smtp-530-failures-gmail-yahoo-etc/)

### 550 rejected recipient

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

See: [Fixing SMTP 550 errors](/blog/fixing-smtp-550-errors/)

### Delayed or queued delivery

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

See: [What does queued mean](/blog/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](/product/email-sandbox/)
- [Email testing tools](/testing/email-testing-tools/)
- [Email testing checklist](/blog/email-testing-checklist/)

If you are ready to implement this in production, start with [free sign-up](https://app.mailslurp.com/sign-up/?onboardingRequest=developers) and then use [pricing](https://app.mailslurp.com/pricing/) or [sales support](/sales/) based on team scale and compliance needs.