Hey again :)
I found some answers to your questions:
Thank you for your detailed answers and concerns. Let’s address your questions and clarify how FortiMail’s Access Control works, its limitations, and what you can do to minimize the risk of unauthorized relaying—especially in the context of Microsoft 365 (Exchange Online) integration.
- How Does FortiMail’s Sender Pattern Matching Work?
Access Control Policy Matching:
- The sender pattern in FortiMail’s Access Control Policy (e.g.,
*@yourdomain.com) matches the SMTP envelope sender address (the "MAIL FROM" in the SMTP transaction), not the "From:" header in the email body. - This means FortiMail checks the address provided during the SMTP conversation, which is more reliable than the message header but can still be spoofed if the sending system is compromised or not otherwise authenticated.
- Is This “Safe Enough”?
Potential Risks:
- Envelope sender spoofing: Anyone with access to Microsoft 365’s infrastructure (or a compromised tenant) could potentially send emails with your domain in the envelope sender, and FortiMail would relay them if the source IP matches the allowed Microsoft IPs and the sender pattern matches.
- Shared Microsoft IPs: Since Microsoft 365 IPs are shared among all tenants, restricting by source IP alone is not sufficient to prevent other tenants from attempting to relay as your domain.
Why This Is a Concern:
- If a malicious actor in another tenant (or a compromised account) sends mail with your domain as the envelope sender, and it originates from Microsoft 365 IPs, FortiMail will relay it unless additional controls are in place.
- This is why relying solely on sender pattern and source IP is not fully secure.
- How to Make It More Secure?
- Restrict by Source and Sender Pattern
- Continue to use both the Microsoft 365 ISDB object (or explicit IPs) and your domain in the sender pattern.
- This is a baseline, but not sufficient for high-security needs.
- Use SMTP Authentication (If Possible)
Best Practice: Require SMTP authentication for relaying. This is the most secure method, but may not be feasible for Microsoft 365 to FortiMail relay scenarios.
- Restrict by Additional Headers or Custom Attributes
If Microsoft 365 can stamp a unique header or attribute (e.g., via a transport rule), you could configure FortiMail to check for this header as an additional relay condition. However, this is not natively supported in all scenarios.
- Use SPF/DKIM/DMARC Validation
- FortiMail can perform SPF, DKIM, and DMARC checks on incoming mail. However, these are primarily for anti-spoofing and anti-phishing, not for relay authorization.
- They help protect your domain’s reputation but do not prevent unauthorized relaying by themselves.
- Limit Recipients
- In your Access Control Policy, set the recipient to "External" only, so only emails to external domains are relayed.
- For internal recipients, ensure that only your on-prem Exchange handles delivery.
- Monitor and Alert
Enable logging and alerting for relayed messages, especially those matching your relay policy, to detect any unusual activity quickly.
- Summary Table: Security Measures
| Control | Effectiveness | Notes | |---------------------------------|--------------|------------------------------------------------------------| | Source IP (Microsoft 365) | Medium | Shared among all tenants | | Sender Pattern (*@yourdomain) | Medium | Can be spoofed in envelope sender | | SMTP Authentication | High | Not always possible with M365 relay | | Custom Header Matching | High | Only if M365 can add unique headers | | SPF/DKIM/DMARC | Medium | Helps with reputation, not relay authorization | | Recipient Restriction | Medium | Prevents internal relay, but not spoofing | | Logging/Alerting | High | Detects abuse quickly |
- Recommendations for Your Scenario
- Continue using sender pattern and source IP restrictions as you have, but understand their limitations.
- Restrict relaying to external recipients only in the Access Control Policy.
- Monitor logs for any suspicious relay activity.
- If possible, work with Microsoft 365 to add a unique header to all emails sent from your tenant, and configure FortiMail to check for this header (if supported).
- Regularly review and update your SPF/DKIM/DMARC records to ensure only authorized sources are allowed.
- Educate users and administrators about the risks of compromised accounts and monitor for signs of abuse.
- Follow-up and Clarification Questions
To further assist you, could you clarify:
- Are you able to configure Microsoft 365 to add custom headers to outbound mail from your tenant?
- Are there any scenarios where you must relay mail for internal recipients via FortiMail, or is all internal mail handled on-prem?
- Would you consider using a dedicated connector or authentication mechanism between Microsoft 365 and FortiMail if available?
If you need step-by-step configuration guidance for any of the above recommendations, please specify which area you’d like more detail on.
References:
If you have further questions or need more technical detail, please let me know!
