PHPMailer and SMTP: A Deployment Checklist With a Minimal Example

TL;DR

• Use PHPMailer through Composer and keep SMTP credentials outside source code.
• Match host, port and encryption mode to the provider's documented configuration.
• A successful send call records submission; later delivery failures still need handling.
• Test authentication, recipient errors and retries with controlled data before using the flow in production.

Start with the maintained library and a clear boundary

PHPMailer provides a PHP interface for constructing and sending email, including SMTP submission. Use the official PHPMailer repository for installation and configuration guidance rather than copying an old single-file example from an unrelated application.

Install the package with Composer in the application that will send mail. Keep the sending code on the server. A browser form should submit validated business data to your application; it should never receive SMTP credentials or choose arbitrary message headers.

For a contact form, decide who receives the message and which verified sender address the application uses. Do not let untrusted form input replace the authenticated From address. A validated visitor address can be used as Reply-To when that is appropriate to the workflow.

Review configuration before writing the send call

Check the provider hostname, authentication method, permitted sender, port and encryption mode. Port 587 commonly uses STARTTLS, while port 465 commonly uses implicit TLS, but the provider's instructions are authoritative for your connection.

Store credentials in the deployment's secret configuration. Validate that they are present at startup or before enabling the email feature. Treat a missing password as a configuration failure, not as a reason to try unauthenticated submission.

Do not turn off TLS certificate checks to fix a connection problem. Investigate the hostname, certificate chain, runtime trust store and network path instead.

A small submission example

The following original example assumes Composer autoloading and a provider that documents authenticated STARTTLS on port 587. Replace the placeholder sender and recipient with addresses you control for testing:

<?php
use PHPMailer\PHPMailer\PHPMailer;

require __DIR__ . '/vendor/autoload.php';

$required = ['SMTP_HOST', 'SMTP_USER', 'SMTP_PASSWORD'];
foreach ($required as $name) {
    if (!getenv($name)) {
        throw new RuntimeException('Missing email configuration');
    }
}

$mail = new PHPMailer(true);
$mail->isSMTP();
$mail->Host = getenv('SMTP_HOST');
$mail->SMTPAuth = true;
$mail->Username = getenv('SMTP_USER');
$mail->Password = getenv('SMTP_PASSWORD');
$mail->SMTPSecure = PHPMailer::ENCRYPTION_STARTTLS;
$mail->Port = 587;
$mail->Timeout = 15;
$mail->setFrom('notifications@example.com', 'Example App');
$mail->addAddress('test-recipient@example.com');
$mail->Subject = 'Controlled email test';
$mail->Body = 'This message checks the configured submission path.';
$mail->send();

This is a connection example, not a complete production notification system. Wrap submission in your application's error handling and avoid displaying raw exceptions or credentials to visitors. The library's SMTP example is a useful reference for additional options.

Add validation and abuse controls around forms

Validate recipient-related input according to the product's actual purpose. If the application always sends contact requests to one support mailbox, keep that recipient on the server. Do not turn the form into an arbitrary email relay.

Apply appropriate request limits and bot protection. Keep the message size bounded. Escape user-provided values when building HTML, and use structured library methods for addresses and headers rather than concatenating raw header strings.

For account notifications, connect the send to an authenticated business event. A public endpoint that can repeatedly trigger messages to arbitrary addresses can create abuse even when the underlying SMTP configuration is correct.

Record outcomes without leaking message content

Save an application notification identifier and the observed submission result. Keep enough information to investigate an error, but avoid recording full message bodies, passwords or authentication exchanges in normal production logs.

A connection failure before submission and an uncertain outcome after a timeout are different states. Do not retry both identically. See our email idempotency guide for a durable approach to intended messages and repeated attempts.

If your provider offers delivery events, verify their authenticity and handle duplicates. A send method returning successfully does not establish inbox placement or reading.

Use a release checklist that reflects real failures

Test the deployed runtime with a controlled recipient, then exercise a rejected recipient, an invalid credential and a temporary failure. Verify that the user sees a useful message, support can locate the notification and the application does not silently discard errors.

Our SMTP versus email API comparison can help if you are choosing the transport. When evaluating MailBlastr, use its current documentation for the supported integration method instead of assuming that every SMTP feature is available through every delivery product.