NIST SP 800-177r1 — Trustworthy Email (digest)

If your customers include US federal agencies, or organizations close to the US public sector, your email service will be measured against the federal government's email security guidance. That guidance is NIST Special Publication 800-177r1, Trustworthy Email (Rose, Nightingale, Garfinkel and Chandramouli; February 2019, 128 pp.).

Its audience is enterprise email administrators. It applies to federal IT systems, as a companion to SP 800-45v2, Guidelines on Electronic Mail Security, and it is explicitly offered to non-government organizations for voluntary use.

For an email service provider (ESP), it matters in two ways. It is the reference that customers in or near the US public sector will hold you to. It also packages SPF, DKIM, DMARC, TLS and DANE as one coherent set of recommendations, with the formal "Security Recommendation" numbers that procurement documents cite.

Some of its references are out of date. The document cites DMARC as RFC 7489, which RFC 9989 has since obsoleted (see DMARC Standard). It describes ARC and REQUIRETLS as IETF work in progress; they have since been published as RFC 8617 and RFC 8689 (see ARC and SMTP TLS in Practice). It also states that MTA-STS had "no publicly available implementations" at the time of writing, although RFC 8461 was published at the same time and MTA-STS is now widely deployed. The recommendations remain the operative federal baseline.

Federal requirements context

• It is issued under the authority of FISMA (the Federal Information Security Modernization Act of 2014), and is consistent with OMB Circular A-130.
• DHS Binding Operational Directive BOD 18-01 (October 2017) requires domain-based authentication (SPF and DMARC, plus hardening of STARTTLS and HTTPS) for the domains of the federal executive branch. SP 800-177 presents itself as the guide to meeting BOD 18-01. It "does not extend those requirements", but gives guidance on best common practice.
• Cryptographic parameters defer to NIST SP 800-57 (key management), SP 800-133 (key generation), SP 800-52 (TLS configuration) and FIPS-approved modules.
• Appendix C provides a full overlay of NIST SP 800-53 Rev. 4 controls onto email systems. It maps the control baselines (Low, Moderate and High) to guidance specific to email for SPF, DKIM and DMARC, for SMTP over TLS, and for end-to-end (S/MIME) protection. Federal deployments must show these controls, and ESPs that serve agencies are asked for exactly this mapping in security questionnaires.

Threats and mitigations matrix (Section 3)

The document classifies threats to an email service as threats to integrity, confidentiality or availability:

The infrastructure recommendations here are to block outbound port 25 except for authorized mail senders (Rec 3-1), to avoid running MTAs on systems that are not part of the mail infrastructure, with internal hosts relaying through a trusted mail submission agent (MSA) instead (Rec 3-2), and to block inbound port 25 to unauthorized receivers (Rec 3-3).

The document also warns about virtualization. Virtual machines that share NAT IP space with legitimate senders must be firewalled off port 25 or given separate NAT instances.

The recommendation set

The normative content of the document is its numbered Security Recommendations, condensed below.

Section 4: authenticating the sending domain

* The published document numbers both the DMARC recommendation and the S/MIME recommendation "4-11". The summary in Section 4.8 lists the S/MIME one. Cite them by topic.

The DKIM key parameters (Table 4-3) are RSA with SHA-256, at a recommended length of 2048 bits and a recommended lifetime of 1–2 years, and ed25519 at 256 bits, which is not approved for federal use.

The key rotation procedure is: publish the new selector first, reconfigure the MTA, wait (the old key stays in DNS for about a week, for queued mail), and then delete the old resource record. Do not use web-based DKIM key generators for federal systems, because they expose the private key.

On the order of deployment, the document advises publishing a p=none DMARC record with rua before you roll out SPF and DKIM, so that you get baseline visibility first. It calls pct= values other than 0 or 100 "not a wise strategy."

For SPF change management, lower the TTL of the TXT record to about 300 seconds before editing it, and restore it (to about 3600 seconds) after you verify the change. Chains of SPF include: mechanisms are bounded by the limit of 10 DNS lookups. Do not + an include you do not control.

To collect DMARC reports at a third party, the external report receiver must publish the authorization record original-sender-domain._report._dmarc.mailto-domain.

Forwarding impact (Table 4-7):

The document's canonical forwarding failure is the Trusted Internet Connection (TIC) scanning loop. A cloud provider forwards mail to a scanner, and the scanner returns mail that now looks spoofed. ARC is the suggested mitigation.

Section 5: transmission and content security

The supporting analysis matches the guidance in DANE and MTA-STS, and goes slightly further:

• PKIX-TA(0) and PKIX-EE(1) should not be used for opportunistic DANE.
• DANE-EE(3) needs no SNI or name check, because the trust comes from DNSSEC.
• Publishing both 3 1 1 and 2 1 1 lets clients validate through either DANE or the CA system.

Its comparison of DANE and MTA-STS (Table 5-3) sets out the differences. DANE uses TLSA records and MTA-STS uses TXT records. DANE requires DNSSEC on the client, and MTA-STS requires HTTPS. DANE can scope CAs and MTA-STS cannot. PKIX is not required with DANE and is required with MTA-STS. Self-signed certificates are acceptable only with DANE certificate usage 3. Failure reporting exists only in the MTA-STS ecosystem (TLS-RPT, RFC 8460). On failure, DANE closes the connection, while the behavior of MTA-STS depends on the policy. When both are deployed, DANE takes precedence.

The certificate profile for federal mail follows the FPKI "FPIX" profiles, with KeyPurposeId id-kp-emailProtection (1.3.6.1.5.5.7.3.4). CA signature hashes are SHA-256 or SHA-512 only, and device certificates carry the DNS name or IP address in subjectAltName.

Sections 6–7: UBE filtering and end-user access

• For inbound and outbound filtering, the recommended pipeline order is blocklist and allowlist checks, then domain-based authentication, then content filtering, cheapest first. Dynamic DNSBLs are preferred over static local lists. Mail that passes SPF, DKIM and DMARC "should not automatically be assumed to not be UBE."
• Rec 7-1: IMAP and POP3 clients must connect over TLS (RFC 8314). Cleartext TCP with password authentication is "strongly discouraged."
• Rec 7-2: maintain a cryptographic key management system (CKMS) for keys related to email (federal: compliance with SP 800-57).
• Rec 7-3: keys that encrypt stored mail must be different from the keys used in transmission.

What an ESP should take from it

1. The -all rule for domains that send no mail (4-1) and a unique DKIM key for each third party (4-10) are the two recommendations aimed most directly at the relationship with an ESP. An agency customer that follows 800-177 will demand a dedicated key pair, not your shared signing key, and will null-route its parked domains.
2. A key and selector for each MTA (4-5) is stricter than common ESP practice, which is one key per customer domain. Expect it in federal security reviews.
3. DANE-TA(2) with DANE-EE(3), using 2 1 1 and 3 1 1, is the concrete federal TLSA recipe if you host inbound mail for such customers.
4. The SP 800-53 Appendix C overlay is the document to point to when a customer close to government asks "how does your email service map to our control baseline."
5. DNSSEC runs through every recommendation (4-2, 4-6, 4-7, and as a prerequisite for DANE). Realistically, sending and bounce domains that serve federal customers need zones signed with DNSSEC.