Home/Resources/Agents/Email Security Auditor
Data Protection

Email Security Auditor

Probes 16 DKIM selectors, four RBLs, and the live STARTTLS handshake for every contractor domain in scope.

Covered practices · NIST SP 800-171 Rev 2
3.13.8Transmission confidentialityPrimary3.13.11FIPS-validated cryptography3.14.6Monitor systems to detect attacks3.14.1Flaw remediation
5
Email authentication layers audited per contractor domain

The problem

Email is the most common CUI exfiltration vector and the most common phishing entry point. SPF, DKIM, and DMARC are how the receiving side authenticates that an email actually came from the contractor's domain. Without all three, attackers can spoof the contractor's domain in social engineering against customers, partners, and prime contractors with no technical barrier whatsoever.

DMARC p=none is functionally no enforcement. The record exists, the policy is monitoring-only, and any email that fails SPF or DKIM still gets delivered to the recipient inbox. Most contractors deploy p=none during the initial DMARC rollout and never advance to p=quarantine or p=reject, leaving the domain spoofable indefinitely and the spoof activity visible only in DMARC reports nobody is reading.

STARTTLS is the transit layer. A mail server without STARTTLS support delivers email in plaintext between mail servers, full stop. STARTTLS supporting only TLS 1.0/1.1 is the same risk class. MTA-STS adds the enforcement, since with mode=enforce a downgrade to plaintext is rejected; without MTA-STS, a MITM can strip STARTTLS silently and the contractor never sees evidence it happened.

What CMMC requires

NIST SP 800-171 Rev 2 controls this agent verifies. Primary mappings drive the gap assessment; secondary mappings provide supporting evidence in the SSP.

Primary mapping
NIST 3.13.8Transmission confidentiality

Audits SPF, DKIM, DMARC, MTA-STS, and STARTTLS,every layer of email transmission protection that prevents CUI disclosure or spoofed-sender phishing.

Read in NIST 800-171 r2
Secondary mapping
NIST 3.13.11FIPS-validated cryptography

Verifies STARTTLS cipher suite enforcement and DKIM key size against FIPS minimums.

Read in NIST 800-171 r2
NIST 3.14.6Monitor systems to detect attacks

RBL presence is an indicator of compromise or abuse,being on Spamhaus often means the host has sent spam, which can mean it is compromised.

Read in NIST 800-171 r2
NIST 3.14.1Flaw remediation

Mail server on RBL is a flaw requiring investigation,the deliverability impact is immediate and the underlying cause needs root-cause analysis.

Read in NIST 800-171 r2

How it works

Per-platform detection logic. The agent runs unprivileged where possible and falls back gracefully when raw access is unavailable.

Linux

Uses the system DNS resolver and never hardcodes 8.8.8.8, since contractor DNS may be split-horizon. Resolves TXT records for the apex domain (SPF), _dmarc.<domain> (DMARC), _mta-sts.<domain> (MTA-STS marker), and probes 16 common DKIM selectors (default, google, mail, selector1, selector2, smtp, k1, s1, s2, dkim, proofpoint, mimecast, sendgrid, mailchimp, ses, amazonses). Counts SPF DNS lookups recursively against the 10-lookup limit. Fetches https://mta-sts.<domain>/.well-known/mta-sts.txt with cert validation, and resolves MX records, reverses each IP, and queries zen.spamhaus.org, bl.spamcop.net, dnsbl.sorbs.net, and psbl.surriel.com.

Windows

Uses the Windows DNS resolver via the system API. Same record set and probe logic as Linux, with the STARTTLS probe driven by .NET socket APIs against the same five-second timeout. RBL reversal handles both IPv4 and IPv6 nibble formats correctly.

macOS

Uses the macOS resolver via getaddrinfo, with dig as a fallback when available. Same record set as Linux and Windows, with the STARTTLS probe driven by a raw socket. Reports identical structured output across platforms so multi-domain contractors get one consolidated SSP artifact.

What it finds

Concrete findings written to the assessor's mental model,not abstract categories. Severity drives POA&M priority and SPRS deduction.

  • CRITICAL
    SPF record uses +all
    Any server on the internet can claim to send email from this domain. No email authentication at all,equivalent to having no SPF record at all but signed with a green light.
  • HIGH
    No SPF record
    Domain has no v=spf1 TXT record. Receiving servers cannot verify which IPs are authorized to send. Spoofing trivial.
  • HIGH
    No DMARC record
    Domain has no _dmarc TXT record. SPF and DKIM alignment cannot be enforced and there is no reporting on authentication failures.
  • HIGH
    DMARC p=none
    Policy is monitoring-only. Authentication failures are reported but not rejected. Spoofed mail still delivers.
  • HIGH
    Mail server no STARTTLS support
    MX host advertises no STARTTLS in EHLO response. Email between contractor and partners transits in plaintext.
  • HIGH
    Mail server IP on Spamhaus ZEN
    MX IP appears in zen.spamhaus.org. Either active spam source, compromised host, or policy block,investigate immediately, deliverability impact is concrete.
  • CRITICAL
    DKIM RSA key under 1024 bits
    DKIM signing key is too small to be cryptographically meaningful. Forgery of signatures is computationally feasible.
  • MEDIUM
    No MTA-STS record
    STARTTLS can be downgraded to plaintext by an active MITM. MTA-STS is the enforcement layer that prevents downgrade.
SPRS impact

3.13.8 is a 5-point control. Email findings cluster, and a contractor with no SPF, no DMARC, and STARTTLS-optional hits 3.13.8 in three different ways simultaneously. The assessor records the worst tier; the SPRS deduction is 5 points either way. RBL presence adds 3.14.1 (3 points) and 3.14.6 (1 point) when discovered, and the deliverability impact is immediate regardless of the assessment outcome. Full SPF, DKIM, DMARC, and MTA-STS deployment with p=reject and STARTTLS plus TLS 1.2+ produces zero findings here.

How it hooks into the platform

Email domains are registered once at setup; the platform resolves SPF, DKIM selectors, DMARC, MTA-STS, and DANE records plus probes STARTTLS and RBLs on a recurring cadence. DNS lookups run from the host doing the discovery, so you decide whether resolved records and probe results stay on-prem or sync up. Each authentication layer drafts the SSP's 3.13.8 transmission protection narrative as a measured-state table. POA&M items capture per-record remediation with the exact TXT content needed for the DNS provider.

How we know it's working

Acceptance criteria from the engineering spec,what the agent must do to ship.

  • Identifies SPF qualifiers +all, ~all, -all, and ?all per domain
  • Counts SPF DNS lookups recursively through includes and redirects, capped at 10
  • Probes 16 common DKIM selectors and reports which ones return a record
  • Parses DKIM key length directly from the p= field of the resolved record
  • Reads DMARC pct= correctly with the default-100 fallback applied
  • Fetches the MTA-STS policy over HTTPS with full certificate validation
  • Reverses MX IPs for RBL queries in both IPv4 and IPv6 nibble form
  • Completes the STARTTLS probe in under five seconds and handles refused connects
  • Uses the system resolver always, never hardcodes a public DNS server
Other agents in Data Protection

Run this agent against your environment.

Book a 30-minute scoping call. We'll deploy the agent on your systems and walk through the findings together.

Book a Scoping Call →