Skip to content
Email & Office

Protecting Your Business: Best Practices for Securing Office Email

An office professional authenticating access to business email.

Business email security best practices should protect more than the inbox. Email is often the recovery route for other business accounts, the place where invoices arrive and the channel customers trust. A compromised mailbox can therefore affect payments, files and access to other services.

Start with stronger sign-in controls, clear payment-verification rules and an account recovery plan. Then review your domain authentication, connected applications and staff access. No single setting stops every threat, but a small team can make meaningful improvements by assigning these tasks and checking that they work.

Use unique passwords and protect recovery access

Give each person their own account. Use a long, unique password for each account that needs one, generated and stored in an approved password manager. Protect the password manager with multifactor authentication as well. NIST recommends password managers to help people manage strong credentials.

Avoid reusing an email password on shopping sites, supplier portals or personal accounts. A rule requiring eight characters and a mixture of symbols is not a complete security strategy. Length and uniqueness matter, but passwords can still be stolen through phishing or malware.

Record who can recover your email service, domain registrar and DNS accounts. Keep recovery information current and recovery codes somewhere protected that remains accessible if the mailbox is unavailable. Do not store the only recovery instructions inside the account they are meant to recover.

For shared addresses such as sales or accounts, use the provider’s supported delegation, shared-mailbox or group features where available. Confirm how access is granted and removed rather than circulating one shared password.

Enable MFA and prefer phishing-resistant options

Multifactor authentication adds a check beyond a password. Where your provider supports them, prefer phishing-resistant methods such as FIDO-based security keys or passkeys. An authenticator code or approval notification can improve protection, but those methods do not all resist phishing in the same way. CISA explains the differences between MFA options.

Start with administrator accounts and then cover every mailbox that supports MFA. Test enrolment, a replacement device and recovery before assuming the rollout is complete. Staff should report unexpected prompts and should never approve a request simply because someone claiming to be support tells them to.

Ask the administrator to review legacy sign-in methods and app passwords. Some older clients or integrations may not use the protection available in modern sign-in. Identify dependencies before disabling them, then replace or restrict them using the provider’s current instructions. Keep everyday email access separate from privileged administration where the platform supports that separation.

Authenticate the services sending from your domain

Your mailbox password protects access to an account. Domain email authentication addresses a different problem: helping receiving systems assess whether a message is authorized to use your domain.

  • SPF identifies the servers permitted to send for the domain used in the message’s envelope sender.
  • DKIM adds a signature that receiving servers can verify, helping detect changes to signed message content and headers.
  • DMARC connects authentication to the visible From domain through alignment, with a published policy and reporting options.

Inventory all legitimate senders first: employee mail, website forms, invoicing software, newsletters and help-desk tools. Follow their documented DNS instructions and test each stream. Google’s sender guidance explains authentication requirements for messages sent to personal Gmail accounts, including additional requirements for bulk senders.

Have your administrator review reports and alignment before moving a DMARC policy toward enforcement. A monitoring policy does not ask recipients to reject failing messages. A rushed restrictive policy can also disrupt legitimate mail if a sender has been missed. Authentication does not make a message’s contents trustworthy, and it does not stop mail sent from an already compromised authorized account or a similar-looking domain.

Understand encryption and share sensitive information carefully

Use the provider’s supported secure connections for webmail and mail clients. Transport encryption protects a connection in transit; it is not the same as end-to-end message encryption and does not prevent the wrong recipient from reading an email. The IETF’s email transport guidance makes that distinction.

For sensitive documents, use an approved sharing method with named recipients, appropriate permissions and an expiry or revocation option where supported. Check the recipient before sending and keep confidential details out of unnecessary copies and subject lines. Do not email passwords or recovery codes as a routine handover method.

If your business needs message-level encryption, retention controls or data loss prevention, check the actual provider and edition. These capabilities are not automatically included in every business email plan. Confirm that recipients can use the chosen method and that it meets the requirements for the information involved.

Make suspicious requests easy to verify and report

Give staff a simple rule for high-impact requests: verify through a trusted channel before changing payment details, sending sensitive records or granting access. Use a phone number or contact method already held in your records, not one supplied in the suspicious message. A familiar display name or an existing email thread is not sufficient proof.

For example, if a supplier appears to request a new bank account, the accounts team should pause the change and verify it independently. This is a hypothetical workflow, not a claim about a particular customer incident. Agree who approves the change and where the verification is recorded.

Provide a known reporting address or supported reporting button and a separate contact route if email itself is unavailable. Encourage prompt reports, including when someone has already clicked or entered a password. Reporting is more useful than blaming the person who encountered the message.

Teach staff to open the service from a known bookmark when a message demands an urgent sign-in. A polished design, accurate grammar or a QR code does not establish legitimacy. Keep examples relevant to your business, such as invoices, shared documents and account-renewal notices.

Review devices, mailbox rules and staff access

Keep supported operating systems, browsers and email applications updated. Use device screen locks and the security tools appropriate to your business. Review access when someone changes roles or leaves, including mobile devices, delegated mailboxes and connected applications.

Check unexpected forwarding rules, unfamiliar delegates and third-party app permissions. These can expose messages even after the obvious sign-in problem has been addressed. Restrict automatic external forwarding where it is not needed, using settings available in your service.

Test your retention and recovery arrangements. Synchronizing a mailbox across devices does not by itself prove you can recover from deletion or account compromise. Confirm what the provider retains, what any backup covers and who can perform a restore. For a broader platform comparison, see our business email solutions guide.

Respond promptly to suspected account compromise

Contact your email administrator or provider using a trusted route. If financial instructions may have been altered, alert the person responsible for payments immediately and use established bank or payment-provider contacts. Preserve relevant messages, timestamps and logs for investigation without continuing to use a potentially compromised session.

The administrator should follow the provider’s response procedure. Typical tasks include containing access, resetting credentials from a trusted device, revoking active sessions, checking recovery and MFA registrations, and removing unauthorized forwarding or connected-app access. Microsoft’s compromised-account guidance illustrates why a password reset alone is not the whole response.

Identify affected messages and recipients, review other accounts that may have been reset through the mailbox, and monitor for continuing access. Have the responsible incident or privacy lead assess any notification duties. Restore normal use only after the cause and persistence routes have been addressed; do not assume that regaining sign-in means the incident is over.

A practical email security review checklist

  • Each person has an individual account and an approved way to manage passwords.
  • MFA is enabled where supported, with stronger methods prioritized and recovery tested.
  • Administrator access, connected apps and external forwarding are reviewed.
  • Legitimate sending services are documented and domain authentication is checked.
  • Payment changes and sensitive requests require independent verification.
  • Staff know how to report suspicious mail, even if their mailbox is unavailable.
  • Departure procedures, retention and restore arrangements have named owners.
  • The response contact list is available outside the email system.

Review this list after a provider change, a new sending integration or an incident, and on a regular schedule suited to the business. Confirm the work against your actual email service rather than treating the checklist as proof of protection.

Frequently asked questions

Does MFA stop every email attack?

No. MFA strengthens sign-in, especially with phishing-resistant methods, but it does not replace device security, safe payment processes or review of connected applications and recovery access.

Do SPF, DKIM and DMARC encrypt email?

No. They support sender authentication, alignment and policy handling. Transport and message encryption serve different purposes.

Is a password reset enough after a mailbox is compromised?

Not necessarily. Sessions, forwarding rules, app permissions and recovery settings may also require attention. Follow the provider’s incident procedure and review the scope of exposure.

Should everyone use the same login for a shared inbox?

Prefer supported delegation or shared-mailbox features with individual access. That makes it easier to remove access and understand who has permission, while avoiding distribution of a common password.

About the author

interpro

More articles by this author →

Continue exploring