Self-hosted email for CIS Control 9

CIS Control 9 asks for DMARC, blocked unnecessary file types and email server anti-malware. This page maps those safeguards to a self-hosted mail platform, the evidence to keep and what tooling alone leaves open.

On this page

Self-hosted email for CIS Control 9: what the safeguards ask of your mail platform

If you run or plan to run your own mail, you need to show coverage of CIS Control 9, and the three safeguards that matter most for your platform are Safeguard 9.5, Safeguard 9.6 and Safeguard 9.7. They ask you to put DMARC policy and verification in place, to block unnecessary file types at the email gateway, and to deploy and maintain anti-malware protections on email servers, such as attachment scanning or sandboxing. Most of the technical work for these safeguards lands on the mail platform itself, not on a separate security product, so the choice of server, filtering layer and authentication setup decides how much of the control you can evidence.

CIS Controls are a voluntary, prioritized set of safeguards, grouped into Implementation Groups. Safeguards 9.5 and 9.6 apply from IG2 upward, while Safeguard 9.7 applies only at IG3, so the first decision is which group your organization sits in. The CIS Controls do not replace regulatory, compliance or authorization schemes, so a financial, healthcare or public sector mail platform still has to meet its own rules on top of these safeguards. The CIS Controls Assessment Specification (CAS) defines what to measure for each safeguard, but it does not tell you how to build it, so confirm with your mail vendor or implementation partner which settings, logs and reports will produce that measurement evidence.

Before you assess coverage, check two things in your own environment. First, confirm which domains send mail, because DMARC only protects the domains you publish records for and the SPF and DKIM results it depends on. Second, confirm which attachment types and scanning engines your gateway and mail server actually enforce, and who maintains their signatures and rules. Write down the owner, the evidence source and the review cycle for each safeguard now, so that a later assessor or auditor sees a working process rather than a set of settings nobody checks.

How each CIS Control 9 safeguard maps to mail platform configuration

This table takes each of the three CIS Control 9 email safeguards in scope for this topic and translates it into what the mail platform must do, how to configure it, and which implementation group applies. Read it as a build checklist: the configuration column is where most self-hosted deployments either close the gap or leave it open, and the implementation group column tells you whether the safeguard applies to your organization at all.

Safeguard and what it asksWhat the mail function must doHow to configure it on a self-hosted platformImplementation group
9.5 DMARC policy and verification, built on SPF and DKIMMake forged or altered mail from your own domains less likely to reach recipients by publishing and enforcing sender authentication, then checking the results.Publish SPF records for each sending domain, sign outbound mail with DKIM in the mail server (mailcow and Stalwart both support DKIM signing), publish a DMARC record, start with a monitoring policy, collect aggregate reports, then move to quarantine or reject once legitimate senders align. Confirm DKIM and DMARC handling for each platform with its documentation.IG2 and IG3 (not IG1)
9.5 measurement dependency on software inventoryProvide the evidence that every domain and sending system is known before its DMARC status can be measured.Use the software inventory (Safeguard 2.1) to list every application that sends mail for your domains, including ticketing, monitoring, HR and marketing tools. Each one needs an SPF include or a DKIM selector, or it will fail alignment once the policy is enforced.Prerequisite for measuring 9.5 (IG2 and IG3)
9.6 Block unnecessary file types at the email gatewayStop attachment types that the business does not need, such as executables and script files, before they reach mailboxes.Define an allowed or blocked file type list in the inbound filter, apply it at the gateway or SMTP ingress layer, and document exceptions with an owner and an expiry date. Confirm which attachment rules each platform supports natively and which need an additional filter in front of it.IG2 and IG3 (not IG1)
9.6 coverage measureShow that the block list applies to all inbound mail paths, including mail relayed from other systems and users on mobile devices.Test the rule with sample messages of each blocked type sent from an external account, and confirm the rule also applies to mail forwarded from other domains. CIS defines three measures for this safeguard, so ask your assessor which evidence they expect for each one.IG2 and IG3 (not IG1)
9.7 Anti-malware on the email server, such as attachment scanning or sandboxingDeploy and keep current a scanning layer on the mail server that inspects attachments and links before delivery.Integrate an antivirus engine such as ClamAV with the spam filter (Rspamd is commonly paired with ClamAV for self-hosted mail), keep signatures updated on a set schedule, and quarantine or reject detected content. Add sandboxing only if your threat model requires it, and confirm whether it is available through an open-source option or a separate product.IG3 only
9.7 maintenance and update evidenceShow that anti-malware protections are maintained, not just installed, with signature and engine update records.Log every signature update and scanner version, alert on failed updates, and keep scan results with message identifiers so an assessor can trace a blocked attachment to a policy decision.IG3 only

Which open-source mail platforms can support these safeguards

No mail platform satisfies Safeguards 9.5, 9.6 and 9.7 on its own. The mail server handles signing and some filtering, DNS owns the SPF and DMARC records, and attachment scanning often sits in a separate layer. The cards below show where each candidate fits and what to verify before you commit.

Stalwart mail server

Stalwart is an all-in-one mail and collaboration server that supports IMAP, JMAP, SMTP, CalDAV, CardDAV and WebDAV. It is licensed under AGPL-3.0, with an optional Enterprise License from Stalwart Labs, and v0.16.26 was published on October 11, 2026. For Safeguard 9.5, confirm that DKIM signing is configured on the server while SPF and DMARC are published in your DNS zone. For Safeguards 9.6 and 9.7, check whether file type blocking and attachment handling are native features or depend on an external scanner, and record the answer for your audit evidence.

mailcow-dockerized suite

mailcow-dockerized is a GPL-3.0 Docker-based mail stack, with release 2026-09a published on October 6, 2026. It bundles common filtering components, so it is a practical starting point for teams that want DKIM, spam filtering and webmail in one deployment. Confirm which bundled components cover attachment blocking and malware scanning in the version you deploy, and whether those settings are enforced for all domains or only some. Treat the bundled stack as a set of controls you must configure and test, not as proof of coverage.

OX App Suite v8 groupware

OX App Suite v8 runs on Kubernetes and is delivered as Helm charts that reference container images. Its UI and middleware are mirrored on GitHub under AGPL-3.0, but certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Before you rely on it for Safeguard 9.6 or 9.7, confirm with Open-Xchange which mail filtering and attachment controls are included in your edition, and whether they require an additional module or an external scanning service.

DNS records for SPF and DMARC

The mail server signs outbound messages with DKIM, but it does not publish the SPF and DMARC policies that receivers check. Those are DNS records, so the owner of the zone must write them, align the DMARC domain with the DKIM signing domain, and move the policy toward enforcement once legitimate senders are accounted for. Keep a list of every service that sends mail for the domain, including scanners, ticketing tools and marketing platforms, because any sender missing from SPF or DKIM will fail DMARC checks.

Separate attachment scanning layer

Attachment scanning, sandboxing and file type blocking usually come from a filtering layer placed in front of or beside the mail server, such as a gateway or a dedicated scanning service. Choose whether that layer runs in your own infrastructure, which keeps mail content inside your boundary, or is provided by a third party. Document the rules that stop unnecessary file types, test them with sample messages, and confirm that the mail server accepts traffic only through that layer. Safeguard 9.7 expects these protections to be both deployed and maintained, so the update process needs an owner.

Where DMARC, file type blocking and anti-malware live in a mail architecture

Safeguard 9.5 is implemented mostly in DNS, not in the mail server. SPF, DKIM and DMARC are published records for each sending domain, and they only protect the organization when every legitimate sending source is accounted for. The CIS assessment specification builds the measurement on SPF and DKIM first, so the DNS work comes before any DMARC enforcement decision. Ownership usually sits with whoever controls the domain registrar and authoritative DNS, which is often a network or domain team rather than the mail platform team.

  • SPF record scope: The TXT record must list every server, relay and third-party service that sends on the domain's behalf. Unlisted senders such as marketing tools or ticketing systems will fail and generate reports you must triage.
  • DKIM key management: The mail platform signs outbound messages, but key generation, rotation and publication of the public key in DNS need a named owner and a documented rotation procedure.
  • DMARC policy progression: Start with a monitoring policy, read the aggregate reports, fix legitimate senders, then move toward enforcement. Confirm the timeline with your own risk owners, since no fixed schedule is supplied here.
  • Report handling: DMARC aggregate and forensic reports need a mailbox and a parser or service. Decide who reads them, how often, and where the results are retained as evidence.

Before changing any policy, confirm with your security and communications leads which business systems send mail under your domain.

Evidence assessors ask for under CIS Control 9

This table lists the evidence items an assessor is likely to request for Safeguards 9.5, 9.6 and 9.7, the Safeguard 2.1 software inventory, and the measurement outputs tied to the CIS Assessment Specification. Each row names the component that produces the evidence, so you can confirm who owns it before an assessment. DeployOpen prepares systems, controls and evidence for assessment, but independent auditors and certification bodies issue any assessment results or certifications.

Evidence itemSafeguard it supportsComponent that produces it
DNS records and DMARC policy history9.5 DMARC policy and verificationDNS provider zone history, plus change records for SPF, DKIM and DMARC TXT entries
DMARC aggregate report review records9.5 DMARC policy and verificationDMARC report receiver or reporting tool, plus a dated log of who reviewed reports and what action followed
Gateway file type rule exports and change logs9.6 Block unnecessary file typesInbound mail gateway or filtering layer, exported blocked-extension rules with version history
Anti-malware engine and signature update logs9.7 Email server anti-malwareAntivirus or scanning engine on the mail server, with dated signature and engine update records
Scan verdict logs for quarantined or blocked attachments9.7 Email server anti-malwareMail server and filtering logs showing scan results, retained for the period the assessor samples
Software inventory for the mail stack2.1 Software inventory (prerequisite for 9.5)Asset inventory tool or configuration management record listing mail server, filters, DNS and scanning components with versions
Measurement outputs for the 9.6 coverage metric9.6 Block unnecessary file typesReporting output that tests the three CIS Assessment Specification measures and combines them into the coverage metric

What mail tooling alone does not satisfy

A mail platform can publish DMARC records, filter attachments and run a scanner, but the safeguards only hold when someone owns the policy, the decisions and the upkeep. The cards below cover the gaps that tend to remain after the server is installed, and the questions to settle before the audit asks for evidence.

DMARC protects only after enforcement

Publishing a DMARC record with a p=none policy records failures but blocks nothing. Safeguard 9.5 expects the policy to be verified and moved toward enforcement, which needs someone to read aggregate reports, find legitimate senders that fail SPF or DKIM, and fix them before the policy tightens. Ask who owns that review and how often it happens. Whether a sending service can pass alignment depends on the deliverability design, so DMARC questions belong with that work.

File type rules need a decided list

Safeguard 9.6 asks that unnecessary file types be blocked at the gateway, but the word unnecessary depends on the business. Executables, macro-enabled Office files, archives containing executables and script files each have legitimate users in some departments. Build the list from documented business need, record who approved each exception, and confirm which types the mail server or the gateway in front of it can actually block. Review the list when new workflows appear.

Anti-malware needs a maintained update process

Safeguard 9.7 expects attachment scanning, sandboxing or both to be deployed and kept current. Scanner signatures, filter rules and any sandbox engine need a defined update cadence, a place where failed updates are noticed, and a documented fallback when a component is down. Mail that arrives while scanning is unavailable should be deferred or quarantined, not delivered unscanned. Confirm how each component is updated in the environment, including offline networks.

The CAS shows how to verify, not configure

The CIS Controls Assessment Specification defines the inputs, operations and measures used to check whether a Safeguard is implemented. It does not tell you which mail server setting, filter or DNS record to use. The configuration is your design, and the evidence is what the assessment reads. Plan the configuration so that each measure can be answered from logs, DNS records, filter reports or change records, and confirm the measurement inputs before the build is finished.

CIS Controls do not replace regulatory schemes

CIS states that the Controls do not replace regulatory, compliance or authorization schemes. A mail platform that satisfies Safeguard 9.5 through 9.7 may still fall short of a sector rule on retention, transmission security or audit logging. Map each Safeguard to the specific obligations your regulator sets, and treat CIS mappings as a starting point. Confirm with your assessor which framework they will test against before collecting evidence.

Sender reputation is ongoing operations

Blocklisting, reputation loss and bounce spikes are not one-time configuration. Someone must watch outbound volume, respond to listings, check reverse DNS and TLS on outbound paths, and decide when to relay through a smarthost. These tasks keep a DMARC policy from causing legitimate mail to fail, and they should be assigned to a named role with on-call coverage. Ask any implementation partner how they monitor reputation and who responds when a listing appears.

Common questions about CIS Control 9 and self-hosted email

What drives the cost of meeting CIS Control 9 on self-hosted email?

The cost depends on how much of the email chain you run yourself and how much you buy. The main components are the mail platform and its hosting, DNS and DMARC work, the filtering and anti-malware layer (including any commercial gateway or sandboxing service), outbound relay or clean IP addresses, and the people time to operate and monitor them. Some costs are one-time, such as the initial DNS, DKIM key and policy setup, the attachment rule design and the migration. Others recur, such as licenses or subscriptions, signature and rule updates, and report review. When you request a quote, ask the partner to split the price into one-time and recurring items, to list which safeguards each item supports, and to state which licensed modules or subscriptions are required. Ask for the assumptions behind the mailbox count and the number of sending domains, because both change the price.

How long does a CIS Control 9 email project take?

The duration depends on scope rather than on a fixed number of weeks. The biggest variables are how many domains send mail, whether a mail platform already runs, how many mailboxes and systems send automated messages, and whether you are building the filtering layer or placing a gateway in front of an existing server. DMARC is usually the slowest item in practice because it needs a monitoring period before enforcement can be raised safely, and the length of that period depends on your sending sources. Ask the partner for a written schedule that separates the DNS and authentication work, the attachment controls, the anti-malware build and the monitoring handover, and ask which steps depend on your internal change approvals.

Can our own team meet CIS Control 9 without a partner?

A capable team can do much of this, but the work spans several skill areas. You need someone who can manage DNS records and reason about SPF, DKIM and DMARC alignment, someone who runs mail operations (queues, TLS, certificates, backups and user support), and someone who watches security telemetry and reads DMARC aggregate reports. Attachment blocking and anti-malware also need a documented policy owner, because each rule creates false positives that users will report. Be honest about gaps in these areas before deciding. If your team already covers them, the main question is whether you can keep the controls maintained over time, since 9.5, 9.6 and 9.7 all require ongoing operation rather than a one-off setup.

Does Safeguard 9.7 apply to smaller organizations?

Safeguard 9.7 applies only to Implementation Group 3, so smaller organizations that fall under IG1 or IG2 are not expected to implement it under the CIS Controls prioritization. Safeguards 9.5 and 9.6 are assigned to IG2 and IG3, while IG1 covers essential cyber hygiene. Implementation Group assignment is a CIS prioritization tool, not a legal finding, so check whether your regulator, customer contracts or cyber insurer expect anti-malware on the mail server regardless of your group. Even where 9.7 is not required, attachment scanning is a common control to reduce risk, and the choice should be a documented decision.

How does CIS Control 9 map to other frameworks?

CIS Controls Navigator for v8.1 shows how each Safeguard maps to other frameworks. As of October 2026, it offers mappings to 30 frameworks and versions, including NIST CSF 2.0, NIST SP 800-53 Rev. 5, ISO/IEC 27001:2022, SOC 2, PCI DSS v4.0, DORA and NIS2. Use it to find which of your other obligations overlap with the email controls, then check each mapping against the framework's own text, because the Navigator is a starting point rather than an assessment. CIS states that the Controls do not replace regulatory or compliance schemes, so a Safeguard mapped to a framework still needs evidence that the framework's requirement is met. For regulated email, the sibling pages on PCI DSS anti-phishing and HIPAA transmission security cover those specific requirements.

Does DeployOpen issue an audit report for CIS Control 9?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. For CIS Control 9, the evidence package typically includes the DNS records and policy settings for SPF, DKIM and DMARC, DMARC aggregate report summaries, attachment rule configuration and change history, anti-malware configuration and update records, and test results showing the controls work. Ask your assessor which evidence format they expect before the build starts, so the collection is designed for them. The CIS Controls Accreditation program is a separate matter, and any accredited services must be verified directly with CIS.

What should we ask a partner to put in writing?

Ask for a written scope that names each safeguard covered (9.5, 9.6 and 9.7 where applicable), the systems and domains in scope, and the responsibilities split between your team and the partner. Request the deliverables: DNS and authentication configuration, the DMARC rollout plan with its monitoring period, the attachment policy and exception process, the anti-malware design, runbooks and an evidence index. Ask which mail platform and filtering components are proposed, which licenses or subscriptions they need, and whether any module is subject to separate fees under the vendor's terms. Also request the acceptance criteria, the process for false positive handling, the handover to your operations team and the support terms after go-live. Confirm that the partner will not sign off the controls as compliant on your behalf.

How a DMARC rollout moves from monitoring to enforcement

The DMARC rollout is a decision the organization owns, and CIS Safeguard 9.5 asks for both a DMARC policy and a way to verify it. DMARC passes for a message when SPF or DKIM passes and the authenticated domain aligns with the domain in the visible From address. The rollout starts with a _dmarc TXT record set to p=none and a rua address that receives aggregate reports. Those reports are the inventory of every system that sends mail as your domain, including the self-hosted mail server, marketing tools, ticketing systems, scanners and forgotten applications. Nothing should move toward enforcement until someone has reviewed that list.

Alignment is where self-hosted platforms most often fail. The mail server must sign outbound messages with DKIM, with keys published in DNS under a selector, and the SPF record must cover every host that actually sends, including any smarthost or outbound relay. A relay that rewrites the envelope, or an application that sends through the domain without signing, produces failures that look like spoofing in the reports. Confirm for your chosen platform, whether mailcow or Stalwart, that DKIM signing is enabled for each sending path, that key length meets your policy, and that the keys were rotated under a documented procedure. Safeguard 2.1 on software inventory helps build the sender list the reports are checked against.

Move the policy from p=none to p=quarantine and then to p=reject only after reports show that legitimate mail passes consistently. Assign named owners for report review, for approving each change, and for handling sources that fail, such as mailing lists and forwarding that break SPF. Decide in advance how long the monitoring phase runs and what evidence proves the change is ready. The CIS Controls Assessment Specification for Safeguard 9.5 describes what to measure, and the separate deliverability guide in this group covers Gmail sender rules, reverse DNS and TLS in more detail.

Phases to bring a mail estate into CIS Control 9 scope

This sequence moves a self-hosted mail estate from an unmapped set of domains and servers to one where the DMARC, file type and anti-malware safeguards are configured, documented and measured against the CIS Controls Assessment Specification. Each phase produces evidence that the next phase depends on.

  1. Inventory the mail stack and sending domains

    Start by listing every mail server, relay, gateway, archive and application that sends or receives mail for each domain, including marketing tools, ticketing systems and scanners that send on your behalf. The CIS Controls Assessment Specification treats the software inventory under Safeguard 2.1 as a prerequisite for measuring Safeguard 9.5, so this list should feed or reconcile with that inventory. The step is done when every sending source has an owner and every domain is mapped to the systems that use it.

  2. Publish and verify SPF and DKIM records

    Publish a Sender Policy Framework record and DKIM signing keys for each domain, covering every legitimate sending source identified in the inventory. Test from each source by sending a message and checking the authentication results in the received headers. The step is done when every legitimate stream passes SPF and DKIM and no unknown source appears in the results.

  3. Run DMARC in monitoring mode and review reports

    Publish a DMARC record with a monitoring policy and aggregate report addresses, then collect and review the reports for several cycles. Compare the reported sources against the inventory, fix misaligned streams, and add any missing senders before tightening the policy. The step is done when reports show that legitimate mail aligns with SPF or DKIM and the team has a documented decision on when to move toward enforcement.

  4. Decide and document the file type block list

    Work with security and business owners to define which attachment types the mail platform should reject or quarantine at the gateway, such as executable and script formats the business does not need. Record the list, the exceptions process and the approver for each change. The step is done when the approved list is versioned, applied to the gateway and tested with sample messages that should be blocked and that should pass.

  5. Configure anti-malware on the mail server

    Enable attachment scanning and any sandboxing or content analysis your platform supports, and confirm that the scanner's signature or rule updates run on a schedule with alerts on failure. Confirm with your mail platform vendor or implementation partner which scanning engines and sandbox options are supported in your edition. The step is done when test messages carrying a benign test signature are flagged, and update failures generate alerts to a monitored queue.

  6. Collect evidence and measure against the CAS

    Gather the configuration exports, DNS records, DMARC report summaries, block list versions, scanner test results and update logs for each safeguard, and map them to the measures defined in the CIS Controls Assessment Specification for Safeguards 9.5, 9.6 and 9.7. Note any gaps and assign owners. The step is done when each measure has a dated evidence artifact and a review record. Independent assessors make the final determination of compliance, so confirm with your assessor which evidence format they expect.

How regulated sectors read these safeguards alongside their own rules

Many regulated organizations use CIS Control 9 as a baseline for email protections, then add the obligations that their own regulator or sector framework imposes. The CIS Controls do not replace those obligations. CIS states that the Controls do not replace any regulatory, compliance or authorization scheme, and it maintains mappings to frameworks such as HIPAA and PCI DSS so that teams can see where the two overlap. A mapping shows where a safeguard may contribute to a requirement. It does not show that the requirement is met, so a CISO should treat the mapping as a starting point for a gap review rather than as proof of compliance.

The sibling pages cover the sector rules that sit beside Safeguards 9.5, 9.6 and 9.7. The self-hosted email for financial services page covers SEC Rule 17a-4 retention of business communications, which requires broker-dealers to preserve communications for not less than three years and which the mail server alone does not satisfy. The self-hosted email for healthcare page and the HIPAA page cover the transmission security and audit controls in 45 CFR 164.312, including encryption of ePHI in transit and audit controls that record activity in systems holding ePHI. A SPF, DKIM and DMARC setup can support the integrity side of those rules, but it does not provide encryption of messages or audit logging by itself. Confirm each of those controls separately with the owner of the rule.

Before you present a CIS Control 9 mapping to an assessor or regulator, confirm two things with them in writing: which framework version and which requirement numbers they will test against, and whether they accept the CIS mapping as evidence. Do not claim alignment with a framework unless the assessor confirms it. Also check whether your scope includes the archive, the journaling path and the mailbox audit log, because those systems often fall outside the mail server but inside the regulator's view. A short written note from the assessor that names the controls in scope will prevent disagreement later in the engagement.

How DeployOpen scopes and delivers CIS Control 9 email work

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For CIS Control 9 email work, that means turning the email safeguards into a written scope, a configured mail platform and evidence your assessors can review.

How we scope

  • Confirm which email domains, mailboxes and sending systems fall under the scope of Safeguards 9.5 to 9.7.
  • Inventory the existing sending sources, including applications, marketing tools and third-party relays, before any DNS change.
  • Agree the written scope, deliverables and timeline in writing before work starts; engagements are fixed-scope.

How we build

  • Configure SPF, DKIM and DMARC for each domain, moving the DMARC policy toward enforcement only after reports are reviewed.
  • Set attachment type restrictions at the mail gateway and document which file types are blocked and why.
  • Deploy and tune anti-malware scanning on the mail server, then test detection with known-safe and known-bad samples.

How we hand over

  • Deliver configuration records, DNS entries, filter rules and runbooks so your team can audit each safeguard.
  • Document the evidence each measure needs, such as DMARC report retention and scanner update logs.
  • Walk your operations and security staff through alert handling, false-positive review and change control before handover.

How we support

  • Offer ongoing support, upgrades and continuous testing as a retainer after handover.
  • Schedule periodic DMARC report reviews, rule updates and mail server upgrades under the agreed support scope.
  • Prepare control evidence for your independent auditor; DeployOpen does not issue audit reports or certifications.

Sources and further reading

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.