Before you begin

Before you start the onboarding process, you will have to:

1. Choose a deployment path: Email Security provides two deployment modes, post-delivery for API and BCC/Journaling and pre-delivery for MX/Inline.
2. Learn about dispositions, impersonation registry, and reclassifications.
3. Know the steps to configure your email environment correctly.

1. Choose a deployment

Post-delivery deployment

When you choose post-delivery deployment, Cloudflare scans emails after they reach a users' inbox.

If you are a Microsoft 365 user, this is done via Microsoft's Graph API or journaling.

If you are a Google Workspace or Microsoft Exchange user, this is done via BCC.

Why you should consider post-delivery deployment

Post-delivery deployment is time-efficient, because it does not involve MX changes. Post-delivery deployment does not disrupt mail flow. Post-delivery deployment allows you to enable auto-move events to hard or soft delete messages, and synchronize your directory when you use Microsoft Graph API or Google Workspace.

Note

When you choose post-delivery deployment:

• The threat is removed after the message has been delivered to the inbox.
• It requires API scopes, or BCC/Journaling rule configuration.
• Auto-move is only available in BCC/Journaling if you associate an integration.

Pre-delivery deployment

When you choose pre-delivery deployment, Cloudflare scans emails before they reach a users' inbox. The MX record points to Cloudflare.

Why you should consider pre-delivery deployment

Pre-delivery deployment provides you with the highest level of protection. It enforces text add-ons or link rewrite at delivery.

Pre-delivery blocks threats in transit, and it adds banners or texts before the user views the email.

Note

When you choose pre-delivery deployment:

• You must edit MX records or create a connector.
• You can enable auto-move events only after you associate an integration.
• Cloudflare egress IPs are allowed on downstream mail servers.

2. Understand dispositions

Dispositions allow you to configure policies and tune reporting. For example, you can configure a policy to move suspicious emails to your junk folder.

Refer to Dispositions to learn more about dispositions.

3. Set up the impersonation registry

Most business email compromise (BEC) ↗ targets executives or finance roles. You must add addresses of roles who are likely to be impersonated. Refer to Impersonation registry to learn how to add a user to the impersonation registry.

Roles you may want to include in the impersonation registry are:

• C-suites
• Finance roles
• HR
• IT help-desk
• Legal

You should review your impersonation registry on a quarterly basis as roles change.

4. Reclassify messages

A reclassification is a change to an email's disposition after initial scanning. It is Cloudflare's built-in feedback loop for correcting false positives/negatives and training the detection models to get smarter over time. Refer to Reclassify messages to learn how to reclassify a message.

Who can reclassify messages

Security teams and end users can submit a reclassification.

Why you should reclassify messages

Reclassifications are critical because:

• They help improve model accuracy: Every validated reclassification teaches Cloudflare's machine learning to recognise new lures, language, infrastructure, and benign patterns.
• They reduce alert fatigue: Correcting Suspicious or Spam emails that users actually want tailors detections to your organization, cutting noise in the dashboard.
• They close the remediation loop: When a disposition is upgraded to Malicious, Cloudflare auto-moves those emails out of every inbox (Graph API or Google Workspace API integrations).
• They can help you log activity taken on any reclassification: Each reclassification displays a submission ID, details about original, requested and final dispositions, and more. Refer to Reclassify messages to learn more about reclassifications.

To make the most of reclassifications:

1. Review reclassifications on a weekly basis.
2. Ensure you have an integration associated with any MX/Inline deployment. When you associate an integration, you will not need to upload the EMLs every time; Cloudflare can use APIs to receive a copy of your email messages.
3. Investigate any increase in user submissions (users may have found a phish that bypassed filters) and confirm that analyst-final dispositions align with your policies.

A correct use of reclassifications ensures that Email Security delivers a stronger protection with less manual tuning.

5. Configuration checklist

Follow the below checklist to ensure your email environment is set up correctly:

Step	Post-delivery	Pre-delivery
Authorize integration (Graph API or Google Workspace)	Required1	Required 2
Associate an integration with an MX/Inline domain		Required
Add/verify domains	Required	Required
Update MX records/connector, then allow Cloudflare egress IPs on downstream mail server		Required
Enable Post‑delivery response and Phish submission response	Required	Required
Populate impersonation registry and allow/block lists	Required	Required
Configure partner domain TLS and admin quarantine		Required
Configure text add-ons and link actions		Required
Send a test email and verify it appears in Monitoring > Email activity with expected disposition	Required	Required

Now that you know which deployment path to choose, you can begin your onboarding process.

Footnotes

1. Associating an integration with BCC/Journaling is required for post-delivery but not for pre-delivery. ↩

2. Still used for directory/auto‑move insight if desired as well as authorizing free API CASB. ↩