- How do I install overtrue/laravel-mail-aliyun?
- Run composer require overtrue/laravel-mail-aliyun in a Laravel application running PHP 8.3 or newer and Laravel 13. The package registers an Aliyun DirectMail transport driver that you select from config/mail.php, so no manual service provider wiring is required. After adding your access keys and region, you keep sending mail through Laravel's normal Mail facade.
- What PHP and Laravel versions does laravel-mail-aliyun require?
- Version 4.0.0 requires PHP 8.3 or higher and Laravel 13, so only applications already on that stack or actively planning the upgrade can adopt it. Earlier releases were built on the old SwiftMailer mail stack and are effectively unusable on current Laravel versions. Check your composer constraints and upgrade timeline before planning adoption.
- How do I configure Aliyun DirectMail in config/mail.php?
- Add a mailer entry in config/mail.php that uses the Aliyun DirectMail transport, along with your AccessKey ID, AccessKey secret, and region. Then point Laravel at that mailer, typically via the MAIL_MAILER environment variable. Keep credentials in environment variables rather than committing them to configuration files.
- Does it work with Laravel mailables, notifications, and queued jobs?
- Yes. Because it plugs into Laravel's Mailer and Transport layer, anything sent through the Mail facade works, including mailables, notifications, and queued jobs. Laravel handles rendering and queueing as usual, and the transport simply delivers the finished message to the DirectMail API. No custom sending code is needed at your call sites.
- Does this transport support attachments, BCC, or raw messages?
- No. Version 4.0.0 is deliberately scoped to simple transactional mail, and BCC, envelope-only hidden recipients, attachments, and raw RFC822 messages are explicitly out of scope. The transport raises exceptions for those cases instead of silently dropping data. Applications that need them should route those messages through an SMTP mailer.
- How do I set DirectMail tags with the new withSymfonyMessage API?
- Tags are set through the withSymfonyMessage callback API introduced in 4.0.0, in line with Symfony Mailer's transport contract. Code that sets tags through the old pre-4.0 path will stop tagging messages, which can quietly break DirectMail analytics and routing. Update your tag callbacks as part of the upgrade rather than after it.
- Can I use it alongside SMTP in the same Laravel application?
- Yes. Laravel supports multiple mailers, so you can keep the DirectMail transport for eligible transactional messages and an SMTP mailer for attachments, BCC, or raw messages. This is configuration-level work, but it adds a routing decision at each send site. Wrapping that choice in a small helper keeps send sites clean.
- Is the package tested against a real Aliyun DirectMail account?
- The test suite is unit-level only, with outbound requests mocked, so no live email is sent to DirectMail during testing. That proves intent for signature handling, Unicode tags, and alternative text and HTML parts, but not real-world interoperability. Canary with a real DirectMail account before rolling it out broadly.
- Is upgrading from 3.x to 4.0.0 a drop-in change?
- No. The release raises the PHP floor to 8.3, requires Laravel 13, moves onto Symfony Mailer's transport contract, and changes protected extension points. Any in-house subclass of the transport, or custom tag callback, must be rewritten. Treat it as a coordinated upgrade rather than a version bump.
- Is overtrue/laravel-mail-aliyun still maintained, and what are the alternatives?
- Version 4.0.0 restores the package on Laravel's modern Symfony Mailer stack after the SwiftMailer era, making it the maintained route for DirectMail on Laravel 13. Its scope is intentionally narrow, so if you need attachments, BCC, or a single mail path, SMTP or a provider such as SES may fit better. Weigh that constraint against the benefit of skipping an SMTP hop.