← All products

Email Security

Cloudflare Email Security, built on the platform formerly named Area 1, evaluates inbound email against campaign intelligence, sender authentication, content analysis, link evaluation and attachment analysis, and applies a disposition. This page documents the deployment modes, disposition model, limits and licensing.

Document control

Dana
Technical writer, Integrity Czech Republic s.r.o.

Overview

Email-borne attacks divide into categories that require different detection methods. Malware attachments and credential phishing pages are detectable from content and from the infrastructure they reference. Business email compromise and supplier invoice fraud frequently contain no attachment, no link and no malware, and are detectable only from sender context, relationship history and message content.

Cloudflare Email Security evaluates inbound messages and assigns a disposition. It is deployed alongside or in front of an existing mail platform rather than as a mail platform in its own right.

To compare detection with your current filtering, measure it on your own mail using a detection-only deployment, and treat the result as a measurement of your traffic rather than a general finding.

Architecture

Detection combines several inputs:

• Campaign and infrastructure intelligence. Cloudflare operates crawling and sensor infrastructure that identifies phishing kits, lookalike domains and hosting used in campaigns. A message that references known campaign infrastructure can be dispositioned on that basis.
• Sender authentication. SPF, DKIM and DMARC evaluation, together with sending infrastructure reputation.
• Content and context analysis. Language patterns associated with payment and urgency fraud, display name and domain similarity to known correspondents, thread context, and deviation from the historical relationship between sender and recipient.
• Link evaluation. Links are resolved through redirect chains and evaluated. Time-of-click evaluation addresses destinations that are changed after delivery.
• Attachment analysis. Static analysis and, where warranted, detonation in a sandbox.

Two deployment modes determine where the service sits relative to mail flow:

• API mode. The service connects to Microsoft 365 or Google Workspace through the provider's API. Mail routing is unchanged. Messages are evaluated after delivery to the mailbox, and configured actions move or remove them. Because evaluation happens after delivery, a message can be present in the mailbox briefly before it is actioned, and messages sent between internal mailboxes are visible to the service.
• Inline mode. The service is placed in the MX path, so messages are evaluated before the mail platform receives them. Delivery of a rejected message never occurs. This mode changes mail routing and therefore requires an MX record change and a rollback plan. Internal mailbox-to-mailbox mail does not traverse the MX path and is therefore not evaluated in this mode.

A detection-only configuration is available in both modes, in which dispositions are recorded and reported but no action is taken on the message.

Capabilities

Configuration model

The central configuration object is the mapping from disposition to action. Cloudflare assigns each evaluated message a disposition such as malicious, suspicious, spoof, spam or bulk. For each disposition, the administrator selects what happens: no action, add a warning banner or subject tag, move to junk, quarantine, or, in API mode, retract after delivery.

Additional configuration includes:

• Domain and directory configuration. The protected domains and the mailbox directory, which supplies the recipient list and the relationship history used in context analysis.
• Allow and block policies. Explicit sender, domain and IP entries. These override detection and should be scoped narrowly and reviewed, because a broad allow entry is a durable bypass.
• Trusted-sender and impersonation registries. Named executives, suppliers and domains that impersonation detection should treat as high value.
• Submission and review workflow. How users report suspected phishing and how administrators reclassify a message.
• Integration outputs. Export of detection data to a SIEM or SOAR system.

In inline mode, mail routing configuration is also part of the deployment: the MX records for the protected domains and the connector or receive configuration on the mail platform that accepts mail only from the filtering service.

Limits and constraints

• API mode evaluates after delivery. A message can be present in the mailbox for an interval before it is moved or removed. Where a requirement states that a malicious message must never reach a mailbox, API mode does not satisfy it and inline mode is required.
• Post-delivery retraction is available in API mode only. Choosing inline mode removes it.
• Inline mode does not evaluate mail sent between mailboxes on the same platform, because that mail does not traverse the MX path. API mode does evaluate it. An account compromise scenario therefore has different coverage in each mode.
• Inline mode changes MX records. The change is bounded by DNS TTL in both directions, so cutover and rollback both require a planned window.
• Sandbox detonation covers supported file types within a maximum size. Password-protected archives and content the service cannot open are evaluated on other signals only.
• Link isolation on click requires the Browser Isolation entitlement and is not included by default.
• Email Security is licensed per mailbox, separately from zone plans, and is not included in the Free, Pro or Business zone plans.
• Data retention and data location are contractual matters. Confirm both against the requirement rather than inferring them from product documentation.
• Outbound mail and internal policy enforcement for your own domains are addressed by SPF, DKIM and DMARC, which are configured in DNS and are not replaced by inbound filtering.
• Detection of fraud sent from a genuinely compromised third-party mailbox relies on content and relationship signals, since sender authentication passes. A residual false negative rate should be assumed and mitigated with process controls such as out-of-band verification of payment detail changes.

Plan availability

Deployment

Prerequisites.

• Record the mail platform, the domains in scope, the mailbox count and any mail that is routed through additional gateways or archiving systems.
• Record the current inbound filtering configuration, including any allow entries, because these frequently explain messages that reach mailboxes.
• Record the current SPF, DKIM and DMARC state for every sending domain, including domains used only by marketing or billing systems.
• Decide the deployment mode against the requirement. Use inline mode where a message must not reach a mailbox; use API mode where post-delivery retraction and internal mail coverage matter, and where mail routing must not change.
• Obtain the administrative consent required for the API integration, or the DNS control required for an MX change.
• Define the disposition-to-action mapping that will be used after the evaluation period, and identify who approves it.

Staged validation. Deploy in detection-only configuration. In API mode this does not alter mail flow. Run for an observation window of at least two to four weeks so that the sample covers a full business cycle including invoicing and month-end periods. Review the dispositions against the messages that the existing filtering delivered, and classify the disagreements into true detections, false positives and cases needing a policy entry.

Configuration.

1. Apply the agreed disposition-to-action mapping, beginning with the highest-confidence disposition and a non-destructive action such as a warning banner or a move to junk.
2. Add allow and block entries only where the evaluation period produced evidence for them, and record an owner and a review date for each.
3. Register executives, finance staff and key suppliers in the impersonation configuration.
4. Configure the user submission workflow and the administrator reclassification path, and publish the instructions to users before enforcement.
5. Configure export of detection events to the SIEM and confirm ingestion.
6. In parallel, progress your own domains through DMARC to an enforcing policy, moving from p=none through p=quarantine to p=reject only after reporting shows all legitimate sources are authenticated.

Cutover. In API mode, enable actions for one disposition at a time. In inline mode, lower the MX TTL in advance, change the MX records during an agreed window, restrict the mail platform to accept mail only from the filtering service, and monitor delivery and rejection rates continuously for the first business day.

Verification.

• Send test messages representing each disposition class from an external domain and confirm the configured action occurs.
• Confirm that legitimate high-volume senders, such as billing, ticketing and monitoring systems, are delivered without action.
• Confirm that a user submission produces an administrator-visible case and that reclassification works.
• In inline mode, confirm that mail from all external sources is accepted, that no sender is rejected by the platform's new receive restriction, and that message tracing shows the expected path.
• Confirm that detection events reach the SIEM with the expected fields.
• Confirm that DMARC aggregate reports show no legitimate source failing authentication before increasing the policy.

Rollback. In API mode, set all dispositions to no action, which restores previous behaviour without a routing change. In inline mode, restore the previous MX records and remove the platform receive restriction; because the change is TTL bounded, keep the MX TTL low until the deployment is confirmed stable. Restore any allow entries that were removed during the transition.

Operational considerations

Review allow and block entries on a schedule. An allow entry added to resolve one delivery problem is a permanent bypass for that sender, and entries accumulate faster than they are removed.

Route user submissions into an existing case workflow with a defined response time. A submission path that produces no visible response stops being used, which removes the most reliable source of missed-detection evidence.

Track false positives and false negatives as separate metrics over time, and record which detection input was responsible where the data allows. This is the only defensible basis for tuning the disposition-to-action mapping.

Keep DMARC reporting under active review after reaching an enforcing policy. New marketing or billing systems introduced by other departments commonly send from your domain without authentication and are rejected without anyone associating the failure with DNS.

Export detection data rather than relying on in-product retention where investigations require a longer window.

Failure modes to plan for: API consent revoked by a tenant administration change, an MX record modified by an unrelated DNS change, a new mail relay introduced upstream that changes the observed sending infrastructure, and a supplier domain change that triggers impersonation detection on legitimate mail.

Known caveats

• The choice between API and inline mode is a trade-off. API mode covers internal mail and supports retraction but evaluates after delivery. Inline mode prevents delivery but does not see internal mail and changes routing.
• A detection-only deployment measures your own mail. It does not establish a general comparison between products, and the result should not be reported as one.
• Sender authentication passing is not evidence that a message is legitimate. Mail from a compromised supplier mailbox authenticates correctly.
• Inbound filtering does not prevent others from spoofing your domains. That requires SPF, DKIM and an enforcing DMARC policy on your own DNS.
• Password-protected archives and unsupported file types cannot be detonated and are evaluated on other signals only.
• Link evaluation at time of click reduces exposure to destinations weaponised after delivery, but a link opened outside the mail client, for example from a forwarded copy, is outside that path.
• Licensing is per mailbox and separate from zone plans. A zone plan upgrade does not provide it.

Interoperability

Email Security operates alongside the native filtering of Microsoft 365 and Google Workspace rather than replacing their mail transport. In API mode both evaluate the same message; in inline mode the platform receives mail that has already been evaluated.

DNS configuration is a dependency in both modes: MX records define the inline path, and SPF, DKIM and DMARC records define authentication for your own domains. Where DNS is hosted on Cloudflare, those records are managed in the same zone as the rest of the domain and must remain DNS-only.

Link isolation composes with Remote Browser Isolation, so a link classified as risky can be opened in a remote browser instead of being blocked outright.

Data Loss Prevention profiles defined for Cloudflare One can be applied to email content where the entitlement covers it, allowing one pattern definition across web and mail enforcement points.

Detection events export to SIEM and SOAR platforms, which allows correlation with endpoint and identity telemetry, in particular for account compromise investigations.

FAQ

Which deployment mode evaluates mail sent between two internal mailboxes? API mode. Internal mail does not traverse the MX path, so inline mode does not evaluate it.

Can a message be removed after it has been delivered? Yes, in API mode. Retraction is not available in inline mode, where the equivalent outcome is achieved by not delivering the message at all.

Does deploying in API mode change mail routing? No. MX records are unchanged and messages flow to the mail platform as before. Inline mode does change routing and requires an MX change with a planned rollback.

Does inbound filtering stop others from sending mail that appears to come from our domain? No. That is addressed by publishing SPF and DKIM for all legitimate sending sources and by moving the DMARC policy to an enforcing value.

References

• https://developers.cloudflare.com/cloudflare-one/email-security/, retrieved 2026-08-28.
• https://developers.cloudflare.com/cloudflare-one/email-security/deployment/, retrieved 2026-08-28.
• https://developers.cloudflare.com/cloudflare-one/email-security/reference/dispositions-and-attributes/, retrieved 2026-08-28.
• https://developers.cloudflare.com/cloudflare-one/email-security/auto-moves/, retrieved 2026-08-28.
• https://developers.cloudflare.com/dmarc-management/, retrieved 2026-08-28.
• https://developers.cloudflare.com/cloudflare-one/remote-browser-isolation/, retrieved 2026-08-28.
• https://www.cloudflare.com/plans/zero-trust-services/, retrieved 2026-08-28.

Content snapshot: 2026-08-28.

Changelog