You can warm up an email sender through its existing SMTP service without moving the mailbox. MailSlurp uses that connection to send paced messages and observe delivery, giving you a way to check the sender before asking it to handle more traffic.

SMTP stands for Simple Mail Transfer Protocol. In this guide, it's the connection used to submit outgoing email to your provider. We'll set up that connection, confirm a test delivery, and work through the common reasons a first send stalls.

## What SMTP warmup actually exercises

The warmup uses the server, credentials and sender identity you configure. That matters if your company has several sending routes: a mailbox used for support, a separate newsletter service and an application sending password resets may all have different configurations.

For example, warming `support@example.com` through its mailbox provider doesn't exercise a newsletter sent through a separate relay. The connection should match the sender you want to prepare. If the distinction between a mailbox, domain and sending IP is getting blurry, our [IP warmup and domain warmup explanation](/blog/ip-warmup-vs-domain-warmup/) sorts out those terms.

MailSlurp has named provider options as well as **Other provider (SMTP)**. A named option is useful when it supplies the correct provider fields; the generic option works with a provider that supplies authenticated SMTP credentials. The [SMTP connection reference](/docs/email-warmup/smtp/) is the short version of the setup.

## Gather the connection details

Most setup mistakes start with a plausible-looking value from the wrong settings page. The incoming-mail server is a particularly convincing impostor.

| Setting | What belongs here |
| --- | --- |
| SMTP host | The provider's outgoing submission server, without an `https://` prefix |
| Port and security | The exact pair documented by the provider |
| Username | The SMTP username, which may differ from the visible email address |
| Password | The provider-issued SMTP credential or eligible app password |
| Sender identity | The From address authorized for this connection |

MailSlurp's generic SMTP guidance uses port `587` with STARTTLS when the provider supports it. STARTTLS upgrades the connection to encrypted transport before message submission. Some providers also offer implicit TLS on port `465`, where encryption starts immediately. These are distinct connection modes; swapping only the port can leave the client and server speaking at cross-purposes. [RFC 8314](https://www.rfc-editor.org/rfc/rfc8314.html#section-3.3) describes both.

The host also needs to be reachable from MailSlurp. A local SMTP server on your laptop and a provider's public submission endpoint are different destinations. For a private relay, the administrator can confirm the supported connection route before you enter credentials.

## Verify the connection before starting a program

1. Open **Email warmup** in MailSlurp and select **Create warmup**.
2. Select an existing sending connection, a named provider, or **Other provider (SMTP)**.
3. Enter the SMTP settings and the authorized sender details.
4. Verify the credential and complete the test delivery.
5. Select the new-sender or sender-repair goal and choose a schedule.
6. Choose the available coverage and content, then create and start the program.

Credential verification and test delivery answer separate questions. A login can succeed while the server rejects the From address or recipient. Completing the test delivery helps catch those restrictions before a scheduled program repeatedly encounters them.

For custom-domain mail, a received test also gives you a chance to inspect authentication. The [email header analyzer](/tools/email-header-analyzer/) helps read SPF, DKIM and DMARC results. A successful SMTP login doesn't establish that the visible From domain is authenticated correctly.



{{LANDING_SHORTCODE:POST_CTA_BANNER:%7B%22title%22%3A%22Put%20your%20SMTP%20sender%20on%20a%20steady%20schedule%22%2C%22content%22%3A%22Connect%20your%20existing%20sender%20to%20MailSlurp%2C%20verify%20a%20test%20delivery%2C%20and%20follow%20paced%20activity%20with%20delivery%20observations%20and%20available%20provider%20placement%20checks.%22%2C%22buttonHref%22%3A%22%2Fproduct%2Femail-warmup%2F%22%2C%22buttonText%22%3A%22Explore%20email%20warmup%22%2C%22buttonTheme%22%3A%22slate%22%2C%22image%22%3A%22asset%3Aproduct%2Femail-warmup%2Fscreenshots%2Fschedule-mobile.png%22%2C%22imageAlt%22%3A%22Example%20Gentle%20warmup%20schedule%20in%20the%20MailSlurp%20app%22%2C%22imageWidth%22%3A%22716%22%2C%22imageHeight%22%3A%22640%22%2C%22imagePosition%22%3A%22%22%7D}}



## When the first send fails

The useful starting point is the stage that failed. A timeout, a rejected login and a spam result need different fixes.

| What you see | Where to look next |
| --- | --- |
| Connection timeout | Host spelling, provider service availability and whether the endpoint is reachable |
| TLS negotiation error | The provider's required port/security pair and certificate configuration |
| Authentication rejected | SMTP username, credential type, expiry or account policy |
| Login succeeds, sender rejected | Authorization for the From address or sending domain |
| Recipient rejected | Provider restrictions, including sandbox rules where applicable |
| Rate or quota error | Other activity on the account as well as the warmup schedule |
| Send accepted, placement poor | Completed destination results, message authentication and sender history |

The exact response text matters more than the category name. For example, an [Amazon SES warmup](/guides/amazon-ses-warmup/) can fail because the credentials belong to another region or the account still restricts recipients. Re-entering the same password won't resolve either condition.

A useful troubleshooting note contains the time, sender, SMTP host, port/security mode, last successful test and the provider's response. Credentials stay out of the note. After correcting the cause, another verification and test delivery gives you a clear point from which to resume.

## Choose a pace that fits the sender's workload

The schedule controls warmup activity; ordinary mailbox sends and other applications still use the provider account. MailSlurp's **Customize schedule** includes current and target daily volume, ramp duration, maintenance, time zone and local sending window. The [warmup schedule guide](/blog/email-warmup/#which-email-warmup-schedule-makes-sense) explains the presets.

Once the program starts, accepted sends show that the sending provider accepted outbound requests. Controlled-inbox receipt and completed provider placement add downstream evidence. A quiet program outside its sending window may be working exactly as configured; repeated failures during scheduled activity deserve a review.

The [guide to reading warmup results](/guides/email-warmup-inbox-placement/) explains how to compare those observations. When the connection and schedule are ready, [create a MailSlurp account](https://app.mailslurp.com/sign-up/?onboardingRequest=deliverability) and start with a verified delivery from the sender you actually plan to use.