PHPMailer 7: three class files, four auth mechanisms, and one feature that adds dependencies

Three class files carry the library and Exception is not optional

The Composer route is one line in composer.json, phpmailer/phpmailer at ^7.0.0:

"phpmailer/phpmailer": "^7.0.0"

or the command composer require phpmailer/phpmailer, run from a project where Composer is available. Behind that line there are only a handful of files, and the manual route shows exactly which. You require src/Exception.php, src/PHPMailer.php, and src/SMTP.php, then use the namespaced classes PHPMailer\PHPMailer\PHPMailer and PHPMailer\PHPMailer\Exception. Two details in that list are the ones people miss. If you never touch the SMTP class explicitly, which is the common case, you do not need a use line for it, but you still have to load the Exception file even if you have no intention of catching exceptions, because it is used internally. And the vendor folder with vendor/autoload.php is generated by Composer rather than shipped inside PHPMailer, so anyone installing manually has to reproduce that part themselves. The manual path is three requires:

<?php
use PHPMailer\PHPMailer\PHPMailer;
use PHPMailer\PHPMailer\Exception;

require 'path/to/PHPMailer/src/Exception.php';
require 'path/to/PHPMailer/src/PHPMailer.php';
require 'path/to/PHPMailer/src/SMTP.php';

The consequence is a maintenance obligation: no Composer means no autoloader, no version pinning, and file copies you must redo on every upgrade.

The zip omits docs and examples, so the manual route starts you blind

The non-Composer path is a zip download from the repository, and the note attached to it is the part worth reading: docs and examples are not included in the zip file. If you take that route, you get working source and none of the surrounding material, including the examples directory that holds smtp.phps, contactform.phps, mail.phps, and the rest. The minimal install guidance makes the trade explicit. You need src/PHPMailer.php at minimum, src/SMTP.php if you send over SMTP, src/POP3.php only for the POP-before SMTP pattern the project calls very unlikely, and src/OAuth.php for XOAUTH2 along with its Composer dependencies. You can skip the language folder, which holds error strings in over 50 languages, if you are not showing errors to users and can live with English-only errors. The consequence: a hand-installed copy with a skipped language folder gives you correct mail and a degraded error surface exactly when something is misconfigured.

Four SMTP mechanisms, two transports, and one that pulls extra packages

Authentication is where the feature list gets specific. The supported mechanisms are LOGIN, PLAIN, CRAM-MD5, and XOAUTH2, and they run over SMTPS and over SMTP with STARTTLS. The first three need nothing beyond your credentials. XOAUTH2 does, and the project says so at installation time: you add a dependency on league/oauth2-client plus the appropriate service adapters package in your composer.json, or you look at the SendOauth2 wrapper by decomplexity, which the note recommends especially for Microsoft services. The repository carries get_oauth_token.php at the root and examples named gmail_xoauth.phps, azure_xoauth2.phps, sendoauth2.phps, and callback.phps, so the token flow is worked through in code rather than described in prose. The consequence is worth planning around: the moment a Gmail or Microsoft account is the sender, PHPMailer stops being a single library and becomes the top of a small dependency set that someone has to keep current.

mail() is named as the thing to avoid, not the fallback path

The case against the built-in function is stated plainly. mail() is the only PHP function that sends mail directly, and it offers no help with authentication, HTML messages, or attachments. It normally hands off to a local mail server, usually a sendmail binary on Linux, BSD, and macOS, and the project notes that Windows usually ships without a local mail server at all. Formatting a message correctly is described as a pile of overlapping and conflicting standards, with the claim that most mail() code found online is wrong or unsafe. The recommendation goes further than a preference: avoid mail() where possible, since using SMTP to localhost is both faster and safer. The consequence for you is that PHPMailer removes the need for a local mail server, but it replaces it with an SMTP conversation. If your environment has no relay to point at, an SMTP host becomes a prerequisite rather than an optimization.

Full UTF-8 addressing depends on the server, and the project says so

Encoding is handled in layers. The library supports UTF-8 content and the 8bit, base64, binary, and quoted-printable transfer encodings, supports iCal events inside multiparts and attachments, and provides multipart/alternative messages for clients that will not render HTML. Full UTF-8 support in addresses and headers is a separate claim, and it is conditional: it requires servers that support SMTPUTF8. The repository carries SMTPUTF8.md at the top level. The consequence is a provider question you should answer before designing an email feature. A mailbox or relay that does not speak SMTPUTF8 will limit what you can put in a header. Test against the actual sending host, not against a local test server.

DKIM and S/MIME run in PHP, which makes key storage your problem

Signing is part of the library rather than something delegated to your mail transfer agent, and it comes in two flavours: DKIM and S/MIME. The examples directory shows the shape of the work with DKIM_gen_keys.phps, DKIM_sign.phps, and smime_signed_mail.phps, so generating a key, signing a message, and sending a signed mail are all things the project demonstrates in code. Two protections sit alongside signing: email addresses are validated automatically, and header injection attacks are blocked. The consequence is that signing moves into your application: your code holds the key material, your deployment has to keep it out of the repository and available to every process that sends mail.

Version 7 moved the sources into src/ and claimed a namespace

The upgrade path is documented but not gentle. Sources live in src/ in current versions and the namespace is PHPMailer\PHPMailer, both changes relative to the 5.2 line, and the repository carries UPGRADING.md plus a changelog.md and a VERSION file. Version 5.2, which covered PHP 5.0 through 7.0, is explicitly no longer supported, not even for security updates, and the last of it sits on the 5.2-stable branch. Current compatibility is stated as PHP 5.5 and later, including PHP 8.5, and the class is namespaced to avoid name clashes. The release record is 7.1.1 on 2026-05-18, 7.1.0 on 2026-05-15, and 7.0.2 on 2026-01-09, with the last push dated 2026-10-21. The consequence is a scheduling decision for anyone still on 5.2: the upgrade guide is the work item, and staying put means no security fixes arrive. The project also names alternatives worth reading first, Symfony Mailer, Laminas/Mail, and ZetaComponents.

Editorial conclusion

PHPMailer is the right default for PHP projects that must send real mail, and the maintainers say so plainly, including naming Symfony Mailer, Laminas/Mail, and ZetaComponents as alternatives to read before rolling your own. It is not the right choice if you want the PHP mail() function with extras, because the project treats mail() as the thing to avoid. Before you commit, check three things. First, whether you can require Composer, because the zip route ships neither docs nor examples and makes you maintain the vendor-equivalent yourself. Second, whether your mail provider supports SMTPUTF8, since full UTF-8 addressing depends on it. Third, whether you need XOAUTH2, because that path pulls league/oauth2-client and service adapters into your manifest. Teams still on the 5.2 line should note that branch receives no security updates, and the current tags are 7.1.1 from 2026-05-18 and 7.1.0 from 2026-05-15.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-2.1
3. PHPMailer/PHPMailer on GitHub
4. README
5. Releases