Reusable PHP code libraries and packages that extend core functionality for common web development tasks. All available with one-click installation on 365i web hosting.
This category is the odd one out. Everything else in our application list is software you install, open in a browser and log into. PHPMailer is a code library: you add it to a PHP project with Composer, call it from your own code, and it has no interface of its own. Nothing to visit, nothing to administer, no dashboard. If you came here looking for a mail server or a newsletter tool, this isn't it.
What PHPMailer does is send email from PHP properly. It has been the default answer to that problem for two decades, with over 111 million installs recorded on Packagist and more than 1,600 packages depending on it. Version 7.1.1 landed in May 2026. The library builds RFC-compliant messages, handles attachments and HTML bodies, protects against header injection, and, most usefully, ships an SMTP client so your application can authenticate to a real mail server instead of shelling out to a local sendmail binary.
The main alternative today is Symfony Mailer. SwiftMailer, which plenty of older codebases still carry, has been unmaintained since the end of November 2021. Symfony Mailer covers the same ground with a modern API and built-in support for third-party sending providers, while PHPMailer stays the lighter drop-in for projects running no framework at all. If your project still imports SwiftMailer, that's a migration that belongs on a list somewhere.
Situations we see often. If one of these sounds like you, this category is worth a look.
The form works, PHP reports success, and nothing arrives at Gmail. Moving from mail() to authenticated SMTP through the domain's own mailbox, with SPF and DKIM published in DNS, usually fixes it in an afternoon.
Frameworks ship their own abstraction, so PHPMailer is not needed and adding it would be duplication. The hosting question is identical either way: which mail server the application authenticates to, and whether the sending domain is authenticated.
The library has had no maintenance since November 2021, so it will keep working right up until a PHP upgrade breaks it. Swapping in PHPMailer or Symfony Mailer is a contained job that is far easier before that day than after it.
Transactional volume from a shared server runs into rate limits and reputation problems long before it runs into a technical ceiling. Point PHPMailer's SMTP client at a transactional provider such as Brevo, Mailgun, Postmark or SendGrid, and keep the shared mail server for low-volume site email.
Now comes the time to officially end the maintenance of Swiftmailer in favor of Symfony Mailer. I've set the end of maintenance date to the end of November 2021, at the same time as the Symfony 5.4 LTS and 6.0 release.
Worth opening your composer.json today. SwiftMailer still installs and still sends mail, which is why so many projects quietly kept it, but it receives no fixes of any kind, security ones included. PHPMailer and Symfony Mailer are both actively maintained, and either migration is a day's work on a typical application rather than a rewrite.
we're requiring those who send significant volumes to strongly authenticate their emails following well-established best practices
That announcement is why deliverability became a hosting question rather than a marketing one. SPF, DKIM and DMARC on the sending domain are now the entry price for reaching a Gmail inbox at all. No library can supply any of it, because authentication is published in DNS and applied by the mail server you send through.
PHP libraries are not full applications, so the hosting question is really about the host application that uses them. We make sure Composer is installed system-wide, the standard PHP extensions are enabled (mbstring, intl, openssl, curl, gd, zip), and SSH is available for installing dependencies. The library itself runs on whatever PHP version your application supports, and our PHP version selector on every plan lets you switch between supported versions without leaving the panel.
There's nothing to install, so every hosting question here is really about the application using the library. Composer is the sane way to add it, and you can either run Composer over SSH on your account or build the vendor directory locally and upload it, which is fine for a small project. PHPMailer itself is undemanding: ctype, filter and hash, all standard. PHP version is selectable per package in the My365i control panel, so an old application can stay on the version it was written for.
The decision that actually matters is transport. PHP's mail() function hands your message to a local binary and tells you almost nothing about what became of it. It's also the path that produced CVE-2016-10033, a remote code execution flaw scored 9.8 that affected PHPMailer before 5.2.18 through the sendmail command line. Use the SMTP client: authenticate as a real mailbox on your own domain, over TLS, and read the server's replies.
Publish SPF and DKIM for the sending domain, then DMARC. We include DKIM signing and full DNS management on every plan. Once you're sending thousands of messages a day, move to a transactional provider, because a shared mail server is the wrong tool for a send queue and pretending otherwise ends in a reputation problem you can't patch.
Common questions we hear from people running PHP libraries applications on 365i hosting.
No. PHPMailer is a library you add to your own PHP project, normally with composer require phpmailer/phpmailer. There is no admin area, no database and no URL to visit. Once installed it sits in your project's vendor directory and you call it from your code. If you want a web application that sends email rather than code that sends it, the marketing and helpdesk categories are the right place to look. This one is for developers building something.
SMTP, every time. Create a mailbox on your domain in the My365i control panel, then configure PHPMailer with isSMTP(), your mail host, port 465 with implicit TLS or 587 with STARTTLS, and that mailbox's credentials. You get authenticated sending, real error messages when a recipient is rejected, and a message that passes SPF and DKIM checks. The mail() function gives you none of that and cheerfully reports success on mail that has already failed.
Almost always because the sending domain is not authenticated, rarely because of the library. Publish an SPF record listing the servers permitted to send for your domain, enable DKIM signing, then add DMARC. Gmail and Yahoo both require authentication from bulk senders now, and unauthenticated mail is increasingly rejected outright rather than filtered. Sending with a From address on a domain you do not control is the other common cause, and no PHP setting will fix that one.
Version 7.1.1 declares PHP 5.5.0 as its floor and is tested up to PHP 8.5, so the library is not what constrains your stack. Your own application almost certainly is. PHP version is selectable per package in the My365i control panel, which lets you pin an older site to the version it was written for while a newer project runs on current PHP. The required extensions are ctype, filter and hash, all enabled by default here.
Composer works on our hosting plans and is the recommended way to manage PHP dependencies. If you would rather not run it on the server, build the vendor directory locally and upload it, since PHPMailer has no compiled components. Our support covers the hosting layer 7 days a week including evenings, weekends and bank holidays, through helpdesk tickets: PHP versions and extensions, SSH, cron, DNS, SSL and mail configuration. Debugging your own application code is development work.
Get PHP Libraries apps up and running in minutes with our fast, reliable web hosting. Every plan includes one-click installation, free SSL, UK, US & Asia data centres, and dedicated expert support.
All prices exclude VAT. No contract, cancel any time.
All 1 php libraries applications available with one-click installation on our fast UK web hosting.
