Skip to main content
aross
Staff
Staff
December 4, 2017

Technical Tip: FortiMail: Integration with Office365

  • December 4, 2017
  • 0 replies
  • 11415 views

Description

 

This article describes how to authenticate Microsoft Office 365 users where Active Directory or LDAP services are not available.

 

Scope

 

FortiMail.


Solution

 

Authentication Server.

To authenticate Office 365 users with FortiMail, the following settings should be used:

 

Authentication type: POP3.
Profile name: Office365_Auth.
Server name/IP: outlook.office365.com.
Server port: 995.
Authentication mechanism: AUTO.
SSL/TLS: CHECKED.
STARTTLS: UNCHECKED.
Secure authentication: UNCHECKED.
Server requires domain: CHECKED.

 

Server Settings.PNG
 

Mail hop count exceeded.

Sending emails to other users on the Office 365 domain may cause the email to bounce with the error hop count exceeded.

This is caused by an Office 365 mail rule used to forward mail to FortiMail (or any other MTA).

To resolve this, log in to the Exchange admin center for Office 365:

  • Access the mail rules under Mail Flow. 
  • Edit the outbound mail rule you created to send mail to the FortiMail.
  • Under 'Except if...add in a new exception that will match if the header contains your FortiMail domain name (found on the FortiMail under System -> Mail Settings).

 

Screenshot 2026-03-25 120353.jpg

 

Screenshot 2026-03-25 120528.jpg

 

Causes: 

  • Office 365 servers send the mail to FortiMail.
  • FortiMail processes the email.
  • The email is then forwarded to another Office 365 server using the recipient's Office 365 MX record.

 

Note: If the sender and recipient are using the same domain, the mail forwarding rule configured to send emails to the same domain MTA causes the loop.  

 

In this instance, the rule causes the Office365 servers to look for messages already processed by FortiMail, preventing them from being continuously forwarded to FortiMail; instead, the messages are sent to the actual recipient. 

 

Recipient verification.

Configuring FortiMail for Office 365 recipient verification:

Recipient verification works by opening a session with the target SMTP server, for example, Office 365, and executing the following commands:

  • EHLO.
  • MAIL FROM.
  • RCPT TO.

 

The target Email address in the RCPT TO is analysed in the response to see if the address exists.
The default value of MAIL FROM in FortiMail is left as a null value, which can cause the Office365 service to fail.
The solution is to define a source email address (for example, noreply@domain.com).

 

Configure FortiMail MAIL FROM settings:

 

config mailsetting smtp-rcpt-verification
    set mail-from-addr noreply@domain.com

end

 

 POP3Auth.PNG

 

The MAIL FROM: default null value is replaced with noreply@domain.com.

 

Note: This fix is for situations where it is possible to telnet from the FortiMail to the Office365 server:

  • Use a non-existent address in the RCPT TO field.
  • The rejection message is sent, but recipient verification still fails.
  • If the Office 365 server responds with an OK, then the issue lies in the Microsoft configuration.