FortiMail anti-phishing design spans antispam profiles, impersonation analysis, cousin-domain detection, sender alignment, heuristic/weighted analysis, URL/content inspection, authentication results, and action profiles. Current FortiMail documentation treats impersonation, cousin domains, and sender alignment as anti-spam/anti-phishing techniques that should be combined rather than used independently. A strong policy must also coexist with SPF, DKIM, and DMARC so identity-based controls and content-based detection reinforce each other.
Within Fortinet Security Operations, anti-phishing policy should focus on who the message appears to be from, where it actually came from, what links/content it carries, and which business identities attackers are most likely to impersonate.
Email Authentication with DMARC provides the domain-authentication layer. FortiMail adds display-name, lookalike-domain, sender-alignment, and message-analysis context that DMARC alone cannot provide.
Antispam profiles are the policy container
Current FortiMail AntiSpam configuration groups impersonation, cousin-domain, weighted/heuristic, and action behavior into profiles that can be applied through recipient/policy routing.
Build profiles around trust zones and mail flow such as inbound internet mail, outbound mail, partners, marketing infrastructure, and internal relay.
Do not apply one aggressive inbound anti-phishing profile blindly to trusted internal relays whose headers or authentication behavior differ.
Impersonation analysis protects high-value identities
FortiMail can map known internal display names to legitimate internal email addresses and detect messages where an external sender uses the protected person’s display name.
Start with executives, finance, HR, IT admins, procurement, legal, and other roles commonly used in business-email compromise.
Keep the mapping updated after name changes, reorganizations, acquisitions, and executive turnover.
Dynamic impersonation learning reduces manual maintenance
Current FortiMail supports a mail statistics service that can learn display-name-to-internal-address mappings dynamically.
By default, manual analysis is used; administrators can configure Dynamic and Manual modes and inspect learned mappings.
Monitor learned data during rollout because shared mailboxes, mailing lists, and delegated senders can create surprising display-name patterns that need review.
Cousin-domain policies catch lookalike senders
Attackers register domains visually similar to a legitimate company or supplier.
FortiMail cousin-domain profiles can scan header/body contexts and identify deliberately misspelled lookalike domains according to current configuration.
Protect not only your own domain but critical banks, payroll providers, cloud vendors, customers, and suppliers used in financial or credential workflows.
Sender alignment catches From versus envelope mismatches
Current FortiMail anti-spam profiles can evaluate mismatches between message-header sender/display information and the SMTP envelope sender.
These mismatches are common in phishing but also occur in legitimate forwarding and SaaS mail.
Use authentication results and trusted sender exceptions so alignment adds risk context rather than blocking every message with complex routing.
Weighted analysis should combine weak signals
Many phishing messages avoid one decisive indicator but exhibit several suspicious traits: lookalike sender, unusual Reply-To, risky URL, spoofed display name, attachment type, or header anomaly.
Weighted/heuristic analysis can score several indicators and trigger an action after a threshold.
Tune with real false-positive/true-positive messages and preserve reason codes so analysts know which combination caused the classification.
Domain authentication should influence actions
SPF/DKIM/DMARC failures do not prove a message is malicious, but they strengthen the case when impersonation or cousin-domain indicators also fire.
Likewise, a DMARC pass does not make the content safe if a legitimate vendor account is compromised.
Use authentication as one signal in the mail-security stack rather than a bypass around URL, attachment, and behavioral analysis.
Action profiles should separate block, quarantine, tag, and deliver
Not every suspicious message needs the same action.
High-confidence executive impersonation or known malicious URLs may justify reject/quarantine, while lower-confidence messages can receive a subject/banner/tag or be routed for review.
Measure user and SOC workload because overly broad quarantine can create operational pressure that leads to unsafe allowlisting.
False-positive handling should be narrow
When a legitimate supplier or SaaS product triggers anti-phishing logic, avoid broad domain bypass unless the business relationship and sending infrastructure are understood.
Create targeted allow conditions based on authenticated domain, expected envelope sender, certificate/IP where appropriate, or specific policy path.
A blanket allow for a partner domain can become a direct phishing bypass if the partner account is compromised.
Phishing incidents should feed policy tuning
For each real phishing incident, record which FortiMail controls fired, which did not, and why.
Update impersonation names, cousin domains, URL/category logic, weighted rules, authentication policy, or user-awareness controls from the evidence.
Social Engineering Beyond Phishing is relevant because some attacks exploit trusted conversations rather than obvious malicious content.
FortiMail anti-phishing succeeds when identity and message signals reinforce each other
The mature policy combines impersonation mappings, cousin domains, sender alignment, authentication, URL/content analysis, weighted scoring, and graduated actions. It tunes exceptions narrowly and updates controls after real incidents.
Email defense is strongest when the gateway can explain both why the message identity looks wrong and what the message is trying to make the user do.
Executive impersonation lists should include alternates and delegates carefully. An executive assistant may legitimately send on behalf of a leader, while the same display name from an external mailbox is suspicious. Model these trusted relationships explicitly and prefer authenticated/internal authorization evidence over broad display-name allowlists that attackers can mimic.
Cousin-domain detection should be paired with domain-registration intelligence. Typos, character substitution, added words, and alternative TLDs can all imitate trusted brands. Maintain a curated list of the organizations users actually interact with for payments, benefits, cloud administration, shipping, and procurement. A generic lookalike engine becomes more useful when it knows which brands are high-value to your specific business.
Reply-To deserves separate attention. Many phishing messages display an apparently legitimate From address but direct replies to an attacker-controlled mailbox. Include Reply-To in sender alignment or weighted analysis where supported and expected by your mail flow. Legitimate mailing systems that rewrite Reply-To should be documented as known exceptions rather than causing the control to be disabled broadly.
URL analysis should consider both displayed text and actual destination. Attackers can use legitimate link-shorteners, compromised websites, open redirects, or newly registered domains. Where FortiMail integrates with FortiSandbox or FortiGuard URL intelligence, let high-risk links feed deeper analysis and quarantine decisions rather than relying only on static domain reputation.
Attachment policy should reflect business need. Executable files, password-protected archives, macro-enabled Office documents, disk images, and script containers have different risk profiles. Block types with no legitimate inbound use and route ambiguous formats through sandboxing. This reduces the anti-phishing burden on users who should never receive certain file types by email in the first place.
Authentication-result handling should be careful with mailing lists and forwarding. ARC or trusted intermediary behavior may preserve evidence when SPF/DKIM changes. Test major partners and distribution lists before making DMARC failure a universal hard-block signal in FortiMail; the stronger policy is to combine authentication with impersonation, content, and relationship context.
Mailbox compromise is not solved by anti-spoofing. A phisher sending from a genuinely compromised supplier or internal mailbox can pass SPF, DKIM, DMARC, sender alignment, and display-name checks. Detect unusual payment language, new URLs, new Reply-To destinations, behavioral anomalies, and impossible sign-ins in the identity platform as complementary controls.
User-reporting workflow should be integrated with gateway investigation. When an employee reports a suspicious message, preserve headers and body, search for other recipients, identify which FortiMail checks fired, and retroactively quarantine where supported. The fastest improvement comes from converting a reported miss into a new indicator, rule, or policy tuning across the mail estate.
Metrics should distinguish blocked malicious messages from false positives and user-reported misses. Track executive impersonation, cousin-domain hits, authentication failures, malicious URL/attachment outcomes, quarantine releases, and time from report to tenant-wide remediation. A rising block count alone can mean attack volume increased rather than policy quality improved.
Anti-phishing policy should have separate treatment for inbound and outbound compromise. Outbound phishing from a compromised internal account may pass every sender-authentication control. Monitor unusual recipients, sending volume, new URLs, and message patterns, and integrate identity/session response when FortiMail identifies suspicious outbound behavior.
Quarantine release should require context. Help-desk or users releasing mail should see why the message was held—impersonation, cousin domain, authentication failure, malicious URL, attachment verdict—and high-risk cases should require security review. Easy self-release of executive impersonation can nullify gateway protection.
Policy testing should use a maintained phishing corpus containing display-name spoofing, cousin domains, Reply-To mismatch, DMARC failures, benign forwarding, legitimate marketing messages, malicious URLs, and attachments. Re-run the corpus after FortiMail upgrades or major policy changes to catch regressions before production mail is affected.
FortiMail policy should be reviewed after major domain or email-platform migrations. Moving to a new SaaS sender, changing DKIM selectors, adopting a new secure email gateway, or merging domains can alter sender alignment and impersonation behavior. Rebaseline before old exceptions become permanent sources of false negatives.
Keep anti-phishing exceptions visible to security operations. A list of trusted senders or domains should show owner, reason, authentication evidence, creation date, and last review. Attackers target trusted relationships, so an exception granted for convenience should never become a permanent bypass with no context.
Review trusted sender exceptions after every major mail-flow change.
Anti-phishing tuning should combine sender authentication, reputation, message content, URL or attachment behavior, and user context. The goal is not simply to increase blocking; it is to reduce successful deception while keeping false positives explainable and recoverable.
