Secure Email for Business: Minimum Security Settings (2026)

Your email inbox is not just where work happens — it's the master key to everything else. Reset your bank password? Email. Reset your CRM? Email. Recover your cloud infrastructure account? Email. If an attacker controls one inbox, they control the whole company.

The bad news: most businesses running business email have at least half of the settings below misconfigured or missing entirely. The good news: fixing them doesn't require a security team or a $50,000 enterprise contract. It requires about two hours and the willingness to actually do it.

This is the baseline. Not the aspirational future state — the minimum. If you can't check every box on this list, you're exposed.

How Businesses Actually Get Compromised

Forget nation-state actors and zero-day exploits. Unless you're building something classified, nobody's burning a sophisticated attack on you. The three risks that account for 90% of SMB email incidents are depressingly mundane.

Credential stuffing: Attackers buy leaked password databases — LinkedIn 2012, Adobe 2013, any of the hundred breaches since — and run scripts against your mail server. If your password showed up in any of those dumps and you haven't changed it, they're in. No hacking required.

Silent forwarding rules: Once inside, a smart attacker doesn't ransack the place. They set up a quiet forwarding rule: "If subject contains 'invoice' or 'wire transfer,' CC attacker@gmail.com and mark as read." Then they watch for months. By the time you notice, they've already intercepted a payment.

Spoofing: Someone emails your accountant from ceo@yourcompany.com asking for an urgent wire. It looks legitimate. If your DNS isn't configured correctly, the receiving mail server has no way to know the email is fake — and it might not even flag it.

All three of these are preventable. Here's how.

Secure Email for Business: Account Security Baseline

This is your perimeter. If this layer fails, no amount of DNS configuration saves you.

1. Enforce Phishing-Resistant MFA — No Exceptions

Passwords are not security. They're identification. A password alone tells you someone knows a string of characters, not that they're actually your employee. Multi-factor authentication is what adds actual verification.

Use an authenticator app (Google Authenticator, Microsoft Authenticator, Authy) or a hardware key (YubiKey). Either is fine. What's not fine: SMS-based 2FA as your primary method. It works, but it's vulnerable to SIM-swapping attacks where an attacker social-engineers your carrier into transferring your number to their device. Use it as a fallback only.

Enforce MFA at the admin level. Don't make it optional. One user who skips it is your weakest link.

TrekMail supports 2FA on all admin accounts — enable it under account security settings. See the full walkthrough in the Two-Factor Authentication guide.

2. Kill Legacy Authentication Immediately

This is the most overlooked vulnerability in 2026. "Legacy authentication" means protocols like basic SMTP AUTH that don't support modern MFA flows. They just ask for a username and password — that's it.

Here's the problem: even if you've enabled 2FA on every account, an attacker can bypass it entirely by connecting via a legacy protocol. Your shiny new MFA setup is irrelevant to a client that never asks for a second factor.

Block legacy auth at the tenant level. The only exception: if you have a printer, scanner, or legacy device that needs to send email, isolate it. Give it a dedicated service account with a long, complex, rotated password. Do not leave general user accounts exposed to legacy protocols just because the copier needs to scan-to-email.

Note: TrekMail intentionally does not support POP3 — a deliberate architectural decision to prevent local-only email storage that can't be recovered if a device is lost. IMAP is supported and required for all client connections.

3. No Shared Credentials

The info@company.com account shared by three people who text each other the password is not a minor inconvenience — it's a security incident waiting to happen. When someone leaves, do you change it? Usually not. Do you know who logged in last? No.

The fix is delegated access or shared mailboxes: each user authenticates with their own credentials and gets access to the shared folder. Full audit trail. Revoke access individually. No password sharing required.

The per-user pricing model actively works against this. When every seat costs $15–$30/month, teams start sharing credentials to cut costs. TrekMail's flat-rate model — storage-pooled, not seat-counted — means you pay the same whether you have 5 users or 50. Give everyone their own account. Stop sharing passwords to save $6/month.

Admin & Access Control

The Break-Glass Account

If your phone falls in the ocean, or your primary identity provider has an outage, you need a way back in that doesn't depend on the thing that just failed. Create one cloud-only recovery admin account — something like admin-recovery@yourdomain.com — with a 30-character random password. Write it on paper. Put the paper in a physical safe.

Then set up an alert: if this account ever logs in, every other admin gets notified immediately. It should almost never be used. If it logs in unexpectedly, something is very wrong.

Separation of Duties

Your daily email account — the one you use to browse the web, click links, and read newsletters — should not be a global admin. If you click a phishing link while logged in as a super admin, you just handed an attacker the keys to everything.

Create a separate admin account. Only log into it when you need to change settings. For everything else, operate as a standard user. This is not paranoia — it's basic operational hygiene that any sysadmin would tell you on day one.

Secure Email for Business: Mail Authenticity Baseline (SPF, DKIM, DMARC)

These three DNS records are the technical plumbing that stops spoofing. As of 2024, Google and Yahoo require them for bulk senders, and they're increasingly expected for all business email. If you haven't configured them, do it now.

For a deeper dive on each layer, the email domain setup guide covers the full implementation sequence.

SPF — The Approved Sender List

Sender Policy Framework is a DNS TXT record that explicitly lists which IP addresses are allowed to send email for your domain. Any server not on the list fails the check.

v=spf1 include:_spf.trekmail.net -all

Two things to get right here:

First, end with -all (hard fail), not ~all (soft fail). Soft fail tells the world "I'm not sure who sends my email, so maybe let it through." That's not a security policy — it's an invitation. Use hard fail once you've confirmed your legitimate senders.

Second, SPF has a 10 DNS lookup limit. If you include Google Workspace, Mailchimp, Salesforce, and Zendesk in the same record, you'll likely exceed it, and SPF will break silently. Use an SPF flattening tool if you're juggling multiple sending services.

DKIM — The Tamper-Evident Seal

DomainKeys Identified Mail adds a cryptographic signature to every outgoing message. Your mail server (holding the private key) signs the email; the recipient's server verifies it against the public key you've published in DNS.

Why you need it even if you have SPF: forwarding breaks SPF. When a message is forwarded, the sending IP changes, so SPF fails. DKIM travels with the message headers and survives forwarding intact. You need both.

TrekMail manages DKIM key generation and rotation automatically on paid plans. The public key gets published to your DNS, and every outgoing message is signed — nothing to configure manually. The Required DNS Records guide shows exactly what gets added and where.

DMARC — The Policy Enforcement Layer

DMARC tells receiving mail servers what to do when SPF or DKIM fails. It also sends you reports about who's sending as your domain — which is how you find out that some forgotten marketing tool is still sending on your behalf.

Start in monitoring mode. Don't skip this phase.

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

This record says: "Tell me who's sending as me, but don't block anything yet." Collect two to four weeks of reports. Audit every sending source. Only after you've confirmed that all legitimate senders pass authentication do you move to enforcement:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

Then eventually:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

If you jump straight to p=reject without auditing first, you will block your own invoices, your own marketing emails, and anything else that isn't perfectly configured. Move slowly. The DMARC documentation covers the full phase-in process.

Forwarding & Catch-All Safety

Block Automatic External Forwarding

This one rule prevents the silent exfiltration attack described earlier. Configure your mail server to prohibit automatic forwarding to external domains.

There is almost no legitimate business reason for an employee to auto-forward all their corporate email to a personal Gmail account. If someone needs access from multiple places, give them IMAP access from multiple devices — that's what IMAP is for. Forwarding rules that silently copy everything to an outside address are a data leak by design.

The Catch-All Problem

A catch-all address accepts anything sent to any address at your domain, even addresses that don't exist. Sounds convenient. The reality: spammers love it. They hammer your domain with dictionary attacks — a@yourdomain.com, aa@yourdomain.com, ab@yourdomain.com — and if you reply to any of them (or if one is a spam trap), your domain gets flagged.

Disable catch-all unless you have a specific operational reason for it. If you do need it, monitor it daily and filter aggressively. TrekMail's Pro plan supports external catch-all routing with built-in spam filtering — but the catch-all setup guide is clear that it requires active management, not set-and-forget.

The 12-Point Security Baseline Checklist

If you can check every box below, you're more secure than most organizations — including a lot of companies with dedicated IT teams who simply never got around to it.

Print this. Put it in your onboarding runbook. Run through it every six months.

Why Per-User Pricing Is a Security Problem

This deserves to be said plainly: per-user pricing — the standard $6–$30/seat model — creates direct financial pressure to cut security corners. When every user costs money, teams share the info@ password instead of creating individual accounts. Contractors don't get their own credentials. Ex-employees stay active because migration feels expensive.

Secure email for business requires isolation. Every human gets their own identity. Every service bot gets its own account. There's no audit trail without that.

TrekMail's flat-rate model charges for a storage pool, not a headcount. Whether you're running five mailboxes or five hundred, the price doesn't change based on seats. That means you can give everyone — employees, contractors, service accounts — their own isolated credentials without the budget conversation every time someone new joins.

Plans start at $3.50/month for up to 50 domains and 100 users per domain. The math works out to well under a dollar per user if you're running a normal-sized team. There's a 14-day free trial on all paid plans — card required.

What to Do Next

Run through the checklist above. Be honest about what's missing. Most businesses find at least three or four gaps on the first pass — that's normal, and it's fixable.

The highest-impact moves, in order of effort versus impact:

1. Enable MFA everywhere. Do it today.
2. Audit your DMARC reports if you have them; start collecting them if you don't.
3. Verify your SPF ends in -all and isn't over the lookup limit.
4. Block external auto-forwarding at the server level.
5. Create the break-glass account before you need it.

Security isn't about buying a magic product. It's about setting the baseline correctly and not drifting from it. Configure your DNS, enforce your MFA, and stop sharing passwords. That combination blocks the vast majority of how businesses actually get hit.

If you're setting this up fresh, TrekMail handles DKIM and SPF configuration automatically through the DNS wizard, blocks POP3 by design, and gives you the flat-rate model that makes proper user isolation financially sane. Try it free for 14 days.