Allow OAuth-connected Google/Microsoft mailboxes to be used for Notification by Email (opt-in with guardrails)
I believe this is a bug in the product’s design. I opened a GitHub issue Cannot send Email Notifications when primary mailbox is Google (OAuth) #5731 which was closed as “not planned.” Closing it doesn’t address the underlying inconsistency: Zammad can send ticket traffic via an OAuth-connected mailbox, yet refuses to use the same authenticated transport for Notification by Email , forcing a split-brain mail setup and unnecessary credential sprawl. I’m filing this feature request to propose a safe, opt-in path that aligns with least-privilege while preserving current defaults.
1) What is your original issue/pain point you want to solve?
Zammad requires a separate, legacy SMTP transport for notifications even when a Google/M365 mailbox is already connected via OAuth for ticket traffic. This creates duplicate credentials, increases attack surface, and leads to reliability gaps (tickets send, but notifications fail in OAuth-only tenants).
2) Which are one or two concrete situations where this problem hurts the most?
- Missed critical notifications: Mentions, escalations, reminders, and password resets don’t send when there’s no basic-auth SMTP relay, a scenario multiple admins have run into during or after migrations to Microsoft 365/Google. Zammad
- Operational overhead: Teams are forced to add/maintain separate relays or fall back to local MTAs, adding IPs to monitor and increasing admin burden—reported by users who expected OAuth to cover notifications as well. Zammad
3) Why is it not solvable with the Zammad standard?
By design, the Notification channel excludes Google/Microsoft OAuth channels; only classic SMTP is supported. Community threads confirm that notifications cannot be routed through the M365/Google channels even when they’re configured for tickets. Zammad
4) What is your expectation/what do you want to achieve?
Add an opt-in option to reuse an existing OAuth-connected Google/Microsoft mailbox (XOAUTH2/Gmail API/Microsoft Graph) for Notification by Email. Ship it with clear guardrails so the safe default remains unchanged:
- Default OFF, with an in-product warning that it’s not recommended for bulk/mass mail.
- Throttling/backoff and configurable caps.
- Health checks that surface errors in the UI and can auto-disable if provider limits are hit.
- Per-channel selection in Admin → E-mail → Settings → Notification:
- “Use connected mailbox … (OAuth)” — list existing OAuth ticket channels
- “Use custom SMTP relay (recommended for bulk)” — current behavior
Anything else which you think is useful to understand your use case:
- There’s clear community demand: the dedicated feature request “Email Notification channel must implement OAuth authentication” has double-digit likes and continued endorsements in 2024, citing Microsoft’s basic-auth phase-out timeline. Zammad
- Additional threads ask for the same capability or describe the pain: “What SMTP auth is using by Zammad? Basic or OAUTH?” (users explicitly requesting OAuth for notifications), and “Notification emails with 365” (admins frustrated by needing a separate relay). Zammad
- Guidance in other discussions reiterates that notifications are locked to the SMTP channel today—further evidence this is a common stumbling block post-migration. Zammad
Thanks for considering an opt-in approach that preserves current best practices while giving smaller and moderate-volume instances a secure, low-friction alternative.