An organization uses Microsoft 365 for email and wants Cisco Security Email Threat Defense, but the messaging team will not change MX records or place another gateway in the mail flow. Which deployment model fits?
Select an answer to reveal the explanation.
Short Explanation
Email Threat Defense can sit beside Microsoft 365 instead of in front of it: journaling feeds it copies and the API lets it clean up mailboxes. That's why you don't have to touch MX records. ETD does have a gateway mode, but pointing MX records at it is exactly the change this team ruled out.
Full Explanation
Cisco Secure Email Threat Defense offers two deployment models. In the journal-based model for Microsoft 365, administrators authorize it against the tenant, Microsoft 365 sends it copies of messages through a journal rule, and it uses the Microsoft APIs to act on messages in mailboxes, for example moving or removing threats after delivery. Because it is out of band, MX records and the existing mail flow stay unchanged, which matches the messaging team's constraint. Email Threat Defense also has a gateway mode in which MX records are pointed at the service for pre-delivery inspection, but that places a gateway in the mail flow, the exact change the team refuses. DNS-layer security in Secure Access controls domain resolution for users; it does not analyze or remediate email messages and does not block mail servers in a tenant's mail flow. Secure Client modules run on endpoints for VPN, posture and visibility; they do not scan mailboxes. Exam caveat: because analysis is out of band, remediation happens after delivery, and it needs read and write permissions in Microsoft 365, so policy should define the automatic action to take on detected threats. Operational check: confirm that the Microsoft 365 tenant is connected and authorized in Email Threat Defense, then send a test message and verify that it appears in the message search with a verdict.