Compliance reference

Email authentication compliance for MSPs — NIST, CMMC, HIPAA, HITRUST

12 min read·Published 2026-04-25· Reviewed by Mailstinger compliance team

Six frameworks, the specific control numbers each one imposes on email authentication, and where Mailstinger sits inside the control map. No hand-waving, no “helps with compliance” generalities — just the line item your auditor is going to ask for.

Contents
  1. 1. NIST 800-53 Rev 5 — AT-2, SC-8, SI-3, SI-7
  2. 2. CMMC Level 1 — FCI / Federal Contract Information
  3. 3. CMMC Level 2 — CUI / Controlled Unclassified Information
  4. 4. HIPAA Security Rule — §164.312(e)(1) Transmission Security
  5. 5. HITRUST CSF — 09.s, 10.b, 13.k
  6. 6. PCI-DSS 4.0 §5.4.1 — anti-phishing technical controls
  7. FAQ

1. NIST 800-53 Rev 5

NIST 800-53 is the federal control catalogue that civilian agencies and most federal contractors inherit through FedRAMP, FISMA and state-level adoptions like StateRAMP and TX-RAMP. Four controls in the catalogue touch email authentication directly:

Mailstinger maps to each one concretely. DMARC enforcement (p=reject) plus DKIM signing satisfies the integrity half of SC-8 for SMTP, and an MTA-STS policy atenforce with TLS-RPT ingestion satisfies the confidentiality half — the platform reports the live state of both for every monitored domain. The lookalike-domain detector and BEC alerting feed AT-2 by giving training programs real, recent examples of attempted impersonation against the customer's own brand. Inbound DMARC verdicts at the receiving gateway provide an SI-3 evidence point for malicious-code protection on the email vector. And DKIM signature verification — logged per-message in the aggregate report — is direct SI-7 evidence of cryptographic integrity on information in transit.

Mailstinger gives MSPs serving federal and FedRAMP-adjacent customers a single pane to evidence AT-2, SC-8, SI-3 and SI-7 on the email vector without spinning up a separate stack.

2. CMMC Level 1 — FCI

CMMC Level 1 is the basic-hygiene tier of the Cybersecurity Maturity Model Certification — required for any DoD contractor or sub that handles Federal Contract Information (FCI) but not Controlled Unclassified Information. Level 1 is a self-assessment against 17 practices drawn from FAR 52.204-21. Two of those practices land on email authentication:

Mailstinger's DKIM/SPF/DMARC stack satisfies the email-authentication subset of both. For SC.L1-3.13.1, the platform monitors the mail boundary continuously and produces a daily verdict on every domain's posture — that monitoring artefact is the control evidence. For SI.L1-3.14.1, every finding (SPF too permissive, DKIM key under 1024 bits, DMARC at p=none) is logged with a remediation suggestion and a paste-ready DNS record; closing the finding closes the flaw, with a timestamped audit trail. Run the free DMARC analyzer on any client domain to see the same finding format you'll get inside a paid tenant.

Mailstinger gives MSPs serving DoD primes and subs at Level 1 a single pane to evidence SC.L1-3.13.1 and SI.L1-3.14.1 on the email vector without spinning up a separate stack.

3. CMMC Level 2 — CUI

CMMC Level 2 is the advanced tier — required for contractors handling Controlled Unclassified Information (CUI). It adds the full 110 practices from NIST SP 800-171 Rev 2 and is third-party assessed by a C3PAO, not self-attested. Three of the practices map directly onto email authentication and audit:

For AC.L2-3.1.20, an enforced DMARC policy plus an MTA-STS policy at enforce are how an organisation actively controls which external systems are permitted to claim its identity in mail and which transport security is acceptable inbound. Mailstinger surfaces both per-domain and alerts on drift. For SI.L2-3.14.2, inbound DMARC failures at a customer's gateway are a malicious-code signal that the platform aggregates and exports. For AU.L2-3.3.1, Mailstinger retains DMARC aggregate reports for 90 days by default and ingests forensic (RUF) reports with recipient redaction; both are direct, exportable audit-log evidence for a C3PAO assessor — including per-message DKIM verdicts, source IPs and SPF results. The RUF ingestion adds per-failure forensic detail that L2 assessors increasingly ask for and that aggregate reports alone cannot provide.

Mailstinger gives MSPs serving DIB primes handling CUI a single pane to evidence AC.L2-3.1.20, SI.L2-3.14.2 and AU.L2-3.3.1 on the email vector without spinning up a separate stack.

4. HIPAA Security Rule — §164.312(e)(1)

The HIPAA Security Rule (45 CFR Part 164, Subpart C) is the federal standard for safeguarding electronic protected health information (ePHI) at covered entities and their business associates — payers, providers, clearinghouses and the MSPs who serve them. The Transmission Security standard sits at §164.312(e)(1) with two implementation specifications:

DKIM signatures provide cryptographic integrity on every outbound message claiming to be from the covered entity — that is the implementation mechanism behind §164.312(e)(2)(i). DMARC ties DKIM to the visible sender, so an attacker can't strip and re-sign with their own key. MTA-STS plus TLS-RPT, both of which Mailstinger publishes and ingests on behalf of the tenant, force opportunistic STARTTLS upgrades into a strict-mode requirement — that is the implementation mechanism behind §164.312(e)(2)(ii). The TLS-RPT JSON reports are retained as evidence of which receiving MTAs honoured the policy and which did not.

One detail that matters specifically for HIPAA: forensic (RUF) reports can contain recipient addresses, which are themselves ePHI in many clinical contexts. Mailstinger's default is forensic_redact_recipients=True, so recipient addresses are hashed before storage. Covered entities should leave that default on, sign a BAA, and treat the platform accordingly.

Mailstinger gives MSPs serving healthcare a single pane to evidence §164.312(e)(1) integrity and encryption controls on the email vector without spinning up a separate stack.

5. HITRUST CSF

HITRUST CSF is the certifiable framework most often demanded by health-payer procurement — it harmonises HIPAA, NIST, ISO 27001, PCI and a dozen others into one assessment. Three control families touch email authentication:

Mailstinger's domain authentication stack — SPF, DKIM, DMARC at enforcement, plus MTA-STS and TLS reporting — is the technical safeguard behind 09.s and 13.k. The DMARC alignment check itself is the input-validation step that satisfies 10.b for the messaging vector: the receiver validates that the visible From: domain aligns with an authorised signing or sending identity before the message is accepted as legitimate. TLS-RPT reports give 13.k an evidence trail of which exchanges actually encrypted in transit. Use the free SPF checker to spot permissive includes that would fail a HITRUST 13.k assessor before you submit for certification.

Note that HITRUST renumbered its control catalogue in CSF v11; the 09.s / 10.b / 13.k references above match the long-stable v9 numbering that most active certifications still cite. The underlying requirements are unchanged in v11.

Mailstinger gives MSPs serving HITRUST-bound healthcare and life sciences customers a single pane to evidence 09.s, 10.b and 13.k on the email vector without spinning up a separate stack.

6. PCI-DSS 4.0 §5.4.1

PCI-DSS 4.0 is the payment-card industry's data security standard — required for any merchant or service provider that stores, processes or transmits cardholder data. Section 5.4.1 was published as a best-practice in 2022 and became a required control on 31 March 2025:

“Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks.” — PCI-DSS 4.0 §5.4.1

§5.4.1's requirement text mandates “automated mechanisms” rather than naming a specific protocol; the PCI Security Standards Council's supplementary anti-phishing guidance explicitly points to DMARC, SPF and DKIM as the satisfying technical controls on outbound mail, and recommends an inbound anti-phishing solution that honours DMARC verdicts. Mailstinger covers the outbound side end-to-end — alignment monitoring, DMARC at enforcement, drift alerts — and exports the daily aggregate report that a QSA will ask to see during a PCI assessment. If you take card payments, this is no longer optional in 2026.

Mailstinger gives MSPs serving merchants and PCI-bound service providers a single pane to evidence §5.4.1 on the email vector without spinning up a separate stack.

FAQ

Common questions from MSP compliance leads and the auditors who assess them. Click any question to expand.

Does DMARC alone make us compliant?
No. DMARC is one technical control inside a much larger framework. It satisfies the email-authentication subset of controls like NIST SC-8, CMMC SI.L1-3.14.1 and PCI-DSS 5.4.1, but you still need policy, training and audit-logging controls layered on top.
What DMARC policy is required for compliance?
Most frameworks do not name a specific policy value. PCI-DSS 4.0 §5.4.1 is the exception — it requires anti-phishing technical controls, and the PCI SSC's guidance points squarely at DMARC enforcement (p=quarantine or p=reject). NIST and CMMC are framework-neutral but auditors generally accept p=reject as satisfying intent; p=none is treated as observation, not control.
Does Mailstinger store HIPAA-protected information?
Mailstinger ingests DMARC aggregate (RUA) and forensic (RUF) reports. Forensic reports can contain message subjects and recipient addresses; the platform defaults forensic_redact_recipients=True so recipient addresses are hashed before storage. For HIPAA workloads we recommend keeping that default on and signing a BAA before enabling RUF ingestion.
How long does Mailstinger retain DMARC reports?
Aggregate reports default to 90 days of retention; forensic reports default to 90 days with recipient redaction on by default. Both are tenant-configurable so MSPs can match the retention requirement of the specific framework they're evidencing against (e.g. CMMC AU.L2-3.3.1 typically requires at minimum 90 days online, longer offline).
Is DMARC actually mandatory under PCI-DSS 4.0?
PCI-DSS 4.0 §5.4.1 became a required (not best-practice) control on 31 March 2025. The requirement is for anti-phishing technical controls on inbound mail and DMARC on outbound; the PCI SSC's published guidance explicitly names DMARC as the satisfying control. If you store, process or transmit cardholder data, this is no longer optional.
Can one Mailstinger tenant evidence multiple frameworks at once?
Yes — that is the design point. A single MSP tenant can hold multiple client domains, each tagged with the frameworks that apply (HIPAA, PCI, CMMC). Reports, audit logs and DNS evidence are exported per-client so each customer's auditor sees only their scope.

Where to go next