A Business Email Security Baseline for Small Teams

Business email is not protected by one setting. A small team may have domain authentication but weak account recovery, strong mailbox authentication but no safe reporting path, or a sensible payment process but no surviving administrator. Calling any of those situations “secure email” hides the gaps that still matter.

This guide creates a baseline register for those gaps. It records what should exist, who owns it, what evidence is available, which dedicated guide owns the next decision, and when the team must stop and seek qualified help. It does not inspect or change a live system.

What this baseline covers

Keep three operational layers separate throughout the register:

• Domain authentication and delivery: the categories of business domains, legitimate sending dependencies, and evidence for SPF, DKIM, and DMARC. Detailed inventory, alignment analysis, reporting, policy progression, and live DNS work belong to the dedicated DMARC rollout guide.
• Mailbox and account protection: accountable account ownership, administrative separation, authentication-decision references, recovery readiness, and continuity. MFA-method choice belongs to the dedicated MFA guide; everyday/admin separation belongs to the dedicated administrator-account guide.
• Human and business process: safe reporting, independent verification of sensitive requests, escalation, continuity, and pre-incident preparation. Dedicated guides own phishing reporting, payment-change verification, and mailbox-compromise preparation.

A strong state in one layer cannot compensate for an Unknown, Blocked, Deferred, or Exception state in another. Do not combine the layers into a score, maturity rating, or claim that the organization is protected.

What the sources establish—and what they do not

FTC small-business guidance describes SPF, DKIM, and DMARC as distinct email-authentication functions and warns that configuration takes expertise if legitimate mail is not to be blocked. NCSC email-security guidance treats anti-spoofing and transport protection as related but distinct controls. NIST small-business phishing guidance describes layered measures that include filtering, email authentication, MFA, staff reporting, and incident planning.

Those sources support a layered approach. They do not prescribe the seven stages, register fields, workflow states, review cadence, or completion rule below. Those are PlainFort editorial judgment for a small-team operating record. They are not certification, compliance, a regulated assurance level, a universal minimum baseline, or a guarantee against phishing, compromise, delivery failure, or fraud.

Keep SPF, DKIM, and DMARC at baseline depth

At this level, the useful distinction is conceptual:

• SPF concerns which sending systems are authorized for a domain.
• DKIM attaches a signature that can support verification of a message and its handling in transit.
• DMARC evaluates alignment with the visible sender identity and provides policy and reporting mechanisms built on SPF and DKIM results.

Their presence does not prove correct configuration, complete sender coverage, legitimate delivery, mailbox integrity, or message authenticity. Unknown sending services, forwarding, inherited DNS, third-party platforms, and legacy routing can change what the evidence means.

Do not use this baseline to look up, generate, copy, or change a DNS record. Do not infer an enforcement policy, an observation period, or a rollout sequence. Route sender inventory, alignment uncertainty, reporting ownership, rollback readiness, and any proposed live change to EP-12, Plan a DMARC Rollout Without Breaking Legitimate Mail, and qualified review.

Build the baseline in seven stages

The sequence below is PlainFort editorial judgment. It keeps unsafe or specialist work outside the baseline rather than making it look complete.

1. Set the boundary and owner

Define which business-email capabilities are in scope using category labels only: business correspondence, transactional sending, customer support, internal collaboration, privileged administration, and other material workflows. Name an internally accountable owner, responsible operator, real backup, evidence location, and escalation authority.

A provider or contractor may operate a control or supply evidence. That does not make the provider the team’s implicit accountable owner. Naming an owner also does not prove competence, capacity, independence, monitoring, or authority.

2. Map non-sensitive dependencies

Record inert references for the categories of domains, mailbox use, sending services, critical workflows, provider administration, recovery, and legacy or unknown dependencies. Do not copy domains, addresses, identifiers, messages, configuration, or evidence content into the register.

Use a reference such as Approved evidence location — sensitive content not copied. If the team cannot identify who controls a dependency without inspecting a live system, record Unknown — follow up rather than guessing.

3. Separate the three layers

Assign every baseline row to domain authentication and delivery, mailbox and account protection, or human and business process. If one item appears to cross layers, split it or record explicit handoffs. For example, the domain layer may record that an authentication decision exists, while the mailbox layer separately records an MFA-decision reference.

This separation prevents a domain-authentication state from being mistaken for mailbox security and prevents awareness or process controls from being mistaken for technical validation.

4. Record evidence and uncertainty

For each row, record what evidence type exists, where an authorized reviewer can find it, and whether it was actually inspected. Do not treat a provider label, a reported state, or a completed checkbox as proof that a control works.

Use these workflow states:

• Documented — evidence referenced
• Reported — evidence not inspected
• Unknown — follow up
• Blocked — qualified help required
• Deferred — owner and review date required
• Exception — scope, reason, owner, expiry, and residual risk required
• Dedicated-guide decision required
• Not applicable — rationale and reviewer required

These labels are not security scores.

5. Route dedicated decisions

Keep each handoff narrow:

• EP-12 owns sender inventory detail, SPF/DKIM dependencies, alignment uncertainty, DMARC reporting, staged policy planning, authorization, and rollback readiness.
• EP-13 owns safe reporting, acknowledgement, triage, escalation, feedback, and learning. EP-11 does not ask a reporter to decide whether a message is malicious.
• EP-14 owns the independent verification and authorization process for payment-detail changes. EP-11 does not perform a callback or verify a real request.
• EP-15 owns pre-incident preparation for suspected mailbox compromise. EP-11 does not investigate, contain, recover, or determine incident scope.
• AA-07 owns MFA-method choice, fallback, and method-specific recovery trade-offs.
• AA-08 owns everyday/admin separation, privilege boundaries, elevation, and exceptions.

EP-11 records whether the decision or workflow is available and who owns the handoff. It does not reproduce the procedure.

6. Test the handoffs on paper

Without touching a live system, ask whether each handoff has an owner, real backup, authorized decision-maker, non-sensitive evidence reference, safe contact category, continuity dependency, and stop condition. A named backup is not real coverage if that person lacks access, time, authority, or a safe route to act.

Stop before any live DNS, email, mailbox, account, authentication, recovery, payment, or incident action. Also stop when the last administrator or critical mail flow may be affected; authority or rollback is unclear; evidence may be sensitive; or legal, privacy, contractual, records, fraud, or incident questions arise.

7. Close with residual risk and review

A row can close only when all fields contain a truthful value or a visible unknown, blocked, deferred, or exception state; ownership and escalation exist; evidence is referenced without being copied; residual risk remains visible; and a next review trigger is recorded.

Completion means the record is usable for coordination. It does not prove correct configuration, control effectiveness, legitimate delivery, mailbox integrity, message authenticity, reliable human judgment, compliance, or absence of compromise or fraud.

The 16-field email-control register

Use one vertical record per bounded baseline area:

1. Baseline area: A short category, not a provider or account identifier.
2. Bounded outcome: What the row is intended to support, without claiming protection.
3. Operational layer: Domain/delivery, mailbox/account, or human/business process.
4. Applicability and rationale: Why the row applies—or why it does not.
5. Non-sensitive system or process reference: An inert label only.
6. Internally accountable owner: The internal role answerable for the bounded outcome.
7. Responsible operator: The internal or external role that performs authorized work.
8. Backup or continuity coverage: Who or what preserves the capability if the primary path is unavailable.
9. Current operational state: One of the non-scoring workflow states above.
10. Primary-source or authoritative-documentation reference: The evidence authority relevant to the row.
11. Evidence type: Policy, approved record, provider documentation, review note, or another non-sensitive category.
12. Non-sensitive evidence-location reference: Where an authorized reviewer can inspect evidence without copying it here.
13. Dedicated-guide dependency or handoff: EP-12, EP-13, EP-14, EP-15, AA-07, AA-08, or another approved boundary.
14. Exception and residual risk: The gap, reason, owner, expiry or exit condition, and remaining exposure.
15. Escalation or stop result: What requires qualified help or prevents safe progression.
16. Completion evidence and next review trigger: What supports closure and what event or date reopens the row.

Keep the register vertical. A wide table, dashboard, heat map, maturity model, or combined score would hide uncertainty and perform poorly for a small team reviewing the record on a narrow screen.

Worked example

Fictional example — do not copy as a completed email-security record

This Example Co. record uses category labels only. It contains no real or plausible domain, address, account, message, DNS value, payment detail, incident fact, credential, or configuration.

1. Baseline area: Business correspondence coverage.
2. Bounded outcome: Maintain visible ownership and handoffs across the three email-security layers.
3. Operational layer: Cross-layer coordination; each underlying control remains in its own layer.
4. Applicability and rationale: Applicable because business correspondence is operationally material.
5. Non-sensitive system or process reference: Approved business-email inventory — content not copied.
6. Internally accountable owner: Operations owner.
7. Responsible operator: Approved service-operations role; provider execution does not transfer accountability.
8. Backup or continuity coverage: Blocked — qualified help required; backup authority has not been confirmed.
9. Current operational state: Unknown — follow up for one legacy sending dependency.
10. Primary-source or authoritative-documentation reference: Accepted organizational email-security guidance and current approved provider documentation location.
11. Evidence type: Review record and provider-documentation reference; configuration is not copied.
12. Non-sensitive evidence-location reference: Approved evidence location — sensitive content not copied.
13. Dedicated-guide dependency or handoff: Dedicated-guide decision required for EP-12; EP-13 reporting ownership is recorded separately.
14. Exception and residual risk: Legacy dependency remains unknown; domain evidence cannot compensate for unconfirmed mailbox recovery and backup coverage.
15. Escalation or stop result: Stop before DNS or account changes; qualified review is required because authority and delivery impact are unclear.
16. Completion evidence and next review trigger: Owner acknowledgement plus inspected non-sensitive references; reopen when the legacy dependency is identified, provider guidance changes, or ownership changes.

The example is not complete merely because all 16 labels are populated. Its blocked backup and unknown dependency remain operational gaps.

Review triggers

Reopen affected rows when:

• a domain, sending service, mailbox category, provider, administrator, or critical workflow changes;
• official guidance or approved provider documentation changes;
• a dedicated EP or AA decision is completed or materially revised;
• evidence expires, becomes unavailable, or contradicts the recorded state;
• a reporting, delivery, authentication, recovery, payment, or incident failure reveals a gap;
• an exception reaches its review or expiry condition;
• ownership, backup, authority, or continuity changes.

Where this guide stops

This baseline organizes decisions; it does not execute them. Do not use it to inspect or change DNS, send or process email, access a mailbox or account, configure MFA, test a provider, verify a payment, investigate an incident, or collect evidence content.

Seek qualified IT, email-delivery, security, legal, privacy, contractual, records, fraud, or incident-response help when the issue exceeds the recorded authority or when a live action could interrupt mail, remove the last viable administrator, expose sensitive evidence, affect money, or alter an incident.