What is your product version? 14.1.0 What is your product type (Angular or MVC)? Angular What is product framework type (.net framework or .net core)? .NET 9.0
Hello, due to Microsoft's increased security settings (same like gmail for example), we are now experiencing problems sending emails from Aspnet Zero. Exchange Online requires 2FA, which means we can no longer use the previous method of sending emails via SMTP and an Office 365 user.
Since ASPNET Zero currently uses MailKit to send emails, the question now is how implementation via OAuth, Microsoft Graph API, or Azure Communication Services could be carried out without completely changing the ASPNET Zero code.
We are also open to alternatives that can be easily integrated into the existing structure, as this only concerns service emails from ASPNET Zero.
Many thanks in advance, Frank
3 Answer(s)
-
0
Hi @geoteam
Thank you for the detailed explanation. You are correct that basic SMTP authentication with Exchange Online is no longer viable due to mandatory MFA and security hardening. In ASP.NET Zero, however, this does not require a full rewrite of the email infrastructure.
ASP.NET Zero abstracts email delivery via
IEmailSender. MailKit is only the default implementation, and it can be replaced cleanly.This allows alternative providers or auth mechanisms to be integrated without touching core framework code.
Microsoft Graph API (OAuth 2.0)
This is the most future-proof approach if you stay within the Microsoft ecosystem.
How it works
- Register an Azure AD App
- Grant
Mail.Send(Application permission) - Use client credentials flow (no user, no MFA)
- Send mail via
POST /users/{sender}/sendMail
ASP.NET Zero integration
- Create a custom
GraphEmailSender : IEmailSender - Inject Graph client using MSAL
- Replace default sender via DI
Configuration.ReplaceService<IEmailSender, GraphEmailSender>(DependencyLifeStyle.Transient);Pros
- Fully compliant with Exchange Online security
- No SMTP, no MFA issues
- Works well for service/system emails
Cons
- Custom implementation required (but isolated and clean)
Azure Communication Services
A solid Microsoft native alternative if Graph is not desired.
- Uses API key auth
- No dependency on Exchange users
- Email domain must be verified in Azure
Same pattern: custom
IEmailSenderimplementation.Pros
- Very simple auth model
- Designed for transactional emails
Cons
- Separate email infrastructure from Exchange
- Slightly higher operational overhead
External SMTP Providers
Providers such as:
- SendGrid
- Amazon SES
- Mailgun
These still support SMTP or API keys and work out of the box with MailKit.
Pros
- Minimal or zero code changes
- Immediate fix
Cons
- Not Microsoft native
- Additional external dependency
All options integrate cleanly into ASP.NET Zero without breaking upgrades or framework compatibility.
Markdown is supportedCopy & paste or drag & drop images (max 30 MB per image) -
0
Hello oguzhanagir,
thank you very much for your detailed response. I think that the Graph API is a good choice in this case. However, this also means that the configuration page for SMTP in the host login becomes unnecessary and can be hidden.
Kind regards, Frank
Markdown is supportedCopy & paste or drag & drop images (max 30 MB per image) -
0
Hi @geoteam
You’re absolutely right. When switching to Microsoft Graph API, the SMTP configuration is no longer used.
In ASP.NET Zero, the SMTP settings page is mainly a UI over the default MailKit based
IEmailSender. If you replaceIEmailSenderwith a Graph based implementation, those settings are simply ignored at runtime.From an implementation perspective, you have two clean options:
- Hide or disable the SMTP settings UI (recommended), since it no longer reflects the active email mechanism.
- Leave it visible but unused, for backward compatibility or future fallback, without affecting the Graph based sender.
Most customers who move to Graph choose to hide the SMTP section to avoid confusion for administrators.
Markdown is supportedCopy & paste or drag & drop images (max 30 MB per image)
