Fortinet NSE 6 - FortiMail 7.4 Administrator — Free Practice Questions
10 free sample questions from a bank of 34, with the correct answers and explanations. No signup required — start practising right now.
- User 1 will use IMAP or POP3 to download the email message from MTA-2.
- MTA-1 will use POP3 to deliver the email message to User 1 directly.
- MTA-1 will use SMTP to deliver the email message to MTA-2.
- MTA-2 will use IMAP to download the email message from MTA-1.
The short version
A and C — clients download via IMAP/POP3; MTAs relay via SMTP. Last-mile vs hop-to-hop.
Key concepts in this question
- IMAP/POP3: client retrieval from its mailbox server.
- SMTP: MTA-to-MTA transfer across the topology.
Why A and C are correct
User 1's Outlook pulls from MTA-2 with IMAP/POP3 (A) while MTA-1 hands the message to MTA-2 with SMTP (C) — the standard protocol split.
Why the others are wrong
- B. POP3 never carries MTA-to-MTA or MTA-to-user delivery.
- D. IMAP is client retrieval, not inter-MTA transfer.
FortiMail exam tip
Client pulls = IMAP/POP3. MTA hops = SMTP.
- 204300
- 10240
- There is no message size limit for outbound email from a protected domain.
- 51200
The short version
D — approved. Only the session-profile limit applies to outbound mail, so 51200 KB wins.
Key concepts in this question
- Session profile cap: Cap message size (KB) enforced on SMTP sessions via the matched IP policy.
- Outbound vs inbound: Outbound checks only the session profile; inbound checks session profile plus domain setting and uses the smaller.
- Domain Other limit: Maximum message size (KB) 204800 shown in the exhibit applies to inbound comparison, not outbound.
Why D is correct
The exhibits show Cap message size 51200 KB in Session Profile—SMTP Limits and Maximum message size 204800 KB in Domain Settings—Other. Fortinet documents that for outgoing email only the session-profile limit is matched, while for incoming both are checked. Therefore outbound email is capped at 51200 KB.
Why the others are wrong
- A. 204300 (204800 in the image) is the domain-level maximum, not the outbound enforcement value.
- B. 10240 is the Cap header size (KB) in the same session profile, not the message size.
- C. A limit does exist for outbound: the session-profile cap, so there is not no limit.
NSE6_FML_AD-7.4 exam tip
Outbound size = session profile only; inbound = smaller of session and domain.
- The public key is stored in a DNS server as a TXT record
- The public key is distributed during the SMTP session establishment
- The public key is stored in the local FortiMail flash memory
- The public key is stored in a DNS server as a PTR record
The short version
A — DKIM public keys live in DNS TXT records. Signers publish, receivers query.
Key concepts in this question
- DKIM signs with a private key; verifiers fetch the public key from the sender domain's DNS.
- The standard record type for DKIM keys is TXT (selector._domainkey).
Why A is correct
DNS TXT publication is the defined DKIM key-distribution mechanism.
Why the others are wrong
- B. Keys are never negotiated inside SMTP sessions.
- C. Flash memory holds private keys, not the published public key.
- D. PTR records map IPs to names; they carry no DKIM keys.
FortiMail exam tip
DKIM public key = DNS TXT.
- Enable MTA-STS action in the appropriate inbound recipient policy.
- Enable secure authentication in the associated SMTP authentication profile.
- Enable MTA-STS in the associated TLS profile.
- Enable SMTPUTF8 support in the mail server settings.
The short version
C — MTA-STS enforcement also needs enabling in the TLS profile. Check plus enforce.
Key concepts in this question
- MTA-STS service check (Check External Domain) looks up the policy.
- The TLS profile enforces it on matching sessions.
Why C is correct
Lookup without enforcement does nothing; the TLS profile is where MTA-STS gets teeth.
Why the others are wrong
- A. Recipient-policy actions govern delivery routing, not MTA-STS.
- B. SMTP auth profiles authenticate clients; they do not enforce STS.
- D. SMTPUTF8 handles internationalized addresses, unrelated to STS.
FortiMail exam tip
MTA-STS = service check + TLS profile.
- Outbound email is being rejected.
- There are no access delivery rules configured for outbound email.
- There are no outgoing recipient policies configured.
- IP policy ID 2 has the exclusive flag set.
The short version
C and D — a zeroed third policy value means no outbound recipient policy matched, possibly forced by an exclusive IP policy. Fallthrough plus exclusivity.
Key concepts in this question
- Policy IDs chain access:IP:recipient:profile; a 0 means that stage had no match.
- Exclusive IP policies short-circuit later stages.
Why C and D are correct
No outbound recipient policy (C) zeroes the recipient slot, and an exclusive IP policy (D) explains why evaluation stopped there.
Why the others are wrong
- A. Rejected mail would not show normal processing IDs.
- B. Access delivery rules govern inbound relay, not the outbound recipient slot.
FortiMail exam tip
Zero in policy ID = that stage unmatched.
- Transparent mode
- Proxy mode
- NAT/Route mode
- Server mode
- Gateway mode
The short version
A, D, E — FortiMail runs Transparent, Server, or Gateway. Three modes, no substitutes.
Key concepts in this question
- Transparent: invisible relay scrubbing. Server: full mail server. Gateway: perimeter MTA.
- Proxy and NAT/Route are FortiGate concepts, not FortiMail modes.
Why A, D and E are correct
The documented FortiMail operation-mode trio is transparent, server, gateway.
Why the others are wrong
- B. No proxy operation mode exists on FortiMail.
- C. NAT/Route is a FortiGate mode, not FortiMail.
FortiMail exam tip
FortiMail modes = Transparent, Server, Gateway.
- Spam outbreak protection
- IP reputation
- DNSBL
- Behavior analysis
The short version
A and B — zero-day spam meets outbreak protection plus IP reputation. Cloud verdicts before signatures exist.
Key concepts in this question
- Spam outbreak protection holds suspicious mail pending cloud verdicts.
- IP reputation blocks botnet sources with no content signature needed.
Why A and B are correct
Both techniques act without content signatures — the definition of zero-day efficacy.
Why the others are wrong
- C. DNSBLs list known offenders; they lag zero-day sources.
- D. Behavior analysis targets malware actions, not spam floods.
FortiMail exam tip
Zero-day spam = outbreak hold + reputation block.
- Decrypted email is displayed using the HTTPS webmail interface
- FortiMail generates a notification email message with an embedded HTTPS URL
- FortiMail encrypts the email and adds it to a notification email as an HTML attachment
- The recipient accesses the HTTPS link and logs in to the FortiMail secure message portal
The short version
A and C — IBE push shows decrypted mail in HTTPS webmail, delivered as an encrypted HTML attachment. Read in browser, carry by attachment.
Key concepts in this question
- Push delivery: the ciphertext rides along as an HTML attachment.
- Recipients open it in the HTTPS webmail view after authentication.
Why A and C are correct
HTTPS webmail display (A) plus encrypted-HTML-attachment transport (C) define push delivery.
Why the others are wrong
- B. Notification-with-URL describes pull delivery, not push.
- D. Portal-login-via-link is the pull flow.
FortiMail exam tip
IBE push = attachment carries it, webmail shows it.
- The IP address had consecutive administrative password failures to FortiMail.
- The IP address had consecutive SSH login failures to FortiMail.
- The IP address had consecutive IMAP login failures to FortiMail.
- The IP address had consecutive SMTPS login failures to FortiMail.
The short version
D — approved. The Authentication Reputation violation is Mail on a gateway-mode unit, so only SMTP/SMTPS authentication failures fit the exhibit.
Key concepts in this question
- Authentication reputation: FortiMail tracks login-attempt failures for CLI, mail, and web access and blocks repeat offenders.
- Gateway mode MTA: the unit relays and scans mail but does not locally host mailboxes; mailboxes stay on the protected server.
- SMTPS authentication: email clients authenticate to FortiMail with SMTP/SMTPS in gateway mode, and those failures count as mail violations.
Why D is correct
The exhibit's Violation column reads Mail, which maps to the mail-access tracking class in the documented CLI/mail/web trio. In gateway mode FortiMail acts as an MTA without local mailboxes, so IMAP retrieval failures belong to the backend server, not FortiMail authentication reputation. SMTP/SMTPS client authentication to FortiMail is the documented mail-login path in gateway mode, so consecutive SMTPS login failures are the consistent cause of the Mail-violation block.
Why the others are wrong
- A. Administrative password failures are web/CLI access failures, not a Mail violation.
- B. SSH login failures are CLI access failures, not a Mail violation.
- C. IMAP login failures target mailbox retrieval, which in gateway mode lives on the protected server rather than FortiMail, so they do not produce this FortiMail Mail-violation block.
NSE6_FML_AD-7.4 exam tip
Gateway mode plus Violation Mail equals SMTP auth; IMAP belongs to server mode.
- FortiMail will archive email sent from [email protected].
- FortiMail Will allow only the [email protected] account to access the archived email.
- FortiMail will exempt spam email from archiving.
- FortiMail will save archived email in the journal account.
The short version
C and D — approved. Spam is exempted and matching mail lands in the journal account.
Key concepts in this question
- Archiving policy: Recipient-type policy with pattern [email protected] archives mail to that recipient.
- Exempt policy: Spam Email type exempts spam from archiving.
- Journal account: The archive destination account named journal in both exhibits.
Why C and D are correct
Email Archiving 1 shows Account journal, Policy type Recipient, Pattern [email protected], so matches archive to the journal account (D). Email Archiving Exempt Policy shows Account journal, Policy type Spam Email, so spam email is exempted from archiving (C). Together they produce exactly C and D.
Why the others are wrong
- A. Policy type is Recipient, so it archives mail sent to [email protected], not sent from it.
- B. Access is via the journal archive account, not restricted to the [email protected] mailbox.
NSE6_FML_AD-7.4 exam tip
Recipient pattern = TO that address; Spam exempt = skip spam; journal = where it lands.
Want the full bank of 34 questions for Fortinet NSE 6 - FortiMail 7.4 Administrator? See all practice exams.