Email is a core business system. It carries payment requests, password resets, contracts, and customer correspondence. A working inbox can still have incomplete controls and no one responsible for reviewing them.
That gap appears in organizations of every size. A solo founder may be managing the domain, finance inbox, and new applications between customer calls. A startup may have several teams sending mail through different tools, with no shared inventory. A larger organization may have security, IT, finance, and communications teams that each own part of the system without a single operating view.
Dashboard scores are indicators. The owner should record decisions and evidence that the controls work.
Assign ownership first
Assign one accountable person for the email security program. That person does not need to perform every task. They need authority to keep the inventory current, coordinate changes, collect evidence, and escalate problems.
ZSoftly recommends treating email security as an operating responsibility, with a named owner and a recurring review cadence. A solo founder can own the program, with a calendar block and an external technical adviser when needed. For a startup, the accountable owner may be an engineering or IT lead. For a larger organization, security can own policy and assurance while messaging or identity teams operate the service. Write down the boundaries either way.
The owner should be able to answer a short set of questions without searching through old tickets:
- Who administers the email domain and its DNS records?
- Which accounts have administrative access, and who can recover them?
- Which systems send messages using the organization’s domains?
- Who reviews suspicious messages and how quickly?
- Who approves changes to payment instructions, forwarding, and group membership?
- When did the team last prove that the controls still work?
The answers give the team a documented process for running email security.
Protect administrative access and domain control
The domain registrar and DNS are part of the email security boundary. An attacker who controls DNS can redirect mail, alter sender-authentication records, or interfere with domain recovery. Treat registrar and DNS access as privileged access: require strong multi-factor authentication, limit administrative roles, keep recovery contacts current, and alert on material changes.
Apply the same discipline to email administration. Give administrators separate, named accounts where the system supports them. Keep the administrator group small. Remove access promptly when a person changes roles or leaves. Review active sessions, delegated applications, forwarding rules, and recovery methods during offboarding. Require MFA for every employee and administrator account, using phishing-resistant methods where supported. The Canadian Centre for Cyber Security recommends both measures.
Recovery deserves the same attention as sign-in. Decide who can regain control of a locked account, what evidence they need, and how the organization will respond if the primary administrator is unavailable. Test this process. A recovery path that has never been tested is an assumption.
Know every system that sends as you
Most organizations send mail from more places than their people realize. Employees send ordinary mail. Applications send password resets, invoices, alerts, and invitations. Support, marketing, finance, recruiting, and customer portals may each send from a different system. A new service can become a sender with one integration change.
Maintain a sender inventory with the owning team, sending domain or subdomain, message type, authentication method, and a contact for changes. Include low-volume systems. A forgotten invoice tool can matter as much as the primary mailbox when a recipient sees a message bearing your domain.
This inventory makes sender authentication manageable. SPF authorizes the hosts permitted to use an envelope-sender, also called return-path, domain in email sending, as defined in RFC 7208. It does not authenticate the visible From domain on its own. DKIM adds a cryptographic signature associated with a signing domain and publishes the public key in DNS, as described in RFC 6376. They solve different parts of the problem, and each needs review when a sender is added or retired.
Engineers implementing these records on ZCP can follow our email authentication DNS tutorial. It covers dedicated DKIM and DMARC records through the CLI or Terraform, plus checks for handling SPF safely. The technical work should follow the sender inventory and policy decisions described here.
DMARC connects the visible From domain to authenticated identifiers and publishes a handling preference for messages that fail validation. Under RFC 9989, which supersedes RFC 7489, a message can pass when at least one authenticated identifier aligns with the author domain. It does not require both SPF and DKIM to align on every message. Aggregate feedback, specified in RFC 9990, helps domain owners find legitimate sources before they enforce a policy.
That detail shapes the rollout. Start by monitoring reports, reconcile them against the sender inventory, and fix legitimate systems that fail. Move next to quarantine, then consider rejection only after validating legitimate senders and business mail flows. Choose alignment settings after testing legitimate mail flows. Forwarding, mailing lists, and delegated senders can change authentication results, so strict alignment and blanket quarantine policies need evidence before deployment. Review DMARC reports daily while changing enforcement, and set a continuing review schedule afterward. The National Cyber Security Centre’s email security guidance also treats SPF, DKIM, and DMARC as a set of complementary controls.
Separate domain authentication from impersonation defence
Domain authentication helps a recipient evaluate whether a message is authorized to use your domain. It does not cover every message that tries to exploit trust in your people.
Attackers can use a similar domain, a familiar display name, or a copied signature. They can send from a legitimate external account and still make a request that looks urgent or authoritative. This is why impersonation protection needs its own policy. Define which executives, finance staff, shared mailboxes, and sensitive teams are protected. Maintain their approved names, aliases, and legitimate sending addresses. Add this review to onboarding, role changes, and offboarding.
Inbound filtering should support that policy. Decide how the organization handles messages that fail authentication checks, appear on block lists, or match impersonation signals. Quarantine can be useful when a named person reviews it and has a documented release process. It can create a silent business failure when nobody reviews it. Keep exceptions narrow, approved, dated, and reviewed. A trusted-sender entry should never become a permanent way to avoid investigating a delivery problem.
The human control matters as much as the technical one. Payment details, bank instructions, payroll changes, and requests for sensitive records should be verified through a separate, previously known channel. The Internet Crime Complaint Center advises secondary channels for changes in account information. The verification contact must come from an established record, not the message asking for the change.
Make sharing and encryption deliberate
Teams often create groups quickly for a project, a client, or a department. A group can also become an unnoticed path for sending internal information outside the organization. Separate organization groups from personal groups. Decide who can create each type, whether external members require approval, and how membership is reviewed. For sensitive groups, limit owners and record the business reason for external access.
End-to-end message encryption deserves the same deliberate approach. S/MIME can provide message signing and encryption, and NIST includes it among the technologies that support trustworthy email. It also requires certificate lifecycle management, secure key recovery, recipient support, and clear rules for handling encrypted records. NIST SP 800-177 Rev. 1 explains these mechanisms in the broader email security stack. Turning on a feature, or relying on transport encryption between mail systems, does not automatically provide end-to-end content encryption.
The same care applies to AI and API integrations that read, summarize, draft, or classify messages. They are optional integrations, not an inherent part of email security. Before enabling one, decide what email content will leave the mailbox environment, which users can invoke it, how API keys are stored and rotated, what logs exist, what data handling terms apply, and who approves the cost.
Operate the controls you have chosen
Email security degrades through normal business change. A sender is added. A team member receives a new alias. A contractor leaves. A mailbox rule is created for convenience. A group gains an external member. A domain renewal notice reaches an unmonitored account.
Set a review cadence that matches your size and rate of change. A solo founder may need a monthly check and a deeper quarterly review. A startup can add email security checks to its access and change-management rhythm. A security team can collect the same evidence through a defined control calendar. The cadence matters less than completing it and recording what changed.
Review quarantined mail promptly, ideally each working day, so legitimate business mail does not remain held. Review sign-in alerts, forwarding changes, and policy changes as they occur. Use monthly or quarterly reviews for the following:
- Administrator access, MFA coverage, and delegated applications.
- The sender inventory, authentication results, and DMARC reports.
- Quarantine exceptions, group owners, and external group members.
- Recent departures, recovery contacts, and retention or recovery requirements.
- Recovery and incident exercises, including a test of the documented response path.
Email security changes with the business. Keep current evidence of the risks, and make sure the team knows who acts when something changes.
Schedule the first review now. Assign the accountable owner, list every legitimate sender, confirm who controls the domain, and test the controls that would matter during an urgent payment request or account recovery. If your team needs help planning or validating the work, start a scoping conversation.