Hosted email carries password resets, invoices, contracts, customer conversations, and alerts from nearly every other system a small team uses. That makes it both a communications tool and a master key. Security should therefore be planned at the domain, administrator, user, device, and recovery levels. Buying a familiar service is only the beginning; configuration and operating habits determine most of the day-to-day risk.

This checklist is designed for a team without a large security department. It favors controls that are understandable, testable, and maintainable. Assign an owner to each section, record the current setting, and review the list after staff changes, domain changes, incidents, or major provider updates.

Protect the domain and DNS account

Email security depends on control of the domain name and its DNS records. Use a registrar account that is separate from ordinary employee email where practical, protect it with strong multi-factor authentication, and keep recovery information current. Limit who can modify nameservers, MX records, and authentication records. A compromised registrar or DNS account can redirect mail even when every mailbox password remains secure.

Document the provider, registrar, DNS host, renewal dates, authorized administrators, and emergency support path. Enable registry or transfer locks where available. Avoid relying on one founder’s personal phone number or email as the only recovery method. Test renewal and recovery well before the domain expires.

Configure sender authentication

Set up SPF, DKIM, and DMARC according to the hosted email provider’s documentation and the systems that legitimately send on behalf of the domain. These controls help receiving systems evaluate whether a message is authorized and whether authentication aligns with the visible sender. They are not one-time text records: marketing platforms, support tools, billing services, and migrations can change the legitimate sender list.

Start DMARC with reporting, inspect legitimate sources, correct misconfigurations, and move toward an enforcement policy when the organization understands the traffic. Keep ownership of reports and alerts clear. Do not copy a strict record from a generic tutorial without confirming every sender; blocking the company’s own receipts or support replies is not a security win.

Harden administrator accounts

Use the fewest global administrators necessary and give routine work a lower-privilege account. Administrator accounts should use phishing-resistant multi-factor authentication where the platform supports it, have no unnecessary third-party app access, and receive high-priority alerts for login, role, forwarding, and security-policy changes. A shared admin login prevents attribution and makes offboarding hazardous.

Create an emergency access procedure that does not depend on the same mailbox system it is meant to recover. Store recovery codes securely, document the conditions for use, and review the emergency account. CISA’s guidance on enhanced email and web security provides a useful official baseline for strengthening email protections.

Require strong sign-in and safe recovery

Require multi-factor authentication for every user, not only executives. Prefer authentication apps, hardware-backed methods, or passkeys over SMS where feasible. Block legacy protocols that bypass modern sign-in controls unless a documented system still requires them. Review remembered devices, app passwords, and active sessions after suspicious activity or a role change.

Recovery should be strict enough to resist social engineering but usable during a real emergency. Verify recovery addresses and phone numbers, limit help-desk resets, and require a second approver for sensitive accounts. Train staff to treat unexpected MFA prompts as warning signals rather than annoyances to approve.

Reduce phishing and unsafe forwarding

Enable anti-phishing, malware scanning, link inspection, and impersonation protections appropriate to the platform. Protect executive names, finance roles, and common vendor identities. Add external-sender indicators carefully so they provide useful context without becoming visual noise that users ignore.

Review automatic forwarding and inbox rules. Attackers often create hidden rules that archive security alerts or forward messages outside the organization. Restrict external forwarding by default, alert on new rules, and teach users how to inspect them. For payment or bank-detail changes, require verification through a known secondary channel rather than trusting an email thread.

Control apps, mobile devices, and shared mailboxes

Third-party apps can receive broad access through delegated permissions. Maintain an approved-app list, review consent grants, and remove integrations that are no longer used. An app that can read all mail should receive the same scrutiny as a new administrator. Ask what data the app stores, how access is revoked, and how an incident would be reported.

Set minimum device protections for phones and laptops that hold mail: screen lock, supported operating system, encryption, remote lock or wipe where appropriate, and prompt reporting of loss. Use shared mailboxes or delegated roles for addresses such as billing@ and support@ instead of sharing passwords. Shared access should still be attributable to named users.

Plan retention, backup, and legal needs

Clarify what the provider retains, what a user can permanently delete, how long recovery is available, and whether a separate backup is needed. Retention is not the same as backup, and backup is not the same as an archive designed for legal or regulatory search. Choose controls based on business obligations rather than keeping everything indefinitely.

Document ownership for former-employee mail, shared records, and customer correspondence. During offboarding, preserve required material, transfer responsibilities, revoke sessions and app tokens, and remove forwarding. Avoid turning a departed user’s mailbox into a permanent catch-all that no one reviews.

Test incident response and provider exit

Run two short exercises. First, assume a user approved a phishing prompt and an attacker created a forwarding rule. Practice session revocation, password reset, rule review, app-token removal, message tracing, notification, and evidence preservation. Second, assume the provider account is unavailable. Confirm that administrators can reach support and access domain and recovery records without relying on the affected mailboxes.

Also plan migration. Know how to export messages, contacts, calendars, groups, aliases, and audit records. Record DNS changes and expected propagation. A provider exit plan is a security control because it reduces the pressure to accept unsafe conditions during an outage, dispute, or acquisition.

Quarterly hosted email review

A quarterly review can be short if records are current. Use a repeatable checklist and assign remediation dates.

  • Verify domain renewal, registrar and DNS administrators, locks, recovery contacts, and nameservers.
  • Review SPF, DKIM, DMARC reports, legitimate senders, and recent DNS changes.
  • Confirm administrator roles, emergency access, multi-factor methods, and security alert recipients.
  • Inspect external forwarding, inbox rules, app permissions, shared mailbox access, and inactive users.
  • Sample device compliance, recovery procedures, retention settings, backups, and offboarding records.
  • Run one phishing or account-recovery exercise and record the lessons.

Secure the bridge from scanned mail into email

Many mailbox systems send arrival notices or scan links through hosted email. Keep those notifications generic enough that a lock screen or forwarded alert does not expose document contents. Prefer authenticated links back to the controlled mailbox rather than attachments that create copies in every recipient inbox.

Use a dedicated role address for alerts, assign named mailbox access, and test escalation when the primary reviewer is absent. If an email rule routes notices into tickets or chat, document the integration and its permissions so a convenience bridge does not quietly widen access to sensitive physical correspondence.

Make email dependable, not merely available

Secure hosted email is a maintained system. Strong defaults help, but the organization must own the domain, control administrators, review delegated access, protect devices, and rehearse recovery. The checklist should produce evidence—settings, logs, owners, and test results—not only policy statements.

Connect email planning to the physical mail workflow as well. A scanned letter may enter the organization through email, and an email account may authorize forwarding or destruction of the original. Protecting both channels with named users, clear approvals, and tested recovery creates a more reliable communications system than treating them as unrelated inboxes.