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 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.
It was lot easier to ask ChatGPT to search for others asking for similar thing and then to rewrite my original GitHub issue. Regardless of how it was constructed this feature request is valid and the use case for various users on this forum are also valid.
Microsoft has two specific services for sending app generated mass mails, which they recommend over their Client SMTP submission:
If you only have internal recipients, you can use HVE, which is easier to setup:
If not, you can use Azure Communication Services:
The normal email infrastructure of M365 is not meant to be used for app generated mass mails. The rate limits can easily be reached, even by a medium Zammad instance. Both methods above support/require Basic Auth.
I hear you on rate limits. Still, it would be valuable if Zammad let admins optionally route Notification by Email through an already OAuth-connected Google/M365 mailbox, with guardrails and a clear warning. That keeps the safe default while giving smaller instances a practical, low-friction path without introducing extra SMTP credentials or infrastructure.
So can we eventually see one if not all fo these options?
• Default OFF + explicit warning, something like: Not recommended for high volume; may hit provider limits—use a dedicated relay for bulk.
• Admin-configurable throttling/caps and backoff.
• Health checks that surface errors and can auto-disable on limit hits.
• Per-channel choice in Admin → E-mail → Settings → Notification:
– “Use connected mailbox (OAuth)”
– “Use custom SMTP relay (recommended)”
These approaches would preserves best practice for mass mail, but also let admins make the right trade-off for their environment. We need to consider the flexibility of smaller orgs, such as my own, that will never come close to provider limits.
Because people raise bug reports and support requests if they occur, no matter how clear you make those errors.
Maybe not you nor everyoneC but enough people do. Many selfhosted admins don‘t ecen use the monitoring endpoint so it will cause unexpected behavior and shitty debugging sessions.
I‘ve worked 7 years at Zamma, let me tell you: Most of the things that are decided are done so hoping that the user base benefits from
It, not to burden them.
Given that SMTP with Basic Authentication will be deprecated in April 2026, and based on the responses from the developers, it seems that in order to continue sending notification emails via Zammad, we would need to follow one of the supported alternatives — such as SMTP support in Azure Communication Services.
In our case, we need to send from example.it to company.as, so Azure SMTP support seems like the appropriate solution.
The feature request is not closed nor moved to “will not implement”, so it’s possible that we will consider it in the future. But we don’t have any immediate plans to tackle it.
That’s why I wanted to provide you with a solution, that can help you Today. As with all feature requests, we have limited resources and need to prioritise. As a community you can influence that by giving the first article of a feature request a like.
You can also setup triggers to send via your OAuth connected email address. It’s a lot more work but when your situation requires that you send through one email address it is the only solution.
You’re right — my mistake was referring to it as exclusive support for SMTP or MTA. It would be more accurate to describe it as: given the current state of things.