FCP FortiMail common mistakes
FCP FortiMail · Understand the traps and how to avoid them.
Treating FortiMail as a single product and studying one deployment mode (gateway) as if it covered all of them, then failing questions about transparent mode or server mode behaviour, interface roles, and where mail stores live.
Most study material and lab guides default to gateway mode because it is the easiest to stand up, so candidates never internalize that transparent mode has no IP change to the MX record and server mode hosts mailboxes locally. Exam items mix the modes and expect you to know which features (e.g., per-user quarantine, SMTP proxy behaviour, routing lookups) are available or behave differently in each.
What to do instead
Build a one-page comparison table of gateway, transparent, and server mode covering: how mail reaches the device, whether the MX record changes, whether local mailboxes exist, which policies apply, and what happens on failure. Lab each mode at least once, including transparent mode with a Layer 2/VLAN setup, and note which GUI menus appear or disappear.
Assuming the FortiMail unit will accept and relay mail for any domain by default, or forgetting to define protected domains and relay hosts, then misreading questions about open-relay protection and recipient validation.
Candidates conflate FortiMail with a plain MTA and skip the concept of protected domains, which determine whose mail is scanned and whose mailboxes exist. Without that model, questions about relaying, recipient verification, and access control lists become guesswork.
What to do instead
Memorize the relationship: protected domains define the domains FortiMail accepts and scans for; relay hosts and access control rules define which clients may send through it. Practice adding a protected domain, assigning it to a mail server or mailbox, and then testing inbound, outbound, and relay-denied paths while watching the logs.
Confusing the order and interaction of the antispam techniques (IP reputation, DNSBL/RBL, greylisting, sender reputation, Bayesian/lexical analysis, SPF/DKIM/DMARC) and answering as if any single check alone decides the verdict.
Each mechanism produces a score or a session-level action, and the profile thresholds plus the session/recipient settings determine the final disposition. Candidates who memorize feature names without the scoring and threshold model cannot answer questions about why a message was tagged, quarantined, or rejected.
What to do instead
Draw the inbound pipeline in order and label each stage as session-level (reject before DATA) or message-level (score contribution). Then set a personal quarantine threshold and a tag threshold in a lab, send test mail that trips only one check at a time, and read the message header and log entry to see which rule fired and how the score accumulated.
Answering antivirus questions as though FortiMail only scans attachments, ignoring that scanning behaviour depends on the antivirus profile, file-type and size limits, and whether scanning happens before or after content filtering and quarantine.
Candidates carry over assumptions from endpoint antivirus and miss FortiMail-specific controls such as which protocols are scanned, what happens to oversized or password-protected archives, and how infected messages are handled (discard, quarantine, clean, replace).
What to do instead
Create a matrix of antivirus profile options: scan by protocol, file-size limits, archive handling, and the action per verdict. Test with the EICAR test file in a plain attachment, inside a ZIP, and inside a password-protected ZIP, and record exactly what the logs and quarantine show for each case.
Treating content profiles and content filtering as a single feature, and failing to distinguish dictionary/banned-word matching, file-type blocking, and the action taken (quarantine, discard, tag, replace) from the policy that applies them.
Content profiles must be attached to a policy or recipient to take effect, and the profile action is separate from the policy action. Candidates who learn the profile screen in isolation answer incorrectly about which action actually occurs and whether the message is still delivered.
What to do instead
Practice building a content profile with a banned-word dictionary and a blocked file type, attach it to an inbound policy, and observe the difference between profile action and policy action. Verify by checking the message tracking log and the quarantine folder to see which action executed.
Mixing up the authentication features - SMTP client authentication, IBE (identity-based encryption), S/MIME, TLS policy, and DKIM signing versus DKIM verification - and applying the wrong one to a scenario.
These features live on different screens and solve different problems: authenticating senders, encrypting message bodies, securing the SMTP channel, and proving domain identity. Candidates see 'encryption' or 'authentication' in a question stem and pick whichever term they studied most recently.
What to do instead
Write a decision guide: who is the sender, is the goal channel security or end-to-end confidentiality, and does the recipient need a portal or a certificate? Then lab each one: force TLS with a policy, sign outbound with DKIM and verify the DNS record, and send an IBE message to an external address to see the notification and portal flow.
Skipping DLP because it looks like a policy-only topic, then missing that DLP profiles must be attached to policies and that the action (block, quarantine, exempt) interacts with encryption and content profiles.
DLP is often taught as a list of pattern types (credit card, SSN, custom regex) without the attachment and precedence model. Exam items test whether you know which profile wins when content filtering and DLP both match, and what happens to the message afterwards.
What to do instead
Build a DLP profile with a built-in pattern and a custom regex, attach it to an outbound policy, and test a message that also matches a content profile. Record which action fires first and where the message ends up, then review the DLP log to confirm the pattern that matched.
Reading monitoring and logging questions as pure GUI navigation and not knowing which log type records which event (antispam, antivirus, content, DLP, system, mail events) or how message tracking correlates a single message across them.
Candidates memorize menu paths but not the data model, so they cannot answer questions that ask which log to consult for a specific symptom or how to trace a message by queue ID and sender/recipient.
What to do instead
Send a test message that triggers one antispam rule, one antivirus hit, and one DLP match, then use message tracking to follow it end to end and note the log category and fields shown at each hop. Practice filtering by queue ID and by sender, and learn where quarantine and history reports pull their data from.
Assuming HA configuration is symmetric and automatic, and answering as if both nodes need identical configuration, licenses, and firmware without understanding which settings are synchronized and which are local to each unit.
FortiMail HA has mode-specific behaviour (active-passive versus active-active), and some settings such as interface IPs and HA-specific parameters are per-unit while others replicate. Candidates who never built an HA pair guess at what fails over and what must be configured manually.
What to do instead
If possible, build a two-node HA pair in a lab or simulator and document: which settings replicate, what the slave shows in the GUI, how mail queues behave on failover, and what happens to the management IP. If hardware is unavailable, study the HA section of the admin guide and write the same list from the documentation, marking each item as synced or local.
Treating backup and troubleshooting as afterthoughts, so questions about configuration backup contents, restore scope, and the first diagnostic step for a mail-flow problem are answered from general networking intuition.
Candidates spend their time on antispam and antivirus features and never learn what a configuration backup includes (and excludes, such as quarantined mail), or the standard troubleshooting order: check the policy match, check the logs, check the queue, check DNS and connectivity.
What to do instead
Perform a configuration backup, inspect what it contains, and restore it to confirm the scope. Then deliberately break mail flow (wrong relay host, missing protected domain, bad DNS) one at a time and practice the diagnostic sequence using the logs and queue view until you can name the first check for each symptom.