Weave Code
Google Mailer Laravel Package
symfony/google-mailer
Official Symfony Mailer bridge for sending email through Gmail and Google Workspace via the Gmail API. Configure OAuth2 credentials and use it as a Symfony Mailer transport for Google-backed delivery.
Symfony Google Mailer is a bridge that connects Symfony Mailer to the Gmail API, letting applications send email through Gmail or Google Workspace without relying on SMTP. It provides a dedicated transport backed by Google’s official API client and OAuth 2.0 authentication.
- Sends messages through the Gmail API
- Integrates as a standard Symfony Mailer transport
- Uses OAuth 2.0 credentials
- Supports Gmail and Google Workspace accounts
- Configurable via DSN and Symfony configuration
Frequently asked questions about Google Mailer
- What is symfony/google-mailer and can I use it in Laravel?
- symfony/google-mailer is a small Symfony Mailer transport bridge that sends messages through the Gmail REST API using a Google Client and OAuth2 credentials. It is not a Laravel package and it is not a full mailer: it does not provide OAuth consent, token storage, queues, templating, retries, or bounce handling. Laravel 9 and later send mail through symfony/mailer, so you can use the bridge by registering a custom Gmail transport, but you must build the credential and operational pieces yourself.
- Which Laravel and PHP versions are compatible with symfony/google-mailer?
- Use Laravel 9 or later, since those versions send mail through Symfony Mailer, which the bridge plugs into. The Symfony 6.4 line requires PHP 8.1 and the Symfony 7.x line requires PHP 8.2, and bridge majors track Symfony Mailer majors. Check composer show symfony/mailer in your app before requiring the package, because Laravel 10 pins Symfony 6.x while Laravel 11 and 12 use Symfony 7.x.
- How do I install and configure symfony/google-mailer for Gmail in Laravel?
- Install it with Composer alongside symfony/mailer, then create a Google Cloud project, enable the Gmail API, and obtain OAuth2 client credentials with the gmail.send scope. In Laravel, add a mailer entry in config/mail.php, register a custom transport through Mail::extend() in a service provider, and construct GmailTransport with a configured Google Client. Keep the client ID, secret, and refresh token out of source control and load them from environment variables or an encrypted store.
- How do I set up Google OAuth2 credentials and scopes for Gmail sending?
- Create an OAuth client in Google Cloud, enable the Gmail API, and request the restricted gmail.send scope, which is enough to send but not read mail. Complete a consent flow to obtain a refresh token, store it encrypted, and refresh access tokens before sending rather than per request. If you publish the app beyond test mode, expect Google verification for restricted scopes and possibly an annual CASA security assessment.
- How do I register a Gmail mailer with Mail::extend() in Laravel?
- Add a service provider that calls Mail::extend('gmail', function (array $config) { ... }) and returns a new Symfony Mailer TransportInterface implementation. Inside the closure, build a Google Client with your stored credentials and return a GmailTransport instance wrapping it. Then set MAIL_MAILER=gmail or call Mail::mailer('gmail') explicitly, and keep the config array limited to IDs, tokens, and sender settings.
- Can I use the Gmail API for bulk or high-volume transactional email?
- No, Gmail is not a bulk sending platform and the API enforces per-user rate limits plus daily send ceilings for free and Workspace accounts. Model your peak and burst volume against Google's published limits before committing, and avoid using one shared mailbox for high-volume application mail. For general transactional email, an ESP such as SES, Postmark, Mailgun, or Resend is cheaper to operate and gives better delivery controls.
- Why do my Gmail refresh tokens keep expiring and how should I store them?
- Testing-mode consent screens issue short-lived refresh tokens, and Google can revoke them after password changes, admin policy changes, or long inactivity. Store tokens encrypted, refresh access tokens before sending, detect invalid_grant responses, and provide a reconnect-account flow for users. For multi-tenant apps, track one credential record per mailbox and never share a single token across unrelated tenants.
- Is symfony/google-mailer better than SMTP or an email service provider?
- Only choose the Gmail bridge when mail must originate from a Google identity, such as a user's own Gmail or Workspace mailbox with Sent-folder visibility and Workspace deliverability. If the requirement is simply reliable transactional delivery, plain SMTP or an ESP is easier, cheaper, and gives webhooks and analytics out of the box. The bridge is stateless and small, so it composes well with Laravel queues and per-tenant mailer routing when Gmail identity is a real product requirement.
- Does symfony/google-mailer handle bounces, complaints, or open tracking?
- No, the bridge only sends messages through the Gmail API and does not provide webhooks or feedback loops for bounces, complaints, or opens. Gmail responses can tell you about immediate API errors, but asynchronous delivery failures require supplementary tooling or acceptance of reduced visibility. Plan for observability separately, especially if you need suppression lists or deliverability monitoring.
- How do I test Gmail sending and avoid duplicate emails on retry in Laravel?
- Use Mail::fake() in tests and swap the transport for a fake in integration tests so you never hit the real Gmail API. In production, note that the Gmail API has no idempotency key, so a timeout-then-retry can double-send; add per-message dedupe keys and conservative retry and backoff policies. Log message IDs and Gmail responses so you can reconcile failures without resending blindly.
Weaver
How can I help you explore Laravel packages today?