Email security RFPs still tend to measure spam and malware catch rates, while the losses that hurt most come from business email compromise messages that carry no link, no attachment and often come from a genuine but compromised supplier mailbox. This template gives you a ready-to-issue request for proposal for an email security platform, with numbered requirements written so that each answer can be tested in a proof of concept and scored. It covers deployment architecture (API-based versus secure email gateway), threat detection including BEC and account takeover, email authentication and DMARC support, user reporting, post-delivery remediation, outbound protection, platform security, services and commercials. It is vendor-neutral and written for security operations, messaging teams and procurement panels. For how the market is structured, read the Email Security Buyer's Guide; for the selection process, the Security Vendor Evaluation and RFP Guide.
How to use this template
- Replace text in square brackets, such as [Organisation], [mail platform] and [number], with your own details. Delete requirements that do not apply.
- Each requirement has an ID (for example EML-BEC-02) and a type: M mandatory (pass or fail), S scored (0 to 5, weighted) or I informational.
- Decide before issue whether you will accept API-based, gateway or hybrid architectures. If you will accept any, keep section 4.1 scored rather than mandatory so that each model can win on merit.
- If you are buying a separate DMARC reporting service, keep section 4.3 limited to inbound authentication and see the DMARC Buyer's Guide.
- Weights, volumes and timings in brackets are illustrative. Set them before issue and do not change them afterwards. Issue sections 1 to 8 to bidders; the Implementation guidance section is for your panel only.
1. Purpose and scope
[Organisation] invites proposals for an email security platform and implementation services. The platform must stop phishing, malware, impersonation and business email compromise before or shortly after delivery, support authentication of [Organisation] domains, let users report suspicious messages easily, and let analysts find and remove malicious messages from every mailbox quickly.
- In scope: inbound, outbound and internal email for [number] mailboxes on [mail platform]; [shared and service mailboxes]; [collaboration messaging, if required]; [user reporting]; [security awareness integration].
- Out of scope: [email archiving and eDiscovery]; [email encryption for regulated messages, unless listed]; [general data loss prevention].
- Drivers: [BEC and payment fraud attempts]; [credential phishing]; [supplier account compromise]; [audit findings on domain spoofing]; [renewal of the current gateway].
- Contract term: [three] years with an option to extend.
2. Organisation background and current state
| Item | [Organisation] value |
|---|---|
| Mail platform and tenants | [cloud mail platform or on-premises servers]; [number] tenants |
| Mailboxes and volume | [number] user mailboxes; [number] shared mailboxes; approximately [number] inbound messages per day |
| Domains | [number] sending domains; [number] parked domains; current DMARC policy per domain [none, quarantine, reject] |
| Current controls | [native platform filtering]; [gateway]; [sandbox]; [DMARC reporting service]; [phishing simulation platform] |
| Third-party senders | [marketing, ticketing, HR and finance platforms sending as our domains] |
| Security operations | [SOC hours, SIEM, SOAR, ticketing] |
| Regulatory or residency constraints | [regions where message content may be processed and stored] |
3. Instructions to bidders
- Timeline: RFP issued [date]; clarification questions by [date]; responses due [date, time, time zone]; proof of concept [dates]; decision [date].
- Single point of contact: [name, email].
- Response scale: available now; available with configuration; custom development; third-party product required (name it); roadmap (committed date); not supported. Roadmap answers score zero unless contractually committed.
- Evidence: reference product documentation for each "available now" answer and state the licence tier.
- Architecture: describe mail flow (MX change, connector or API), every permission requested in [mail platform], where message content is processed and stored, and for how long.
4. Functional requirements
4.1 Deployment architecture: API versus gateway
| ID | Requirement | Type |
|---|---|---|
| EML-ARC-01 | State the deployment model (MX-based gateway, API-based integration with [mail platform], or hybrid) and which threats are stopped before delivery versus removed after delivery. | M |
| EML-ARC-02 | For API models: state the delay between delivery and verdict, and the share of malicious messages a user could open in that window, measured in the proof of concept. | S |
| EML-ARC-03 | For gateway models: describe how the platform avoids breaking SPF, DKIM and DMARC evaluation by the mail platform (for example connector configuration, enhanced filtering or ARC sealing). | S |
| EML-ARC-04 | Inspects internal (mailbox to mailbox) email, so that a compromised internal account sending phishing is detected. | S |
| EML-ARC-05 | Describes failure behaviour: what happens to mail flow if the service is unavailable, and how to bypass it in an emergency. | M |
4.2 Threat detection, BEC and account takeover
| ID | Requirement | Type |
|---|---|---|
| EML-BEC-01 | Detects impersonation of executives, staff and suppliers using display name, lookalike domain and relationship analysis, including text-only messages with no link or attachment. | M |
| EML-BEC-02 | Detects payment and bank detail change requests and invoice fraud language, and flags them with a visible banner or holds them for review. | S |
| EML-BEC-03 | Detects messages from genuine but compromised supplier or partner accounts, using sender behaviour history rather than authentication results alone. | S |
| EML-BEC-04 | Detects signs of internal account takeover, such as suspicious inbox rules, forwarding to external addresses and anomalous sending patterns, and integrates with [identity provider] to revoke sessions. | S |
| EML-THR-01 | Rewrites or scans URLs at time of click, follows redirects and detects credential harvesting pages, including adversary-in-the-middle phishing kits and QR codes in images and attachments. | M |
| EML-THR-02 | Detonates attachments in a sandbox, including password-protected archives where the password is in the message, and states the delivery delay. | S |
| EML-THR-03 | Maps detections to MITRE ATT&CK T1566 Phishing sub-techniques (T1566.001 Spearphishing Attachment, T1566.002 Spearphishing Link) and T1534 Internal Spearphishing where relevant. | I |
See the Email Identity and BEC Guide and the AiTM Phishing Guide.
4.3 Email authentication and DMARC support
| ID | Requirement | Type |
|---|---|---|
| EML-AUT-01 | Evaluates SPF, DKIM and DMARC on inbound mail and honours the sender's DMARC policy; state whether DMARC as defined in RFC 9989 (May 2026, obsoleting RFC 7489) is supported, including the np tag. | M |
| EML-AUT-02 | Supports ARC (RFC 8617, Experimental) to evaluate authentication results across trusted intermediaries. | S |
| EML-AUT-03 | Signs outbound mail with DKIM for all [Organisation] domains, supports key rotation and 2048-bit keys. | S |
| EML-AUT-04 | Provides or integrates with DMARC aggregate report analysis to identify all legitimate senders before moving domains to p=reject. | S |
| EML-AUT-05 | Supports inbound and outbound TLS, MTA-STS (RFC 8461) and TLS reporting for [Organisation] domains. | S |
See the DMARC, SPF and DKIM Guide and the DMARCbis Changes Guide.
4.4 User reporting and awareness
| ID | Requirement | Type |
|---|---|---|
| EML-USR-01 | Provides a report button in [desktop, web and mobile clients] that sends the full original message with headers to analysis. | M |
| EML-USR-02 | Automatically triages reported messages, clusters duplicates, and informs the reporter of the outcome. | S |
| EML-USR-03 | Shows context banners (external sender, first-time sender, lookalike domain) that can be tuned to avoid banner fatigue. | S |
| EML-USR-04 | Integrates with [phishing simulation platform] so that simulated messages are not reported as real threats, and reports feed awareness metrics. | I |
See the Phishing Report Button and User Reported Message Triage Guide.
4.5 Post-delivery remediation and investigation
| ID | Requirement | Type |
|---|---|---|
| EML-REM-01 | Searches all mailboxes for a message by sender, subject, URL, attachment hash or header, and removes matches in bulk, within [five minutes] for [number] mailboxes. | M |
| EML-REM-02 | Automatically removes messages that are reclassified as malicious after delivery, and lists who opened or clicked. | S |
| EML-REM-03 | Provides message trace and full header view for analysts, with logs retained for [period]. | S |
| EML-REM-04 | Sends alerts, verdicts and message metadata to [SIEM and SOAR] and supports response actions through API. | M |
| EML-REM-05 | Manages quarantine with user self-release rules by category, and blocks release of malware and high-confidence phishing. | S |
See the Phishing Incident Response Playbook and the Business Email Compromise Response Playbook.
4.6 Outbound protection
| ID | Requirement | Type |
|---|---|---|
| EML-OUT-01 | Detects outbound spam and phishing from compromised accounts and automatically restricts sending. | S |
| EML-OUT-02 | Warns users about misdirected email (wrong recipient, unusual external recipient) before sending. | I |
| EML-OUT-03 | Applies policy-based encryption or data loss prevention to outbound messages, or integrates with existing tools. | I |
5. Security of the platform
API-based products typically need broad read and delete permissions over every mailbox, and gateways see all message content, so these requirements carry heavy weight.
| ID | Requirement | Type |
|---|---|---|
| EML-SEC-01 | List every application permission and consent requested in [mail platform], explain why each is needed, and confirm credentials are certificate-based and rotatable, not static secrets. | M |
| EML-SEC-02 | Console access through [Organisation] SSO with phishing-resistant MFA; roles separate viewing message content from policy change and bulk deletion. | M |
| EML-SEC-03 | All analyst access to message content and all bulk actions are logged and exportable to [SIEM]. | M |
| EML-SEC-04 | Describe retention of message content and metadata, encryption at rest, regions of processing, and whether content is used to train models shared with other customers. | M |
| EML-SEC-05 | Provide a current independent assurance report, a [SIG or CAIQ] response, vulnerability disclosure policy and incident history for the last three years. | M |
| EML-NF-01 | Availability of [percentage] with service credits, and a documented mail queueing period during outages. | S |
See the Consent Phishing and Illicit OAuth Grants Guide for how broad mailbox permissions are abused.
6. Implementation, services and support
- Phasing: propose phases, for example [monitor-only for [two] weeks, then enforcement for a pilot group, then all mailboxes, then MX change if a gateway is chosen].
- Tuning: describe allow-list hygiene, how existing transport rules and allow lists are migrated or retired, and the tuning period.
- References: [two or three] references of similar size on [mail platform].
- Support: severity definitions, response targets, and a 24x7 route for mail flow outages.
7. Commercials
| Cost element | What to state |
|---|---|
| Licence metric | Per user or per mailbox; how shared, service and inactive mailboxes are counted |
| Tiers and add-ons | Which section 4 requirements need higher tiers (BEC, remediation, DMARC, awareness, outbound DLP) |
| Data retention | Included log and message retention; cost of extension |
| Implementation | Fixed price or day rate, including DMARC rollout support if offered |
| Growth, renewal and exit | Price for [growth percentage] more mailboxes; renewal cap; exit and MX reversion support |
8. Evaluation method and proof of concept
| Criterion | Weight | Evidence |
|---|---|---|
| Detection of BEC, phishing and malware missed by current controls | [35%] | Proof of concept in monitor mode on live mail |
| Remediation, reporting and analyst workflow (4.4, 4.5) | [15%] | Analyst-scored tasks |
| Authentication and architecture fit (4.1, 4.3) | [10%] | Response, architecture review |
| Platform security and data handling (section 5) | [15%] | Permission review, assurance reports |
| Implementation and support | [5%] | Section 6, references |
| Three-year life-cycle cost | [20%] | Section 7 |
Scores use 0 to 5: 0 not met; 1 roadmap only; 3 met with configuration; 5 met fully and demonstrated. The proof of concept runs for [four] weeks, ideally with each bidder in monitor-only mode on the same mail, and covers at minimum:
- Count of malicious messages detected that current controls delivered, reviewed by [Organisation] analysts to confirm each is a true positive.
- False positive rate: legitimate messages, especially from finance, HR and supplier contacts, that the product would have blocked or bannered.
- A benign simulated BEC message (text only, payment change request from a lookalike supplier domain), sent from a test domain under your control with prior approval.
- Bulk search and removal of a test message from [number] mailboxes, timed.
- User report from desktop and mobile clients, with automatic triage and feedback.
- Review of permissions granted during the trial, and their removal at the end.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- API or gateway: API products are quick to deploy, see internal mail and can remove messages after delivery, but act after delivery. Gateways stop threats before delivery and can hold mail during outages, but need MX changes and careful handling of authentication. Many organisations combine native platform filtering with an API layer; choose based on where your current misses are.
- Measure what was missed: the only fair comparison is messages your current stack delivered. Run bidders side by side on the same mail in monitor mode where possible.
- Do not let the RFP replace DMARC work: moving your own domains to p=reject stops direct spoofing of your brand regardless of which product you choose; the NCSC sets out a staged path from monitoring to rejection.
- Identity angle: API connectors are high-privilege application identities with access to every mailbox. Record an owner, review the grant annually and alert on any change to its permissions.
- Clean up the trial: remove application consents and connectors of unsuccessful bidders at the end of the proof of concept.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | MITRE ATT&CK |
|---|---|---|---|
| Threat and BEC detection (4.2) | SI-3, SI-8, SI-4 | DE.CM-09, DE.AE-02 | T1566, T1534 |
| Authentication and transport (4.3) | SI-8, SC-7 | PR.DS-02 | T1566 |
| User reporting (4.4) | IR-4 | PR.AT-01, DE.AE-02 | T1566.002 |
| Remediation (4.5) | IR-4, AU-6 | RS.MI-01 | T1566.001, T1566.002 |
| Platform and supplier (5) | SA-9, SR-6, AC-6 | GV.SC-05, GV.SC-06 |
Standards and references
- NCSC: Email security and anti-spoofing
- IETF: RFC 9989 Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- IETF: RFC 8461 SMTP MTA Strict Transport Security (MTA-STS)
- IETF: RFC 8617 The Authenticated Received Chain (ARC) Protocol
- MITRE ATT&CK: T1566 Phishing
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Email Security Buyer's Guide · Email Security Guide · DMARC Buyer's Guide · EDR and XDR RFP Template · Security Vendor Evaluation and RFP Guide