Email Security Policy Template: Rules for Mail Use, Authentication and Reporting

Email is still the most common way attackers reach staff, and many organisations run it on technical controls that nobody is formally required to maintain: DMARC left at monitoring for years, automatic forwarding to personal mailboxes allowed by default, and no agreed way for staff to report a suspicious message. This template is the governing document for email security. It sets rules for acceptable mail use, sender authentication for every domain, transport encryption, filtering and external sender warnings, forwarding, message encryption, phishing reporting, retention, and the administrator and application accounts that can read or send mail. It is written for CISOs, messaging administrators and policy owners; have HR and legal review the user rules and retention periods before adoption. The technology itself is explained in the Email Security Guide and product selection in the Email Security Buyer's Guide.

How to use this template

• Replace text in square brackets, such as [Organisation], [Head of IT Operations] and [90 days], with your own terms and values. Bracketed values are suggested defaults, not external requirements.
• "Must" indicates a mandatory requirement. "Should" indicates a recommended practice where a documented exception may be justified.
• Section 4.1 is written for all staff and can be lifted into your Acceptable Use Policy Template; sections 4.2 to 4.10 are technical requirements for the messaging and security teams.
• Keep detailed configuration values (DNS records, filtering rules, allowed forwarding domains) in a separately versioned email security standard so they can change without re-approving the policy. The Email Authentication Checklist can serve as that standard for SPF, DKIM and DMARC.
• Place this policy beneath your Information Security Policy Template.

1. Purpose

This policy sets the requirements for the secure use and operation of email at [Organisation]. Its aims are to stop attackers sending mail that appears to come from [Organisation]'s domains, to reduce phishing, malware and business email compromise reaching staff, to protect sensitive information sent by email, to make sure suspicious messages are reported and acted on quickly, and to keep email records only as long as required.

2. Scope

This policy applies to:

• All email systems operated by or for [Organisation], including cloud mail tenants, on-premises mail servers, secure email gateways and archiving services.
• All domains and subdomains registered by [Organisation], including domains that do not send email.
• Third parties that send email using [Organisation]'s domains, such as marketing, payroll, ticketing and customer notification platforms.
• Applications, scripts and service accounts that send, read or process mail, including AI assistants and agents with mailbox access.
• All employees, contractors and others given an [Organisation] mailbox or permission to send on its behalf.

3. Roles and responsibilities

4. Policy statements

4.1 Acceptable use of email (all staff)

1. Work email must be sent from [Organisation] accounts. Personal email accounts must not be used for [Organisation] business.
2. Users must not set up rules that forward or redirect work email to external addresses.
3. Information classified [Confidential] or above must only be sent by email when protected as section 4.6 requires. See the Data Classification Policy Template.
4. Any request received by email to change bank details, make an urgent payment, buy gift cards or share credentials must be verified through a known, independent channel (for example a phone number from the supplier record, not from the email) before acting. See the Business Email Compromise Awareness for Finance Teams Guide.
5. Users must report suspicious messages with [the report button] and must not forward them to colleagues as a warning.
6. Users must not enter their [Organisation] password on a page reached from an email link unless they navigated to it themselves.
7. Users who think they clicked a malicious link, opened a malicious attachment or entered their password must report it to [the service desk] immediately. Reporting promptly will not lead to disciplinary action.

4.2 Sender authentication for all domains

1. Every domain in the inventory must have SPF, DKIM and DMARC records as shown above. The NCSC recommends protecting every domain, including those that do not send email.
2. DMARC must be introduced at p=none with aggregate reporting, moved to p=quarantine once legitimate senders pass, and then to p=reject, following the staged approach in NCSC email security guidance. No domain may remain at p=none for more than [6 months] without an approved exception.
3. DMARC aggregate reports must be collected and reviewed at least [weekly] during rollout and [monthly] after enforcement.
4. DMARC is now specified by RFC 9989 (May 2026), which obsoletes RFC 7489. New records must follow RFC 9989; existing records must be reviewed against it. See the DMARCbis Changes Guide.
5. Any service sending more than [5,000] messages a day to consumer mailboxes must meet the bulk sender requirements of the major mailbox providers (aligned SPF or DKIM, DMARC, one-click unsubscribe for marketing mail and low spam complaint rates).
6. No third-party service may send as an [Organisation] domain until the domain owner has added it to SPF or configured aligned DKIM signing for it.

4.3 Transport security

1. Mail servers must offer and use TLS for SMTP between servers. Inbound and outbound connections must support TLS 1.2 or higher.
2. Primary receiving domains should publish an MTA-STS policy (RFC 8461) in enforce mode and TLS reporting records, so sending servers refuse to deliver over unencrypted or downgraded connections.
3. Connections to named partners exchanging [Confidential] information must use enforced TLS connectors with certificate validation.
4. Mail client access must use modern authentication with multi-factor authentication. Legacy protocols that do not support it (basic authentication for POP, IMAP and SMTP) must be disabled.

4.4 Filtering and external sender warnings

1. All inbound mail must pass anti-malware, anti-spam, anti-phishing and impersonation checks before delivery, including URL rewriting or time-of-click checks and attachment sandboxing for [file types].
2. Executable and script file types listed in the email security standard must be blocked as attachments.
3. Messages from outside [Organisation] must carry a visible external sender tag or banner. Messages that fail DMARC, or come from look-alike domains of [Organisation] or key suppliers, must be quarantined or clearly flagged.
4. Administrators must be able to remove a malicious message from all mailboxes after delivery, and must do so within [30 minutes] of confirmation.
5. Allow lists that bypass filtering must be approved by [Security operations], reviewed every [6 months] and must never bypass malware scanning.

4.5 Forwarding and delegation

1. Automatic forwarding of mail to external domains must be disabled by default at the platform level. In Microsoft 365, for example, Microsoft recommends setting the outbound spam policy explicitly to On or Off rather than relying on the system-controlled default, whose behaviour varies by tenant.
2. External forwarding for a business need must be approved by [the CISO], limited to named destination domains and reviewed every [6 months].
3. Creation of inbox rules that forward, redirect or delete mail must generate an alert to [Security operations]. Forwarding rules are a common sign of a compromised mailbox (MITRE ATT&CK T1114.003 Email Forwarding Rule).
4. Delegated, shared and full-access mailbox permissions must be granted through [the access request process] and reviewed every [quarter].

4.6 Message encryption and sensitive information

1. [Confidential] and [Restricted] information sent outside [Organisation] must be protected by message encryption, a rights-management label or a secure file sharing link with access control, rather than plain email.
2. Passwords, private keys, API keys and other credentials must never be sent by email. Use [the secrets management or secure sharing tool]. See the Encryption Policy Template.
3. Data loss prevention rules must detect and block or warn on outbound messages containing [payment card numbers, national identifiers or classified labels].

4.7 Reporting suspicious email

1. A report button must be available in every supported mail client and on mobile.
2. Reported messages must be triaged within [1 business hour] during working hours. Confirmed malicious messages must trigger a search and removal across all mailboxes and blocking of the sender, URLs and attachments.
3. The reporter must receive feedback on the outcome.
4. Credential entry on a phishing page must be handled as an incident: reset the password, revoke sessions and tokens, check for forwarding rules and new MFA methods. See the Phishing Incident Response Playbook and the Business Email Compromise Response Playbook.
5. Staff must receive phishing awareness training at induction and at least [annually], with simulated phishing at least [quarterly]. Simulations must not be used to punish individuals.

4.8 Retention and archiving

1. Email must be retained according to [the retention schedule], with a default mailbox retention of [X years] and longer periods only where law, regulation or legal hold requires it. See the Data Retention and Disposal Policy Template.
2. Mail must be deleted at the end of its retention period unless under legal hold. Keeping all email indefinitely increases the data exposed in a breach.
3. Archives and journaling copies must have the same access controls and logging as live mailboxes.
4. Mail platform audit logs (sign-ins, mailbox access, rule changes, admin actions) must be retained for at least [12 months].

4.9 Administrator, application and agent access

1. Mail administrators must use separate, dedicated admin accounts with phishing-resistant multi-factor authentication, managed through [the privileged access process].
2. Applications and scripts that send mail must authenticate with their own service identity using modern authentication (for example OAuth client credentials or certificates), not a shared user mailbox password.
3. Application permissions that allow reading or sending as any mailbox must be restricted to named mailboxes where the platform supports it, approved by [the CISO] and reviewed every [6 months].
4. OAuth consent to third-party mail apps must be restricted to administrator-approved apps. See the Consent Phishing and Illicit OAuth Grants Guide.
5. AI assistants and agents with mailbox access must be inventoried, granted the minimum scope needed and must not send external mail without human approval unless [an approved exception] applies.

4.10 Monitoring

1. [Security operations] must monitor for: new external forwarding rules, impossible travel or unusual sign-ins to mailboxes, mass mailbox access by applications, new OAuth consents with mail scopes, spikes in outbound mail and DMARC failures for [Organisation] domains.
2. Mailbox content may be accessed for security investigation only as set out in [the monitoring notice] and applicable law.

5. Exceptions

1. Exceptions must be requested through [the exception process], stating the requirement, business reason, compensating controls and an expiry date of no more than [12 months].
2. Exceptions to sections 4.2 (DMARC enforcement), 4.5 (external forwarding) and 4.9 (application access) must be approved by [the CISO].
3. All exceptions must be recorded in [the risk register] and reviewed at expiry.

6. Compliance and monitoring

Breaches of this policy may lead to removal of access and to action under [the disciplinary policy]. Honest mistakes reported promptly under section 4.1 are not treated as breaches.

7. Review and approval

Implementation guidance

1. Build the domain inventory first. Sections 4.2 and 4.3 depend on knowing every domain and every service that sends as it. Parked and defensive domains are quick wins: publishing v=spf1 -all and p=reject on them is low risk because no legitimate mail should break.
2. Move DMARC to enforcement in stages. Run p=none with reporting, fix each failing legitimate source, move to p=quarantine, then p=reject. Small organisations with one mail platform and a handful of senders can often finish in weeks; large estates with many marketing and SaaS senders should work domain by domain. If legitimate mail is rejected, step back to quarantine for that domain while the sender is fixed.
3. Switch off external forwarding with a review window. Report existing forwarding rules first, contact owners, approve the genuine business cases, then disable by default. Warn users in advance and give a route to request an exception.
4. Make reporting easy and rewarding. A single report button and quick feedback do more than extra training slides. Measure the time from first report to removal across all mailboxes.
5. Review machine access. Inventory application registrations, service accounts and AI agents with mail permissions; mailbox-wide read access held by a forgotten integration is a direct path to data theft. See the Email Identity and BEC Guide.

Framework mapping

The main threats addressed are MITRE ATT&CK T1566 Phishing and T1114.003 Email Forwarding Rule. See the MITRE ATT&CK T1566 Phishing guide.

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 7208, Sender Policy Framework (SPF)
• NIST: SP 800-177 Rev. 1, Trustworthy Email
• Google: Email sender guidelines
• Microsoft Learn: Control automatic external email forwarding

This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Email Security Guide · DMARC, SPF and DKIM Guide · Email Security Maturity Model · Phishing Guide · Top 10 Email Security Threats