Skip to main content
jheadley_FTNT
Staff
jheadley_FTNT
Staff
May 22, 2017

Technical Tip: Inbound email to mail server protected by FortiGate is not logged or inspected by Anti-Spam profile

  • May 22, 2017
  • 1 reply
  • 10063 views

Description

 
This article describes that when using an anti-spam profile on FortiGate, users may notice some inbound emails are not being logged under the anti-spam security logs.  In addition, some of the emails that are not logged may also not be inspected by the anti-spam profile or other security profiles, such as AV or DLP.


Scope

 
Networks where an email server is located behind a FortiGate.


Solution:

 

In this example, a mail server is connected behind the FortiGate.

 

Part A: Configure/check the Email-Filter/Anti-Spam Profile. Ensure Logging is Enabled in the CLI

  1.  If 'Email Filter' is not yet visible on the GUI, enable 'Email Filter' in Feature Visibility. Navigate to System -> Feature Visibility -> Enable Email Filter -> Select 'Apply' to save settings
  2. By default, 'clean' emails will not be logged in the anti-spam logs if the anti-spam profile does not perform any action on the email. However, it is possible to enable logging of all emails for the SMTP and other mail protocols in the CLI with the following commands.

 

config emailfilter profile
    edit <Name of Email Filter Profile>
        set spam-log enable
            config imap
                set log-all enable
            end


config pop3
    set log-all enable
end


config smtp
    set log-all enable
end


config msn-hotmail
    set log-all enable
end


config gmail
    set log-all enable
end

 

  1. Change feature-set of email filter to proxy:

 

CLI:


config emailfilter profile
    edit <name of Email Filter Profile>
        set feature-set proxy
    end

 

  1. Apply the Email Filter profile on the firewall policy. Change the inspection mode of policy to proxy-based. Refer to below for a guide on how to change inspection mode: Changing the inspection mode of the firewall


Part B: Some Inbound Email Still Not Being Logged or Inspected
If the CLI commands above have already been implemented, but all emails logged or inspected are still not visible, a common cause is that the email has been encrypted via SMTPS (generally over port 465) or using a mechanism called STARTTLS (generally over port 587 or the normal SMTP port of 25.)

To log and inspect this traffic, FortiGate must perform SSL Inspection on these connections to the mail server. To avoid certificate warnings, the following configuration is recommended.

 

  1. Upload the mail server’s SSL certificate and private key under System -> Certificates section, as shown below.


jheadley_FD40479_1-2.png

 

jheadley_FD40479_2.png

 

  1. Create a new SSL Inspection profile of type 'Protecting SSL Server' and select the newly uploaded mail server certificate as the 'Server Certificate'.

 

 jheadley_FD40479_3.png

 

Another option is to use the built-in certificate of the FortiGate 'Fortinet_SSL'. 

On the ‘SSL Inspection Options’, Enable SSL inspection of ‘Protecting SSL Server’, select 'Fortinet_SSL' on the Server certificate, then enable ‘Inspect all ports’. Select 'OK' to save changes.

 

Email Filter 2.PNG

 

  1. Select the SSL inspection profile on the firewall policy that allows the mail traffic through the FortiGate.

jheadley_FD40479_4.png

 

  1. After changes are made, monitor the email. On the FortiGate, check the logs, navigate to Log & Report -> Security Events -> Anti-Spam and select the necessary log location (Disk, Memory, FortiCloud, FortiAnalyzer, etc)

 

Related article:

Technical Note: AV scanning on SMTP traffic

    1 reply

    V
    VUSALDADASHOV
    New Member
    May 16, 2026

    Thanks. Yes, I think that confirms my original direction.

    This is inbound SMTP: Internet MTAs → FortiGate VIP → internal SMTP gateway

    I am not trying to inspect outbound SMTP from my server to the Internet. The mail server is behind FortiGate, and external MTAs connect to it through VIPs.

    I also found this Fortinet KB, which looks very close to my case:

    Technical Tip: Inbound email to mail server protected by FortiGate is not logged or inspected by Anti-Spam profile


    The article says that if inbound email is encrypted with SMTPS or STARTTLS, even on normal SMTP port 25, FortiGate needs SSL inspection to log/inspect it with Anti-Spam, AV, DLP, etc.

    It also recommends the same approach you mentioned:


    Import the mail server certificate + private key into FortiGate
    Create an SSL inspection profile using Protecting SSL Server
    Use that certificate in the profile
    Apply it to the inbound mail policy


    So I tried that first.

    I imported a valid public certificate for `*.domain.tld` into FortiGate and used it in a Protecting SSL Server inspection profile. The SMTP policy was inbound:

    WAN → VIP → internal SMTP gateway


    The VIP/DNAT worked, the policy matched, and the certificate/DNS side looked OK. But real mail delivery started failing. For example, Gmail connected to FortiGate and the policy matched, but the message never reached the backend mail gateway. As soon as I rolled back to certificate-inspection, delivery worked again.

    Then I tried a second approach based on another Fortinet KB about AV scanning on SMTP traffic. I created a CA-based SMTP STARTTLS deep inspection profile using Fortinet_CA_SSL, plus a custom protocol-options profile for SMTP on port 25.

    Interesting result:

    SMTP STARTTLS deep inspection profile only = works
    SMTP STARTTLS deep inspection + any UTM profile = SMTP banner timeout

    For example:

    SSL inspection profile + protocol-options only:
    MXToolbox sees the banner, STARTTLS is advertised, transaction is OK.

    Add only AV profile: SMTP banner timeout.
    Add only Email Filter: SMTP banner timeout.
    Add only Application Control: SMTP banner timeout.

    In packet capture, the backend SMTP gateway does send the banner: 220 mail.domain.tld Mail Server

    But when UTM is enabled, FortiGate does not seem to release that banner back to the external client. Debug flow shows policy match and DNAT working, then traffic is sent to IPS/application layer.

    So conceptually I agree: for inbound SMTP, Protecting SSL Server with the real mail server certificate should be the correct approach.

    My problem is that in practice both tested methods break once real inspection/UTM is involved:

    Protecting SSL Server + real cert = mail delivery breaks
    CA-based STARTTLS DI + UTM profile = SMTP banner timeout
    certificate-inspection + existing UTM profiles = works


    At this point I am wondering if this is a configuration gap...
     

    Terms & ConditionsAccessibility statement