Social Engineering Beyond Phishing<\/a> is relevant because some attacks exploit trusted conversations rather than obvious malicious content.<\/p>\nFortiMail anti-phishing succeeds when identity and message signals reinforce each other<\/h3>\n 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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
Quarantine release should require context. Help-desk or users releasing mail should see why the message was held\u2014impersonation, cousin domain, authentication failure, malicious URL, attachment verdict\u2014and high-risk cases should require security review. Easy self-release of executive impersonation can nullify gateway protection.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
Review trusted sender exceptions after every major mail-flow change.<\/p>\n
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.<\/p>\n","protected":false},"excerpt":{"rendered":"
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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-19983","post","type-post","status-publish","format-standard","hentry","category-general"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t