Cloudflare email security checklist
Use this checklist to plan Cloudflare Email Security work across domain inventory, MX and DNS readiness, mail routing, threat policy design, allow and block handling, quarantine workflows, alerting, reporting, and operational ownership.
Use this checklist to plan Cloudflare Email Security work across domain inventory, MX and DNS readiness, mail routing, threat policy design, allow and block handling, quarantine workflows, alerting, reporting, and operational ownership.
Topics: cloudflare, resource, cloudflare, email, security, checklist
Machine-readable context: /ai-index.json
Step by step
Step-by-step checklist
- 1
Inventory email domains and subdomains, the mail platform behind each (Microsoft 365, Google Workspace, on-premises), and the current mail flow so deployment is planned against the real estate.
- 2
Confirm DNS readiness: existing MX records, SPF, DKIM, and DMARC alignment and policy, since Email Security depends on accurate sender authentication to judge messages.
- 3
Choose the deployment mode for each domain — inline via MX (Email Security as the receiving MX) or API/journaling integration with the mailbox provider — and plan the routing change accordingly.
- 4
Configure mail routing and connectors so messages flow through Email Security and on to the mailbox, validating with test mail before production traffic moves.
- 5
Design threat-detection policy: how phishing, business email compromise, malware, spoofing, and malicious links are handled, and the disposition (deliver, tag, quarantine, reject) for each verdict.
- 6
Set up allow and block handling: trusted senders, internal domains, and partner mail that must always deliver, plus block lists, scoped narrowly so they do not create new bypasses.
- 7
Define quarantine and end-user workflows: who reviews quarantined mail, release and report-false-positive paths, and notification behaviour, then wire alerting and reporting on detections.
- 8
Pilot on a limited group or domain, review verdicts and false positives against real mail, tune policy, then expand and hand over operational ownership.
Risk register
Risks to control
SPF, DKIM, or DMARC are misaligned, so legitimate mail is judged as spoofed or detection quality drops.
Validate SPF, DKIM, and DMARC alignment per sending domain before deployment, and fix authentication gaps so verdicts are based on accurate sender data.
Changing the MX record to route through Email Security disrupts mail flow during cutover.
Plan the routing change with low TTLs, test with a pilot domain or group first, and keep the prior mail flow documented for rollback.
Quarantine fills up with no one owning review, so real threats and false positives both sit unattended.
Assign quarantine review ownership, define release and false-positive-report workflows, and set notification behaviour before enabling enforcement.
Broad allow rules for partners or internal senders become a phishing bypass.
Scope allow entries to specific authenticated senders and domains rather than wide patterns, and review the allow list on a schedule.
Detection policy is set to reject aggressively before verdicts are validated against real mail.
Pilot with tagging or quarantine before reject, review verdicts and false positives on live traffic, and tighten disposition gradually.
Detections are not surfaced anywhere, so phishing campaigns go unnoticed.
Configure alerting and reporting on detections and quarantine activity, and confirm the right team receives and acts on them.
Output
Useful deliverables
- Email domain and platform inventory with current mail flow for each domain in scope.
- DNS readiness report covering MX, SPF, DKIM, and DMARC alignment and policy, with required fixes.
- Deployment-mode decision per domain (inline MX versus API/journaling) and the routing change plan.
- Mail-routing and connector configuration validated with test mail before cutover.
- Threat-detection policy mapping verdicts to dispositions for phishing, BEC, malware, spoofing, and malicious links.
- Allow and block handling design plus quarantine and end-user release and reporting workflows.
- Pilot results, policy tuning notes, alerting and reporting setup, and an operational ownership handover.
Keep reading
Related resources
FAQ
Frequently asked questions
Common questions teams ask when putting this resource into practice.
Does Cloudflare Email Security replace Microsoft 365 or Google Workspace protection?
It complements them. Email Security can sit inline as the receiving MX or integrate via API/journaling with the mailbox provider, adding phishing, business email compromise, and malicious-link detection on top of the platform's native filtering. The checklist covers deciding which mode fits each domain.
Why do SPF, DKIM, and DMARC matter so much before deployment?
Sender authentication is a core input to threat verdicts. If SPF, DKIM, or DMARC are misaligned, legitimate mail can look spoofed and detection quality suffers. Validating and fixing DNS authentication first makes the policy decisions that follow far more reliable.
What is the difference between inline (MX) and API deployment?
Inline deployment makes Email Security the receiving MX, so mail passes through it before reaching the mailbox and can be blocked pre-delivery. API or journaling deployment integrates with the mailbox provider and analyses mail with less disruption to mail flow. The right mode depends on the domain, platform, and appetite for routing changes.
How do you avoid quarantining legitimate mail at go-live?
Pilot first. Run detection with tagging or quarantine rather than reject on a limited group, review verdicts and false positives against real mail, scope allow rules to trusted authenticated senders, and only tighten disposition once the false-positive rate is understood.
Nanosek
Review email security
Nanosek can turn this resource into a practical delivery plan for your environment — with rollback planning, stakeholder alignment, and 24/7 managed operations support.