Email Security Best Practices: Individual and Business

Email remains the primary attack surface for most individuals and organisations — it’s the delivery channel for phishing, the recovery path for account takeovers, the transmission medium for malware-laden attachments, and the identity layer that most services rely on for authentication. Despite this, most users and many small businesses haven’t systematically applied the email security best practices that would close these attack vectors. This fits into the wider topic we cover in our Complete Guide to Online Security and Privacy.

Email security isn’t a single action — it’s a layered set of controls addressing different attack vectors at different levels. Account security addresses credential-based account takeover. Authentication records (SPF, DKIM, DMARC) address domain impersonation. Content filtering addresses malicious delivery. Habits and awareness address the human-layer phishing that technical controls can’t fully prevent. Each layer is necessary; none is sufficient alone.

Account-level protection — the foundation

Email account compromise is the highest-consequence individual account compromise because email controls password reset for every other account. Treat the email account as the most sensitive credential in the digital identity.

Password: strong, unique, at least 16 characters, generated by a password manager. For the email account specifically, also memorise a passphrase (five to six random Diceware words) — because if the password manager becomes unavailable, the email account is how you recover it. Don’t trap yourself in that circular dependency.

Two-factor authentication: an authenticator app, not SMS (vulnerable to SIM swap). Together, a unique password and authenticator 2FA prevent credential stuffing and phishing from granting unauthorised access even when the correct password is known.

Recovery options deserve specific attention because they’re the backdoor around primary credentials. A recovery phone number susceptible to SIM swap undermines authenticator 2FA. A recovery email less secured than the primary is a weaker path. Best practice: use a VoIP number for recovery phone (not a mobile carrier number), secure the recovery email with the same strength as the primary, and keep backup codes for the 2FA in the password manager’s secure notes.

Connected app audit: most email accounts accumulate OAuth connections to third-party apps (calendar integrations, productivity tools, email managers) that retain access indefinitely. Any connected app with email read access can read all incoming email. Review and revoke: Google: myaccount.google.com → Security → Third-party apps with account access. Microsoft: account.microsoft.com → Privacy → Apps and services. Our guide on securing your email covers the full account hardening process including forwarding rule checks.

Domain authentication — SPF, DKIM, DMARC

For anyone who sends email from a custom domain — businesses, professionals, organisations — implementing email authentication records is among the most impactful email security best practices. These records prevent attackers from sending emails that appear to originate from your domain, which enables domain impersonation attacks and business email compromise.

SPF (Sender Policy Framework) is a DNS TXT record listing the mail servers authorised to send email on behalf of the domain. Any unlisted server is unauthorised. Without SPF, any server can send email claiming to be from any domain. Create a TXT record at the root domain: v=spf1 include:your-email-provider.com ~all (replacing the include with the authorised sending service’s mechanism). The ~all soft fail is a starting point; -all hard fail is the stricter setting once the SPF record is verified to be complete.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outbound email using a private key held by the sending server. Recipients verify the signature using the public key published in DNS. A valid DKIM signature confirms the email came from a server controlling the domain’s private key and that the content wasn’t modified in transit. DKIM setup is handled through the email provider’s domain authentication setup — Google Workspace, Microsoft 365, and most business email providers offer guided DKIM setup.

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the policy layer that tells receiving servers what to do when SPF or DKIM checks fail: deliver (p=none — monitoring only), quarantine to spam (p=quarantine), or reject (p=reject).

The correct rollout sequence:

1. Publish SPF record with ~all soft fail
2. Enable DKIM signing through the email provider
3. Publish DMARC with p=none and an address for reports: rua=mailto:[email protected]
4. Review DMARC reports for 2–4 weeks to identify all legitimate sending sources
5. Promote to p=quarantine after verifying no legitimate mail fails
6. Promote to p=reject for maximum domain impersonation protection

Organisations that skip the monitoring phase and deploy p=reject directly frequently discover undocumented legitimate sending sources (marketing tools, third-party service notifications) that break during enforcement. The monitoring phase exists specifically to prevent disrupting legitimate mail flow.

Content filtering and attachment handling

Even with strong account credentials and authentication records, malicious content arrives — phishing from unrelated domains, malware-laden attachments, and business email compromise attempts that pass all technical checks because they originate from legitimate-but-compromised sender accounts.

Enable the provider’s advanced threat protection: Google Workspace admins: Admin console → Apps → Google Workspace → Gmail → Safety → configure enhanced phishing and malware protection. Microsoft 365 admins: Microsoft Defender portal → Policies & rules → Anti-phishing → impersonation protection and Safe Attachments scanning. For personal Gmail and Outlook accounts, the provider’s default filtering catches a significant proportion of threats, but the enhanced settings available to administrators provide substantially higher detection rates.

Attachment handling rules:

• Never enable macros in any Office document received via email. Disable macros globally: File → Options → Trust Center → Trust Center Settings → Macro Settings → “Disable all macros except digitally signed macros”
• Treat PDF attachments from unexpected senders with the same skepticism as executable files — PDFs can contain malicious JavaScript
• Preview documents in the email client’s built-in preview rather than downloading when possible
• Use VirusTotal (virustotal.com) to scan unexpected attachments before opening — paste the file hash or upload directly
• Unexpected ZIP or password-protected archive files are a strong indicator of malware delivery — the password-protection bypasses automatic scanning

Email security operational habits

Technical controls address infrastructure. Operational habits address the human layer that technical controls can’t fully protect:

• Verify sender address before acting on any request. Check the actual email address (not just the display name — the display name can say anything). For financial or credential-related requests, verify through a separate channel before taking any action.
• Never click a link in an email to log into an account. Navigate directly to the service’s URL or use the bookmark. Phishing links create convincing replicas of login pages — the only reliable defence is not following email links to login forms.
• Be sceptical of urgency. “Your account will be suspended in 24 hours” is a manufactured pressure technique. Legitimate services don’t require immediate action that bypasses verification.
• Use email aliases for services that don’t need your real address. SimpleLogin or AnonAddy provide unique aliases per service — when one is breached, only that alias is compromised. Our guide on protecting personal data covers this in more detail.

Business email security — additional requirements

Organisations face email security threats at a different scale: business email compromise (BEC) targets finance teams with fraudulent payment requests; executives’ inboxes are spoofed to authorise transfers; former employees’ credentials may remain active.

Organisational email security best practices beyond individual account controls:

• Employee offboarding process includes email access revocation on the last working day — not after. Accounts of former employees that remain active are a common source of unauthorised access.
• Payment and transfer verification procedures: any email requesting a change to payment bank details, an urgent wire transfer, or a payroll change should be verified by phone (using a number from internal records, not from the email) before executing. This procedure doesn’t require employees to detect sophisticated BEC — it requires them to make a phone call regardless of how convincing the email seems.
• Email security awareness training: periodic phishing simulations that test and immediately debrief employees produce better recognition habits than any classroom training. Our guide on security awareness training covers the programme structure.
• Email encryption for sensitive content: S/MIME or PGP for encrypting message content in transit and at rest, beyond the TLS protection that email providers apply at the transport layer. Required for legal and healthcare communications where client confidentiality or HIPAA applies.

For DMARC aggregate report analysis tools that simplify the monitoring phase, MXToolbox’s DMARC report analyzer and similar services parse the XML reports that DMARC sends to the designated address and present them in readable form — significantly reducing the effort of identifying sending sources during the monitoring phase before enforcement.

Email encryption — when and how

Standard email is transmitted with TLS encryption between mail servers, but the content is stored on the provider’s servers in a form they can read. True end-to-end email encryption requires either of two approaches:

S/MIME (Secure/Multipurpose Internet Mail Extensions): uses digital certificates to sign and encrypt email content. Built into Outlook, Apple Mail, and most enterprise email clients. Requires both sender and recipient to have certificates — the sender needs the recipient’s public certificate to encrypt; the recipient uses their private key to decrypt. Certificate management adds friction; S/MIME is most practical in corporate environments where certificates are issued by IT.

PGP (Pretty Good Privacy) / OpenPGP: uses public-key cryptography through software like GPG4WIN (Windows), GPGTools (macOS), or OpenKeychain (Android). The sender encrypts with the recipient’s public key; the recipient decrypts with their private key. More widely used in technical communities, journalism, and security-sensitive contexts. The challenge: both parties need to have the tools installed and have exchanged public keys in advance.

ProtonMail and Tutanota: provide end-to-end encrypted email without either party needing to manage keys manually. Email between two ProtonMail users (or two Tutanota users) is automatically E2E encrypted. Email to external addresses can be sent encrypted (the recipient receives a link to view the message on a secure web page with a password provided separately). The trade-off: both services require a new email address rather than encrypting an existing Gmail or Outlook account.

For most individuals and small businesses, the account security, SPF/DKIM/DMARC configuration, content filtering, and operational habits covered in this guide address the practical email security risks they actually face. Email encryption becomes relevant when the specific threat model includes regulatory requirements, legal confidentiality obligations, or targeted surveillance by sophisticated actors — rather than for routine email security best practices applied at scale. See also Secure Password Reset for a related case.

Email security by account type — what matters most

The email security best practices in this guide scale from the individual user spending 15 minutes hardening a personal Gmail account to the IT administrator deploying organisation-wide DMARC enforcement. In both cases, the principle is the same: address the account layer first (credentials, 2FA, recovery), then the domain authentication layer (SPF, DKIM, DMARC for custom domains), then the content layer (filtering, attachment handling), then the habit layer. Each layer addresses what the others leave open — and the combination closes the email attack surface far more completely than any single measure can. You might also run into Cloud Security Best Practices.