PCI DSS 5.4.1 anti-phishing for self-hosted email

Self-hosted email for PCI DSS anti-phishing: what 5.4.1 asks of your mail platform

A payment environment team that runs its own mail now has a requirement it cannot delegate by default. Requirement 5.4.1 of PCI DSS asks for processes and automated mechanisms to detect and protect personnel against phishing attacks. It was a best practice until 31 March 2025 and is now a required control in PCI DSS v4.x. The note to 5.4.1 in the SAQ D says the systems providing the automated mechanism, such as email servers, are not brought into PCI DSS scope by that note, and that the focus is on personnel with access to in-scope system components. That scoping point matters for your mail platform design: the work is filtering, sender authentication and the evidence that those mechanisms operate. Confirm the exact wording and your own scope with your Qualified Security Assessor or acquirer before you assume the mail server is out of scope for other reasons, such as storing cardholder data in mailboxes.

Keep two requirements apart in your planning. Requirement 12.6.3.1 covers security awareness training, including phishing, and the SAQ D treats it as separate from 5.4.1. Meeting one does not meet the other, so a training program does not replace the technical mechanisms, and a mail gateway does not replace the training record. Also note that the PCI Security Standards Council does not enforce compliance or impose penalties. The individual payment brands decide which entities must validate and run any enforcement programs, so ask your acquirer or payment brand which validation type applies to you, and whether it is a Self-Assessment Questionnaire with an Attestation of Compliance or a Report on Compliance completed by a Qualified Security Assessor. The PCI DSS standard page is the natural starting point for the current version.

Who must meet 5.4.1 and which assessment path applies

PCI DSS is maintained by the PCI Security Standards Council, but the individual payment brands decide which entities must validate compliance and run any enforcement programs. The standard applies to any entity that stores, processes or transmits cardholder data or sensitive authentication data, or that could affect the security of the cardholder data environment. That covers merchants, processors, acquirers, issuers and service providers. Requirement 5.4.1 applies to all of them, because the risk it addresses is personnel being tricked into giving up access, whatever the business role.

Merchants: Any retailer or online business that accepts card payments falls under the standard, and the brand or acquirer determines the validation level.
Processors and acquirers: These entities usually face the most demanding validation paths because they handle large volumes of cardholder data.
Issuers: Banks that issue cards are in scope for the environments that store or process account data.
Service providers: Hosting companies or managed service firms that could affect the security of a client's cardholder data environment are in scope, even if they never see the card data themselves.
Mail-only operators: A self-hosted mail platform is not automatically in the cardholder data environment. The SAQ D note to 5.4.1 says systems providing the automated mechanism, such as email servers, are not brought into scope by that requirement alone.

Confirm with your acquirer or the relevant brand which validation level applies to your entity and whether your mail platform is connected to any in-scope system.

How requirement 5.4.1 maps to mail platform functions

This table separates what Requirement 5.4.1 asks of the organization from what the mail platform must provide, and shows where each function is configured in Stalwart, mailcow or OX App Suite. Read the process rows as the program your team owns and the mechanism rows as the controls the mail platform supplies. The main takeaway is that the mail server is one input to 5.4.1, not the whole requirement, and that vendor features must be confirmed before they are cited as evidence.

Requirement or scope item	What the function must do	How to configure it in Stalwart, mailcow or OX App Suite
5.4.1 processes	Define how phishing is detected, reported and handled for personnel, with named owners and a documented response path.	Not a mail server setting. Document the reporting address, triage owner and escalation steps, then confirm which mail platform logs support the process.
5.4.1 automated mechanisms: sender authentication	Verify that inbound mail claiming to come from your domains is authenticated and that spoofing is blocked or quarantined.	Enable SPF, DKIM and DMARC checks on inbound mail. Confirm with the vendor how Stalwart, mailcow and OX App Suite each apply DMARC policy on receipt.
5.4.1 automated mechanisms: content filtering	Scan messages for phishing indicators such as suspicious links, lookalike domains and malicious attachments before they reach mailboxes.	Use the built-in spam and malware filtering chain (for example, Rspamd in mailcow). Confirm whether link and attachment inspection is native or needs an add-on or external gateway.
5.4.1 automated mechanisms: user reporting path	Give personnel a one-step way to report suspicious messages that feeds the processes above.	Confirm whether the client offers a report-as-phishing action and whether it routes to a mailbox, a ticket queue or a learning feed. Test it with a sample message.
5.4.1 automated mechanisms: logging and review	Record filtering decisions, authentication results and user reports so the team can review them and show the mechanism operates.	Enable filter and authentication logs and forward them to central storage. Confirm retention periods and log fields with the vendor.
SAQ D note: email servers and scope	The note states that the automated mechanism, such as an email server, is not brought into PCI DSS scope by this requirement, while the focus stays on personnel with access to in-scope components.	Ask your assessor to confirm how the mail platform is treated in your environment. Record the decision in writing, since scope depends on your cardholder data flows and access paths.
12.6.3.1 phishing awareness training	A separate requirement for security awareness training that covers phishing. Meeting 5.4.1 does not meet it.	Not configured in the mail platform. Run training through a separate program, and keep completion records as evidence for this requirement.

Which open-source mail platforms fit a PCI-scoped anti-phishing design

PCI DSS 5.4.1 does not put the mail server itself in scope, but the platform still has to deliver the filtering and sender authentication that protect personnel from phishing. The three candidates below differ in licensing, deployment model and how much of the filtering stack you assemble yourself, so the choice should follow from what your team can operate and evidence.

Stalwart as an all-in-one server

Stalwart bundles IMAP, JMAP, SMTP, CalDAV, CardDAV and WebDAV in one server under AGPL-3.0, with an optional Enterprise License from Stalwart Labs. Its current release, v0.16.26, was published on October 11, 2026. Confirm which spam scoring, attachment scanning and DKIM, SPF and DMARC handling ship in the version you run, and which parts you must supply through an external filter. Ask the vendor how the optional enterprise license changes the feature set before you commit to a design.

mailcow as a Docker-based stack

mailcow-dockerized is licensed under GPL-3.0 and is deployed as a set of containers managed through its own configuration. Release 2026-09a was published on October 6, 2026. The stack bundles common filtering and mailbox components, which makes it a practical fit for a small team, but you still need to document how those components are updated, monitored and backed up to meet your own PCI evidence expectations. Verify the included antivirus and spam components against your change control and patch cadence.

OX App Suite on Kubernetes

OX App Suite v8 runs on a Kubernetes cluster and is delivered as Helm charts that reference container images, with Helm 3.17.0 or newer required. It depends on Istio, or on a basic ingress-nginx option where Istio cannot be used, and uses Redis 7.4.x for caching and sessions and MariaDB with InnoDB as its primary store. Persistent data needs a distributed file system such as NFS or object storage. v8.47 is the current LTS release, so plan upgrades around the support windows.

Commercial module terms for OX

Open-Xchange publishes mirrors of its App Suite UI and middleware under AGPL-3.0, but its Operations Guide states that some modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Before you design around a feature, ask which anti-phishing, filtering or authentication capabilities are included in your edition and which require a separate agreement. Get those answers in writing so the design does not depend on an unlicensed module.

Filtering and authentication you add

None of the three platforms should be assumed to cover the full PCI anti-phishing control set on its own. Plan for a filtering layer that scores inbound messages, scans attachments and blocks known malicious links, plus DKIM signing, SPF and a DMARC policy for your domains. Document which component owns each function, who tunes false positives, and how you test that a simulated phishing message is caught. The mail platform choice narrows these integrations but does not replace them.

Evidence for the mail platform

Because the mail server sits outside PCI scope under the SAQ D note to Requirement 5.4.1, your evidence should show how the automated mechanism is configured and monitored, not that the mail server is validated. Keep configuration baselines, filter rule change records, DMARC report reviews and test results for each platform. Confirm with your assessor which of these records they expect and how long you must keep them, since that depends on your assessment type and environment.

Why the mail server stays out of scope but its controls still matter

The SAQ D note to Requirement 5.4.1 says that the systems providing the automated mechanism, such as email servers, are not brought into PCI DSS scope by that requirement alone. The note focuses the requirement on personnel who have access to in-scope system components. For a self-hosted mail platform, this means the mail server, its filtering engine and its authentication settings do not become part of the cardholder data environment just because they detect phishing. Segmentation decisions still matter: confirm with your assessor and your network diagram that the mail platform has no route into the cardholder data environment, and that mailbox credentials and administrative access are kept separate from payment systems.

The audited population is the set of personnel with access to in-scope components, not every mailbox on the domain. That changes what goes into the evidence file. Assessors will still ask how the mechanism works, which messages it inspects, who receives alerts when a phishing attempt is detected, how users are protected once a message is delivered, and how the mechanism is monitored for failure. Expect to show configuration exports for spam and malware filtering, sender authentication results for your domains, and a record of who reviews detections and how quickly. Ask your assessor which of these artifacts they expect for your scope before you build the evidence pack.

The scope note does not remove any obligation. Requirement 5.4.1 is a separate requirement from the phishing awareness training in Requirement 12.6.3.1, and meeting one does not meet the other. Treat the mail platform as the mechanism that the assessed controls depend on: if it is misconfigured, unmonitored or left without patching, the assessed population is still exposed to phishing. Before the assessment, decide who owns the mechanism, what its monitoring looks like and how a failure is escalated, and confirm the approach you plan to take with your Qualified Security Assessor or the entity that manages your assessment.

What evidence assessors ask for from the mail platform

What evidence do assessors expect for PCI DSS Requirement 5.4.1 from a self-hosted mail platform?

Assessors expect records showing that the anti-phishing process and its automated mechanisms exist, run and are reviewed. The mail platform contributes configuration exports, authentication policy records, filter rule change history and mail logs. The SAQ D note says systems such as email servers are not brought into scope by this requirement, so the evidence is about how the mechanism is operated, not a PCI scope argument. Confirm with your assessor which artifacts they will sample and in what format before you build the evidence folder.

Which mail platform components produce the DMARC policy and aggregate report records?

The DMARC policy is a DNS TXT record published for your sending domains, so the evidence is the zone record and its change history from your DNS provider. Aggregate (RUA) reports arrive at the mailbox you name in the policy and must be parsed by a reporting tool or a script on your side. Keep the policy version, the dates it changed and a monthly summary of alignment results. Confirm with your DNS and reporting vendors which report formats and retention periods they support.

How do DKIM key rotation records show the signing keys are managed?

DKIM signing keys are generated by the mail server or its milter for each domain, and the public key is published in DNS under a selector. Evidence is the key generation date, the selector name, the DNS record history and the change ticket for each rotation. Store private keys in a restricted location and log access to them. Confirm with your mail platform vendor how key generation and selector changes are logged, since the exact log fields vary by product and version.

What phishing simulation or user report metrics can a mail platform provide?

A mail platform does not usually produce phishing simulation results by itself. User-reported messages are the nearest native signal, typically forwarded to a reporting mailbox or passed to a helpdesk, so count them and record how each was triaged. Simulation metrics come from a separate tool or your awareness program. Keep these numbers separate from the training records for Requirement 12.6.3.1, which is a different requirement. Confirm with your vendor whether user report buttons and their logs are available in the edition you plan to run.

Which mail logs and retention settings do assessors usually review?

Assessors look for logs that show inbound and outbound messages were scanned, quarantined or delivered, with timestamps and enough detail to trace a suspicious message. Typical sources are the SMTP transaction log, the filter engine decision log and the authentication results recorded in headers. Define how long each log is kept and where it is copied. Confirm the log format, field names and retention controls with your vendor, because they differ between Stalwart, mailcow and OX App Suite deployments.

What change records prove that anti-phishing filter rules are controlled?

Each change to a filter rule, score, allow list or quarantine policy should have a ticket, an approver, a before and after copy of the configuration and a test result. Export the active configuration on a schedule and keep the exports in version control or a configuration store. Compare exports between dates to show what changed. The exact configuration keys and export formats depend on the filter engine and version you run, so confirm them with the vendor before you design the record set.

How should training records for Requirement 12.6.3.1 be kept separate from mail evidence?

Keep training records in the learning or awareness system that delivered the course, with attendance, completion date, content version and the individual or role covered. Do not mix them into mail logs or filter exports, because Requirement 5.4.1 and Requirement 12.6.3.1 are separate requirements and meeting one does not meet the other. Link the two evidence sets only through a short cross-reference in your compliance matrix. Ask your assessor how they want the records indexed.

What mail tooling alone does not satisfy under 5.4.1

Requirement 5.4.1 asks for processes and automated mechanisms together, and the mail platform only covers part of the automated side. The cards below cover what an assessor will still expect to see around the server: a documented procedure, people who own it, training that is tracked separately, tuned filters, and documented objectives if a customized approach is chosen.

A documented anti-phishing procedure

The requirement expects a defined process for detecting phishing and protecting personnel, not just a filter configuration. Write down how suspicious messages are identified, reported, quarantined and investigated, and who decides on each step. Ask your QSA which evidence they will sample, such as the procedure version, review records and examples of handled messages.

Named roles and a review cadence

Assign owners for the mail filtering, the user reporting path and the periodic review of the process. Each owner should know what they must check and how often, and the review should lead to recorded changes. Without named people and dated reviews, the process exists only on paper and will not hold up at assessment.

Awareness training is not 12.6.3.1

Requirement 5.4.1 and the phishing awareness training in Requirement 12.6.3.1 are separate, and meeting one does not meet the other. Keep a training program with its own records, and do not count filter performance or simulated messages as proof of training. Plan both controls so each has its own evidence.

Tuned filters and false positive handling

Anti-spam and anti-malware rules on the mail platform need ongoing tuning, with a clear route for users to report false positives and for administrators to release legitimate mail. Record which rule changes were made, why, and who approved them. Confirm with your mail platform vendor or integrator which filtering components ship with the chosen server and how their rule updates are delivered.

Documented objectives for a customized approach

If you meet the requirement through the customized approach instead of the defined approach, you must document the stated objective, the risk analysis and how your controls meet that objective. An assessor will test whether the design meets the objective, so the documentation has to exist before the assessment. Confirm with your QSA whether the customized approach suits your environment.

Confirm the current PCI DSS version

The PCI SSC ran a request for comments on PCI DSS v4.0.1 and had announced no release date for a next version as of October 2026. Do not assume the version you prepared against will remain current. Ask your QSA which version and SAQ applies to your entity, and which dated requirements are in force for your assessment.

How a phishing control rollout is sequenced

The sequence settles scope with the assessor before any configuration starts, then builds the process, the mail platform controls and the evidence in an order that lets each step be checked against the one before it.

Confirm scope and assessment type
Before any build work, confirm with your Qualified Security Assessor or acquirer whether you complete a Report on Compliance or a Self-Assessment Questionnaire, and which version of PCI DSS applies to your assessment. Ask them to state in writing whether the mail platform is in scope, since the SAQ D note to Requirement 5.4.1 says the automated mechanism, such as an email server, does not by itself bring that system into scope. The step is done when the assessor's answers are recorded in the project file and the scope statement matches them.
Inventory personnel with in-scope access
Build a list of the personnel who have access to in-scope system components, because Requirement 5.4.1 focuses on that group. Pull mailbox, directory and administrative accounts from the identity system and match each one to a role and a business reason for access. Note any shared or service mailboxes that receive payment-related messages. The step is done when the list is signed off by the process owner and each entry can be traced to an account in the directory.
Publish the anti-phishing process
Write the documented process that defines how personnel report suspected phishing, how reports are triaged, who acts on them and how confirmed threats are removed from mailboxes. Assign owners for each handoff, including the mail administrator and the security team. Keep the process separate from the awareness training required under Requirement 12.6.3.1, because meeting one does not meet the other. The step is done when the approved document is version-controlled and staff can find it.
Configure authentication and filtering
On the self-hosted mail platform, enable the automated mechanisms that detect phishing: sender authentication (SPF, DKIM and DMARC), anti-spam and anti-malware scoring, link and attachment inspection, and a user-facing report button or mailbox that feeds the triage process. Document each setting with its configuration source and its owner. Confirm that the filtering layer is tested against messages that spoof your own domains. The step is done when a test message that fails authentication is quarantined or flagged as configured and the change record is filed.
Test with simulated messages
Run controlled phishing simulations against the inventoried group, using scenarios that resemble your real payment and credential lures. Record how many messages were reported, how many were clicked or opened and how quickly the triage team responded. Use the results to tune filtering rules and to adjust the process where handoffs failed. The step is done when results for each scenario are written up and every failed handoff has a tracked fix.
Collect evidence for the assessment
Gather the artifacts the assessor will ask for: the approved process, the personnel inventory, configuration exports for filtering and authentication, change tickets, simulation reports and triage logs. Store each item with a date, an owner and a link to the requirement it supports. Ask your assessor which evidence format they accept before collecting. The step is done when an evidence index maps every artifact to 5.4.1 and the assessor has confirmed the set is sufficient.
Schedule recurring review
Set a recurring cadence for reviewing the inventory, the process, filtering rules and simulation results, and rerun the review when the mail platform or PCI DSS changes. PCI SSC has announced a request for comments on the next iteration of the standard but no release date, so track announcements and confirm with your assessor which version applies at each assessment. The step is done when the review calendar, owners and review record template are agreed and a first review has been logged.

Questions buyers ask before hiring help for PCI anti-phishing email

Does PCI DSS requirement 5.4.1 apply to my organization?

Requirement 5.4.1 applies to any entity that falls under PCI DSS, which includes merchants, processors, acquirers, issuers and service providers that store, process or transmit cardholder data or could affect the security of the cardholder data environment. Since 31 March 2025 the requirement is no longer a best practice, so it must be met where the standard applies. Which requirements your assessment covers, and which questionnaire or report you file, depends on your card flows and your payment brands. Confirm your validation type and the applicable requirements with your acquirer or your Qualified Security Assessor (QSA) before scoping any mail work.

Is the mail server itself in PCI DSS scope?

The SAQ D note to 5.4.1 states that the systems providing the automated mechanism, such as email servers, are not brought into PCI DSS scope by that requirement. The requirement focuses on personnel who have access to in-scope system components. That does not remove the mail platform from your broader assessment, because it may still carry cardholder data, connect to the cardholder data environment or share identity systems with it. Ask your QSA to confirm whether any mail flow, mailbox, archive or administrative account touches in-scope systems, and document that answer before design begins.

What makes a PCI anti-phishing mail project take longer or cost more?

The main drivers are mail volume and the number of domains and mailboxes, the filtering you already run, the size of any migration from a hosted provider, and how much evidence your assessor expects. Higher volume and more domains increase the tuning and monitoring work. Existing gateways that must be integrated or replaced add design time. Migration adds mailbox transfer, DNS cutover and user testing. Evidence scope affects how much logging, reporting and policy documentation must be produced and retained. Cost has one-time parts (design, build, migration, tuning) and recurring parts (operations, updates, monitoring, support). Ask any provider for a quote that separates these items and states the assumptions behind each one.

Can our internal team build and run this without outside help?

Many teams can, provided they already operate mail infrastructure and have someone who understands authentication, filtering and log review. The work spans DNS records for sender authentication, filtering policy, reputation management, user-facing phishing reporting and evidence collection for the assessment. Internal teams usually find the hardest parts are keeping filter tuning current, handling false positives, and producing the records a QSA asks for on schedule. Assess your current skills and staffing against that list. A partner can cover the gaps as a fixed-scope project, a retainer for ongoing support, or a mix of both.

What do we need to provide before an implementation partner starts?

The partner will need administrative access to the mail platform, DNS and the identity directory, along with access to current filtering, logging and backup systems. Named policy owners must approve the phishing controls, reporting paths and retention settings. Your QSA or acquirer contact should confirm the evidence they expect so the design produces it. You also need a written list of in-scope domains, mailboxes and integrations, and a change window for cutover. Agree on who approves access and who signs off on each deliverable before work starts, since these decisions set the scope and timeline.

How long does a PCI anti-phishing email engagement usually take?

Duration depends on scope: the number of domains and mailboxes, whether you migrate from a hosted provider, how many filtering layers you change, and how much evidence must be produced before your assessment date. A narrow project that tunes an existing platform and documents controls takes less time than a full platform build with migration and staged user testing. Ask a partner to tie the timeline to a written scope with named milestones, and to state which dependencies, such as DNS changes, QSA reviews and change windows, sit outside their control.

Does using OX App Suite add licensing costs for PCI mail work?

It can. The OX App Suite Operations Guide states that the right to use certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Before choosing OX for a payment-related environment, list the modules you need, such as mail, calendar, drive or security features, and get written confirmation from Open-Xchange of which are included in your license. Also confirm the support lifecycle you will run, because the support commitment ties each LTS release to a defined support window. Licensing and support terms are separate from the implementation fee and should be quoted separately.

Does meeting requirement 5.4.1 also satisfy phishing awareness training?

No. Requirement 5.4.1 covers the processes and automated mechanisms that detect and protect personnel against phishing attacks, while the phishing awareness training sits in requirement 12.6.3.1. The SAQ notes state that meeting one does not meet the other. A mail platform with strong filtering still needs a documented awareness program, and a training program does not replace technical controls. Plan both as separate workstreams with separate owners and evidence, and confirm the exact wording and validation method with your QSA.

How DeployOpen scopes and delivers a PCI-aligned mail anti-phishing build

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For PCI DSS anti-phishing, we start by agreeing which mail, identity and monitoring controls the written scope covers, then build and document them so your team and your assessor can review the evidence.

How we scope

We confirm which mail platform, domains and user groups fall inside the written scope before any work starts.
We map the phishing detection and staff protection mechanisms to Requirement 5.4.1 and note where awareness training under 12.6.3.1 sits separately.
We agree in writing whether a defined or customized approach applies, and which assessor-facing evidence each deliverable produces.

How we build

We deploy the chosen mail server, such as Stalwart or mailcow, with SPF, DKIM and DMARC records configured and checked.
We configure spam, malware and link filtering, enforced TLS, and mailbox access logging, then test detection against sample phishing messages.
We integrate reporting for suspected phishing reports, so security staff can review user submissions and filter tuning changes.

How we hand over

You receive configuration records, runbooks and test results covering each filtering and authentication control in scope.
We document the boundary between the mail platform and the cardholder data environment, which the SAQ D note says the email server is not brought into scope by.
We train your administrators on routine tuning, log review and incident steps, and confirm the handover in writing.

How we support

Ongoing support, upgrades and continuous security testing are available as a retainer after handover.
We track upstream releases and security updates for the mail platform and apply them through an agreed change process.
DeployOpen prepares evidence for your assessment. Qualified Security Assessors and the payment brands decide compliance, and we do not issue attestations.

Self-hosted email for PCI DSS anti-phishing