NIST Special Publication 800-177
Revision 1

Trustworthy EmailScott RoseJ. Stephen Nightingale
Simson Garﬁnkel
Ramaswamy ChandramouliThis publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-177r1

C O M P U T E R

S E C U R I T Y

NIST Special Publication 800-177
Revision 1

Trustworthy EmailScott RoseJ. Stephen Nightingale*
Advanced Network Technology Division
Information Technology Laboratory
Simson L. Garﬁnkel
US Census Bureau
Ramaswamy ChandramouliComputer Security Division
Information Technology Laboratory
Former employee; all work for this publication was done while at NIST*

This publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-177r1
February 2019

U.S. Department of Commerce
Wilbur L. Ross, Jr., Secretary

National Institute of Standards and Technology
Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology

Authority
�is publication has been developed by NIST in accordance with its statutory responsibilities under theFederal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law(P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including
minimum requirements for federal information systems, but such standards and guidelines shall not apply
to national security systems without the express approval of appropriate federal oﬃcials exercising policy
authority over such systems. �is guideline is consistent with the requirements of the Oﬃce of Management
and Budget (OMB) Circular A-130, Section 8b(3), Securing Agency Information Systems, as analyzed in
Circular A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in Circular
A-130, Appendix III, Security of Federal Automated Information Resources.
Nothing in this publication should be taken to contradict the standards and guidelines made mandatory andbinding on federal agencies by the Secretary of Commerce under statutory authority. Nor should theseguidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce,
Director of the OMB, or any other federal oﬃcial. �is publication may be used by nongovernmentalorganizations on a voluntary basis and is not subject to copyright in the United States. Attribution would,
however, be appreciated by NIST.
National Institute of Standards and Technology Special Publication 800-177 Revision 1
Natl. Inst. Stand. Technol. Spec. Publ. 800-177 Revision 1, 128 pages (February 2019)
CODEN: NSPUE2This publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-177r1
Certain commercial entities, equipment, or materials may be identiﬁed in this document in order to describe an
experimental procedure or concept adequately. Such identiﬁcation is not intended to imply recommendation or
endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best
available for the purpose.
�ere may be references in this publication to other publications currently under development by NIST in accordancewith its assigned statutory responsibilities. �e information in this publication, including concepts and methodologies,
may be used by federal agencies even before the completion of such companion publications. �us, until eachpublication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For
planning and transition purposes, federal agencies may wish to closely follow the development of these new
publications by NIST.
Organizations are encouraged to review all draft publications during public comment periods and provide feedback to
NIST. All NIST Computer Security Division publications, other than the ones noted above, are available athttps://csrc.nist.gov/publications.

Comments on this publication may be submitted to:
National Institute of Standards and Technology
Attn: Advanced Network Technologies Division, Information Technology Laboratory
100 Bureau Drive (Mail Stop 8920) Gaithersburg, MD 20899-8920
Email: SP800-177@nist.gov

All comments are subject to release under the Freedom of Information Act (FOIA).

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

Reports on Computer Systems Technology
�e Information Technology Laboratory (ITL) at the National Institute of Standards andTechnology (NIST) promotes the U.S. economy and public welfare by providing technicalleadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test
methods, reference data, proof of concept implementations, and technical analyses to advance thedevelopment and productive use of information technology. ITL’s responsibilities include thedevelopment of management, administrative, technical, and physical standards and guidelines forthe cost-eﬀective security and privacy of other than national security-related information in federal
information systems. �e Special Publication 800-series reports on ITL’s research, guidelines, andoutreach eﬀorts in information system security, and its collaborative activities with industry,
government, and academic organizations.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Abstract�is document gives recommendations and guidelines for enhancing trust in email. �e primary
audience includes enterprise email administrators, information security specialists and network
managers. �is guideline applies to federal IT systems and will also be useful for small or
medium sized organizations. Technologies recommended in support of core Simple Mail
Transfer Protocol (SMTP) and the Domain Name System (DNS) include mechanisms forauthenticating a sending domain: Sender Policy Framework (SPF), Domain Keys Identiﬁed Mail
(DKIM) and Domain based Message Authentication, Reporting and Conformance (DMARC).
Recommendations for email transmission security include Transport Layer Security (TLS) andassociated certiﬁcate authentication protocols. Recommendations for email content security
include the encryption and authentication of message content using S/MIME(Secure/Multipurpose Internet Mail Extensions) and associated certiﬁcate and key distribution
protocols.
Keywords
Email; Simple Mail Transfer Protocol (SMTP); Transport Layer Security (TLS); Sender Policy
Framework (SPF); Domain Keys Identiﬁed Mail (DKIM); Domain based Message
Authentication, Reporting and Conformance (DMARC); Authentication of Named Entities(DANE); S/MIME; OpenPGP.

ii

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

Audience
�is document gives recommendations and guidelines for enhancing trust in email. �e primary
audience for these recommendations is federal enterprise email administrators, information
security specialists and network managers. While some of the guidelines in this document pertain
to federal IT systems and network policy, most of the document will be more general in natureand could apply to any organization.
For most of this document, it will be assumed that the organization has some or all responsibility
for email and can conﬁgure or manage its own email and Domain Name System (DNS) systems.
Even if this is not the case, the guidelines and recommendations in this document may help in
education about email security and can be used to produce a set of requirements for a contracted
service.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Trademark Information
All registered trademarks belong to their respective organizations.

iii

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

Executive Summary
�is document gives recommendations and guidelines for enhancing trust in email. �e primary
audience includes enterprise email administrators, information security specialists and network
managers. �is guideline applies to federal IT systems and will also be useful for small or
medium sized organizations.
Email is a core application of computer networking and has been such since the early days ofInternet development. In those early days, networking was a collegial, research-oriented
enterprise. Security was not a consideration. �e past forty years have seen diversity inapplications deployed on the Internet, and worldwide adoption of email by researchorganizations, governments, militaries, businesses and individuals. At the same time there has
been an associated increase in (Internet-based) criminal and nuisance threats.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

�e Internet’s underlying core email protocol, Simple Mail Transport Protocol (SMTP), was ﬁrst
adopted in 1982 and is still deployed and operated today. However, this protocol is susceptible toa wide range of attacks including man-in-the-middle content modiﬁcation and content
surveillance. �e basic standards have been modiﬁed and augmented over the years withadaptations that mitigate some of these threats. With spooﬁng protection, integrity protection,
encryption and authentication, properly implemented email systems can be regarded as
suﬃciently secure for government, ﬁnancial and medical communications.
NIST has been active in the development of email security guidelines for many years. �e mostrecent NIST guideline on secure email is NIST SP 800-45, Version 2 of February 2007,
Guidelines on Electronic Mail Security. �e purpose of that document is:“To recommend security practices for designing, implementing and operating email
systems on public and private networks,”�ose recommendations include practices for securing the environments around enterprise mailservers and mail clients, and eﬀorts to eliminate server and workstation compromise. �is guidecomplements SP 800-45 by providing more up-to-date recommendations and guidance for email
digital signatures and encryption (via S/MIME), recommendations for protecting against
unwanted email (spam), and recommendations concerning other aspects of email system
deployment and conﬁguration.
Following a description of the general email infrastructure and a threat analysis, these guidelines
cluster into techniques for authenticating a sending domain, techniques for assuring emailtransmission security and those for assuring email content security. �e bulk of the security
enhancements to email rely on records and keys stored in the Domain Name System (DNS) by
one party and extracted from there by the other party. Increased reliance on the DNS ispermissible because of the recent security enhancements there, in particular the development andwidespread deployment of the DNS Security Extensions (DNSSEC) to provide source
authentication and integrity protection of DNS data.

iv

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL�e purpose of authenticating the sending domain is to guard against senders (both random andmalicious actors) from spooﬁng another’s domain and initiating messages with bogus content,
and against malicious actors from modifying message contents in transit. Sender Policy
Framework (SPF) is the standardized way for a sending domain to identify and assert theauthorized mail senders for a given domain. Domain Keys Identiﬁed Mail (DKIM) is themechanism for asserting sending servers and eliminating the vulnerability of man-in-the-middle
content modiﬁcation by using digital signatures generated from the sending mail server.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Domain based Message Authentication, Reporting and Conformance (DMARC) was conceived
to allow email senders to specify policy on how their mail should be handled, the types of
security reports that receivers can send back, and the frequency those reports should be sent.
Standardized handling of SPF and DKIM removes guesswork about whether a given message isauthentic, beneﬁtting receivers by allowing more certainty in quarantining and rejecting
unauthorized mail. In particular, receivers compare the “From” address in the message to the
SPF and DKIM results, if present, and the DMARC policy in the DNS. �e results are used todetermine how the mail should be handled. �e receiver sends reports to the domain owner about
mail claiming to originate from their domain. �ese reports should illuminate the extent to which
unauthorized users are using the domain, and the proportion of mail received that is “good.”
Man-in-the-middle attacks can intercept cleartext email messages as they are transmitted hop-byhop between mail relays. Any bad actor that can passively monitor network traﬃc can read such
mail as it travels from submission to delivery systems. Email message conﬁdentiality can beassured by encrypting traﬃc along the path. �e Transport Layer Security Protocol (TLS) uses
an encrypted channel to protect message transfers from man-in-the-middle attacks. TLS relies on
the Public Key Infrastructure (PKI) system of X.509 certiﬁcates to carry exchange material andprovide information about the entity holding the certiﬁcate. �ese are usually generated by a
Certiﬁcate Authority (CA). �e global CA ecosystem has in recent years become the subject toattack and has been successfully compromised more than once. One way to protect against CA
compromises is to use the DNS to allow domains to specify their intended certiﬁcates or vendor
CAs. Such uses of DNS require that the DNS itself be secured with DNSSEC. Correctly
conﬁgured deployment of TLS may not stop a passive eavesdropper from viewing encrypted
traﬃc but does practically eliminate the chance of deciphering it.
Server to server transport layer encryption also assures the integrity of email in transit, but
senders and receivers who desire end-to-end assurance, (i.e., mailbox to mailbox) may wish to
implement end-to-end, message-based authentication and conﬁdentiality protections. �e sender
may wish to digitally sign and/or encrypt the message content, and the receiver can authenticate
and/or decrypt the received message. Secure Multipurpose Internet Mail Extensions (S/MIME) isthe recommended protocol for email end-to-end authentication and conﬁdentiality. �is usage of
S/MIME is not common at the present time but is recommended. Certiﬁcate distribution remains
a signiﬁcant challenge when using S/MIME, especially the distribution of certiﬁcates between
organizations. Research is underway on protocols that will allow the DNS to be used as alightweight publication infrastructure for S/MIME certiﬁcates.
S/MIME is useful for authenticating email, since the protocol usually includes PKI certiﬁcates inmessages in order to authenticate them, avoiding the necessity of distributing the sender’s publicv

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

key certiﬁcate in advance. Encrypted mass mailings are more problematic, as S/MIME senders
need to possess the certiﬁcate of each recipient if the sender wishes to send encrypted mail.
Email communications cannot be made trustworthy with a single package or application. It
involves incremental additions to basic subsystems, with each technology adapted to a particulartask. Some of the techniques use other protocols such as DNS to facilitate speciﬁc security
functions like domain authentication, content encryption and message originator authentication.
�ese can be implemented discretely or in aggregate, according to organizational needs.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

vi

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

Table of Contents
Executive Summary ..................................................................................................... iv
1

Introduction ............................................................................................................ 1
1.1 What This Guide Covers ................................................................................. 1
1.2 What This Guide Does Not Cover ................................................................... 1
1.3 Document Structure ........................................................................................ 1
1.4 Conventions Used in this Guide ...................................................................... 2

2

Elements of Email .................................................................................................. 3
2.1 Email Components.......................................................................................... 3

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

2.1.1

Mail User Agents (MUAs) .............................................................................. 3

2.1.2

Mail Transfer Agents (MTAs)......................................................................... 4

2.1.3

Special Use Components .............................................................................. 4

2.1.4

Special Considerations for Cloud and Hosted Service Customers ................ 5

2.1.5

Email Server and Related Component Architecture ...................................... 5

2.2 Related Components ...................................................................................... 5
2.2.1

Domain Name System (DNS)........................................................................ 5

2.2.2

Enterprise Perimeter Security Components................................................... 6

2.2.3

Public Key Infrastructure (PKI) ...................................................................... 6

2.3 Email protocols ............................................................................................... 7
2.3.1

Simple Mail Transfer Protocol (SMTP) .......................................................... 7

2.3.2

Mail Access Protocols (POP3, IMAP, MAPI/RPC) ......................................... 8

2.3.3

Internet Email Addresses .............................................................................. 9

2.4 Email Formats ............................................................................................... 10
2.4.1

Email Message Format: Multi-Purpose Internet Mail Extensions (MIME)......10

2.4.2

Security in MIME Messages (S/MIME) .........................................................10

2.4.3

Pretty Good Privacy (PGP/OpenPGP) .........................................................11

2.5 Secure Web-Mail Solutions ........................................................................... 13
3

Security Threats to an Email Service ................................................................. 15
3.1 Integrity-related Threats ................................................................................ 15
3.1.1

Unauthorized Email Senders within an Organization’s IP Address Block .....15

3.1.2

Unauthorized Email Receiver within an Organization’s IP Address Block .....16

3.1.3

Unauthorized Email Messages from a Valid DNS Domain (Address Spoofing).....................................................................................................................17vii

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

3.1.4

Tampering/Modification of Email Content .....................................................17

3.1.5

DNS Cache Poisoning..................................................................................18

3.1.6

Phishing and Spear Phishing .......................................................................18

3.2 Confidentiality-related Threats ...................................................................... 20
3.3 Availability-related Threats ............................................................................ 20
3.3.1

Email Bombing .............................................................................................21

3.3.2

Unsolicited Bulk Email (Spam) .....................................................................21

3.3.3

Availability of Email Servers .........................................................................22

3.4 Summary of Threats and Mitigations ............................................................ 22
3.5 Security Recommendations Summary .......................................................... 24
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

4

Authenticating a Sending Domain and Individual Mail Messages ................... 25
4.1 Introduction ................................................................................................... 25
4.2 Visibility to End Users ................................................................................... 27
4.3 Requirements for Using Domain-based Authentication Techniques forFederal Systems ........................................................................................... 28
4.4 Sender Policy Framework (SPF)................................................................... 28
4.4.1

Background ..................................................................................................28

4.4.2

SPF on the Sender Side...............................................................................30

4.4.3

SPF and DNS ..............................................................................................33

4.4.4

Considerations for SPF when Using Cloud Services or Contracted Services.....................................................................................................................33

4.4.5

SPF on the Receiver Side ............................................................................34

4.5 DomainKeys Identified Mail (DKIM) .............................................................. 35
4.5.1

Background ..................................................................................................35

4.5.2

DKIM on the Sender Side.............................................................................36

4.5.3

Generation and Distribution of the DKIM Key Pair ........................................36

4.5.4

Example of a DKIM Signature ......................................................................37

4.5.5

Generation and Provisioning of the DKIM Resource Record ........................38

4.5.6

Example of a DKIM RR ................................................................................39

4.5.7

DKIM and DNS ............................................................................................39

4.5.8

DKIM Operational Considerations ................................................................39

4.5.9

DKIM on the Receiver Side ..........................................................................41

4.5.10 Issues with Mailing Lists ...............................................................................41
4.5.11 Considerations for Enterprises When Using Cloud or Contracted Emailviii

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

Services .......................................................................................................42

4.6 Domain-based Message Authentication, Reporting and Conformance(DMARC) ...................................................................................................... 42

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

4.6.1

DMARC on the Sender Side.........................................................................43

4.6.2

The DMARC DNS Record ............................................................................44

4.6.3

Example of DMARC RR’s ............................................................................46

4.6.4

DMARC on the Receiver Side ......................................................................47

4.6.5

Policy and Reporting ....................................................................................48

4.6.6

Considerations for Agencies When Using Cloud or Contracted Email Services.....................................................................................................................50

4.6.7

Mail Forwarding and Indirect Email Flows ....................................................50

4.7 Authenticating Mail Messages with Digital Signatures .................................. 53
4.7.1

End-to-End Authentication Using S/MIME Digital Signatures .......................54

4.8 Recommendation Summary.......................................................................... 55
5

Protecting Email Confidentiality ......................................................................... 57
5.1 Introduction ................................................................................................... 57
5.2 Email Transmission Security ......................................................................... 57
5.2.1

TLS Configuration and Use ..........................................................................58

5.2.2

X.509 Certificates .........................................................................................59

5.2.3

STARTTLS...................................................................................................63

5.2.4

SMTP Security via Opportunistic DNS-based Authentication of Named
Entities (DANE) Transport Layer Security (TLS)...........................................64

5.2.5

SMTP MTA Strict Transport Security (MTA-STS) .........................................66

5.2.6

Comparing DANE and MTA-STS .................................................................69

5.2.7

Reporting TLS Errors to Senders .................................................................69

5.3 Email Content Security ................................................................................. 70
5.3.1

S/MIME and SMIMEA ..................................................................................71

5.3.2

OpenPGP and OPENPGPKEY ....................................................................73

5.4 Security Recommendation Summary............................................................ 74
6

Reducing Unsolicited Bulk Email ....................................................................... 75
6.1 Introduction ................................................................................................... 75
6.2 Why an Organization May Want to Reduce Unsolicited Bulk Email .............. 75
6.3 Techniques to Reduce Unsolicited Bulk Email .............................................. 75
6.3.1

Approved/Non-approved Sender Lists..........................................................76ix

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

6.3.2

Domain-based Authentication Techniques ...................................................77

6.3.3

Content Filtering ...........................................................................................78

6.4 User Education ............................................................................................. 78
7

End User Email Security ...................................................................................... 80
7.1 Introduction ................................................................................................... 80
7.2 Webmail Clients ............................................................................................ 80
7.3 Standalone Clients ........................................................................................ 80
7.3.1

Sending via SMTP .......................................................................................80

7.3.2

Receiving via IMAP ......................................................................................81

7.3.3

Receiving via POP3 .....................................................................................81

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

7.4 Mailbox Security............................................................................................ 82
7.4.1

Confidentiality of Data in Transit...................................................................82

7.4.2

Confidentiality of Data at Rest ......................................................................82

7.5 Security Recommendation Summary............................................................ 83
List of Appendices
Appendix A— Acronyms ............................................................................................ 84
Appendix B— References .......................................................................................... 85
B.1 NIST Publications ......................................................................................... 85
B.2 Core Email Protocols .................................................................................... 86
B.3 Sender Policy Framework (SPF)................................................................... 87
B.4 DomainKeys Identified Mail (DKIM) .............................................................. 87
B.5 Domain-based Message Authentication, Reporting and Conformance(DMARC) ...................................................................................................... 88
B.6 Cryptography and Public Key Infrastructure (PKI) ........................................ 88
B.7 Other ............................................................................................................. 90
Appendix C— Overlay of NIST SP 800-53 Controls to Email Messaging Systems 93
C.1 Introduction ................................................................................................... 93
C.2 Applicability ................................................................................................... 93
C.3 Trustworthy Email Overlay ............................................................................ 93
C.4 Control Baselines .......................................................................................... 94
C.5 Additional/Expanded Controls ..................................................................... 108

x

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

List of Figures
Figure 2-1: Main Components Used for Email ................................................................ 3
Figure 2-2: Basic SMTP Connection Set-up.................................................................... 8
Figure 4-2: SMTP envelope header vs. message header ............................................. 29
Figure 4-3: Use of Cloud Email with Third Party Email Scanning .................................. 51
Figure 4-4: Two models for sending digitally signed mail. ............................................. 54
Figure 5-1: Example of X.509 Certificate....................................................................... 61
Figure 6-1: Inbound email "pipeline" for UBE filtering.................................................... 75
Figure 6-2: Outbound email "pipeline" for UBE filtering ................................................. 76
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

List of Tables
Table 2-1: Comparison of S/MIME and OpenPGP operations ...................................... 13
Table 4-1: SPF Mechanisms ......................................................................................... 31
Table 4-2: SPF Mechanism Qualifiers ........................................................................... 31
Table 4-3: Recommended Cryptographic Key Parameters ........................................... 36
Table 4-4: DKIM Signature Tag and Value Descriptions ............................................... 37
Table 4-5: DKIM RR Tag and Value Descriptions ......................................................... 39
Table 4-6: DMARC RR Tag and Value Descriptions ..................................................... 44
Table 4-7: Common relay techniques and their impact on domain-based authentication............................................................................................................................... 51
Table 5-1: MTA-STS Resource Record Tags and Descriptions .................................... 67
Table 5-2: MTA-STS Policy Tags and Descriptions ...................................................... 68
Table 5-3: Comparing DANE and MTA-STS ................................................................. 69
Table 5-4: TLS Reporting Value Tags and Descriptions ............................................... 70
Table C-1: Overlay Control Baselines ........................................................................... 94xi

NIST SP 800-177 REV. 1

1

Introduction

1.1

What This Guide Covers

TRUSTWORTHY EMAIL

�is guide provides recommendations for deploying protocols and technologies that improve thetrustworthiness of email. �ese recommendations reduce the risk of spoofed email being used as
an attack vector and reduce the risk of email contents being disclosed to unauthorized parties.
�ese recommendations cover both the email sender and receiver.
Several of the protocols discussed in this guide use technologies beyond the core email protocols
and systems. �ese include the Domain Name System (DNS), Public Key Infrastructure (PKI)
and other core Internet protocols. �is guide discusses how these systems can be used to provide
security services for email.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

1.2

What This Guide Does Not Cover�is guide views email as a service, and thus it does not discuss topics such as individual server
hardening, conﬁguration and network planning. �ese topics are covered in NIST Special
Publication 800-45, Version 2 of February 2007, Guidelines on Electronic Mail Security [SP80045]. �is guide should be viewed as a companion document to SP 800-45 that provides more
updated guidance and recommendations that covers multiple components. �is guide attempts toprovide a holistic view of email and will only discuss individual system recommendations as
examples warrant.
Likewise, this guide does not give speciﬁc conﬁguration details for email components. �ere area variety of hardware and software components that perform one or multiple email related tasks
and it would be impossible to list them all in one guide. �is guide will discuss protocols andconﬁguration in an implementation neutral manner and administrators will need to consult theirsystem documentation on how to execute the guidance for their speciﬁc implementations.
1.3

Document Structure

�e rest of the document is presented in the following manner:•

Section 2: Discusses the core email protocols and the main components such as Mail
Transfer Agents (MTA) and Mail User Agents (MUA), and cryptographic email formats.

•

Section 3: Discusses the threats against an organization's email service such as phishing,spam and denial of service (DoS).

•

Section 4: Discusses the protocols and techniques a sending domain can use toauthenticate valid email senders for a given domain. �is includes protocols such as
Sender Policy Framework (SPF), DomainKeys Identiﬁed Mail (DKIM) and Domainbased Message and Reporting Conformance (DMARC).

1

NIST SP 800-177 REV. 1

1.4

TRUSTWORTHY EMAIL•

Section 5: Discusses server-to-server and end-to-end email authentication andconﬁdentiality of message contents. �is includes email sent over Transport Layer
Security (TLS), Secure Multipurpose Internet Mail Extensions (S/MIME) and OpenPGP.

•

Section 6: Discusses technologies to reduce unsolicited and (often) malicious email
messages sent to a domain.

•

Section 7: Discusses email security as it relates to end users and the ﬁnal hop between
local mail delivery servers and email clients. �is includes Internet Message AccessProtocol (IMAP), Post Oﬃce Protocol (POP3), and techniques for email encryption.
Conventions Used in this Guide

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

�roughout this guide, the following format conventions are used to denote special use text:
keyword - �e text relates to a protocol keyword or text used as an example.

Security Recommendation: - Denotes a recommendation that administrators should noteand account for when deploying the given protocol or security feature.
URLs are also included in the text and references to guide readers to a given website or online
tool designed to aid administrators. �is is not meant to be an endorsement of the website or any
product/service oﬀered by the website publisher. All URLs were considered valid at the time ofwriting.

2

NIST SP 800-177 REV. 1

2

Elements of Email

2.1

Email Components

TRUSTWORTHY EMAIL�ere are a number of software components used to produce, send and transfer email. �ese
components can be classiﬁed as clients or servers, although some components act as both. Some
components are used interactively, and some are completely automated. In addition to the corecomponents, some organizations use special purpose components that provide a speciﬁc set of
security features. �ere are also other components used by mail servers when performing
operations. �ese include the Domain Name System (DNS) and other network infrastructure
pieces.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Fig 2-1 shows the relationship between the email system components on a network, which aredescribed below in greater detail.

Figure 2-1: Main Components Used for Email

2.1.1

Mail User Agents (MUAs)

Most end users interact with their email system via a Mail User Agent (MUA). A MUA is a
software component (or web interface) that allows an end user to compose and send messages
and to one or more recipients. A MUA transmits new messages to a server for further processing(either ﬁnal delivery or transfer to another server). �e MUA is also the component used by end
users to access a mailbox where in-bound emails have been delivered. MUAs are available for avariety of systems including mobile hosts. �e proper secure conﬁguration for a MUA depends
on the MUA in question and the system it is running on. Some basic recommendations can befound in Section 7.
MUAs may utilize several protocols to connect to and communicate with email servers, (seeSection 2.3.2 below). �ere may also be other features as well such as a cryptographic interface
for producing encrypted and/or digitally signed email.

3

NIST SP 800-177 REV. 1

2.1.2

TRUSTWORTHY EMAIL

Mail Transfer Agents (MTAs)

Email is transmitted, in a “store and forward” fashion, across networks via Mail Transfer Agents(MTAs). MTAs communicate using the Simple Mail Transfer Protocol (SMTP) described below
and act as both client and server, depending on the situation. For example, an MTA can act as aserver when accepting an email message from an end user's MUA, then act as a client inconnecting to and transferring the message to the recipient domain's MTA for ﬁnal delivery.
MTAs can be described with more specialized language that denotes speciﬁc functions:This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1•

Mail Submission Agents (MSA): An MTA that accepts mail from MUAs (usually after
authenticating the sender) and begins the transmission process by sending it to a MTA for
further processing. Often the MSA and ﬁrst-hop MTA is the same process, just fulﬁllingboth roles.

•

Mail Delivery Agent (MDA): An MTA that receives mail from an organization's
inbound MTA and ultimately places the message in a speciﬁc mailbox. Like the MSA,
the MDA could be a combined in-bound MTA and MDA component.

Mail servers may also perform various security functions to prevent malicious email from being
delivered or include authentication credentials such as digital signatures (see Sender Policy
Framework Section 4.3 and DomainKeys Identified Mail (DKIM) Section 4.5). �ese security
functions may be provided by other components that act as lightweight MTAs or these functions
may be added to MTAs via ﬁlters or patches.
An email message may pass through multiple MTAs before reaching the ﬁnal recipient. Each
MTA in the chain may have its own security policy (which may be uniform within an
organization but may not be uniform) and there is currently no way for a sender to request aparticular level of security for the email message. However, there is work in progress 1 forspecifying how a client can request the use of TLS for message transmission.
2.1.3

Special Use Components

In addition to MUAs and MTAs, an organization may use one or more special purpose
components for a particular task. �ese components may provide a security function such as
malware ﬁltering or may provide some business process functionality such as email archiving orcontent ﬁltering. �ese components may exchange messages with other parts of the email
infrastructure using all or part of SMTP (see Section 2.3.1) or use another protocol altogether.
Given the variety of components, there is no one single set of conﬁgurations for an administrator
to deploy, and diﬀerent organizations have deployed very diﬀerent email architectures. An

1 J. Fenton. SMTP Require TLS Option. Work in Progress. https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-require-tls/.

4

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

administrator should consult the documentation for their given component and their existing sitespeciﬁc architecture.
2.1.4

Special Considerations for Cloud and Hosted Service Customers

Organizations that outsource their email service (whole or in part) may not have direct access to
MTAs, Authoritative DNS servers, or any possible special use components. In cases of Email asa Service (EaaS), the service provider is responsible for the email infrastructure. Customers ofInfrastructure as a Service (IaaS) may have suﬃcient access privileges to conﬁgure their email
servers themselves. In either architecture, the enterprise may have complete conﬁguration control
over MUAs in use.
2.1.5

Email Server and Related Component ArchitectureThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

How an organization architects its email infrastructure is beyond the scope of this document. It is
up to the organization and administrators to identify key requirements (availability, security, etc.)
and available product or service oﬀerings to meet those requirements. Federal IT administrators
also need to take relevant federal IT policies into account when acquiring and deploying email
systems.
Guidance for deploying and conﬁguring an MTA for federal agency use exists as NIST SP 80045 Guidelines on Electronic Mail Security [SP800-45]. In addition, the Dept. of Homeland
Security (DHS) has produced the Email Gateway Reference Architecture [REFARCH] foragencies to use as a guide when setting up or modifying the email infrastructure for an agency.
2.2

Related Components

In addition to MUAs and MTAs, there are other network components used to support the email
service for an organization. Most obviously is the physical infrastructure: the cables, wirelessaccess points, routers and switches that make up the network. In addition, there are network
components used by email components in the process of completing their tasks. �is includes the
DNS, Public Key Infrastructure (PKI), and network security components that are used by theorganization.
2.2.1

Domain Name System (DNS)

�e DNS is a global, distributed database and associated lookup protocol. DNS is used to map apiece of information (most commonly a domain name) to an IP address or some other network
information used by a computer system. �e DNS is used by MUAs to ﬁnd MSAs and by MTAs
to ﬁnd the IP address of the next-hop server for mail delivery. Sending MTAs query DNS for the
Mail Exchange Resource Record (MX RR) of the recipient's domain (the part of an email
address to the right of the “@” symbol) in order to ﬁnd the receiving MTA to contact.
In addition to the “forward” DNS (translate domain names to IP addresses or other data), there isalso the “reverse” DNS tree that is used to map IP addresses to their corresponding DNS name,or other data. Traditionally, the reverse tree is used to obtain the domain name for a given client
based on the source IP address of the connection, but it is also used as a crude, highly imperfect
5

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

authentication check. A host compares the forward and reverse DNS trees to check that the
remote connection is likely valid and not a potential attacker abusing a valid IP address block.
�is can be more problematic in IPv6, where even small networks can be assigned very large
address blocks. Email anti-abuse consortiums such as the Messaging, Malware Mobile AntiAbuse Working Group (M3AAWG) recommend that enterprises should make sure that DNS
reverse trees identify the authoritative mail servers for a domain [M3AAWG].

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

�e DNS is also used as the publication method for protocols designed to protect email andcombat malicious, spoofed email. Technologies such as SPF, DKIM and other use the DNS to
publish policy artifacts or public keys that can be used by receiving MTAs to validate that agiven message originated from the purported sending domain's mail servers. �ese protocols are
discussed in Section 4. In addition, there are new proposals to encode end-user certiﬁcates or
public keys (for S/MIME or OpenPGP) in the DNS using a mailbox as the hostname. �ese
protocols are discussed in Section 5.3.
A third use of the DNS with email is with reputation services. �ese services provide information
about the authenticity of an email based on the purported sending domain or originating IP
address. �ese services do not rely on the anti-spooﬁng techniques described above but throughhistorical monitoring, domain registration history, and other information sources. �ese services
are often used to combat unsolicited bulk email (i.e., spam) and malicious email that could
contain malware or links to subverted websites.
�e Domain Name System Security Extensions (DNSSEC) [RFC4033] provides cryptographic
security for DNS queries. Without security, DNS can be subjected to a variety of spooﬁng andman-in-the-middle attacks. Recommendations for deploying DNS in a secure manner are beyond
the scope of this document. Readers are directed to NIST SP 800-81 [SP800-81] forrecommendations on deploying DNSSEC.
2.2.2

Enterprise Perimeter Security Components

Organizations may utilize security components that do not directly handle email but may
perform operations that aﬀect email transactions. �ese include network components likeﬁrewalls, Intrusion Detection Systems (IDS) and similar malware scanners. �ese systems may
not play any direct role in the sending and delivering of email but may have a signiﬁcant impact
if misconﬁgured. �is could result in legitimate SMTP connections being denied and the failureof valid email to be delivered. Network administrators should take the presence of these systems
into consideration when making changes to an organization's email infrastructure. �is document
makes no speciﬁc recommendations regarding these peripheral components.
2.2.3

Public Key Infrastructure (PKI)

Organizations that send and receive S/MIME or OpenPGP protected messages, as well as thosethat use TLS, will also need to rely on the certiﬁcate infrastructure (S/MIME) or key server
ecosystem (OpenPGP) used with these protocols. �ese infrastructures do not always require thedeployment of a dedicated system, but does require administrator time to obtain, conﬁgure anddistribute security credentials to end-users.
6

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

X.509 certiﬁcates can be used to authenticate one (or both) ends of a TLS connection when
SMTP runs over TLS (usually MUA to MTA). S/MIME also uses X.509 certiﬁcates [RFC5280]
to certify and store public keys used to validate digital signatures and encrypt email. �e Internet
X.509 Public Key Infrastructure Certiﬁcate and Certiﬁcate Revocation List (CRL) Proﬁle iscommonly called PKIX and is speciﬁed by [RFC5280]. Certiﬁcate Authorities (CA) (or theorganization itself) issues X.509 certiﬁcates for an individual end-user or enterprise/business role
(performed by a person or not) that sends email (for S/MIME). Recommendations for S/MIME
protected email are given in Section 5. Recommendations for SMTP over TLS are given in
Section 5. Federal agency network administrators should also consult NIST SP 800-57 Part 3[SP800-57P3] and the Federal PKI Key Recovery Policy [FPKIKRP] for further guidance on
cryptographic parameters and deployment of any PKI components and credentials within an
organization.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

2.3

Email protocols

�ere are two types of protocols used in the transmission of email. �e ﬁrst are the protocols
used to transfer messages between MTAs and their end users (using MUAs). �e second is the
protocol used to transfer messages between mail servers.
�is guide is not meant to be an in-depth discussion of the protocols used in email. �ese
protocols are discussed here simply for background information.
2.3.1

Simple Mail Transfer Protocol (SMTP)

Email messages are transferred from one mail server to another (or from an MUA to
MSA/MTA) using SMTP. SMTP was originally speciﬁed in 1982 in [RFC821] and has
undergone several revisions, the most current being [RFC5321]. SMTP is a text-based clientserver protocol where the client (email sender) contacts the server (next-hop MTA) and issues a
set of commands to tell the server about the message to be sent, and then transmits the message
itself. �e majority of these commands are ASCII text messages sent by the client and a resulting
return code (also ASCII text) returned by the server. �e basic SMTP connection procedure isshown below in Figure 2-2:

7

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Client connects to port 25
Server: 220 mx.example.com
Client: HELO mta.example.net
S: 250 Hello mta.example.net, I am glad to meet you
C: MAIL FROM:<alice@example.org>
S: 250 Ok
C: RCPT TO:<bob@example.com>
S: 354 End data with <CR><LF>.<CR><LF>
Client sends message headers and body
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye
Server closes the connection
Figure 2-2: Basic SMTP Connection Set-up

In the above, the client initiates the connection using TCP over port 25 2. After the initialconnection, the client and server perform a series of SMTP transactions to send the message.
�ese transactions take the form of ﬁrst stating the return address of the message (known as thereturn path) using the MAIL command, then the recipient(s) using the RCPT command andending with the DATA command which contains the header and body of the email message.
After each command the server responds with either a positive or negative (i.e., error) code.
SMTP servers can advertise the availability of options during the initial connection. �ese
extensions are currently deﬁned in [RFC5321]. �ese options usually deal with the transfer of theactual message and will not be covered in this guide except for the STARTTLS option. �isoption advertised by the server is used to indicate to the client that Transport Layer Security(TLS) is available. SMTP over TLS allows the email message to be sent over an encryptedchannel to protect against monitoring a message in transit. Recommendations for conﬁguring
SMTP over TLS are given in Section 5.2.
2.3.2

Mail Access Protocols (POP3, IMAP, MAPI/RPC)

MUAs typically do not use SMTP when retrieving mail from an end-user's mailbox, only forsubmission. MUAs use another client-server protocol to retrieve the mail from a server for
display on an end-user's host system. �ese protocols are commonly called Mail AccessProtocols and are either Post Oﬃce Protocol (POP) or Internet Message Access Protocol(IMAP). Most modern MUAs support both protocols but an enterprise service may restrict theuse of one in favor of a single protocol for ease of administration or other reasons.
Recommendations for the secure conﬁguration of these protocols are given in Section 7.

2

Although MUAs often use TCP port 587 when submitting email to be sent.

8

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

POP version 3 (POP3) [STD35] is the simpler of the two protocols and typically downloads all
mail for a user from the server, then deletes the copy on the server, although there is an option tomaintain it on the server. POP3 is similar to SMTP, in that the client connects to a port (normallyport 110 or port 995 when using TLS) and sends ASCII commands, to which the server
responds, only instead of sending messages, it retrieves messages from the MTA. When thesession is complete, the client terminates the connection. POP3 transactions are normally done in
the clear, but an extension is available to do POP3 over TLS using the STLS command, which isvery similar to the STARTTLS option in SMTP. Clients may connect initially over port 110 andinvoke the STLS command, or alternatively, most servers allow TLS by default connections on
port 995.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

IMAP [RFC3501] is an alternative to POP3 but includes more built-in features that make it more
appealing for enterprise use. IMAP clients can download email messages, but the messages
remain on the server. �is and the fact that multiple clients can access the same mailbox
simultaneously mean that end-users with multiple devices (laptop and smartphone for example),can keep their email synchronized across multiple devices. Like POP3, IMAP also has the ability
to secure the connection between a client and a server. Traditionally, IMAP uses port 143 withno encryption. Encrypted IMAP runs over port 993, although modern IMAP servers also support
the STARTTLS option on port 143.
In addition to POP3 and IMAP, there are other proprietary protocols in use with certain
enterprise email implementations. Microsoft Exchange clients 3 can use the Messaging
Application Programming Interface (MAPI/RPC) to access a mailbox on a Microsoft Exchange
server (and some other compatible implementations). Some cloud providers require clients toaccess their cloud-based mailbox using a web portal as the MUA instead of a dedicated email
client. With the exception of Microsoft’s Outlook Web Access, most web portals use IMAP toaccess the user’s mailbox.
2.3.3

Internet Email Addresses

Two distinct email addresses are used when sending an email via SMTP: the SMTP MAIL
FROM address and the email header FROM address. The SMTP envelope MAIL FROM (alsosometimes referred to as the RFC5321.From, or the return-path address, or envelope From:) isfrom address used in the client SMTP mail from: command as shown in Fig. 2-2 above. Thisemail address may be altered by a sending MTA and may not always match the email address ofthe original sender. In the rest of this document, the term envelope-From: will be used. The
second is the sender email address (sometimes referred to as the RFC5322.From). This is theaddress end-users see in the message header. In the rest of this document, the term messageFrom: will be used to denote this email address. The full details of the syntax and semantics ofemail addresses are defined in [RFC3696], [RFC5321] and [RFC5322].

3

Administrators should consult their implementation's version-specific documentation on the correct security
configuration.

9

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILBoth types of contemporary email addresses consist of a local-part separated from a domain-part(a fully-qualified domain name) by an at-sign ("@") (e.g., local-part@domain-part). Typically,
the local-part identifies a user of the mail system or server identified by the domain-part. The
semantics of the local-part are not standardized, which occasionally causes confusion among
both users and developers. 4 The domain-part is typically a fully qualified domain name of thesystem or service that hosts the user account that is identified by the local-part (e.g.,
user@example.com).

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

While the user@example.com is by far the most widely used form of email address, otherforms of addresses are sometimes used. For example, the local-part may include “subaddressing” that typically specifies a specific mailbox/folder within a user account (e.g.,user+folder@example.com). Exactly how such local-parts are interpreted can vary acrossspecific mail system implementations. The domain-part can refer to a specific MTA server, thedomain of a specific enterprise or email service provider (ESP).
The remainder of this document will use the terms email-address, local-part and domain-part torefer the Internet email addresses and their component parts.
2.4

Email Formats

Email messages may be formatted as plain text or as compound documents containing one ormore components and attachments. Modern email systems layer security mechanisms on top ofthese underlying systems.
2.4.1

Email Message Format: Multi-Purpose Internet Mail Extensions (MIME)Internet email was originally sent as plain text ASCII messages [RFC2822]. �e Multi-purpose
Internet Mail Extensions (MIME) [RFC2045] [RFC2046] [RFC2047] allows email to contain
non-ASCII character sets as well as other non-text message components and attachments.
Essentially MIME allows for an email message to be broken into parts, with each part identiﬁedby a content type. Typical content types include text/plain (for ASCII text), image/jpeg,
text/html, etc. A mail message may contain multiple parts, which themselves may containmultiple parts, allowing MIME-formatted messages to be included as attachments in other
MIME-formatted messages. �e available types are listed in an IANA registry5 for developers,
but not all may be understood by all MUAs.
2.4.2

Security in MIME Messages (S/MIME)

�e Secure Multi-purpose Internet Mail Extensions (S/MIME) is a set of widely implemented
proposed Internet standards for cryptographically securing email [RFC5750] [RFC5751].
S/MIME provides authentication, integrity and non-repudiation (via digital signatures) andconﬁdentiality (via encryption). S/MIME utilizes asymmetric keys for cryptography (i.e., public
4 For example, on some systems the local-parts local-part, lo.cal-part, and local-part+special represent the same mailbox orusers, while on other systems they are different.

5

http://www.iana.org/assignments/media-types/media-types.xhtml

10

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

key cryptography) where the public portion is normally encoded and presented as X.509 digital
certiﬁcates.
With S/MIME, signing digital signatures and message encryption are two distinct operations:messages can be digitally signed, encrypted, or both digitally signed and encrypted (Figure 2-5).
Because the process is ﬁrst to sign and then encrypt, S/MIME is vulnerable to re-encryption
attacks 6; a protection is to include the name of the intended recipient in the encrypted message.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Figure 2-3: S/MIME Messages can be signed, encrypted, or both signed and encrypted

2.4.3

Pretty Good Privacy (PGP/OpenPGP)

OpenPGP [RFC3156] [RFC4880] is an alternative proposed Internet standard for digitallysigning and encrypting email. OpenPGP is an adaptation of the message format implemented by
the Pretty Good Privacy (PGP) email encryption system that was ﬁrst released in 1991. Whereas
the PGP formats were never formally speciﬁed, OpenPGP speciﬁes open, royalty-free formats
for encryption keys, signatures, and messages. Today the most widely used implementation of
OpenPGP is Gnu Privacy Guard (gpg) 7, an open source command-line program that runs on
many platforms, with APIs in popular languages such as C, Python and Perl. Most desktop andweb-based applications that allow users to send and receive OpenPGP-encrypted mail rely on
gpg as the actual cryptographic engine.
OpenPGP provides similar functionality as S/MIME, with three signiﬁcant diﬀerences:•

Key Certiﬁcation: Whereas X.509 certiﬁcates are issued by Certiﬁcate Authorities (orlocal agencies that have been delegated authority by a CA to issue certiﬁcates), users
generate their own OpenPGP public and private keys and then solicit signatures for their
public keys from individuals or organizations to which they are known. Whereas X.509
certiﬁcates can be signed by a single party, OpenPGP public keys can be signed by any

6 Don Davis. 2001. Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML. In Proceedings of theGeneral Track: 2001 USENIX Annual Technical Conference, Yoonho Park (Ed.). USENIX Association, Berkeley, CA,
USA, 65-78.
7 https://www.gnupg.org/

11

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

number of parties. Whereas X.509 certiﬁcates are trusted if there is a valid PKIX chain toa trusted root, an OpenPGP public key is trusted if it is signed by another OpenPGP
public key that is trusted by the recipient. �is is called the “Web-of-Trust.”•

Key Distribution: OpenPGP does not always include the sender’s public key with eachmessage, so it may be necessary for recipients of OpenPGP-messages to separately obtainthe sender’s public key in order to verify the message or respond to the sender with an
encrypted message. Many organizations post OpenPGP keys on SSL-protected websites;
people who wish to verify digital signatures or send these organizations encrypted mailneed to manually download these keys and add them to their OpenPGP clients.
Essentially this approach exploits the X.509 certiﬁcate infrastructure to certify OpenPGP
keys, albeit with a process that requires manual downloading and veriﬁcation.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

OpenPGP keys may also be registered with the OpenPGP “public key servers” (described
below). OpenPGP “public key servers” are internet connected systems that maintain adatabase of PGP public keys organized by email address. Anyone may post a public key
to the OpenPGP key servers, and that public key may contain any email address. Some
OpenPGP clients can search the key servers for all of the keys that belong to a given
email address and download the keys that match. Because there are no access controls on
the servers, attackers are free to submit a fraudulent public key, and it is the responsibilityof the person or program that downloads the public key to validate it.
•

Key and Certiﬁcate Revocation: S/MIME keys are revoked using the PKIX revocation
infrastructure of Certiﬁcate Revocation Lists [RFC5280] and the Online Certiﬁcate Status
Protocol (OCSP) [RFC6960]. �ese protocols allow a certiﬁcate to be revoked at any
time by the CA. With OpenPGP, in contrast a key is only allowed to be revoked by the
key holder, and only with a Key Revocation Certiﬁcate. �us, an OpenPGP user who
loses access to a private key has no way to revoke the key if a Key Revocation Certiﬁcate
was not prepared in advance. If a Key Revocation Certiﬁcate does exist, the certiﬁcate
can be uploaded to a PGP Key Server, OpenPGP key servers are generally not checked
by a client that already has a copy of an OpenPGP key. �us, is it not clear how relying
parties learn that an OpenPGP key has been revoked.

�e Web-of-Trust is designed to minimize the problems of the key server. After an OpenPGP
user downloads all of the keys associated with a particular email address, the correct OpenPGP
certiﬁcate is selected by the signatures that it carries. Because Web-of-Trust supports arbitrary
validation geometries, it allows both the top-down certiﬁcation geometry of X.509 as well as
peer-to-peer approaches. However, studies have demonstrated that users ﬁnd this process
confusing [WHITTEN1999], and the Web-of-Trust has not seen widespread adoption.
An alternative way to publish OpenPGP keys using the DNS is described in Section 5.3.2,
OpenPGP, although the technique has not yet been widely adopted.
Like S/MIME, among the biggest hurdles of deploying OpenPGP are the need for users to create
certiﬁcates in advance, the diﬃculty of obtaining the certiﬁcate of another user in order to send
12

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILan encrypted message and incorporating this seamlessly into mail clients. However, in OpenPGP
this diﬃculty impacts both digital signatures and encryption, since OpenPGP messages may notinclude the sender’s public key (or generated certiﬁcate).
�ese diﬀerences are summarized in Table 2-1.
Table 2-1: Comparison of S/MIME and OpenPGP operations

ActionThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

S/MIME

OpenPGPKey creation

Users obtain X.509
certiﬁcates from employer(e.g., a US Government PIV
card [FIPS 201]) or a
Certiﬁcate Authority

Users make their own
public/private key pairs andhave them certiﬁed byassociates.

Certiﬁcate Veriﬁcation

PKIX: Certiﬁcates are
veriﬁed using trusted rootsthat are installed on the end
user’s computer.

Web-of-Trust: Keys can besigned by any number ofcertiﬁers. Users base theirtrust decisions on whether or
not they “trust” the keys thatwere used to sign the key.

Certiﬁcate Revocation

Certiﬁcates can be revokedby the CA or Issuer. Methods
exist to publish revokedstatus of key (e.g., Certiﬁcate
Revocation List, etc.).

Keys/Certiﬁcates can only be
revoked by the public key’s
owner. Few options to signal
key revocation and nouniform way for clients to seethat a key has been revoked.

Obtaining public keys

Querying an LDAP server or
exchanging digitally signed
email messages.

PGP public key server or outof-band mechanisms (e.g.,
posting a public key on a web
page.)

2.5

Secure Web-Mail Solutions

Whereas S/MIME and OpenPGP provide a security overlay for traditional Internet email, someorganizations have adopted secure web-mail systems as an alternative approach for sending
encrypted e-mail messages between users. Secure web-mail systems can protect email messages
solely with host-based security, or they can implement a cryptographic layer using S/MIME,
OpenPGP, or other algorithms, such as the Boneh-Franklin (BF) and Boneh-Boyen (BB1)
Identity-Based Encryption (IBE) algorithms [RFC5091] [RFC5408] [RFC5409].
Secure webmail systems can perform message decryption at the web server or on the end-user’sclient. In general, these systems are less secure than end-to-end systems because the private key
is under the control of the web server, which also has access to the encrypted message. Thesesystems cannot ensure non-repudiation since the server has direct access to the signing key.
13

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

An exception is webmail-based systems that employ client-side software to make use of a private
key stored at the client—for example, a webmail plug-in that allows the web browser to makeuse of a private key stored in a FIPS-201 compliant smartcard. In these cases, the message isdecrypted and displayed at the client, and the server does not access the decrypted text of themessage.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

14

NIST SP 800-177 REV. 1

3

TRUSTWORTHY EMAILSecurity Threats to an Email Service

�e security threats to email service discussed in this section are related to canonical functions of
the service such as: message submission (at the sender end), message transmission (transfer) andmessage delivery (at the recipient end).
�reats to the core email infrastructure functions can be classiﬁed as follows:•••This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Integrity-related threats to the email system, which could result in unauthorized accessto an enterprises’ email system, or spoofed email used to initiate an attack.
Conﬁdentiality-related threats to email, which could result in unauthorized disclosureof sensitive information.
Availability-related threats to the email system, which could prevent end users frombeing able to send or receive email.

�e security threats due to insuﬃciency of core security functions are not covered. �ese include
threats to support infrastructure such as network components and ﬁrewalls, host OS and systemthreats, and potential attacks due to lax security policy at the end user or administrator level (e.g.,poor password choices). �reats directed to these components and recommendations forenterprise security policies are found in other documents.
3.1

Integrity-related Threats

Integrity in the context of an email service assumes multiple dimensions. Each dimension can be
the source of one or more integrity-related threats:
•
•
•
•
•
•
3.1.1

Unauthorized email senders within an organization’s IP address block
Unauthorized email receivers within an organization’s IP address block
Unauthorized email messages from a valid DNS domain
Tampering/Modiﬁcation of email content from a valid DNS domain
DNS Cache Poisoning
Phishing and spear phishing
Unauthorized Email Senders within an Organization’s IP Address Block

An unauthorized email sender is some MSA or MTA that sends email messages that appear to befrom a user in a speciﬁc domain (e.g., user@example.com) but is not identiﬁed as a legitimate
mail sender by the organization that runs the domain.
�e main risk that an unauthorized email sender may pose to an enterprise is that a sender may
be sending malicious email and using the enterprise’s IP address block and reputation to avoid
anti-spam ﬁlters. A related risk is that the sender may be sending emails that present themselves
as legitimate communications from the enterprise itself.
�ere are many scenarios that might result in an unauthorized email sender:
15

NIST SP 800-177 REV. 1•••

TRUSTWORTHY EMAIL

Malware present on an employee’s laptop may be sending out email without theemployee’s knowledge.
An employee (or intruder) may conﬁgure and operate a mail server without authorization.
A device such as a photocopier or an embedded system may contain a mail sender that is
attempting to send mail without anyone’s knowledge.

One way to mitigate the risk of unauthorized senders is for the enterprise to block outbound port
25 (used by SMTP) for all hosts except those authorized to send mail. In addition, domains candeploy the sender authentication mechanism described in Section 4.3 (Sender Policy Framework(SPF)), using which senders can assert the IP addresses of the authorized MTAs for their domainusing a DNS Resource Record.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Security Recommendation 3-1: To mitigate the risk of unauthorized sender, an enterpriseadministrator should block outbound port 25 (except for authorized mail senders) and look to
deploy ﬁrewall or intrusion detection systems (IDS) that can alert the administrator when an
unauthorized host is sending mail via SMTP to the Internet.

�e proliferation of virtualization greatly increases the risk that an unauthorized virtual server
running on a virtual machine (VM) within a particular enterprise might send email. �is isbecause VMs may be conﬁgured (by default or otherwise) to run email servers (MTAs), andmany VM hypervisors use network address translation (NAT) to share a single IP address
between multiple VMs. �us, a VM that is unauthorized to send email may share an IP address
with a legitimate email sender. To prevent such a situation, ensure that VMs that are authorized
mail senders and those VMs that are not authorized, do not share the same set of outbound IP
addresses. An easy way to do this is assigning these VMs to diﬀerent NAT instances.
Alternatively, internal ﬁrewall rules can be used to block outbound port 25 for VMs that are notauthorized to send outbound email.
Security Recommendation 3-2: Systems that are not involved in the organization’s email
infrastructure should be conﬁgured to not run Mail Transfer Agents (MTAs). Internal systems
that need to send mail should be conﬁgured to use a trusted internal MSA.
3.1.2

Unauthorized Email Receiver within an Organization’s IP Address Block

Unauthorized mail receivers are a risk to the enterprise IT security posture because they may be
an entry point for malicious email. If the enterprise email administrator does not know of theunauthorized email receiver, they cannot guarantee the server is secure and provide theappropriate mail handling rules for the enterprise such as scanning for malicious links/code,ﬁltering spam, etc. �is could allow malware to bypass the enterprise perimeter defenses andenter the local network undetected.
Security Recommendation 3-3: To mitigate the risk of unauthorized receivers, an enterpriseadministrator should block inbound port 25 and look to deploy ﬁrewall or intrusion detection

16

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

systems (IDS) that can alert the administrator when an unauthorized host is accepting mail via
SMTP from the Internet.
3.1.3

Unauthorized Email Messages from a Valid DNS Domain (Address Spoofing)

Just as organizations face the risk of unauthorized email senders, they also face the risk that theymight receive email from an unauthorized sender. �is is sometimes called “spooﬁng,” especiallywhen one group or individual sends mail that appears to come from another. In a spooﬁng attack,the adversary spoofs messages using another (sometimes even non-existent) user’s email
address.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

For example, an attacker sends emails that purport to come from user@example.com, when infact the email messages are being sent from a compromised home router. Spooﬁng the messageFrom: address is trivial, as the SMTP protocol [RFC2821] allows clients to set any messageFrom: address. Alternatively, the adversary can simply conﬁgure a MUA with the name andemail address of the spoofed user and send emails to an open SMTP relay (see [RFC2505] for a
discussion of open relays).
�e same malicious conﬁguration activity can be used to conﬁgure and use wrong, misleading or
malicious display names. When a display name that creates a degree of trust such as“Administrator” shows up on the email received at the recipient’s end, it might make therecipient reveal some sensitive information which the recipient would not normally do. �us, thespooﬁng threat/attack also has a social engineering dimension as well.
Section 4 discusses a variety of countermeasures for this type of threat. �e ﬁrst line of defense isto deploy domain-based authentication mechanisms (see Section 4). �ese mechanisms can beused to alert on or block email that was sent using a spoofed domain. Another end-to-end
authentication technique is to use digital signatures to provide integrity protection for email
headers. �e digital signature used should cover the header portion of the email message that
contains the address of the sender.
3.1.4

Tampering/Modification of Email Content

�e content of an email message, just like any other message content traveling over the Internet,
is liable to be altered in transit. Hence the content of the received email may not be the same aswhat the sender originally composed. �e countermeasure for this threat is for the sender todigitally sign the message, attach the signature to the plaintext message and for the receiver toverify the signature.
�ere are several solutions available to mitigate this risk by either encrypting the transmission ofemail messages between servers using Transport Layer Security (TLS) for SMTP or using an
end-to-end solution to digitally sign email between initial sender and ﬁnal receiver.
Recommendations for using TLS with SMTP are discussed in Section 5.2.1 and end-to-end
email encryption protocols are discussed in Section 4.6. �e use of digital signatures within the
S/MIME and OpenPGP protocols is described in section 5.3.

17

NIST SP 800-177 REV. 1

3.1.5

TRUSTWORTHY EMAILDNS Cache Poisoning

Email systems rely on DNS for many functions. Some of them are:••�e sending MTA uses the DNS to ﬁnd the IP address of the next-hop email server(assuming the To: address is not a local mailbox).
�e recipient email server (if domain-based email authentication is supported) uses the
DNS to look for appropriate records in the sending DNS domain either to authenticate thesending email server (using SPF) or to authenticate an email message for its origin
domain (using DKIM). See Section 5 for domain-based authentication mechanisms.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

�ere are risks to using the DNS as a publication mechanism for authenticating email. First,
those highly motivated to conduct phishing/spam campaigns, may attempt to spoof a given
domain’s DNS-based email authentication mechanisms in order to continue to deliver spoofedemail masquerading as the domain in question. �e second risk is that an attacker would spoof adomain’s DNS-based authentication mechanisms in order to disrupt legitimate email from thesource domain. For example, maliciously spooﬁng the SPF record of authorized mail relays, toexclude the domains legitimate MTAs, could result in all legitimate email from the target domain
being dropped by other MTAs. Lastly, a resolver whose cache has been poisoned can potentiallyreturn the IP address desired by an attacker, rather than the legitimate IP address of a querieddomain name. In theory, this allows email messages to be redirected or intercepted.
Another impact of a DNS server with a poisoned cache as well as a compromised web server isthat the users are redirected to a malicious server/address when attempting to visit a legitimate
web site. Although the visit to an illegitimate web site can occur by clicking on a link in a
received email, this use case has no direct relevance to integrity of an email service and hence is
outside the scope of this document.
As far as DNS cache poisoning is concerned, DNSSEC security extension [RFC4033][RFC4034] [RFC4035] can provide protection from these kinds of attacks since it ensures theintegrity of DNS resolution through an authentication chain from the root to the target domain of
the original DNS query. However, even the presence of a single non-DNSSEC aware server inthe chain can lead to a risk of compromise of the integrity of the DNS resolution.
3.1.6

Phishing and Spear Phishing

Phishing is the process of using a spoofed email to collect private information, distributemalware, or commit fraud. �is is done with the intention of committing identity theft, gaining
access to credit cards and bank accounts of the victim etc. Adversaries use a variety of tactics tomake the recipient of the email believe that they have received the phishing email from alegitimate user or a legitimate domain, including:•

Using a message-From: address that looks very close to one of the legitimate addresses
the user is familiar with or from someone claiming to be an authority (IT administrator,
manager, etc.). Or altering the display name (also known as the friendly name).
18

NIST SP 800-177 REV. 1••

TRUSTWORTHY EMAIL

Using the email’s content to present to the recipient an alarm, a ﬁnancial lure, orotherwise attractive situation, that either makes the recipient panic or tempts the recipient
into taking an action or providing requested information.
Sending the email from an email using a legitimate account holder’s software orcredentials, typically using a bot that has taken control of the email client or malware thathas stolen the user’s credentials (described in detail in Section 3.3.1 below)

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

As part of the email message, the recipient may usually be asked to click on a link to what
appears like a legitimate website, but in fact is a URL that will take the recipient into a spoofed
website set up by the adversary. If the recipient clicks on the embedded URL, the victim oftenﬁnds that the sign-in page, logos and graphics are identical to the legitimate website in theadversary-controlled website, thereby creating the trust necessary to make the recipient submit
the required information such as user ID and the password. Some attackers use web pages todeliver malware directly to the victim’s web browser.
In many instances, the phishing emails are generated in thousands without focus on proﬁle of thevictims. Hence, they will have a generic greeting such as “Dear Member”, “Dear Customer” etc.
A variant of phishing is spear phishing where the adversary is aware of, and speciﬁc about, thevictim’s proﬁle. More than a generic phishing email, a spear phishing email makes use of more
contextual information to make users believe that they are interacting with a legitimate source.
For example, a spear phishing email may appear to relate to some speciﬁc item of personal
importance or a relevant matter at the organization—for instance, discussing payroll
discrepancies or a legal matter. As in phishing, the ultimate motive is the same—to lure therecipient to an adversary-controlled website masquerading as a legitimate website to collectsensitive information about the victim or attack the victim’s computer.
�ere are two minor variations of phishing: clone phishing and whaling. Clone phishing is theprocess of cloning an email from a legitimate user carrying an attachment or link and thenreplacing the link or attachment alone with a malicious version and then sending altered email
from an email address spoofed to appear to come from the original sender (carrying the pretextof re-sending or sending an updated version). Whaling is a type of phishing speciﬁcally targetedagainst high proﬁle targets so that the resulting damage carries more publicity and/or ﬁnancial
rewards for the perpetrator is greater.
�e most common countermeasures used against phishing are domain-based checks such as SPF,
DKIM and DMARC (see Section 4). More elaborate is to design anti-phishing ﬁlters that can
detect text commonly used in phishing emails, recovering hidden text in images, intelligent word
recognition – detecting cursive, hand-written, rotated or distorted texts as well as the ability todetect texts on colored backgrounds. While these techniques will not prevent malicious email
sent using compromised legitimate accounts, they can be used to reduce malicious email sentfrom spoofed domains or spoofed “From:” addresses.

19

NIST SP 800-177 REV. 1

3.2

TRUSTWORTHY EMAIL

Confidentiality-related Threats

A conﬁdentiality-related threat occurs when the data stream containing email messages withsensitive information are accessible to an adversary. �e type of attack that underlies this threat
can be passive since the adversary only requires read access but not write access to the email
data being transmitted. �e two variations of this type of attack include:••

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1•

�e adversary may have access to the packets that make up the email message as they
move over a network. �is access may come in the form of a passive wiretapping or
eavesdropping attack.
Software may be installed on a MTA that makes copies of email messages and delivers
them to the adversary. For example, the adversary may have modiﬁed the target’s email
account so that a copy of every received message is forwarded to an email address
outside the organization.
�e valid receiver’s mail servers may be spoofed (or DNS MX reply spoofed), to get thesender to connect to a MTA controlled by an attacker.

Encryption is the best defense against eavesdropping attacks. Encrypting the email messages
either between MTAs (using TLS as described in Section 5) can thwart attacks involving packet
interception. End-to-end encryption (described in Section 5.3) can protect against both
eavesdropping attacks as well as MTA software compromise.
A second form of passive attack is a traﬃc analysis attack. In this scenario, the adversary is notable to directly interpret the contents of an email message, mostly due to the fact that themessage is encrypted. However, since inference of information is still possible in certain
circumstances (depending upon interaction or transaction context) from the observation of
external traﬃc characteristics (volume and frequency of traﬃc between any two entities) andhence the occurrence of this type of attack constitutes a conﬁdentiality threat.
Although the impact of traﬃc analysis is limited in scope, it is much easier to perform this attackin practice—especially if part of the email transmission media uses a wireless network, if packets
are sent over a shared network, or if the adversary has the ability to run network management ormonitoring tools against the victim’s network. TLS encryption provides some protection against
traﬃc analysis attacks, as the attacker is prevented from seeing any message headers. End-to-end
email encryption protocols do not protect message headers, as the headers are needed fordelivery to the destination mailbox. �us, organizations may wish to employ both kinds ofencryption to secure email from conﬁdentiality threats.
3.3

Availability-related Threats

An availability threat exists in the email infrastructure (or for that matter any IT infrastructure),
when potential events occur that prevent the resources of the infrastructure from functioning
according to their intended purpose. �e following availability-related threats exist in an email
infrastructure:••

Email Bombing,
Unsolicited Bulk Email (UBE) – also called “Spam,” and20

NIST SP 800-177 REV. 1

•
3.3.1

TRUSTWORTHY EMAIL

Availability of email servers.
Email Bombing

Email bombing is a type of attack that involves sending several thousands of messages to aparticular mailbox in order to cause overflow. These can be many large messages or a very large
number of small messages. Such a mailbox will become unusable for the legitimate email
account holder to access. No new messages can be delivered, and the sender receives an error
asking to resend the message. In some instances, the mail server may also crash.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

The motive for email bombing is denial of service (DoS). A DoS attack by definition either
prevents authorized access to resources or causes delay (e.g., long response times) of timecritical operations. Hence email bombing is a major availability threat to an email system since it
can potentially consume substantial Internet bandwidth as well as storage space in the message
stores of recipients. An email bombing attack can be launched in several ways.
�ere are many ways to perpetrate an email bombing attack, including:
•
•
•

•

An adversary can employ any (anonymous) email account to constantly bombard thevictim’s email account with arbitrary messages (that may contain very long large
attachments).
If an adversary controls an MTA, the adversary can run a program that automaticallycomposes and transmits messages.
An adversary can post a controversial or signiﬁcant oﬃcial statement to a large audience(e.g., a social network) using the victim’s return email address. Humans will read themessage and respond with individually crafted messages that may be very hard to ﬁlter
with automated techniques. �e responses to this posting will eventually ﬂood thevictim’s email account.
An adversary may subscribe the victim’s email address to many mailing lists(“listservers”). �e generated messages are then sent to the victim, until the victim’s
email address is unsubscribed from those lists.

Possible countermeasures for protection against email bombing are: (a) Use filters that are basedon the logic of filtering identical messages that are received within a chosen short span of timeand (b) configuring email receivers to block messages beyond a certain size and/or containing
attachments that exceed a certain size.
3.3.2

Unsolicited Bulk Email (Spam)

Spam is the internet slang for unsolicited bulk email (UBE). Spam refers to indiscriminately sent
messages that are unsolicited, unwanted, irrelevant and/or inappropriate, such as commercial
advertising in mass quantities. �us spam, generally, is not targeted towards a particular email
receiver or domain. However, when the volume of spam coming into a particular email domain
exceeds a certain threshold, it has availability implications since it results in increased network
traﬃc and storage space for message stores. Spam that looks for random gullible victims ortargets particular users or groups of users with malicious intent (gathering sensitive information
21

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

for physical harm or for committing ﬁnancial fraud) is called phishing. From the above
discussion of email bombing attacks, it should be clear that spam can sometimes be a type ofemail bombing.
Protecting the email infrastructure against spam is a challenging problem. �is is due to the factthat the two types of techniques currently used to combat spam have limitations. See Section 6
for a more detailed discussion of unsolicited bulk email.
3.3.3

Availability of Email Servers

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

�e email infrastructure, just like any other IT infrastructure, should provide for fault tolerance
and avoid single points of failure. A domain with only a single email server or a domain withmultiple email servers, but all located in a single IP subnet is likely to encounter availability
problems either due to software glitches in MTA, hardware maintenance issues or local data
center network problems. �e typical measures for ensuring high availability of email as aservice are: (a) Multiple MTAs with placement based on the email traﬃc load encountered by
the enterprise; and, (b) Distribution of email servers in diﬀerent network segments or evenphysical locations.
3.4

Summary of Threats and Mitigations

A summary of the email related threats to an enterprise is given in Table 3-1. �is includes
threats to both the email the receiver and the purported sender - often spoofed, and who may not
be aware an email was sent using their domain. Mitigations are listed in the ﬁnal column toreduce the risk of the attack being successful, or to prevent them.
Table 3-1 Email-based Threats and Mitigations

ThreatEmail sent by
unauthorized MTA inenterprise (e.g.,
malware botnet).

Impact on Purported
SenderImpact on Receiver

Mitigation

Loss of reputation,
valid email fromenterprise may beblocked as possible
spam/phishing attack.

UBE and/or email
containing malicious
links or attachments
may be delivered into
user inboxes.

Deployment of
domain-based
authentication
techniques (seeSection 4). Use ofdigital signatures
over email (seeSection 6). Blocking
outbound port 25 for
all non-mail sending
hosts.

22

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

Impact on Purported
SenderImpact on Receiver

Email message sent
using spoofed or
unregistered sending
domain.

Loss of reputation,
valid email fromenterprise may beblocked as possible
spam/phishing attack.

UBE and/or email
containing malicious
links or attachments
may be delivered into
user inboxes.

Deployment of
domain-based
authentication
techniques (seeSection 4). Use ofdigital signatures
over email (seeSection 6).

Email message sent
using forged sending
address or email
address (i.e.,
phishing, spear
phishing).

Loss of reputation,
valid email fromenterprise may beblocked as possible
spam/phishing attack.

UBE and/or email
containing malicious
links or attachments
may be delivered.
Users may
inadvertently divulge
sensitive information
or PII.

Deployment of
domain-based
authentication
techniques (seeSection 4). Use ofdigital signatures
over email (seeSection 6). DNSBlacklists (seeSection 7).

Email modiﬁed intransit.

Leak of sensitive
information or PII.

Leak of sensitive
information, alteredmessage may containmalicious
information.

Use of TLS toencrypt email transfer
between servers (seeSection 5). Use ofend-to-end email
encryption and/or
digital signatures (seeSection 7). Use of
DKIM to identify
message mods (seeSection 4.5).

Disclosure ofsensitive information(e.g., PII) via
monitoring andcapturing of email
traﬃc.

Leak of sensitive
information or PII.

Leak of sensitive
information.

Use of TLS toencrypt email transfer
between servers (seeSection 5). Use ofend-to-end email
encryption (seeSection 7).

Disclosure of
metadata of email
messages.

Possible privacy
violation.

Possible privacy
violation.

Use of TLS toencrypt email transfer
between servers (seeSection 5).

ThreatThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

23

Mitigation

NIST SP 800-177 REV. 1

Threat

TRUSTWORTHY EMAIL

Impact on Purported
SenderImpact on Receiver

Mitigation

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Unsolicited Bulk
Email (i.e., spam).

None, unlesspurported sender isspoofed.

UBE and/or email
containing malicious
links or attachments
may be delivered into
user inboxes.

Techniques toaddress UBE (seeSection 7).

DoS/DDoS attack
against an
enterprises’ email
servers.

Inability to send
email.

Inability to receive
email.

Multiple mail servers,
use of cloud-based
email providers. DNSBlacklists (seeSection 7).

Email containing
links to malicious
site or malware.

None, unlesspurported sending
domain spoofed.

Potential malware
installed onenterprise systems.

Techniques toaddress UBE (Section
7). “Detonationchambers” to open
links/attachments formalware scanning,
sanitization of
attachments, etc.
before delivery.

3.5

Security Recommendations Summary

Security Recommendation 3-1: To mitigate the risk of unauthorized sender, an enterpriseadministrator should block outbound port 25 (except for authorized mail senders) and look to
deploy ﬁrewall or intrusion detection systems (IDS) that can alert the administrator when an
unauthorized host is sending mail via SMTP to the Internet.
Security Recommendation 3-2: Systems that are not involved in the organization’s email
infrastructure should not be conﬁgured to run Mail Transfer Agents (MTAs). Internal systems
that need to send mail should be conﬁgured to use a trusted internal MSA.
Security Recommendation 3-3: To mitigate the risk of unauthorized receivers, an enterpriseadministrator should block inbound port 25 and look to deploy ﬁrewall or intrusion detection
systems (IDS) that can alert the administrator when an unauthorized host is accepting mail via
SMTP from the Internet.

24

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

4Authenticating a Sending Domain and Individual Mail Messages

4.1

Introduction

RFC 5322 deﬁnes the Internet Message Format (IMF) for delivery over the Simple Mail Transfer
Protocol (SMTP) [RFC5321], but in its original state any sender can write any envelope-From:
address in the header (see Section 2.3.3). �is envelope-From: address can however beoverridden by malicious senders or enterprise mail administrators, who may have organizational
reasons to rewrite the header, and so both [RFC 5321] and [RFC 5322] deﬁned From: addresses
can be aligned to some arbitrary form not intrinsically associated with the originating IP address.
In addition, any man in the middle attack can modify a header or data content. New protocols
were developed to detect these envelope-From: and message-From: address spooﬁng or
modiﬁcations.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Sender Policy Framework (SPF) [RFC4408] uses the Domain Name System (DNS) to allow
domain owners to create records that associate the envelope-From: address domain name with
one or more IP address blocks used by authorized MTAs. It is then a simple matter for areceiving MTA to check a SPF TXT record in the DNS. �is check would conﬁrm the purported
sender of a message is in the listed approved sending MTA is indeed authorized to transmit email
messages for the domain listed in the envelope-From: address. Mail messages that do not passthis check may be marked, quarantined or rejected. SPF is described in subsection 4.4 below.
�e DomainKeys Identiﬁed Mail (DKIM) [RFC6376] protocol allows a sending MTA todigitally sign selected headers and the body of the message with a RSA signature and include thesignature in a DKIM header that is attached to the message prior to transmission. �e DKIM
signature header ﬁeld includes a selector, which the receiver can use to retrieve the public key
from a record in the DNS to validate the DKIM signature over the message. So, validating thesignature assures the receiver that the message has not been modiﬁed in transit – other thanadditional headers added by MTAs en route which are ignored during the validation. Use of
DKIM also ties the email message to the domain publishing the public key, regardless of the
From: address (which could be diﬀerent). DKIM is detailed in subsection 4.5.
Deploying SPF and DKIM may curb illicit activity against a sending domain, but the sender getsno indication of the extent of the beneﬁcial (or otherwise) eﬀects of these policies. Sending
domain owners may choose to construct pairwise agreements with selected recipients tomanually gather feedback, but this is not a scalable solution. �e Domain-based Message
Authentication, Reporting and Conformance protocol (DMARC) [RFC7489] institutes such a
feedback mechanism, to let sending domain owners know the proportionate eﬀectiveness of their
SPF and DKIM policies, and to signal to receivers what action should be taken in various
individual and bulk attack scenarios. After setting a policy to advise receivers to deliver,quarantine or reject messages that fail both SPF and DKIM, email receivers then return DMARC
aggregate and/or failure reports of email dispositions to the domain owner, who can review theresults and potentially reﬁne the policy. DMARC is described in subsection 4.6.
While DMARC can do a lot to curb spooﬁng and phishing (Section 3.1.6 above), it does needcareful conﬁguration. Intermediaries that forward mail have many legitimate reasons to rewrite
25

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

headers, usually related to legitimate activities such as operating mailing lists, mail groups, and
end-user mail forwarding. It should be noted that mail server forwarding changes the source IP
address, and without rewriting the envelope-From: address, this can make SPF checks fail. On
the other hand, header rewriting, or adding a footer to mail content, may cause the DKIM
signature to fail. Both of these interventions can cause problems for DKIM validation and formessage delivery. Section 4.6 expands on the problems of mail forwarding, and its mitigations.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

SPF, DKIM and DMARC authenticate that the sending MTA is an authorized, legitimate senderof email messages for the domain-part of the envelope-From: (and message-From: for DMARC)
address, but these technologies do not verify that the email message is from a speciﬁc individual
or logical account. �at kind of assurance is provided by end-to-end security mechanisms such as
S/MIME (or OpenPGP). �e DKIM and S/MIME/OpenPGP signature standards are notinterfering: DKIM signatures go in the email header, while S/MIME/OpenPGP signatures arecarried as MIME body parts. �e signatures are also complementary: a message is typicallysigned by S/MIME or OpenPGP immediately after it is composed, typically by the sender’s
MUA, and the DKIM signature is added after the message passes through the sender’s MSA or
MTA.
�e interrelation of SPF, DKIM, DMARC, and S/MIME signatures are shown in the Figure 4-1
below:

26

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Figure 4-1: The interrelationship of DNSSEC, SPF, DKIM, DMARC andS/MIME for assuring message authenticity and integrity.

4.2

Visibility to End Users

As mentioned above, the domain-based authentication protocols discussed in this section were
designed with MTAs in mind. There was thought to be no need for information passed to the end
recipient of the email. The results of SPF and DKIM checks are not normally visible in MUA
components unless the end user views the message headers directly (and knows how to interpretthem). This information may be useful to some end users who wish to filter messages based onthese authentication results. [RFC7601] specifics how an MTA/MDA can add a new header to amessage upon receipt that provides status information about any authentication checks done by
the receiving MTA. Some MUAs make use of this information to provide visual cues (an icon,
text color, etc.) to end users that this message passed the MTAs checks and was deemed valid.
This does not explicitly mean that the email contents are authentic or valid, just that the email
passed the various domain-based checks performed by the receiving MTA.
Email administrators should be aware if the MUAs used in their enterprise can interpret andshow results of the authentication headers to end users. Email administrators should educate end
27

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

users about what the results mean when evaluating potential phishing/spam email as well as notassuming positive results means they have a completely secure channel.
4.3

Requirements for Using Domain-based Authentication Techniques for Federal
Systems

As of the time of writing of this guidance document, the DHS has called out the use of domainbased authentication techniques for email as Binding Operational Directive (BOD) 18-01[BOD18-01]. �is includes the techniques discussed below. �is section gives best-commonpractice guidance of the domain-based authentication techniques listed (but not described) in
BOD 18-01 and [FISMAMET]. �is document does not extend those requirements in anyway
but gives guidance on how to meet existing requirements.
4.4

Sender Policy Framework (SPF)

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Sender Policy Framework (SPF) is a standardized way for the domain of the envelope-From:
address to identify and assert the mail originators (i.e., mail senders) for a given domain. �esending domain does this by placing a specially formatted Text Resource Record (TXT RR) in
the DNS database for the domain. �e idea is that a receiving MTA can check the IP address ofthe connecting MTA against the purported sending domain (the domain-part of the envelopeFrom: address) and see if the domain vouches for the sending MTA. �e receiving MTA does
this by sending a DNS query to the purported sending domain for the list of valid senders.
SPF was designed to address phishing and spam being sent by unauthorized senders (i.e.,botnets). SPF does not stop all spam, in that spam email being sent from a domain that asserts its
sending MTAs via an SPF record will pass all SPF checks. �at is, a spammer can send email
using an envelope-From: address using a domain that the spammer controls, and that email will
not result in a failed SPF check. SPF checks fail when mail is received from a sending MTA
other than those listed as approved senders for the envelope-From: domain. For example, aninfected botnet of hosts in an enterprise may be sending spam on its own (i.e., not through theenterprises outgoing SMTP server), but those spam messages would be detected as the infected
hosts would not be listed as valid senders for the enterprise domain and would fail SPF checks.
See [HERZBERG2009] for a detailed review of SPF and its eﬀectiveness.
4.4.1

Background

SPF works by comparing the sender's IP address (IPv4 or IPv6, depending on the transport used
to deliver the message) with the policy encoded in any SPF record found at the sending domain.
�at is, the domain-part of the envelope-From: address. �is means that SPF checks can actually
be applied before the bulk of the message is received from the sender. For example, in Fig 4-1,
the sender with IP address 192.168.0.1 uses the envelope MAIL FROM: tag as
alice@example.org even though the message header is alice.sender@example.net. �ereceiver queries for the SPF RR for example.org and checks if the IP address is listed as a valid
sender. If it is listed, or no valid SPF record is found, the message is processed as usual. If not,the receiver may mark the message as a potential spoofed email, quarantine it for further(possibly administrator) analysis or reject the message, depending on the SPF policy and/or thepolicy discovered in any associated DMARC record (see subsection 4.5, below) for example.org.
28

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Client connects to port 25
Server: 220 mx.example.com
Client: HELO mta.example.net
S: 250 Hello mta.example.net, I am glad to meet you
C: MAIL FROM:<alice@example.org>
S: 250 Ok
C: RCPT TO:<bob@example.com>
S: 354 End data with <CR><LF>.<CR><LF>
C: To: bob@example.org
From: alice.sender@example.net
Date: Today
Subject: Meeting today…
Figure 4-2: SMTP envelope header vs. message header

Because of the nature of DNS (which SPF uses for publication) an SPF policy is tied to one
domain. �at is, @example.org and @sub.example.org are considered separate domains justlike @example.net and all three need their own SPF records. �is complicates things fororganizations that have several domains and subdomains that may (or may not) send mail. �ere
is a way to publish a centralized SPF policy for a collection of domains using the include: tag(see Sec 4.2.2.2 below)
SPF was ﬁrst speciﬁed in [RFC4408] as an experimental protocol, since at the same time other,similar proposals were also being considered. Over time however, SPF became widely deployed
and was ﬁnalized in [RFC7208] (and its updates). �e changes between the ﬁnal version and theoriginal version are mostly minor, and those that base their deployments on the experimental
version are still understood by clients that implement the ﬁnal version. �e most signiﬁcantdiﬀerence is that the ﬁnal speciﬁcation no longer calls for the use of a specialized RRType(simply called a SPF RR) and instead calls for the sender policy to be encoded in a TXT
Resource Record, in part because it proved too diﬃcult to universally upgrade legacy DNS
systems to accept a new RRType. Older clients may still look for the SPF RR, but the majority
will fall back and ask for a TXT RR if it fails to ﬁnd the special SPF RR. Resolution of theSender Policy Framework (SPF) and Sender ID Experiments [RFC6686] presents the evidence
that was used to justify the abandonment of the SPF RR.
SPF is seen as a way to reduce the risk of phishing email being delivered and used as to installmalware inside an agency's network. Since it is relatively easy to check using the DNS, SPF isseen as a useful layer of email checks.

29

NIST SP 800-177 REV. 1

4.4.2

TRUSTWORTHY EMAILSPF on the Sender Side

Deploying SPF for a sending domain is fairly straightforward. It does not even require SPF
aware code in mail servers, as receivers, not senders, perform the SPF processing. �e only
necessary actions are identifying IP addresses or ranges of permitted sending hosts for a given
domain and adding that information in the DNS as a new resource record.
4.4.2.1 Identifying Permitted Senders for a Domain and Setting the Policy

�e ﬁrst step in deploying SPF for a sending domain is to identify all the hosts that send email
out of the domain (i.e., SMTP servers that are tasked with being email gateways to the Internet).
�is can be hard to do because:•This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1••

�ere may be mail-sending SMTP servers within sub-units of the organization that are
not known to higher-level management.
�ere may be other organizations that send mail on behalf of the organization (such as email marketing ﬁrms or legitimate bulk-mailers).
Individuals who work remotely for the organization may send mail using theirorganization’s email address but a local mail relay.

If the senders cannot be listed with certainty, the SPF policy can indicate that receivers should
not necessarily reject messages that fail SPF checks by using the “~” or “?” mechanisms, rather
than the “-“ mechanism (see 4.3.2.2 below) in the SPF TXT record.
Note: Deployment of DMARC [RFC7489] (discussed below) allows for reporting SPF check
results back to sending domain owners, which allows senders to modify and improve their policy
to minimize improper rejections.
4.4.2.2 Forming the SPF Resource Record

Once all the outgoing senders are identiﬁed, the appropriate policy can be encoded and put into
the domain database. �e SPF syntax is fairly rich and can express complex relationships
between senders. Not only can entities be identiﬁed and called out, but the SPF statement canalso request what emphasis should be placed on each test.
SPF statements are encoded in ASCII text (as they are stored in DNS TXT resource records) andchecks are processed in left to right order. Every statement begins with v=spf1 to indicate that
this is an SPF (version 1) statement 8.
Other mechanisms are listed in Table 4-1:

8Note that there is a technology called SenderID that uses "v=spf2.0", but it is not an updated version of SPF, but adifferent protocol, not recommended in these guidelines.

30

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

Table 4-1: SPF Mechanisms

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Tag

Description

ip4:

Specifies an IPv4 address or range of addresses that are authorized senders
for a domain.

ip6:

Specifies an IPv6 address or range of addresses that are authorized senders
for a domain.

aAsserts that the IP address listed in the domain’s primary A RR is authored
to send mail.

mx

Asserts that the listed hosts for the MX RR’s are also valid senders for thedomain.

include:Lists another domain where the receiver should look for an SPF RR for
further senders. �is can be useful for large organizations with many
domains or sub-domains that have a single set of shared senders. �einclude: mechanism is recursive, in that the SPF check in the record foundis tested in its entirety before proceeding. It is not simply a concatenationof the checks.

allMatches every IP address that has not otherwise been matched.

Each mechanism in the string is separated by whitespace. In addition, there are qualiﬁers that canbe used for each mechanism (Table 4-2):
Table 4-2: SPF Mechanism Qualifiers

QualifierDescription+

�e given mechanism check must pass. �is is the default mechanism and does
not need to be explicitly listed.

-�e given mechanism is not allowed to send email on behalf of the domain.

~

�e given mechanism is in transition and if an email is seen from the listed
host/IP address, that it should be accepted but marked for closer inspection.

?

�e SPF RR explicitly states nothing about the mechanism. In this case, thedefault behavior is to accept the email. (�is makes it equivalent to “+” unlesssome sort of discrete or aggregate message review is conducted).

31

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL�ere are other mechanisms available as well that are not listed here. Administrators interested inseeing the full depth of the SPF syntax are encouraged to read the full speciﬁcation in[RFC7208]. To aid administrators, there are some online tools that can be used assist in thegeneration and testing of an SPF record. �ese tools take administrator input and generate thetext that the administrator then places in a TXT RR in the given domain's zone ﬁle.
4.4.2.3 Example SPF RRs

Some examples of the mechanisms for SPF are given below. In each example, the purported
sender in the SMTP envelope is example.com
�e given domain has one mail server that both sends and receives mail. No other system isauthorized to send mail. �e resulting SPF RR would be:This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

example.com IN TXT "v=spf1 mx -all"�e given enterprise has a DMZ that allows hosts to send mail but is not sure if other senders
exist. As a temporary measure, they list the SPF as:
example.com IN TXT "v=spf1 ip4:192.168.1.0/16 ~all"�e enterprise has several domains for projects, but only one set of sending MTAs. For eachdomain, there is an SPF RR with the include: declaration pointing to a central TXT RR with the
SPF policy that covers all the domains. For example, each domain could have:example.com IN TXT "v=spf1 include:spf.example.net."�e follow up query for the spf.example.net then has:
spf.example.net

IN TXT "v=spf1 ip4:192.168.0.1 …"

�is makes SPF easier to manage for an enterprise with several domains and/or public
subdomains. Administrators only need to edit spf.example.net to make changes to the SPF RR
while the other SPF RR's in the other domains simply use the include: tag to reference it. No
email should originate from the domain:
example.com IN TXT "v=spf1 -all"�e above should be added to all domains that do not send mail to prevent them being used byphishers looking for sending domains to spoof that they believe may not be monitored as closely
as those that accept and send enterprise email. This is an important principle for domains thatthink they are immune from email related threats. Domain names that are only used to host web
or services are advised to publish a “-all” record, to protect their reputation.
Notice that semicolons are not permitted in the SPF TXT record.
Security Recommendation 4-1: Organizations are recommended to deploy SPF to specify
which IP addresses are authorized to transmit email on behalf of the domain. Domains controlled
32

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

by an organization that are not used to send email, for example Web only domains, should
include an SPF RR with the policy indicating that there are no valid email senders for the given
domain.
4.4.3

SPF and DNS

Since SPF policies are now only encoded in DNS TXT resource records, no specialized softwareis needed to host SPF RRs. Organizations can opt to include the old (no longer mandated) unique
SPF RRType as well, but it is usually not needed, as clients that still query for the typeautomatically query for a TXT RR if the SPF RR is not found.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Organizations that deploy SPF should also deploy DNS security (DNSSEC) [RFC4033],[RFC4034], [RFC4035]. DNSSEC provides source authentication and integrity protection for
DNS data. SPF RRs in DNSSEC signed zones cannot be altered or stripped from responses
without DNSSEC aware receivers detecting the attack. Its use is more fully described in Section
5.
4.4.3.1 Changing an Existing SPF Policy

Changing the policy statement in an SPF RR is straightforward but requires timing
considerations due to the caching nature of DNS. It may take some time for the new SPF RR to
propagate to all authoritative servers. Likewise, the old, outgoing SPF RR may be cached inclient DNS servers for the length of the SPF's TXT RR Time-to-Live (TTL). An enterpriseshould be aware that some clients might still have the old version of the SPF policy for sometime before learning the new version. To minimize the eﬀect of DNS caching, it is useful todecrease the DNS timeout to a small period of time (e.g., 300 seconds) before making changes,
and then restoring DNS to a longer time period (e.g., 3600 seconds) after the changes have been
made, tested, and conﬁrmed to be correct.
4.4.4

Considerations for SPF when Using Cloud Services or Contracted Services

When an organization outsources its email service (whole or part) to a third party such as a cloudprovider or contracted email service, that organization needs to make sure any email sent by
those third parties will pass SPF checks. To do this, the enterprise administrator should include
the IP addresses of third party senders in the enterprise SPF policy statement RR. Failure toinclude all the possible senders could result in valid email being rejected due to a failure when
doing the SPF check.
Including third-parties to an SPF RR is done by adding the IP addresses/hostnames individuallyor using the include: tag to reference a third party's own SPF record (if one exists). In general, it
is preferable to use the include: mechanism, as the mechanism avoids hard-coding IP addresses
in multiple locations. �e include: tag does have a hard limit on the number of “chained”
include: tag that a client will look up to prevent an endless series of queries. �is value is ten
unique DNS lookups by default.

33

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

For instance, if example.com has its own sending MTA at 192.0.0.1 but also uses a third party(third-example.net) to send non-transactional email as well, the SPF RR for example.com
would look like:example.com IN TXT "v=spf1 ip4:192.0.0.1
include:third-example.net -all"

As mentioned above, the include: mechanism does not simply concatenate the policy tests of the
included domain (here: third-example.net) but performs all the checks in the SPF policy
referenced and returns the ﬁnal result. An administrator should not include the modiﬁer "+"(requiring the mechanism to pass in order for the whole check to pass) to the include: unlessthey are also in control of the included domain, as any change to the SPF policy in the included
domain will aﬀect the SPF validation check for the sending domain.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

4.4.5

SPF on the Receiver Side

Unlike senders, receivers need to have SPF-aware mail servers to check SPF policies. SPF has
been around in some form (either experimental or ﬁnalized) and available in just about all major
mail server implementations. �ere are also patches and libraries available for other
implementations to make them SPF-aware and perform SPF queries and processing 9. �ere may
be plug-ins available for a particular Mail User Agent so end users can perform SPF checks even
if their incoming mail server does not.
As mentioned above, SPF uses the envelope-From: address domain-part and the IP address of thesender. �is means that SPF checks can be started before the actual text of the email message is
received. Alternatively, messages can be quickly received and held in quarantine until all thechecks are ﬁnished. In either event, checks must be completed before the mail message is sent toan end user's inbox (unless the only SPF checks are performed by the end user using their own
MUA).
�e resulting action based on the SPF checks depends on local receiver policy and the statementsin the purported sending domain's SPF statement. �e action should be based on the modiﬁers(listed above) on each mechanism. If no SPF TXT RR is returned in the query, or the SPF hasformatting errors that prevent parsing, the default behavior is to accept the message. �is is thesame behavior for mail servers that are not SPF-aware.
4.4.5.1 SPF Queries and DNS

Just as an organization that deploys SPF should also deploy DNSSEC [SP800-81], receivers that
perform SPF processing should also perform DNSSEC validation (if possible) on responses to
SPF queries. A mail server should be able to send queries to a validating DNS recursive server if
it cannot perform its own DNSSEC validation.

9

A list of some SPF implementations can be found at http://www.openspf.org/Implementations.

34

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILSecurity Recommendation 4-2: Organizations should deploy DNSSEC for all DNS nameservers and validate DNSSEC responses on all systems that receive email.
4.5

DomainKeys Identified Mail (DKIM)

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns thesigning domain to claim some responsibility for a message by associating the domain with themessage. This can be an author's organization, an operational relay, or one of their agents. DKIM
separates the question of the identity of the signer of the message from the purported author of
the message. Assertion of responsibility is validated through a cryptographic signature and by
querying the signer's domain directly to retrieve the appropriate public key. Message transit from
author to recipient is through relays that typically make no substantive change to the message
content and thus preserve the DKIM signature. Because the DKIM signature covers the message
body, it also protects the integrity of the email communication. Changes to a message body will
result in a DKIM signature validation failure, which is why some mailing lists (that add footersto email messages or change Subject header fields) will cause DKIM signature validation
failures (discussed below).
A DKIM signature is generated by the signing MTA using the email message body and headersand places it in the header of the message along with information for the client to use invalidation of the signature (i.e., key selector, algorithm, etc.). When the receiving MTA gets themessage, it attempts to validate the signature by looking for the public key indicated in the
DKIM signature. �e MTA issues a DNS query for a text resource record (TXT RR) that
contains the encoded key.
Like SPF (see Section 4.4), DKIM allows an enterprise to vouch for an email message sent froma domain it does not control (as would be listed in the SMTP envelope). �e sender only needs
the private key to generate signatures. �is allows an enterprise to have email sent on its behalf
by an approved third party. �e presence of the public key in the enterprises' DNS implies that
there is a relationship between the enterprise and the sender.
Since DKIM requires the use cryptographic keys, enterprises must have a key management planin place to generate, store and retire key pairs. Administrative boundaries complicate this plan if
one organization sends mail on another organization's behalf.
4.5.1

Background

DKIM was originally developed as part of a private sector consortium and only later transitioned
to an IETF standard. �e threat model that the DKIM protocol is designed to protect against was
published as [RFC4686] and assumes bad actors with an extensive corpus of mail messages fromthe domains being impersonated, knowledge of the businesses being impersonated, access tobusiness public keys, and the ability to submit messages to MTAs and MSAs at many locations
across the Internet. �e original DKIM protocol speciﬁcation was developed as [RFC4871],
which is now considered obsolete. �e speciﬁcation underwent several revisions and updates andthe current version of the DKIM speciﬁcation is published as [RFC6376].

35

NIST SP 800-177 REV. 1

4.5.2

TRUSTWORTHY EMAIL

DKIM on the Sender Side

Unlike SPF, DKIM requires specialized functionality on the sender MTA to generate thesignatures. �erefore, the ﬁrst step in deploying DKIM is to ensure that the organization has an
MTA that can support the generation of DKIM signatures. DKIM support is currently available
in some implementations or can be added using open source ﬁlters 10. Administrators should
remember that since DKIM involves digital signatures, signing MTAs should also haveappropriate cryptographic tools to create and store keys and perform cryptographic operations.
4.5.3

Generation and Distribution of the DKIM Key Pair�e next step in deploying DKIM, after ensuring that the sending MTA is DKIM-aware, is togenerate a signing key pair.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Cryptographic keys should be generated in accordance with NIST SP 800-57,“Recommendations for Key Management” [SP800-57pt1] and NIST SP 800-133,“Recommendations for Cryptographic Key Generation.” [SP800-133] Although there exist webbased systems for generating DKIM public/private key pairs and automatically producing thecorresponding DNS entries, such systems should not be used for federal information systems
because they may compromise the organization’s private key.
Currently the DKIM standard speciﬁes that messages must be signed with one of two digital
signature algorithms: RSA/SHA-256 and the Edwards-curve Digital Signature Algorithm
Curve25519 (ed25519) [RFC8463]. Of these, only RSA/SHA-256 is approved for use bygovernment agencies with DKIM, as the hash algorithm SHA-1 is no longer approved for use inconjunction with digital signatures (see Table 4-3).
Table 4-3: Recommended Cryptographic Key Parameters

DKIM Specified
Algorithm

Approved for
Government Use?

Recommended
LengthRecommended
Lifetime

RSA/SHA-256

YES

2048 bits

1-2 years

ed25519NO 11

256 bits

N/A

Once the key pair is generated, the administrator should determine a selector name to use withthe key. A DKIM selector name is a unique identiﬁer for the key that is used to distinguish one
DKIM key from any other potential keys used by the same sending domain, allowing diﬀerent
MTAs to be conﬁgured with diﬀerent signing keys. �is selector name is used by receiving
MTAs to query the validating key.

10 Mail filters are sometimes called “milters.” A milter is a process subordinate to a MTA that can be deployed to perform special

message header or body processing.

11 As of the time of writing, ed25519 is being considered for approval, but has not been approved for use for federal systems.

36

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL�e public part of the key pair is stored in a the DKIM TXT Resource Record (RR). �is record
should be added to the organization’s DNS server and tested to make sure that it is accessible
both within and outside the organization.
�e private part of the key pair is used by the MTA to sign outgoing mail. Administrators must
conﬁgure their mail systems to protect the private part of the key pair from exposure to preventan attacker from learning the key and using it to spoof email with the victim domain's DKIM
key. For example, if the private part of the key pair is kept in a ﬁle, ﬁle permissions must be set
so that only the user under which the MTA is running can read it.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

As with any cryptographic keying material, enterprises should use a Cryptographic KeyManagement System (CKMS) to manage the generation, distribution, and lifecycle of DKIM
keys. Federal agencies are encouraged to consult NIST SP 800-130 [SP800-130] and NIST SP
800-152 [SP800-152] for guidance on how to design and implement a CKMS within an agency.
Security Recommendation 4-3: Federal agency administrators shall only use keys withapproved algorithms and lengths for use with DKIM.
Security Recommendation 4-4: Administrators should ensure that the private portion of the
key pair is adequately protected on the sending MTA and that only the MTA software has readprivileges for the key. Federal agency administrators should follow FISMA control SC-12[SP800-53] guidance with regards to distributing and protecting DKIM key pairs.
Security Recommendation 4-5: Each sending MTA should be conﬁgured with its own
private key and its own selector value, to minimize the damage that may occur if a private key iscompromised. �is private key must have protection against both accidental disclosure orattacker’s attempt to obtain or modify.
4.5.4

Example of a DKIM Signature

Below is an example of a DKIM signature as would be seen in an email header. A signature ismade up of a collection of tag=value pairs that contain parameters needed to successfully
validate the signature as well as the signature itself. An administrator usually cannot conﬁgure
the tags individually as these are done by the MTA functionality that does DKIM, though somerequire conﬁguration (such as the selector, discussed above). Some common tags are describedin Table 4-4.
Table 4-4: DKIM Signature Tag and Value Descriptions

Tag

Name

Descriptionv=

VersionVersion of DKIM in use by the signer. Currently
the only deﬁned value is "1".

a=Algorithm

�e algorithm used (rsa-sha1 or rsa-sha256)b=

Signature (“base”)

�e actual signature encoded as a base64 stringin textual representations
37

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Tag

Name

Descriptionbh=

Signature Hash (“base hash”)

�e hash of the body of the email message
encoded as a base64 string.

d=

Domain�e DNS name of the party vouching for thesignature. �is is used to identify the DNS
domain where the public key resides.

i=

Identiﬁer

�e identiﬁer is normally either the same as, or a
subdomain of, the d= domain.

s=

Selector

Required selector value. �is, together with thedomain identiﬁed in the d= tag, is used to form
the DNS query used to obtain the key that canvalidate the DKIM signature.

t=Timestamp

�e time the DKIM signature was generated.

x=

Signature expiration

An optional value to state a time after which the
DKIM signature should no longer be consideredvalid. Often included to provide anti-replay
protection.

l=LengthLength speciﬁcation for the body in octets. So
the signature can be computed over a given
length, and this will not aﬀect authentication in
the case that a mail forwarder adds an additional
suﬃx to the message.

Thus, a DKIM signature from a service provider sending mail on behalf of example.gov might
appear as an email header:
DKIM-Signature: v=1; a=rsa-sha256; d=example.gov; c=simple; i=@govsender.example.gov; t=1425066098; s=adkimkey; bh=base64 string; b=base64 string

Note that DKIM requires the use of semicolons between statements.
4.5.5

Generation and Provisioning of the DKIM Resource Record

�e public portion of the DKIM key is encoded into a DNS TXT Resource Record (RR) andpublished in the zone indicated in the FROM: ﬁeld of the email header. �e DNS name for the
RR uses the selector the administrator chose for the key pair and a special tag to indicate it is for
DKIM ("_domainkey"). For example, if the selector value for the DKIM key used with
example.gov is "dkimkey", then the resulting DNS RR has the namedkimkey._domainkey.example.gov.
Like SPF, there are other tag=value pairs that need to be included in a DKIM RR. �e full list oftags is listed in the speciﬁcation [RFC6376], but relevant ones are listed below:
38

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

Table 4-5: DKIM RR Tag and Value Descriptions

Tag

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

4.5.6

Name

Descriptionv=

VersionVersion of DKIM in use with the domain and required for every
DKIM RR. �e default value is "DKIM1".

k=

Key type�e default is rsa and is optional, as RSA is currently the only
speciﬁed algorithm used with DKIM

p=

Public Key

�e encoded public key (base64 encoded in text zone ﬁles). An
empty value indicates that the key with the given selector ﬁeld
has been revoked.

t=

Optional ﬂags

One deﬁned ﬂag is "y" indicating that the given domain isexperimenting with DKIM and signals to clients to treat signed
messages as unsigned (to prevent messages that failed
validation from being dropped). �e other is "s" to signal that
there must be a direct match between the "d=" tag and the "i="tag in the DKIM signature. �at is, the "i=" tag must not be a
subdomain of the "d=" tag.

Example of a DKIM RR

Below is an example for the DKIM key that would be used to validate the DKIM signature
above. Here, not all the ﬂags are given:adkimkey._domainkey.example.gov. IN TXT "v=DKIM1; k=rsa;
p=<base64 string>"

Note that unlike SPF, DKIM requires the use of semicolons between statements in a DNS RR.
4.5.7

DKIM and DNS

Since DKIM public keys are encoded in DNS TXT resource records, no specialized software isneeded to host DKIM public keys. Organizations that deploy DKIM should also deploy DNS
security (DNSSEC) [RFC4033] [RFC4034] [RFC4035]. DNSSEC provides source
authentication and integrity protection for DNS data. �is prevents attackers from spooﬁng orintercepting and deleting responses for receivers’ DKIM key TXT queries.
Security Recommendation 4-6: Organizations should deploy DNSSEC to provide
authentication and integrity protection to the DKIM DNS resource records.
4.5.8

DKIM Operational Considerations

�ere are several operations an email administrator will need to perform to maintain DKIM foran email service. New email services are acquired; DKIM keys are introduced, rolled (i.e.,changed), and eventually retired, etc. Since DKIM requires the use of DNS, administrators needto take the nature of DNS into account when performing maintenance operations. [RFC5863]
39

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

describes the complete set of maintenance operations for DKIM in detail, but the three mostcommon operations are summarized below.
4.5.8.1 Introduction of a New DKIM KeyWhen initially deploying DKIM for enterprise email, or a new email service to support anorganization, an administrator should insure that the corresponding public key is available forvalidation. �us, the DNS entry with the DKIM public portion should be published in thesender's domain before the sending MTA begins using the private portion to generate signatures.
�e order should be:This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

1.
2.
3.
4.
5.

Generate a DKIM key pair and determine the selector that will be used by the MTA(s).
Generate and publish the DKIM TXT RR in the sending domain's DNS.
Ensure that the DKIM TXT RR is returned in queries.
Conﬁgure the sending MTA(s) to use the private portion.
Begin using the DKIM key pair with email.

4.5.8.2 Changing an Active DKIM Key Pair

DKIM keys may change for various purposes: suspected weakness or compromise, scheduled
policy, change in operator, or because the DKIM key has reached the end of its lifetime.
Changing, or rolling, a DKIM key pair consists of introducing a new DKIM key before its use
and keeping the old, outgoing key in the DNS long enough for clients to obtain it to validate
signatures. �is requires multiple DNS changes with a wait time between them. �e relevant
steps are:1. Generate a new DKIM key pair.
2. Generate a new DKIM TXT RR, with a diﬀerent selector value than the outgoing DKIM
key and publish it in the enterprise’s DNS. At this point, the DNS will be serving both theold and the new DKIM entries.
3. Reconﬁgure the sending MTA(s) to use the new DKIM key.
4. Validate the correctness of the public key.
5. Begin using the new DKIM key for signature generation.
6. Wait a period of time.
7. Delete the outgoing DKIM TXT RR.
8. Delete or archive the retired DKIM key according to enterprise policy.
�e necessary period of time to wait before deleting the outgoing DKIM key’s TXT RR cannot
be a universal constant value due to the nature of DNS and SMTP (i.e., mail queuing). An
enterprise cannot be certain when all of its email has passed DKIM checks using its old key. An
old DKIM key could still be queried for by a receiving MTA for hours (or potentially days) after
the email had been sent. �erefore, the outgoing DKIM key should be kept in the DNS for aperiod of time (potentially a week) before ﬁnal deletion.
40

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

If it is necessary to revoke or delete a DKIM key, it can be immediately retired by either be
removing the key’s corresponding DKIM TXT RR or by altering the RR to have a blank p=.
Either achieves the same eﬀect (the client can no longer validate the signature) but keeping the
DKIM RR with a blank p= value explicitly signals that the key has been removed.
Revoking a key is similar to deleting it but the enterprise may pre-emptively delete (or change)
the DKIM RR before the sender has stopped using it. �is scenario is possible when an
enterprise wishes to break DKIM authentication and does not control the sender (i.e., a third
party or rogue sender). In these scenarios, the enterprise can delete or change the DKIM RR inorder to break validation of DKIM signatures. Additional deployment of DMARC (see Section
4.5) can be used to indicate that this DKIM validation failure should result in the email being
rejected or deleted.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

4.5.9

DKIM on the Receiver SideOn the receiver side, email administrators should ﬁrst make sure their MTA implementation has
the functionality to verify DKIM signatures. Most major implementations have the functionality
built-in or can be included using open source patches or a mail ﬁlter (i.e., milter). In some cases,
the administrator may need to install additional cryptographic libraries to perform the actual
validation.
4.5.9.1 DKIM Queries in the DNS

Just as an organization that deploys DKIM should deploy DNSSEC, receivers that perform
DKIM processing should also perform DNSSEC validation (if possible) on responses to DKIM
TXT queries. A mail server should be able to send queries to a validating DNS recursive server if
it cannot perform its own DNSSEC validation.
Security Recommendation 4-7: Organizations should enable DNSSEC validation on DNS
servers used by MTAs that verify DKIM signatures.
4.5.10 Issues with Mailing Lists

DKIM assumes that the email came from the MTA domain that generated the signature. �ispresents some problems when dealing with certain mailing lists. Often, MTAs that process
mailing lists change the bodies of mailing list messages—for example, adding a footer withmailing list information or similar. Such actions are likely to invalidate DKIM signatures, unlessfor example, a message length is speciﬁed in the signature headers, and the additions comebeyond that length.
Fundamentally, mailing lists act as active mail parties. �ey receive messages from senders andresend them to recipients. Sometimes they send messages as they are received, sometimes themessages are bundled and sent as a single combined message, and sometimes recipients are able
to choose their delivery means. As such, mailing lists should verify the DKIM signatures ofincoming messages, and then re-sign outgoing messages with their own DKIM signature, madewith the MTA’s public/private key pair. See [RFC6377], “DomainKeys Identiﬁed Mail (DKIM)
41

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

and Mailing Lists,” also identiﬁed as IETF BCP 167, for additional discussion of DKIM andmailing lists.
Additional assurance can be obtained by providing mailing lists with a role-based (i.e., not a
named individual) S/MIME certiﬁcate and digitally signing outgoing. Such signatures will allow
veriﬁcation of the mailing list signature using S/MIME aware clients such as Microsoft Outlook,
Mozilla �underbird, and Apple Mail. See Sections 2.4.2 and 4.7 for a discussion of S/MIME.
Signatures are especially important for broadcast mailing lists that are sent with message-From:
addresses that are not monitored, such as “do-not-reply” email addresses.
Security Recommendation 4-8: Mailing list software should verify DKIM signatures on
incoming mail and re-sign outgoing mail with new DKIM signatures.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Security Recommendation 4-9: Mail sent to broadcast mailing lists from do-not-reply orunmonitored mailboxes should be digitally signed with S/MIME signatures so that recipients canverify the authenticity of the messages.
As with SPF (subsection 4.2 above), DKIM does not prevent a spammer/advertiser from using a
legitimately obtained domain to send unsolicited, DKIM-signed email. DKIM is used to provide
assurance that the purported sender is the originator of the message, and that the message has notbeen modiﬁed in transit by an unauthorized intermediary.
4.5.11 Considerations for Enterprises When Using Cloud or Contracted Email Services

An enterprise that uses third party senders for email services needs to have a policy in place for
DKIM key management. �e nature of DKIM requires that the sending MTA have the private
key in order to generate signatures while the domain owner may only have the public portion.
�is makes key management controls diﬃcult to audit and or impossible to enforce.
Compartmentalizing DKIM keys is one approach to minimize risk when sharing keying material
between organizations.
When using DKIM with cloud or contracted services, an enterprise should generate a unique key
pair for each service. No private key should be shared between contracted services or cloudinstances. �is includes the enterprise itself, if email is sent by MTAs operated within theenterprise.
Security Recommendation 4-10: A unique DKIM key pair should be used for each third
party that sends email on the organization's behalf.
Likewise, at the end of contract lifecycle, all DKIM keys published by the enterprise must be
deleted or modiﬁed to have a blank p= ﬁeld to indicate that the DKIM key has been revoked.
�is prevents the third party from continuing to send DKIM validated email.
4.6

Domain-based Message Authentication, Reporting and Conformance (DMARC)SPF and DKIM were created so that email sending domain owners could give guidance toreceivers about whether mail purporting to originate from them was valid, and thus whether it
42

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

should be delivered, ﬂagged, or discarded. Both SPF and DKIM oﬀer implementation ﬂexibility
and diﬀerent settings can have diﬀerent eﬀects at the receiver. However, neither SPF nor DKIM
include a mechanism to tell receivers if SPF or DKIM are in active use, nor do they havefeedback mechanism to inform sending domain owners of the eﬀectiveness of theirauthentication techniques. For example, if a message arrives at a receiver without a DKIM
signature, DKIM provides no mechanism to allow the receiver to learn if the message isauthentic but was sent from a sender that did not implement DKIM, or if the message is a spoof.
DMARC [RFC7489] allows email sending domain owners to specify policy on how receivers
can verify the authenticity of their email, how the receiver can handle email that fails to verify,
and the frequency and types of report that receivers should send back. DMARC beneﬁts
receivers by removing the guesswork about which security protocols are in use, allowing morecertainty in quarantining and rejecting inauthentic mail.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

To further improve authentication, DMARC adds a link between the domain of the sender withthe authentication results for SPF and DKIM. In particular, receivers compare the domain in themessage-From: address in the message to the SPF and DKIM results (if deployed) and the
DMARC policy in the DNS. �e results of this data gathering are used to determine how the mailshould be handled. �us, when an email fails SPF and DKIM veriﬁcation, or the message-From:domain-part doesn’t match the authentication results, the email can be treated as inauthentic
according to the sending domain owners DMARC policy.
DMARC also provides a mechanism that allows receivers to send reports to the domain ownerabout mail claiming to originate from their domain. �ese reports can be used to illuminate theextent to which unauthorized users are using the domain, and the proportion of mail received thatis from the purported sender.
4.6.1

DMARC on the Sender SideDMARC policies work in conjunction with SPF and/or DKIM, so a mail domain ownerintending to deploy DMARC must deploy SPF or DKIM or (preferably) both. To deploy
DMARC, the sending domain owner will publish SPF and/or DKIM RRs in the DNS andcalculate a signature for the DKIM header of every outgoing message. �e domain owner also
publishes a DMARC policy in the DNS advising receivers on how to treat messages purporting
to originate from the sender’s domain. �e domain owner does this by publishing its DMARC
policy as a TXT record in the DNS 12; identiﬁed by creating a _dmarc DNS record andpublishing it in the sending domain name. For example, the DMARC policy for “example.gov”
would reside at the fully qualiﬁed domain name _dmarc.example.gov.
When implementing email authentication for a domain for the ﬁrst time, a sending domain owneris advised to ﬁrst publish a DMARC RR with a “none” policy before deploying SPF or DKIM.
�is allows the sending domain owner to immediately receive reports indicating the volume of

12 Example tool: https://dmarcguide.globalcyberalliance.org/

43

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

email being sent that purports to be from their domain. �ese reports can be used in crafting anemail authentication policy that reduces the risk of errors.
Since the sending domain owner will be soliciting feedback reports by email from receivers, theadministrator should establish email addresses to receive aggregate and failure reports. As the
DMARC RR is easily discovered, the reporting inboxes could be subject to voluminous
unsolicited bulk email (i.e., spam). �erefore, some kind of abuse counter-measures for theseemail in-boxes should be deployed.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Even if a sending domain owner does not deploy SPF or DKIM records it may be useful todeploy a DMARC record with policy p=none and a rua tag, to encourage receivers to sendaggregate reports about the use to which the sender’s domain is being put. �is can help withpreliminary evaluation to determine whether a mail sender should mount SPF and DKIM
defenses.
4.6.2

The DMARC DNS Record�e DMARC policy is encoded in a TXT record placed in the DNS by the sending domain
owner. Similar to SPF and DKIM, the DMARC policy is encoded in a series of tag=value pairs
separated by semicolons. Common keys are:Table 4-6: DMARC RR Tag and Value Descriptions

Tag

Name

Descriptionv=

VersionVersion ﬁeld that must be present as the ﬁrst element.
By default, the value is always DMARC1.

p=

PolicyMandatory policy ﬁeld. May take values none orquarantine or reject. �is allows for a graduallytightening policy where the sender domain recommends
no speciﬁc action on mail that fails DMARC checks(p=none), through treating failed mail as suspicious(p=quarantine), to rejecting all failed mail (p=reject),preferably at the SMTP transaction stage.

SPF Policy

Values are "r" (default) for relaxed and "s" for strict
SPF domain enforcement. Strict alignment requires anexact match between the message-From: address
domain and the (passing) SPF check must exactly matchthe RFC envelope-From: address (i.e., the HELO
address). Relaxed requires that only the message-From:and envelope-From: address domains be in alignment.
For example, the envelope-From: address domain-part"smtp.example.org" and the message-From: address"announce@example.org" are in alignment, but not astrict match.

aspf=

44

NIST SP 800-177 REV. 1

Tagadkim=

fo=

TRUSTWORTHY EMAIL

Name

Description

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

DKIM
PolicyOptional. Values are “r” (default) for relaxed and “s”
for strict DKIM domain enforcement. Strict alignment
requires an exact match between the message-From:domain in the message header and the DKIM domainpresented in the “d=” DKIM tag. Relaxed requires onlythat the domain part is in alignment (as in aspf above).

FailureReportingoptions

Optional. Ignore if a "ruf" argument below is not alsopresent. Value 0 indicates the receiver should generate a
DMARC failure report if all underlying mechanisms failto produce an aligned “pass” result. Value 1 means
generate a DMARC failure report if any underlying
mechanism produces something other than an aligned“pass” result. Other possible values are “d” and “s”:
“d” means generate a DKIM failure report if a signature
failed evaluation. “s” means generate an SPF failure
report if the message failed SPF evaluation. �esevalues are not exclusive and may be combined together
in a colon-separated list.

ruf=

Optional. Lists a series of Universal Resource Indicators(URI's) (currently just "mailto:<emailaddress>") thatlist where to send failure feedback reports. �is is forreports on message speciﬁc failures. Sending domain
owners should use this argument sparingly, since it isused to request a report on a per-failure basis, which
could result in a large volume of failure reports.

rua=

Optional list of URI's (like in ruf= above, using the"mailto:" URI) listing where to send aggregate
feedback back to the sending domain owner. �esereports are sent based on the interval requested using the"ri=" option below, with a default of 86400 seconds if
not listed.

ri=

ReportingInterval

Optional with the default value of 86400 seconds (oneday). �e value listed is the reporting interval desired by
the sending domain owner.

45

NIST SP 800-177 REV. 1

Tag

TRUSTWORTHY EMAIL

Name

Description

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

pct=

Percent

Optional with the default value of 100(%). Expresses
the percentage of a sending domain owner’s mail thatshould be subject to the given DMARC policy in arange from 0 to 100. �is allows domain owners to
ramp up their policy enforcement gradually and prevent
having to commit to a rigorous policy before getting
feedback on their existing policy. Note: this value must
be an integer.

sp=

Subdomain
PolicyOptional with a default value of none. Other values
include the same range of values as the ‘p=’ argument.
�is is the policy to be applied to mail from all
identiﬁed subdomains of the given DMARC RR. If a
receiver fails to ﬁnd a valid DMARC RR for a given
sending domain, it will attempt to ﬁnd a DMARC RR
for a parent zone and apply a DMARC policy if the sp=
tag is present.

Like SPF and DKIM, the DMARC record is actually a DNS TXT RR. Like all DNS information,
it should be signed using DNSSEC [RFC4033], [RFC4034], and [RFC4035] to prevent an
attacker from spooﬁng the DNS response and altering the DMARC check by a client.
4.6.3

Example of DMARC RR’s

Below are several examples of DMARC policy records using the above tags. �e most basic
example is a DMARC policy that eﬀectively does not assert anything and does not request thereceiver send any feedback reports, so it is, in eﬀect, useless.
_dmarc.example.gov 3600 IN TXT “v=DMARC1; p=none;“An agency that is preparing to deploy SPF and/or DKIM, or has deployed these technologies, but
may not be conﬁdent in their current policies may request aggregate reports from receivers, butotherwise advises no speciﬁc action. �e agency can do so by publishing a p=none policy as in
the example below.
_dmarc.example.gov 3600 IN TXT “v=DMARC1; p=none;
rua=reports@example.gov;“

An agency that has deployed SPF and DKIM and advises receivers to reject any messages thatfail these checks would publish a p=reject policy as in the example below. Here, the agency also
wishes to receive aggregate reports on a daily basis (the default).
_dmarc.example.gov 3600 IN TXT “v=DMARC1; p=reject;
rua=reports@example.gov;“
46

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

�e agency in the process of deploying DKIM (but has conﬁdence in their SPF policy) may wish
to receive feedback solely on DKIM failures, but does not wish to be inundated with feedback,so requests that the policy be applied to a subset of messages received. In this case, the DMARC
policy would include the fo= option to indicate only DKIM failures are to be reported and a pct=
value of 10 to indicate that only 1 in 10 email messages should be subjected to this policy (andsubsequent reporting on a failure). Note that this is not a wise strategy in that it reduces theenforcement policy and the completeness of reporting. �e use of the pct value in values otherthan 0 or 100 (i.e., none or full) limits DMARC eﬀectiveness and usefulness of reporting. It isalso burdensome for receivers to choose that intermediate percentage of mail for testing.
_dmarc.example.gov 3600 IN TXT “v=DMARC1; p=none; pct=10; fo=d;
ruf=reports@example.gov;“
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

An agency with several subdomains may wish to have a single unified policy, in which case a
DMARC RR with the sp= tag is used. In this example, the domain has a policy to reject any mailfrom a subdomain of example.gov that fails checks, while only quarantining email that failed
checks from the parent domain.
_dmarc.example.gov 3600 IN TXT “v=DMARC1; p=quarantine; sp=reject;
rua=reports@example.gov;”

Security Recommendation 4-11: Sending domain owners who deploy SPF and/or DKIM
are recommended to publish a DMARC record signaling to mail receivers the disposition
expected for messages purporting to originate from the sender’s domain.
4.6.4

DMARC on the Receiver Side

Receivers of email purporting to originate from a given domain will look up the SPF, DKIM and
DMARC records in the DNS and act on the policies encoded therein. �e recommended
processing order per [RFC7489] is given below. Note that it is possible that some steps could bedone in parallel and local policy may alter the order of some steps (i.e., steps 2, 3 and 4).
1. �e receiver extracts the message-From: address from the message. �is must contain asingle, valid address or else the mail is refused as an error.
2. �e receiver queries for the DMARC DNS record based on the message-From: address. If
none exists, terminate DMARC processing. �is may include queries to any potential
parent zone of the sender.
3. �e receiver performs DKIM signature checks. If more than one DKIM signature exists
in the message, one must verify.
4. �e receiver queries for the sending domain's SPF record and performs SPF validation
checks.
5. �e receiver conducts Identiﬁer Alignment checks between the message-From: and theresults of the SPF and DKIM records (if present). It does so by comparing the domain
extracted from the message-From: (as in step 2 above) with the domain in the veriﬁed

47

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILSPF and/or DKIM veriﬁcation steps. If there is a match with either the domain veriﬁed by
SPF or DKIM, then the DMARC Identiﬁer Alignment check passes.
6. �e receiver applies the DMARC policy found in the purported sender's DMARC record
unless it conﬂicts with the receiver's local policy. �e receiver will also store the resultsof evaluating each received message for the purpose of compiling aggregate reports sent
back to the domain owner (as speciﬁed in the rua tag).
Note that local email processing policy may override a sending domain owner’s stated DMARC
policy. �e receiver should also store the results of evaluating each received message in somepersistent form for the purpose of compiling aggregate reports.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Even if steps 2-5 in the above procedure yield no SPF or DKIM records to evaluate the message,
it is still useful to send aggregate reports based on the sending domain owner’s DMARC
preferences, as it helps shape sending domain responses to spam in the system.
Security Recommendation 4-12: Mail receivers who evaluate SPF and DKIM results ofreceived messages are recommended to dispose them in accordance with the sending domain’s
published DMARC policy, if any. �ey are also recommended to initiate failure reports andaggregate reports according to the sending domain’s DMARC policies.
4.6.5

Policy and Reporting

DMARC can be seen as consisting of two components: a policy on linking SPF and DKIM
checks to the message-From: address, and a reporting mechanism. �e reason for DMARC
reporting is so that domain owners can get feedback on their SPF, DKIM, Identiﬁer Alignment
and message disposition policies so these can be made more eﬀective. �e DMARC protocol
speciﬁes a system of aggregate reports sent by receivers on a periodic basis, and failure reports
sent on a message-by-message basis for email that fail some component part of the DMARC
checks. �e speciﬁed form in which receivers send aggregate reports is as a compressed (zipped)
XML ﬁle based on the AFRF format [RFC6591], [RFC7489] 13. Each aggregate report from amail receiver back to a particular domain owner includes aggregate ﬁgures for successful andunsuccessful message authentications including:
•

•
•
•
•

13

�e sending domain owner’s DMARC policy for that interval (domain owners maychange policies and it is undetermined whether a receiver will respond based on the oldpolicy or the new policy).
�e message disposition by the receiver (i.e., delivered, quarantined, rejected).
SPF result for a given SPF identiﬁer.
DKIM result for a given DKIM identiﬁer.
Whether identiﬁers are in alignment or not.

Appendix C of RFC 7489.

48

NIST SP 800-177 REV. 1

•
•
•
•
•

TRUSTWORTHY EMAIL

Results classiﬁed by sender subdomain (whether or not a separate sp policy exists).
�e sending and receiving domain pair.
�e policy applied, and whether this is diﬀerent from the policy requested.
�e number of successful authentications.
Totals for all messages received.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Based on the return ﬂow of aggregate reports from the aggregation of all receivers, a domain
owner can build up a picture of the email being sent and how it appears to outside receivers. �isallows the domain owner to identify gaps in email infrastructure and policy and how (and when)
it can be improved. In the early stages of building up this picture, the sending domain should set
a DMARC policy of p=none, so the ultimate disposition of a message that fails some checks
rests wholly on the receiver's local policy. As DMARC aggregate reports are collected, thedomain owner will have a quantitatively better assessment of the extent to which the sender’semail is authenticated by outside receivers and will be able to set a policy of p=reject, indicatingthat any message that fails the SPF, DKIM and alignment checks really should be rejected via a
SMTP reply code signaling rejection, or silently discarding the message. Note, however, mailinglists and some other email uses (e.g., “share this post” type links) may fail DMARC validationand may need to be considered when forming a policy. From their own traﬃc analysis, receivers
can develop a determination of whether a sending domain owner’s p=reject policy is suﬃciently
trustworthy to act on.
Failure reports from receivers to domain owners help debug and tune the component SPF and
DKIM mechanisms as well as alerting the domain owner that their domain is being used as partof a phishing/spam campaign. Typical initial rollout of DMARC in an enterprise will include theruf tag with the values of the fo tag progressively modiﬁed to capture SPF debugging, DKIM
debugging or alignment debugging. Failure reports are expensive to produce and bear a real
danger of providing a DDoS source back to domain owners, so when suﬃcient conﬁdence isgained in the integrity of the component mechanisms, the ruf tag may be dropped from DMARC
policy statements if the sending domain no longer wants to receive failure reports. Note howeverthat failure reports can also be used to alert domain owners about phishing attacks being
launched using their domain as the purported sender and therefore dropping the ruf tag is notrecommended.
�e same AFRF report format as for aggregate reports [RFC6591], [RFC7489] is also speciﬁed
for failure reports, but the DMARC standard updates it for the speciﬁcity of a single failure
report:••••Receivers include as much of the message and message header as is reasonable to allow
the domain to investigate the failure.
Add an Identity-Alignment ﬁeld, with DKIM and SPF DMARC-method ﬁelds asappropriate (see above).
Optionally add a Delivery-Result ﬁeld.
Add DKIM Domain, DKIM Identity and DKIM selector ﬁelds, if the message was DKIM
signed. Optionally also add DKIM Canonical header and body ﬁelds.
49

NIST SP 800-177 REV. 1

•
4.6.6

TRUSTWORTHY EMAIL

Add an additional DMARC authentication failure type, for use when some authentication
mechanisms fail to produce aligned identiﬁers.
Considerations for Agencies When Using Cloud or Contracted Email Services

�e rua and ruf tags typically specify mailto: addresses in the sender’s domain. �ese reporting
addresses are normally assumed to be in the same domain as the purported sender, but notalways. Cloud providers and contracted services may provide DMARC report collection as partof their service oﬀerings. In these instances, the mailto: domain will diﬀer from the sending
domain. To prevent DMARC reporting being used as a DoS vector, the owner of the mailto:
domain must signal its legitimacy by posting a DMARC TXT DNS record with the Fully
Qualiﬁed Domain Name (FQDN):This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

original-sender-domain._report._dmarc.mailto-domain
For example, an original message sent from example.gov is authenticated with a DMARC
record:_dmarc.example.gov. IN TXT "v=DMARC1; p=reject;
rua=mailto:reports.example.net"

�e recipient then queries for a DMARC TXT RR at
example.gov._report._dmarc.example.net and checks the rua tag includes the value
rua=mailto:reports.example.net to ensure that the address speciﬁed in the sending domain
owner's DMARC record is the legitimate receiver for DMARC reports.
Note that, as with DKIM, DMARC records require the use of semicolons between tags.
4.6.7

Mail Forwarding and Indirect Email Flows�e message authentication devices of SPF, DKIM and DMARC are designed to work directly
between a sender domain and a receiver domain. �e message envelope and RFC5322.From
address pass through a series of MTAs and are authenticated by the receiver. �e DKIM
signature, message headers and message body arrive at the receiver unchanged. �e email system
has additional complexities as there are a variety of message forwarding activity that will very
often either modify the message or change the apparent message-From: domain. For example,
user@example.gov sends a message to ourgroup@example.net, which is subsequently
forwarded to all members of the mail group. If the mail group software simply relays themessage, the envelope-From: address denoting the forwarder diﬀers from the message-From:
address, denoting the original sender. In this case DMARC processing will rely on DKIM forauthentication. If the forwarder modiﬁes the message-From: ﬁeld to match the HELO of thesending MTA (see Section 2.3.1), SPF may authenticate, but the modiﬁed header will make the
DKIM signature invalid.
Another example is the use of some third-party email scanning services. In cases where email isreceived by a domain, and then “shunted” to a third party for scanning. �e email is then sent
back (via SMTP) to the original receiving domain, which may consider the incoming email as a
50

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

newly seen message. �is is sometimes seen in federal agencies that use one provider for email
and another provider for Trusted Internet Connection (TIC) services (see Figure 4-2). Incoming
mail is received by the cloud provider, then forwarded to the TIC provider for scanning. Afterscanning, the email message is sent back to the cloud provider. Upon the second delivery, themessage appears to be spoofed, as SPF and DMARC validations will fail.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Figure 4-3: Use of Cloud Email with Third Party Email Scanning

Table 4-7 below summarizes the various forwarding techniques and their eﬀect on domain-based
authentication mechanisms:
Table 4-7: Common relay techniques and their impact on domain-based authentication

Relay Technique

Typical Uses

Negatively Impacts

Aliases

Forwarding, many-to-one consolidation,
vanity addresses

SPF

Re-sender

MUA level forwarding, inline forwarding

SPF & DKIM

Mailing Lists

Re-posting to a subscriber list, often with
modiﬁcations to the message body (such as afooter identifying the mailing list).

SPF & DKIM
results may lead to
DMARC policy
rejection and senderunsubscribe

Gateways

Unrestricted message re-writing, andforwarding

SPF & DKIM

Boundary Filters

Spam or malware ﬁlters that change/delete
content of an email message

DKIM

�ird Parties

Email malware scanners, TIC providers

SPF & DMARC

51

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

One solution that can reduce the impact due to domain-based validation failures is theAuthenticated Receiver Chain (ARC) 14 extension. ARC is an extension of DKIM that generates
a chain of custody (called an “ARC Set”) as an email message moves from one MTA to another.
�e ARC Set is actually three new headers that contain a receiver’s authentication results, anadditional signature over the message a second signature over selected headers (including theother ARC headers). Downstream receivers include their authentication results as well as alsosigning the previous handler’s ARC headers. ARC can be used to give information aboutauthentication results throughout the chain of possession. ARC is not perfect because a malicious
actor can alter the ARC Set, so ARC should only be seen as a purported chain of custody and a
way to use indirect email ﬂows without invalidating previous authentication results.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

ARC may be especially useful when using third party email scanners (or TIC providers). A
federal agency’s cloud email provider can forward all email to the TIC provider for scanning.
Upon resubmission of the email, the cloud email provider can examine the ARC chain to see thatthe incoming email was validated previously and only returning from (known) third party
scanning and override the sending domain’s DMARC policy in favor of a local policy about
messages received from the TIC provider that has a valid ARC chain. As of the time of writing,
ARC is still being ﬁnalized in the IETF. However, email service providers and administrators
are encouraged to look at ARC as a means to minimize the impact of domain-based validation
failures when forwarding email, or when using email mailing lists.
Forwarding in general creates problems for DMARC results processing, and as of this writing,universal solutions are still in development. �ere is a currently existing set of mitigations that
could be used by the mail relay and by the receiver, but would require modiﬁed MTA processing
from traditional SPF and DKIM processing:
1. �e mediator can alter the message-From: ﬁeld to match the envelope-From:. In this casethe SPF lookup would be on the mediator’s domain.
2. After making the customary modiﬁcations, which break the originators DKIM signature,
the email relay can generate its own DKIM signature over the modiﬁed header and body.
Multiple DKIM signatures in a message are acceptable and DMARC policy is that atleast one of the signatures must authenticate to pass DMARC.
It should also be noted that if one or the other (SPF or DKIM) authentication and domainalignment checks pass, then the DMARC policy could be satisﬁed.
At the receiver side, if a message fails DMARC and is bounced (most likely in the case where
the sender publishes a p=reject policy), then a mailing list may respond by unsubscribing therecipient. Mailing list managers should be sensitive to the reasons for rejection and avoid
unsubscribing recipients if the bounce is due to message authentication issues. If the mailing list
is in a domain where the recommendations in this document can be applied, then such mailing

14 Authenticated Receiver Chain (ARC) Protocol. Work-in-Progress. https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-

protocol/52

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

list managers should be sensitive to and accommodate DMARC authentication issues. In the casewhere the mailing list is outside the domain of inﬂuence, the onus is on senders and receivers to
mitigate the eﬀects of forwarding as best they can. ARC may also be useful in mitigating thesetypes of errors, as a receiver can examine the ARC chain for additional information about how
the message traveled through diﬀerent MTAs.
4.7

Authenticating Mail Messages with Digital Signatures

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

In addition to authenticating the sender of a message, the message contents can be authenticatingwith digital signatures. Signed email messages protect against phishing attacks, especiallytargeted phishing attacks, as users who have been conditioned to expect signed messages fromco-workers and organizations are likely to be suspicious if they receive unsigned messages
instructing them to perform an unexpected action [GAR2005]. For this reason, the Department of
Defense requires that all e-mails containing a hyperlink or an attachment be digitally signed[DOD2009].
Because it interoperates with existing PKI and most deployed software, S/MIME is therecommended format for digitally signing messages. Users of most email clients who receive
S/MIME signed messages from organizations that use well-known CAs will observe that themessage signatures are automatically validated, without the need to manually add or trust
certiﬁcates for each sender. If users receive mail that originates from a sender that uses a nonpublic CA, then either the non-public CA must be added or else each S/MIME sender must be
individually approved. Today, the US Government PIV [FIPS 201] cards are signed by wellknown CAs, whereas the US Department of Defense uses CAs that are generally not trusted
outside the Department of Defense. �us, email signed by PIV cards will generally be validatedwith no further action, while email signed by DoD Common Access Cards will result in awarning that the sender’s certiﬁcate is not trusted.

53

NIST SP 800-177 REV. 1

4.7.1

TRUSTWORTHY EMAIL

End-to-End Authentication Using S/MIME Digital Signatures

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Figure 4-4: Two models for sending digitally signed mail.

Organizations (and individuals in organizations) can use S/MIME digital signatures to certify
email that is sent within or external to the organization. Because support for S/MIME is present
in many modern mail clients 15, S/MIME messages that are signed with a valid digital signature
will automatically validate when they are displayed. �is is particularly useful for messages thatare designed to be read but not replied to—for example, status reports and alerts that are sent
programmatically, as well as messages that are sent to announcement-only distribution lists.
To send S/MIME digitally signed messages, organizations must ﬁrst obtain a S/MIME certiﬁcate
where the sender matches the message-From: address that will be used to sign the messages.
Typically, this will be done with a S/MIME certiﬁcate and matching private key that corresponds
to the role, rather than to an individual. 16 Once a certiﬁcate is obtained, the message is ﬁrst
composed. Next, software uses both the S/MIME certiﬁcate and the private portion of their
S/MIME key pair to generate the digital signature. S/MIME signatures contain both the signatureand the signing certiﬁcate, allowing recipients to verify the signed message without having to

15 Support for S/MIME is included in Microsoft Outlook, Apple Mail, iOS Mail, Mozilla Thunderbird, and other mail programs.
16 For example, DoDI 8520.02 (May 24, 2011), “Public Key Infrastructure (PKI) and Public Key (PK) Enabling,” specificallyallows certificates to be issued for groups, roles, information system, device, and code signing purposes, in addition to theissuance of certificates to eligible users.

54

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

fetch the certiﬁcate from a remote server; the certiﬁcate itself is validated using PKI. Sending
S/MIME signed messages thus requires either a MUA that supports S/MIME and the necessary
cryptographic libraries to access the private key and generate the signature, or else anintermediate program that will sign the message after it is created but before it is delivered (Fig4-3).
�e receiver of the signed S/MIME message then uses the sender's public key (from the sender's
attached X.509 certiﬁcate) and validates the digital signature. �e receiver should also check to
see if the senders certiﬁcate has a valid PKIX chain back to a root certiﬁcate the receiver trusts tofurther authenticate the sender. Some organizations may wish to conﬁgure MUAs to perform
real-time checks for certiﬁcate revocation and an additional authentication check (See Section
5.2.2.3).
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

�e principal barrier to using S/MIME for end-user digital signatures has been the diﬃculty ofarranging for end-users to obtain S/MIME certiﬁcates. One approach is to issue S/MIME
credentials in physical identity tokens, as is done with the US Government’s PIV (Personal
Identity Veriﬁcation) cards [FIPS 201]. Individuals can obtain free S/MIME certiﬁcates from anumber of online providers, who verify the individual’s address with an email challenge.
�e principal barrier to using S/MIME for signing organizational email has been the lack ofattention to the issue, since only a single certiﬁcate is required for signing mail and software forverifying S/MIME signatures is already distributed.
Security Recommendation 4-11: Use S/MIME signatures for assuring message authenticity
and integrity.
4.8

Recommendation Summary

Security Recommendation 4-1: Organizations are recommended to deploy SPF to specify
which IP addresses are authorized to transmit email on behalf of the domain. Domains controlled
by an organization that are not used to send email, for example Web only domains, should
include an SPF RR with the policy indicating that there are no valid email senders for the given
domain.
Security Recommendation 4-2: Organizations should deploy DNSSEC for all DNS nameservers and validate DNSSEC responses from all systems that receive email.
Security Recommendation 4-3: Federal agency administrators shall only use keys withapproved algorithms and lengths for use with DKIM.
Security Recommendation 4-4: Administrators should ensure that the private portion of the
key pair is adequately protected on the sending MTA and that only the MTA software has readprivileges for the key. Federal agency administrators should follow FISMA control SC-12[SP800-53] guidance with regards to distributing and protecting DKIM key pairs.

55

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILSecurity Recommendation 4-5: Each sending MTA should be conﬁgured with its own
private key and its own selector value, to minimize the damage that may occur if a private key iscompromised.
Security Recommendation 4-6: Organizations should deploy DNSSEC to provide
authentication and integrity protection to the DKIM DNS resource records.
Security Recommendation 4-7: Organizations should enable DNSSEC validation on DNS
servers used by MTAs that verify DKIM signatures.
Security Recommendation 4-8: Mailing list software should verify DKIM signatures on
incoming mail and re-sign outgoing mail with new DKIM signatures.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Security Recommendation 4-9: Mail sent to broadcast mailing lists from do-not-reply orunmonitored mailboxes should be digitally signed with S/MIME signatures so that recipients canverify the authenticity of the messages.
Security Recommendation 4-10: A unique DKIM key pair should be used for each third
party that sends email on the organization's behalf.
Security Recommendation 4-11: Use S/MIME signatures for assuring message authenticity
and integrity.

56

NIST SP 800-177 REV. 1

5

Protecting Email Confidentiality

5.1

Introduction

TRUSTWORTHY EMAIL

Cleartext mail messages are submitted by a sender, transmitted hop-by-hop over a series ofrelays and delivered to a receiver. Any successful man-in-the-middle can intercept such traﬃcand read it directly. Any bad actor, or organizationally privileged actor, can read such mail on
the submission or delivery systems. Email transmission security can be assured by encrypting thetraﬃc along the path. �e Transport Layer Security protocol (TLS) [RFC5246] protects
conﬁdentiality by encrypting bidirectional traﬃc and prevents passive monitoring. TLS relies on
public key cryptography and uses X.509 certiﬁcates [RFC5280] to encapsulate the public key,
and the Certiﬁcate Authority (CA) system to issue certiﬁcates and authenticate the origin of the
key.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

In recent years the CA system has become the subject of attack and has been successfullycompromised on several occasions. 1718 �e DANE protocol [RFC6698] is designed to overcome
problems in the CA system by providing an alternative channel for authenticating public keys
using DNSSEC. �e result is that the same trust relationships used to certify IP addresses can beused to certify servers operating on those addresses the mechanisms that combine to improve theassurance of email transmission security are described in section 5.2.
Encryption at the transport layer gives assurance of the integrity of data in transit, but senders
and receivers who want end-to-end assurance, (i.e., mailbox to mailbox) of conﬁdentiality have
two alternative mechanisms for achieving this: S/MIME [RFC5750] and OpenPGP [RFC4880].
Both protocols are capable of signing (for authentication) and encryption (for conﬁdentiality).
�e S/MIME protocol is deployed to sign and/or encrypt message contents, using keys stored as
X.509 certiﬁcates and a PKI (See Section 2.4.2) while OpenPGP uses a diﬀerent certiﬁcate and a
Web-of-Trust model for authentication of identities (See Section 2.4.3). Both of these protocols
have the issue of trustworthy certiﬁcate publication and discovery. Traditionally, this was doneusing dedicated key/certiﬁcate servers, LDAP servers, etc., but these methods are not always
easy to deploy and standardize for every enterprise. �ese certiﬁcates can be published throughthe DNS by a diﬀerent implementation of the DANE mechanism for S/MIME [RFC8162] andOpenPGP [RFC7929]. S/MIME and OpenPGP, with their strengthening by DANE
authentication are discussed below.
5.2

Email Transmission Security

Email proceeds towards its destination from a Message Submission Agent (MSA), through asequence of Message Transfer Agents (MTAs), to a Message Delivery Agent (MDA), as
described in Section 2. �is translates to the use of SMTP [RFC5321] for submission and hopby-hop transmission and IMAP [RFC3501] or POP3 [RFC1939] for ﬁnal delivery into a

17 “Comodo SSL Affiliate The Recent RA Compromise,” Phillip Hallam Baker, Comodo, March 15, 2011.

https://blog.comodo.com/other/the-recent-ra-compromise/

18 Peter Bright, “Independent Iranian hacker claims responsibility for Comodo hack,” Ars Technica, March 28, 2011.

http://arstechnica.com/security/2011/03/independent-iranian-hacker-claims-responsibility-for-comodo-hack/

57

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

recipient’s mailbox. TLS [RFC5246] can be used to protect email in transit for one or more hops,
but intervening hops may be under autonomous control, so a securely encrypted end-to-end pathcannot be guaranteed. �is is discussed further in section 5.2.1. Opportunistic encryption oversome portions of the path can provide “better-than-nothing” security. �e use of STARTTLS[RFC3207] is a standard method for establishing a TLS connection. TLS has a secure handshakethat relies on asymmetric encryption, to establish a secure session (using symmetric encryption).
As part of the handshake, the server sends the client an X.509 certiﬁcate containing its public
key, and the cipher suite and symmetric key are negotiated with a preference for the optimallystrongest cipher that both parties support. SMTP clients have traditionally not veriﬁed theserver’s certiﬁcate due to the lack of an appropriate mechanism to specify allowable certiﬁcatesand certiﬁcate authorities. �e newly adopted RFC 7672 [RFC 7672] rectiﬁes this, by providing
rules for applying the DANE protocol to SMTP servers. �e use of DANE in conjunction with
SMTP is discussed Section 5.2.4.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Ultimately the entire path from sender to receiver will be protected by TLS. But this may consistof many hops between MTAs, each the subject of a separate transport connection. �ese are notcompelled to upgrade to TLS at the same time, however in the patchwork evolutionary
development of the global mail system, this cannot be completely guaranteed. �ere may besome MTAs along the route uncontrolled by the sender or receiver domains that have not
upgraded to TLS. In the interim until all mail nodes are certiﬁably secure, the principle is thatsome incrementally improving security is better than no security, so opportunistic TLS (using
DANE or other methods to validate certiﬁcates) should be employed at every possible hop.
5.2.1

TLS Configuration and Use

Traditionally, sending email begins by opening an SMTP connection over TCP and entering aseries of cleartext commands, possibly even including usernames and passwords. �is leaves theconnection exposed to potential monitoring, spooﬁng, and various man-in-the-middle
interventions. A clear improvement would be to open a secure connection that is encrypted sothat the message contents cannot be passively monitored, and third parties cannot spoof message
headers or contents. Transport Layer Security (TLS) oﬀers the solution to these problems.
TCP provides a reliable, ﬂow-controlled connection for transmitting data between two peers.
Unfortunately, TCP provides no built-in security. Transport connections carry all manner ofsensitive traﬃc, including web pages with ﬁnancial and sign-in information, as well as email
messages. �is traﬃc can only be secured through physical isolation, which is not possible on theInternet, or by encrypting the traﬃc.
�e Secure Sockets Layer (SSL) was developed to provide a standard protocol for encrypting
TCP connections. SSL evolved into Transport Layer Security (TLS), the most recent version at
the time of writing being Version 1.3 [RFC8446]. TLS negotiates a secure connection between
initiator and responder (typically client and server) parties. �e negotiation entails the exchangeof the server’s certiﬁcate, and possibly the client’s certiﬁcate, and agreement on a cipher to use
for encrypting the data. In essence, the protocol uses the public-private key pair: the public key
in the server’s certiﬁcate, and the server’s closely held private key, to negotiate a symmetricalgorithm and establish a key known to both parties, and with which both can encrypt, transmit
58

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

and decrypt the application data. RFC 5246 Appendix A describes a range of permissible
ciphers, and the parties agree on one from this set. �is range of ciphers may be restricted onsome hosts by local policy (such as only ciphers Approved for federal use). Data transmitted
over the connection is encrypted using the negotiated session key. At the end, the connection isclosed, and the session key can be deleted (but not always, see below).
Negotiating a TLS connection involves a signiﬁcant time and processor load, so when the twoparties have the need to establish frequent secure connections between them, a session
resumption mechanism allows them to continue with the previously negotiated cipher, for asubsequent connection.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

TLS gains its security from the fact that the server holds the private key securely and the publickey can be authenticated due to it being wrapped in an X.509 certiﬁcate that is guaranteed bysome Certiﬁcate Authority. If the Certiﬁcate Authority is somehow compromised, there is no
guarantee that the key in the certiﬁcate is truly the one belonging to the server, and a client may
inadvertently negotiate with a man-in-the-middle. An investigation of what X.509 certiﬁcates
are, how they work, and how they can be better secured, follows.
Security Recommendation 5-1: Organizations are recommended only use approved TLS
versions listed in NIST SP 800-52 [SP800-52] with FIPS approved cryptographic modules.
5.2.2

X.509 Certificates

The idea of certificates as a secure and traceable vehicle for locating a public key, its ownershipand use was first proposed by the Consultative Committee for International Telephony andTelegraphy (CCITT), now the International Telecommunications Union (ITU). The X.509
specification was developed and brought into worldwide use as a result. In order to vest acertificate with some authority, a set of Certificate Authorities is licensed around the world as
identifiable authentic sources. Each certificate hierarchy has a traceable root for authenticationand has specific traceable requirements for revocation if that is necessary. As a certificate has acomplex set of fields, the idea of a certificate profile has more recently come into play. X.509
certificate formats are described in Section 5.2.2.1, their authentication in Section 5.2.2.2, andpossible revocation in Section 5.2.2.3. The profile concept and a specific example are describedin Section 5.2.2.4
5.2.2.1 X.509 Description

A trusted Certiﬁcate Authority (CA) is licensed to validate applicants’ credentials, store eachapplicant’s public key in a X.509 [RFC5280] structure, and digitally sign it with the CA’s private
key. Each applicant must ﬁrst generate their own public and private key pair, save the private key
securely, and wrap the public key into an X.509 request. �e openssl req command is an
example of how to do this on Unix/Linux systems with OpenSSL19 installed. Many CAs will
generate a certiﬁcate without receiving a request (in eﬀect, generating the request themselves on

19 https://www.openssl.org/

59

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

the customer’s behalf). �e resulting digitally encoded structure is transmitted to the CA, vetted
according to the CA’s policy, and a certiﬁcate is issued. An example certiﬁcate is given below in
Figure 5-1, with salient ﬁelds described.
•••

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

•

•

•

•

Issuer: �e Certiﬁcate Authority that issued and signed this end-entity certiﬁcate. If theissuer is a well-known reputable entity, its root certiﬁcate may be listed in host systems’root certiﬁcate repository.
Subject: Sometimes referred to as the common name (CN). �e entity to which thiscertiﬁcate is issued by this CA. Here: www.example.com.
Public Key: (this ﬁeld truncated for readability). �is is the public key corresponding to
the private key held by the subject. Clients who receive the certiﬁcate in a securecommunication attempt extract the public key and use it for one of the stated key usages.
X509v3 Key Usage: �e use of this certiﬁcate is restricted to digital signature, key
encipherment or key agreement. So an attempt to use it for data encipherment, forexample, should result in error.
X509v3 Basic Constraints: �is certiﬁcate is an end certiﬁcate so the constraint is set to
CA:FALSE. It is not a CA certiﬁcate and its key cannot be used to sign downstream
certiﬁcates for other entities.
X509v3 SubjectAltName: Together with the common name in the Subject ﬁeld, thisrepresents the binding of the public key to a domain. Any attempt by another domain totransmit this certiﬁcate to try to establish a connection should result in failure toauthenticate and connection closure by the client.
Signature Algorithm (truncated for convenience). �e signature generated by the CA
over this certiﬁcate, demonstrating the CA’s authentication of the subject and its public
key.

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 760462 (0xb9a8e)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=IL, O=ExampleCA LLC, OU=Secure Digital Certificate Signing, CN=ExampleCA PrimaryIntermediate Server CA
Validity
Not Before: Aug 20 15:32:55 2013 GMT
Not After : Aug 21 10:17:18 2014 GMT
Subject: description=I0Yrz4bhzFN7q1lb, C=US,
CN=www.example.com/emailAddress=admin@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:00:b7:14:03:3b:87:aa:ea:36:3b:b2:1c:19:e3:a7:
7d:84:5b:1e:77:a2:44:c8:28:b7:c2:27:14:ef:b5:
04:67
Exponent: 65537 (0x10001)

60

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment, Key Agreement
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Subject Key Identifier:C2:64:A8:A0:3B:E6:6A:D5:99:36:C2:70:9B:24:32:CF:77:46:28:BD
X509v3 Authority Key Identifier:keyid:EB:42:34:D0:98:B0:AB:9F:F4:1B:6B:08:F7:CC:64:2E:EF:0E:
2C:45
X509v3 Subject Alternative Name:
DNS:www.example.com, DNS:example.com
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.23223.1.2.3
CPS: http://www.exampleCA.com/policy.txt
User Notice:
Organization: ExampleCA Certification Authority
Number: 1
Explicit Text: This certificate was issued according to the Class 1 Validation requirements ofthe ExampleCA CA policy, reliance only for the intended purpose in compliance of the relying party
obligations.
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.exampleCA.com/crl.crl
Authority Information Access:
OCSP - URI:http://ocsp.exampleCA.com/class1/server/ocsp
CA Issuers - URI:http://aia.exampleCA.com/certs/ca.crt
X509v3 Issuer Alternative Name:
URI:http://www.exampleCA.com/
Signature Algorithm: sha1WithRSAEncryption
93:29:d1:ed:3a:2a:91:50:b4:64:1d:0f:06:8a:79:cf:d5:35:
ba:25:39:b0:dd:c0:34:d2:7f:b3:04:5c:46:50:2b:97:72:15:
ea:3a:4f:b6

Figure 5-1: Example of X.509 Certificate

5.2.2.2 X.509 Authentication

�e certiﬁcate given above is an example of an end certiﬁcate. Although it claims to be signed bya well-known CA, anyone receiving this certiﬁcate in communication has the problem ofauthenticating that signature. For this, full PKIX authentication back to the root certiﬁcate isrequired. �e CA issues a well-known self-signed certiﬁcate containing its public key. �is is theroot certiﬁcate. A set of current root certiﬁcates, often numbering in the hundreds of certiﬁcates,
are held by individual browser developers and operating system suppliers as their set of trusted
root certiﬁcates. �e process of authentication is the process of tracing the end certiﬁcate back toa root certiﬁcate, through a chain of zero or more intermediate certiﬁcates.

61

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

5.2.2.3 Certificate Revocation

Every certiﬁcate has a period of validity typically ranging from 30 days up to a number of years.
�ere may, however, be reasons to revoke a certiﬁcate prior to its expiration, such as thecompromise or loss of the private key [RFC5280]. �e act of revocation is associated with the
CA publishing a certiﬁcate revocation list. Part of authenticating a certiﬁcate chain is perusing
the certiﬁcate revocation list (CRL) to determine if any certiﬁcate in the chain is no longer valid.
�e presence of a revoked certiﬁcate in the chain should result in failure of authentication.
Among the problems of CRL management, the lack of real-time revocation checks leads to nondeterminism in the authentication mechanism. Problems with revocation led the IETF to develop
a real-time revocation management protocol, the Online Certiﬁcate Status Protocol (OCSP)[RFC6960]. Mozilla has now taken the step to deprecate CRLs in favor of OCSP.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

5.2.2.4 Certificate Profiles

�e Federal Public Key Infrastructure (FPKI) Policy Authority has speciﬁed proﬁles (called theFPIX proﬁle) for two types of X.509 version 3 certiﬁcates that can be used for conﬁdentiality
and integrity protection of federal email systems [FPKI-CERT]. �e applicable certiﬁcate proﬁleis identiﬁed by the KeyPurposeId with value id-kp-emailProtection (1.3.6.1.5.5.7.3.4) andincludes the following:••

End-Entity Signature Certiﬁcate Proﬁle (Worksheet 5)
Key Management Certiﬁcate Proﬁle (Worksheet 6)

�e overall FPIX proﬁle is an instantiation of IETF’s PKI proﬁle developed by the PKIX
working group (and hence called the PKIX proﬁle) [PKIX] with unique parameter settings forFederal PKI systems. �us, a FPIX certiﬁcate proﬁle complements the corresponding PKIX
certiﬁcate proﬁle. �e following is a brief overview of the two applicable FPIX proﬁlesreferenced above.
5.2.2.4.1 Overview of Key Management Certificate Profile

�e public key of a Key Management certiﬁcate is used by a device (e.g., a Mail Transfer Agent(MTA) in this context) to set up a session key (a symmetric key) with its transacting entity (e.g.,
the next-hop MTA in this context). �e parameter values speciﬁed in the proﬁle for thiscertiﬁcate type, for some of the important ﬁelds are:•••Signature: (of the certiﬁcate issuer) If the RSA is used as the signature algorithm for signing
the certiﬁcate by the CA, then the corresponding hash algorithms can only be either SHA256 or SHA-512.
subjectPublicKeyInfo: �e allowed algorithms for the public key are RSA, Diﬃe-Hellman(DH), Elliptic Curve (ECC), or the Key Exchange Algorithm (KEA).
KeyUsage: �e keyEncipherment bit is set to 1 when the subject public key is RSA. �e
KeyAgreement bit is set to 1 when the subject public key is Diﬃe-Hellman (DH), Elliptic
Curve (ECC), or Key Exchange Algorithm (KEA).
62

NIST SP 800-177 REV. 1••

TRUSTWORTHY EMAILKeyPurposeId: Should include the value id-kp-emailProtection (1.3.6.1.5.5.7.3.4)
subjectAltName: Since this certiﬁcate is used by devices (as opposed to a human subject),
this ﬁeld should contain the DNS name or IP Address.

5.2.3

STARTTLS

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Unlike the World Wide Web, where the URL indicates that the secure variant (i.e., HTTPS) is inuse, an email sender has only the email address, “user@domain”, to signal the destination andno way to direct that the channel must be secured. �is is an issue not just on a sender-to-receiverbasis, but also on a transitive basis, as SMTP is not an end-to-end protocol but instead a protocolthat sends mail messages as a series of hops (i.e., MUA, MSA, multiple MTAs, etc.). Not only isthere no way to signal that message submission must be secure, there is also no way to signalthat any hop in the transmission should be secure. STARTTLS was developed to address some ofthe shortcomings of this system.
RFC 3207 [RFC3207] describes an extension to SMTP that allows an SMTP client and server touse TLS to provide private, authenticated communication across the Internet. �is gives SMTP
agents the ability to protect some or all of their communications from eavesdroppers andattackers. If the client initiates the connection over a TLS-enabled port (e.g., port 465 waspreviously used for SMTP over SSL), the server advertises that the STARTTLS option isavailable to connecting clients. �e client can then issue the STARTTLS command in the SMTP
command stream, and the two parties proceed to establish a secure TLS connection. An
advantage of using STARTTLS is that the server can oﬀer SMTP service on a single port, rather
than requiring separate port numbers for secure and cleartext operations. Similar mechanisms areavailable for running TLS over IMAP and POP protocols.
When STARTTLS is initiated as a request by the server side, it may be susceptible to adowngrade attack, where a man-in-the-middle (MITM) is in place. In this case the MITM
receives the STARTTLS request from the server reply to a connection request and scrubs it out.
�e initiating client sees no TLS upgrade request and proceeds with an unsecured connection (asoriginally anticipated). Likewise, most MTAs default to sending messages over unencrypted
TCP if certiﬁcate validation fails during the TLS handshake.
Domains can signal their desire to receive email over TLS by publishing a public key in their
DNS records using DANE (Section 5.2.4). Domains can also conﬁgure their email servers toreject mail that is delivered without being preceded by a TLS upgrade. Unfortunately, doing so at
the present time may result in email not being delivered from clients that are not capable of TLS.
Furthermore, mail that is sent over TLS will still be susceptible to MITM attacks unless theclient veriﬁes the that the server’s certiﬁcate matches the certiﬁcate that is advertised using
DANE.

63

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

If the client wants to ensure an encrypted channel, there is a new proposal to allow for signaling
the required use of TLS via the REQUIRETLS SMTP option20. �is option is set by senders toindicate that they wish TLS to be used for each hop and not deliver to the next hop if TLS is notavailable. If the server wishes to indicate that an encrypted channel is available and should be
used by senders, this can be indicated through an advertisement using DANE. If the end user
wants security over the message content, then the message should be encrypted using S/MIME
or OpenPGP, as discussed in Section 5.3.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

In this long transition period towards “TLS everywhere,” there will be security gaps where some
MTA to MTA hop oﬀers TCP only. In these cases, the receiving MTA suggestion of
STARTTLS can be downgraded by the above MITM attack. In such cases, a channel thought
secure by the end user can be compromised. A mitigating consolation is that opportunistic
security (i.e., use encryption when available) is better than no security. �e more mailadministrators who actively deploy TLS, the fewer opportunities for eﬀective MITM attacks. In
this way global email security improves incrementally.
5.2.3.1 Recommendations

Security Recommendation 5-2: TLS-capable servers should prompt clients to invoke the
STARTTLS command. TLS clients should attempt to use STARTTLS for SMTP, either initially,or issuing the command when oﬀered.
5.2.4

SMTP Security via Opportunistic DNS-based Authentication of Named Entities(DANE) Transport Layer Security (TLS)

For years, TLS has solved the problem of distributing public keys by using a certiﬁcate, signed
by some well-known Certiﬁcation Authority (CA). Every browser developer and operating
system supplier maintain a list of CA root certiﬁcates as trust-anchors. �ese are called thesoftware’s root certiﬁcates and are stored in the root certiﬁcate store. �e PKIX procedureallows the certiﬁcate recipient to trace a certiﬁcate back to the root. So long as the root certiﬁcate
remains trustworthy, and the authentication concludes successfully, the client can proceed withthe connection.
Currently, there are hundreds of organizations acting as CAs on the Internet. If one CA
infrastructure or vetting procedure is compromised, the attacker can obtain the CA’s private key,or get issued certiﬁcates under a false name. �ere is no limitation of scope for the global PKI,
and a compromise of a single CA damages the integrity of the entire PKI system.
Aside from a CA compromise, some CAs have engaged in poor security practices. For example,
some CAs have issued wildcard certiﬁcates that allow the holder to issue sub-certiﬁcates for any
domain or entity, anywhere in the world. 21

20 J. Fenton SMTP Require TLS Option. Work in Progress https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-require-tls/
21 For examples of poor CA issuing practices involving sub-certificates, see “Bug 724929—Remove Trustwave Certificate(s)64NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILDANE introduces mechanisms for domains to specify to a client which certiﬁcates should betrusted for the domain. With DANE, a domain owner can publish DNS records that declareclients should only trust certiﬁcates from a particular CA or that they should only trust only aspeciﬁc certiﬁcate or public key. Essentially, DANE replaces reliance on the security provided
by the CA system with reliance on the security provided by DNSSEC.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

DANE complements TLS. �e TLS handshake yields an encrypted connection between a server
and a client and provides a server’s X.509 certiﬁcate to the client. 22 �e TLS protocol does not
deﬁne how the certiﬁcate should be authenticated. Some implementations may do this as part of
the TLS handshake, and some may leave it to the application to perform authentication.
Whichever way is used, there is still a vulnerability: a CA can issue certiﬁcates for any domain,and if that a CA is compromised (as has happened more than once all too recently), an attacker
can have it can issue a replacement certiﬁcate for any domain and take control of a server’s
connections. Ideally, issuance and delivery of a certiﬁcate should be tied absolutely to the given
domain. DANE creates this explicit link by allowing the server domain owner to create a TLSA
resource record in the DNS [RFC6698] [RFC7671], which identiﬁes the certiﬁcate, its public
key, or a hash of either. When the client receives an X.509 certiﬁcate in the TLS negotiation, it
looks up the TLSA RR for that domain and matches the TLSA data against the certiﬁcate as partof the client’s certiﬁcate validation procedure.
DANE has a number of usage models (called Certiﬁcate Usages) to accommodate users who
require diﬀerent forms of authentication. �ese Certiﬁcate Usages are given mnemonic names[RFC7218]:•

With Certiﬁcate Usage DANE-TA(2), the TLSA RR designates a trust-anchor that issued
one of the certiﬁcates in the PKIX chain. [RFC7671] requires that DANE-TA(2) trust
anchors be included in the server "certiﬁcate message" unless the entire certiﬁcate is
speciﬁed in the TLSA record (i.e., usage 2 0 0, indicating the TLSA RR contains a local
root certiﬁcate).

•

With Certiﬁcate Usage DANE-EE(3), the TLSA RR matches an end-entity, or leaf
certiﬁcate.

•

Certiﬁcate Usages PKIX-TA(0) and PKIX-EE(1) should not be used for opportunistic
DANE TLS encryption [RFC 7672]. �is is because, outside of web browsers, there is noauthoritative list of trusted certiﬁcate authorities, and PKIX-TA(0) and PKIX-EE(1)require that both the client and the server have a prearranged list of mutually trusted CAs.

In DANE-EE(3) the server certiﬁcate is directly speciﬁed by the TLSA record. �us, thefrom trusted root certificates,” February 7, 2012. https://bugzilla.mozilla.org/show_bug.cgi?id=724929, Also “Bug698753—Entrust SubCA: 512-bit key issuance and other CPS violations; malware in wild,” November 8, 2011.
https://bugzilla.mozilla.org/show_bug.cgi?id=698753. Also “Revoking Trust in one CNNIC Intermediate Certificate,”
Mozilla Security Blog, March 23, 2015. https://blog.mozilla.org/security/2015/03/23/revoking-trust-in-one-cnnicintermediate-certificate/.
22 Also possibly from client to server.

65

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

certiﬁcate may be self-issued, or it may be issued by a well-known CA. �e certiﬁcate may becurrent or expired. Indeed, operators may employ either a public or a private CA for their DANE
certiﬁcates and publish a combination of “3 1 1” and “2 1 1” TLSA records, both of whichshould match the server chain and be monitored. �is allows clients to verify the certiﬁcate using
either DANE or the traditional Certiﬁcate Authority system, signiﬁcantly improving reliability.
Secure SMTP communications involves additional complications because of the use of mailexchanger (MX) and canonical name (CNAME) DNS RRs, which may cause mail to be routed
through intermediate hosts or to ﬁnal destinations that reside at diﬀerent domain names. [RFC7671] and [RFC7672] describe a set of rules that are to be used for ﬁnding and interpreting
DANE policy statements.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

As originally deﬁned, TLS did not oﬀer a client the ability to specify a particular hostname whenconnecting to a server; this was a problem in the case where the server oﬀers multiple virtual
hosts from one IP address, and there was a desire to associate a single certiﬁcate with a single
hostname. [RFC6066] deﬁnes a set of extensions to TLS that include the Server Name Indication(SNI), allowing a client to speciﬁcally reference the desired server by hostname, and the server
can respond with the correct certiﬁcate.
[RFC7671] and [RFC7672] require the client to send SNI just in case the server needs this toselect the correct certificate. There is no obligation on the server to employ virtual hosting, or to
return a certificate that matches the client's SNI extension. There is no obligation on the client tomatch anything against the SNI extension. Rather, the requirement on the client is to support at
least the TLSA base domain as a reference identifier for the peer identity when performing namechecks (matching against a TLSA record other than DANE-EE(3)). With CNAME expansion
either as part of MX record resolution or address resolution of the MX exchange, additional
names must be supported as described in [RFC7671] and [RFC7672].
A DANE matching condition also requires that the connecting server match the SubjectAltName
from the delivered end certiﬁcate to the certiﬁcate indicated in the TLSA RR. DANE-EE
authentication allows for the server to deliver a self-signed certiﬁcate. In eﬀect, DANE-EE issimply a vehicle for delivering the public key. Authentication is inherent in the trust provided by
DNSSEC, and the SNI check is not required.
5.2.5

SMTP MTA Strict Transport Security (MTA-STS)

Some email providers regard the requirement that DANE records be secured with DNSSEC as amajor barrier to deployment. As an alternative, they have proposed SMTP Strict Transport
Security [RFC8461], which relies on records that are announced via DNS but authenticated using
information distributed via HTTPS. The goal of MTA-STS is the same as DANE: to have a way
for a receiving MTA to publish its TLS policy and mitigate Man-in-the-Middle (MITM)
spoofing. SMA-STS can be used with DANE, as neither method precludes the use of the other.
MTA-STS works by publishing both a special TXT RR in the DNS and a policy document at a
Well-Known URL. The client obtains both artifacts before attempting to establish a connection
to the receiving domain’s mail servers.
66

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

5.2.5.1 The MTA-STS DNS Resource Record

The receiving domain administrator generates an MTA-STS policy RR (a TXT Text RR) withthe following tag:value pairs (separated by “;”):
Table 5-1: MTA-STS Resource Record Tags and Descriptions

Tag

Descriptionsv=

Version of MTA-STS in use. Currently, the only defined value isid=

A string used to indicate policy instance. Used to signal to clientsthat the receiver’s policy has changed. It must be changed every
time there is a policy update on the receiver’s side.

STSv1

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

The MTA-STS RR is published as a TXT RR using the receiving domain with _mta-sts
prepended. For example, if the receiving domain is example.gov, the MTA-STS RR is:_mta-sts.example.gov

IN

TXT “v=STSv1; id=20170101000000Z”

5.2.5.2 The MTA-STS Policy

The receiver then published a detailed policy document at a well-known URL consisting of thedomain with mta-sts prepended and .well-known/mta-sts.txt as the path. So, in the example
above, the URL containing the MTA-STS policy for example.gov would be found at:https://mta-sts.example.gov/.well-known/mta-sts.txt

The policy must only be accessible via HTTPS and contains a plain/text resource used by theclient to connect to the receiver. The document contains tag:values pairs, separated by newlines.
The tags are:67

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

Table 5-2: MTA-STS Policy Tags and Descriptions

Tag

Description

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

version:The version of MTA-STS in use by the receiver. Currently, the only
defined value is STSv1

mode:

The requested behavior of clients if a TLS validation failure or MX
matching failure occurs. Defined values are enforce, meaning a client
should reject the connection, report, meaning a client should stop theconnection and send a TLS failure report (see Section XX) and none,
meaning a client should continue with the connection.

mx:

A hostname of a mail receiver that should be present (as common nameor subject alternative name) in any received X.509 server certificatessent during a TLS handshake. A receiver’s policy resource may containmultiple mx= tags, each on a separate line.

max_age:

Maximum lifetime of a policy (in seconds). Used as a time to live for acached policy. Clients should recheck the receiver’s MTA-STS URL fora possible updated policy after the max_age has elapsed.

An example MTA-STS policy for example.gov may look like the following (found at the URL
above):
version: STSv1
mode: enforce
mx: mail1.example.gov.
mx: mail2.example.gov.
max_age:86400

In the above, example.gov lists two mail servers for the domain (mail1.example.gov andmail2.example.gov). The domain also sets its policy to enforce, meaning that if a client sees aserver certificate that lacks mail1.example.gov or mail2.example.gov, or encounters someother PKIX validation failure, it is to reject the connection.
An MTA-STS compliant sender first checks for the presence of an MTA-STS policy at thereceiver domain. First by checking its cache to see if an earlier discovered policy was found, orby looking in the DNS for the MTA-STS DNS RR. If it is a newly discovered policy, the client
first gets the policy over HTTPS, then attempts to connect to each candidate MX listed in orderin the policy. For each receiving mail server, the sender attempts to connect via STARTTLS,
and validates the receiver’s server certificate. If successful, the message is delivered. If not, thesender moves on to the next mail server listed in the policy. If none of the connections are
successful, the sender does not deliver the message.
At the time of writing, there are no publicly available MTA-STS implementations, and only asingle MTA-STS Internet draft has been posted. Therefore, it is not possible for organizations to
deploy MTA-STS aware clients at the present time.
68

NIST SP 800-177 REV. 1

5.2.6

TRUSTWORTHY EMAIL

Comparing DANE and MTA-STS

Both DANE and MTA-STS were designed to assist opportunistic encryption and combat passive
monitoring of SMTP connections. Receiving domains can support both if desired, to support all
clients. Senders can implement both as well, as the current MTA-STS spec states that DANEDNSSEC responses take precedence. The basic merits of both are summarized in the tablebelow:
Table 5-3: Comparing DANE and MTA-STS

FeatureThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

DANE

MTA-STSDNS RRType used

TLSA RRs

TXT RRs

Client Requirements

DNSSECHTTPSCA scoping?

Yes

No

PKIX required?

No always

Yes

Yes (when using CU=3)

No

Failure reporting to receiver?

No

Yes

Client behavior on failure

Close connection

Depends on policy

Self-Signed certificates
acceptable?

Security Recommendation 5-3: Receiving domains should implement protocols to signal
TLS usage to clients. Receivers should implement DANE, MTA-STS (or both) for all mailservers listed in the domain’s MX Resource Record set.
Security Recommendation 5-4: As federal agency use requires certiﬁcate chainauthentication against a known CA, Certiﬁcate Usage DANE-TA(2) is recommended when
deploying DANE to specify the CA that the agency has chosen to employ. Agencies should also
publish a DANE-EE(3) RR alongside the DANE-TA(2) RR for increased reliability. In bothcases the TLSA record should use a selector of SPKI(1) and a Matching ﬁeld type of SHA2256(1), for parameter values of “3 1 1” and “2 1 1” respectively.
5.2.7

Reporting TLS Errors to Senders

Currently, there is no way for an MTA to report TLS failures to a receiving domain. If a sending
MTA cannot establish a TLS protected connection, there is no automated signaling to thereceiver as to the nature of the failure, only the receiver’s own logs. Previously, most MTAs
would simply continue to connect without TLS and deliver the mail. However, with options
such as MTA-STS (Section 5.2.5) or REQUIRETLS (Section 5.2.3), TLS errors will cause more
failures in delivery.
There is a way to have a standard way to report TLS failures back to receivers known as SMTP
TLS Reporting [RFC8460]. The concept is similar to DMARC (see Section 4.6) where receivers
send failure reports back to senders, only here senders send the failure report. The specification
69

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

includes the report format as well as how to signal reporting over SMTP or HTTPS. HTTPS isgiven as an option for senders that wish to use a secure channel but believe SMTP over TLS will
not work. Also, like DMARC, the location (via email or HTTPS) where reports should be sent
are published in a DNS TXT resource record that the sender can query for in the receiver’s
domain. Here the TXT RR has a well-known string _smtp.-tls prepended and using thefollowing tag:value pairs each separated by a semicolon ‘;’:
Table 5-4: TLS Reporting Value Tags and Descriptions

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Tag

Descriptionv=

The version string. Default is TLSRPTv1

rua=

How the receiver wishes to have reports submitted. Options are
mailto: (for email) or https (for a URI to submit reports via a POST
command).

An example TLS reporting RR is given below for example.gov:_smtp-tlsrpt.example.gov IN TXT“v=TLSRPTv1;rua=https://reporttls.example.gov/reports”

Indicating that TLS failure reports when connecting to example.gov mail receivers should besent to the URI listed in the rua tag. A reporting RR may have multiple values in the rua tag,indicating several alternative means to send reports.
5.3

Email Content Security

End users and their institutions have an interest in rendering the contents of their messages
completely secure against unauthorized eyes. �ey can take direct control over message content
security using either S/MIME [RFC5751] or OpenPGP [RFC4880]. In each of these protocols,
the sender signs a message with a private key, and the receiver authenticates the signature withthe public key obtained (somehow) from the sender. Signing provides a guarantee of the message
source, but any man in the middle can use the public key to decode and read the signed message.
For proof against unwanted readers, the sender encrypts a message with the recipient’s public
key or with a generated symmetric key that is encrypted with the receiver’s public key which is
obtained (somehow) from the receiver. �e receiver decrypts the message with the corresponding
private key, or a symmetric key encrypted with the recipient’s public key, and the message
content is kept conﬁdential from mailbox to mailbox. Both S/MIME and OpenPGP are protocols
that facilitate signing and encryption, but secure open distribution of public keys is still a hurdle.
Two recent DANE protocols have been proposed to address this. �e SMIMEA (for S/MIME
certiﬁcates) and OPENPGPKEY (for OpenPGP keys) initiatives specify new DNS RR types forstoring email end user key material in the DNS. S/MIME and SMIMEA are described insubsection 5.3.1, while OpenPGP and OPENPGPKEY are described in subsection 5.3.2.

70

NIST SP 800-177 REV. 1

5.3.1

TRUSTWORTHY EMAIL

S/MIME and SMIMEA

S/MIME is a protocol that allows email users to authenticate messages by digitally signing witha private key and including the public key in an attached certiﬁcate. �e recipient of the message
performs a PKIX validation on the certiﬁcate, authenticating the message’s originator. On theencryption side, the S/MIME sender typically encrypts the message text using a generated
symmetric key, which is encrypted in turn with the public key of the recipient, which waspreviously distributed using some other, out of band, method. Within an organization it iscommon to obtain a correspondent’s S/MIME certiﬁcate from an LDAP directory server.
Another way to obtain a S/MIME certiﬁcate is by exchanging digitally signed messages.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

S/MIME had the advantage of being based on X.509 certiﬁcates, allowing existing software andprocedures developed for the PKI to be used for email. Hence, where the domain-owningenterprise has an interest in securing the message content, S/MIME is preferred.
�e Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC5751] describes a protocolthat will sign, encrypt or compress some, or all, of the body contents of a message. Signing isdone using the sender’s private key, while key encipherment is done with the recipient’s known
public key. Message encryption using the data encryption key, signing and compression can bedone in any order and any combination. �e operation is applied to the body, not the RFC 5322
headings of the message. In the signing case, the certiﬁcate containing the sender’s public key isalso attached to the message.
�e receiver uses the associated public key to authenticate the digital signature over the message,
demonstrating proof of origin and non-repudiation. �e usual case is for the receiver toauthenticate the supplied certiﬁcate using PKIX back to the Certiﬁcate Authority. Users whowant more assurance that the key supplied is bound to the sender’s domain can deploy the
SMIMEA mechanism [RFC8162] in which the certiﬁcate and key can be independently retrieved
from the DNS and authenticated per the DANE mechanism, similar to that described in Subsection 5.2.5, above. �e user who wants to encrypt a message retrieves the receiver’s public
key: which may have been sent on a prior signed message 23. If no prior signed message is at
hand, or if the user seeks more authentication than PKIX, then the key can be retrieved from the
DNS in an SMIMEA record. �e receiver decrypts the data encryption key using thecorresponding private key, decrypts the message using the newly decrypted key and reads orstores the message as appropriate.

23 The use of one key pair for both digital signatures and data encryption is not recommended, but very common.

71

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

Figure 5-2: Sending an Encrypted EmailThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

To send an S/MIME encrypted message (Fig 2-4) to a user, the sender must ﬁrst obtain therecipient's X.509 certiﬁcate and may (optionally) validate the certiﬁcate to a trusted root, if
possible. �e sender then uses the certiﬁcate’s public key to generate a data encryption key anduse that generated key to encrypt the composed message. In this case the sender must possess therecipient's certiﬁcate before sending the message.
An enterprise looking to use S/MIME to provide email conﬁdentiality will need to obtain or
produce credentials for each end user in the organization. An organization can generate its own
root certiﬁcate and give its members a certiﬁcate generated from that root, or purchasecertiﬁcates for each member from a well-known Certiﬁcate Authority (CA).
Using S/MIME for end-user encryption is further complicated by the need to distribute each endusers’ certiﬁcate to potential senders. Traditionally this is done by having correspondents
exchange email messages that are digitally signed that includes the sender’s encryption
certiﬁcate, but not encrypted. Alternatively, organizations can conﬁgure LDAP servers to makeS/MIME public keys available as part of a directory lookup; mail clients such as Outlook andApple Mail can be conﬁgured to query LDAP servers for public keys necessary for message
encryption.
5.3.1.1 S/MIME Recommendations

Oﬃcial use requires certiﬁcate chain authentication against a known Certiﬁcate Authority.
Current MUAs use S/MIME private keys to decrypt the data encryption key that was used toencrypt the email message each time that it is displayed, but leave the message encrypted in theemail store. �is mode of operation is not recommended, as it forces the recipient of theencrypted email to maintain their private key indeﬁnitely. Instead, the email should be decrypted
prior to being stored in the mail store. �e mail store, in turn, should be secured using anappropriate cryptographic technique (for example, disk encryption), extending protection to both
encrypted and unencrypted email. If it is necessary to store mail encrypted on the mail server (forexample, if the mail server is outside the control of the end-user’s organization), then themessages should be re-encrypted with a changeable session key on a message-by-message basis.

72

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

Where the DNS performs canonicalization of email addresses, a client requesting a hash encoded
OPENPGPKEY or SMIMEA RR shall perform no transformation on the left part of the addressoﬀered, other than UTF-8 and lower-casing. �is is an attempt to minimize the queries needed to
discover an S/MIME certiﬁcate in the DNS for newly learned email addresses and allow for the
initial email to be sent encrypted (if desired).
5.3.2

OpenPGP and OPENPGPKEY

OpenPGP [RFC4880] is a proposed Internet Standard for providing authentication andconﬁdentiality for email messages. Although similar in purpose to S/MIME, OpenPGP is
distinguished by using message and key formats that are built on the “Web of Trust” model (seeSection 2.4.3).
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

�e OpenPGP standard is implemented by PGP-branded software from Symantec 24 and by theopen source GNU Privacy Guard. 25 �ese OpenPGP programs have been widely used by
activists and security professionals for many years but have never gained a widespread following
among the general population owing to usability programs associated with installing thesoftware, generating keys, obtaining the keys of correspondents, encrypting messages, anddecrypting messages. Academic studies have found that even “easy-to-use” versions of thesoftware that received good reviews in the technical media for usability were found to be not
usable when tested by ordinary computer users. [WHITTEN1999]
Key distribution was an early usability problem that OpenPGP developers attempted to address.
Initial eﬀorts for secure key distribution involved key distribution parties, where all participants
are known to and can authenticate each other. �is method does a good job of authenticating
users to each other and building up webs of trust, but it does not scale at all well, and it is not
greatly useful where communicants are geographically widely separated.
To facilitate the distribution of public keys, a number of publicly available key servers have been
set up and have been in operation for many years. Among the more popular of these is the poolof SKS key servers 26. Users can freely upload public keys on an opportunistic basis. In theory,
anyone wishing to send a PGP user encrypted content can retrieve that user’s public key from the
SKS server, use it to encrypt a generated data encryption key used to encrypt the message, andsend it. However, there is no authentication of the identity of the key owners; an attacker can
upload their own key to the key server, then intercept the email sent to the unsuspecting user.
A renewed interest in personal control over email authentication and encryption has led to further
work within the IETF on key sharing, and the DANE mechanism [RFC7929] is being adopted toplace a domain and user’s public key in an OPENPGPKEY record in the DNS. Unlike
DANE/TLS and SMIMEA, OPENPGPKEY does not use X.509 certiﬁcates, or require full PKIX
authentication as an option. Instead, full trust is placed in the DNS records as certiﬁed by
DNSSEC: �e domain owner publishes a public key and minimal “certiﬁcate” information. �e

24 http://www.symantec.com/products-solutions/families/?fid=encryption
25 https://www.gnupg.org/

26 An incomplete list of well-known keyservers can be found at https://www.sks-keyservers.net

73

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

key is available for the receiver of a signed message to authenticate, or for the sender of amessage to encrypt a data encryption key.
Security Recommendation 5-5: For Federal use, OpenPGP is not preferred for message
conﬁdentiality. �e use of S/MIME with a certiﬁcate signed by a known CA is preferred.
5.3.2.1 Recommendations

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Where an institution requires signing and encryption of end-to-end email, S/MIME is preferredover OpenPGP. Like the S/MIME discussion above, if used, the email should be decrypted prior
to being stored in the mail store. �e mail store, in turn, should be secured using an appropriate
cryptographic technique (for example, disk encryption), extending protection to both encrypted
and unencrypted email. If it is necessary to store mail encrypted on the mail server (for example,
if the mail server is outside the control of the end-user’s organization), then the messages should
be re-encrypted with a changeable session key on a message-by-message basis. In addition,
where the DNS performs canonicalization of email addresses, a client requesting a hash encoded
OPENPGPKEY or SMIMEA RR shall perform no transformation on the left part of the addressoﬀered, other than UTF-8 and lower-casing.
5.4

Security Recommendation Summary

Security Recommendation 5-1: Organizations are recommended only use approved TLS
versions listed in NIST SP 800-52 with FIPS approved cryptographic modules.
Security Recommendation 5-2: TLS-capable servers should prompt clients to invoke the
STARTTLS command. TLS clients should attempt to use STARTTL for SMTP, either initially,or issuing the command when oﬀered.
Security Recommendation 5-3: Receiving domains should implement protocols to signal
TLS usage to clients. Receivers should implement DANE, MTA-STS (or both) for all mailservers listed in the domain’s MX Resource Record set.
Security Recommendation 5-4: Oﬃcial use of digitally signed/encrypted email requires
certiﬁcate chain authentication against a known CA and using DANE-TA Certiﬁcate Usagevalues when deploying DANE.
Security Recommendation 5-5: Do not use OpenPGP for message conﬁdentiality. Instead,use S/MIME with a certiﬁcate that is signed by a known CA.

74

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

6Reducing Unsolicited Bulk Email

6.1

Introduction

Unsolicited Bulk Email (UBE) has an analogy with “beauty”, in that it is often in the eye of thebeholder. To some senders, it is a low-cost marketing campaign for a valid product or service. To
many receivers and administrators, it is a scourge that ﬁlls up message inboxes and can be avector for criminal activity or malware. Both of these views can be true, as the term Unsolicited
Bulk Email (or spam, as it is often called) comprises a wide variety of email received by anenterprise.
6.2

Why an Organization May Want to Reduce Unsolicited Bulk EmailThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

While some unsolicited email is from legitimate marketing ﬁrms and may only rise to the levelof being a nuisance, it can also lead to increased resource usage in the enterprise. UBE can ﬁll up
user inbox storage, consume bandwidth in receiving email and consume end users' time as theysort through and delete unwanted email. However, some UBE may rise to the level of being a
legitimate threat to the organization in the form of fraud, illegal activity, or the distribution of
malware.
Depending on the organization's jurisdiction, UBE may include advertisements for goods orservices that are illegal. Enterprises or organizations may wish to limit their employees' (andusers') exposure to these oﬀers. Other illegitimate UBE are fraud attempts aimed at the users of agiven domain and used to obtain money or private information. Lastly, some UBE is simply a
Trojan horse aimed at trying to inﬁltrate the enterprise to install malware.
6.3

Techniques to Reduce Unsolicited Bulk Email�ere are a variety of techniques that an email administrator can use to reduce the amount of
UBE delivered to the end users’ inboxes. Enterprises can use one or multiple technologies toprovide a layered defense against UBE since no solution is completely eﬀective against all UBE.
Administrators should consider using a combination of tools for processing incoming, andoutgoing email.

Figure 6-1: Inbound email "pipeline" for UBE filtering

75

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

�ese techniques can be performed in serial as a "pipeline" for both incoming and outgoingemail [REFARCH]. Less computationally expensive checks should be done early in the pipeline
to prevent wasted eﬀort later. For example, a UBE/SMTP connection that would be caught andrefused by a blacklist ﬁlter should be done before more computationally expensive content
analysis is performed on an email that will ultimately be rejected or deleted. In Figure 6-1, an
example pipeline for incoming email checks is given. Figure 6-2 shows an example outboundpipeline for email checks.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Figure 6-2: Outbound email "pipeline" for UBE filtering

6.3.1

Approved/Non-approved Sender Lists

�e most basic technique to reduce UBE is to simply accept or deny messages based on some listof known bad or known trusted senders. �is is often the ﬁrst line of UBE defense utilized by anenterprise because, if a message was received from a known bad sender, it could reasonably be
dropped without spending resources in further processing. Or, email originating from a trusted
source could be marked so as not to be subject to other anti-UBE checks and inadvertently
deleted or thrown out.
A non-approved sender list can be composed of individual IP addresses, IP blocks, or sending
domain bases [RFC5782]. For example, it is normal for enterprises to refuse email from senders
using a source address that has not be allocated, or part of a block reserved for private use (suchas 192.168/16). Or an administrator could choose to not accept email from a given domain if
there is no reason to assume that they have any interaction with senders using a given domain.
�is could be the case where an organization does not do business with certain countries and may
refuse mail from senders using those country code Top Level Domains (ccTLDs).
Given the changing nature of malicious UBE, static lists are not eﬀective. Instead, a variety ofthird party services produce dynamic lists of known bad UBE senders that enterpriseadministrators can subscribe to and use. �ese lists are typically accessed by DNS queries andinclude the non-commercial ventures such as the Spamhaus Project 27 and the Spam and Open
27 https://www.spamhaus.org/

76

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

Relay Blocking System (SORBS) 28, as well as commercial vendors such as SpamCop. 29 An
extensive list of DNS-based blacklists can be found at http://www.dnsbl.info. Because anindividual service may be unavailable, many organizations conﬁgure their mailers to use
multiple blacklists. Email administrators should use these services to maintain a dynamic rejectlist rather than attempting to maintain a static list for a single organization.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

An approved list is the opposite of a non-approved list. Instead of refusing email from a list of
known bad actors, an approved list is composed of known trusted senders. It is often a list of
business partners, community members, or similar trusted senders that have an existing
relationship with the organization or members of the organization. �is does not mean that all
email sent by members on an approved list should be accepted without further checks. Email sentby an approved sender may not be subject to other anti-UBE checks but may still be checked forpossible malware or malicious links. Email administrators wishing to use approved list should bevery stringent about which senders make the list. Frequent reviews of the list should also occur
to remove senders when the relationship ends or add new members when new relationships areformed. Some email tools allow for end users to create their own approved list, so administrators
should make sure that end users do not approve a known bad sender.
A list of approved/non-approved receivers can also be constructed for outgoing email to identify
possible victims of malicious UBE messages or infected hosts sending UBE as part of a botnet.
�at is, a host or end user sending email to a domain or setting the message-From: address
domain to one listed in a non-approved receiver list. Again, since this is a relatively easy(computational) activity, it should be done before any more intensive scanning tools are used.
6.3.2

Domain-based Authentication Techniques

Techniques that use sending policy encoded in the DNS, such as Sender Policy Framework(SPF), DomainKeys Identiﬁed Mail (DKIM), and Domain-based Message Authentication andReporting Conformance (DMARC) can also be used to reduce some UBE. Receiving MTAs use
these protocols to see if a message was sent by an authorized sending MTA for the purported
domain. �ese protocols are discussed in Section 4 and should be utilized by email
administrators for both sending and receiving email.
�ese protocols only authenticate that an email was sent by a mail server that is considered avalid email sender by the purported domain and does not authenticated the contents of the email
message. Messages that pass these checks should not automatically be assumed to not be UBE,
as a malicious bulk email sender can easily set up and use their own sending infrastructure thatwould pass these checks. Likewise, malicious code that uses an end user's legitimate account tosend email will also pass domain-based authentication checks.
Domain-based authentication checks require more processing by the receiver MTA and thus
should be performed on any mail that has passed the ﬁrst set of blacklist checks. �ese checks do

28 http://www.sorbs.net/

29 https://www.spamcop.net/

77

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

not require the MTA to have the full message and can be done before any further and morecomputationally expensive content checks. 30
6.3.3

Content Filtering�e third type of UBE ﬁltering measures involves analysis of the actual contents of an email
message. �ese ﬁltering techniques examine the content of a mail message for words, phrases orother elements (images, web links, etc.) that indicate that the message may be UBE.
Examining the textual content of an email message is done using word/phrase ﬁlters or Bayesianﬁlters [UBE1] to identify possible UBE. Since these techniques are not foolproof, most tools that
use these techniques allow for administrators or end users to set the threshold for UBE
identiﬁcation or allow messages to be marked as possible UBE to prevent false positives and thedeletion of valid transactional messages.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Messages that contain URLs or other non-text elements (or attachments) can also be ﬁltered andtested for possible malware, UBE advertisements, etc. �is could be done via blacklisting(blocking email containing links to known malicious sites) or by opening the links in a
sandboxed browser-like component 31 in an automated fashion to record the results. If the activity
corresponds to anomalous or known malicious activity, the message will be tagged as malicious
UBE and deleted before placed into the end-user's in-box.
Content ﬁltering and URL analysis is more computationally expensive than other UBE ﬁltering
techniques since the checks are done over the message contents. �is means that the checks areoften done after blacklisting and domain-based authentication checks have completed. �isavoids accepting and processing email from a known bad or malicious sender. End-to-end
encryption of messages (e.g., S/MIME or OpenPGP) can also prevent content ﬁltering.
Content ﬁltering could also be applied to outgoing email to identify possible botnet infection or
malicious code attempting to use systems within the enterprise to send UBE. Some content ﬁlters
may include organization-speciﬁc ﬁlters or keywords to prevent the loss of private or
conﬁdential information.
6.4

User Education

�e ﬁnal line of defense against malicious UBE is an educated end user. An email user that isaware of the risks inherent in using email should be less likely to fall victim to fraud attempts,
social engineering or convinced into clicking links containing malware. While such training may
not stop all suspicious email, often times an educated end user can sometimes detect and avoid
malicious UBE that passes all automated checks.

30 Messages are transmitted incrementally with SMTP, header by header and then body contents and attachments. This allows forincremental and ‘just-in-time’ header and content filtering.

31 Sometimes called a "detonation chamber."

78

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

How to setup a training regime that includes end user education on the risks of UBE to theenterprise is beyond the scope of this document. �ere are several federal programs to help inend user IT security training, such as the “Stop. �ink. Connect.” 32 program from the
Department of Homeland Security (DHS). Individual organizations should tailor available IT
security education programs to the needs of their organization.
User education does not ﬁt into the pipeline model in Section 6.3 above, as it takes place at thetime that the end user views the email using their MUA. At this point, all of the above techniques
have failed to identify the threat that now has been placed in the end user's in-box. For outgoing
UBE, the threat is being sent out (possibly using the user's email account) via malicious code
installed on the end user's system. User education can help to prevent users from allowing theirmachines to become infected with malicious code or teach them to identify and remediate theissue when it arises.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1
32 https://www.dhs.gov/stopthinkconnect

79

NIST SP 800-177 REV. 1

7

End User Email Security

7.1

Introduction

TRUSTWORTHY EMAILThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

In terms of the canonical email processing architecture as described in Section 2, the client may
play the role of the MUA. �is section we will discuss clients and their interactions andconstraints when using POP3, IMAP, and SMTP. �e range of an end user’s interactions with amailbox is usually done using one of two classes of clients: webmail clients and standalone
clients. �ese clients communicate with the mailbox in diﬀerent ways. Webmail clients use
HTTPS. �ese are discussed in Section 7.2. Mail client applications for desktop or mobile
devices may use IMAP or POP3 for receiving and SMTP for sending, and these are examined in
Section 7.3. �ere is also the case of command-line clients, the original email clients that are stillused for certain embedded system accesses. However, these represent no signiﬁcant proportionof the enterprise market and will not be discussed in this document.
7.2

Webmail Clients

Many enterprises permit email access while away from the workplace or the corporate LAN. �emechanisms for this access is a Virtual Private Network (VPN) or a web interface through abrowser. In the latter case, the security posture is determined at the web server. Actual
communication between a client and server is conducted over HTTP or HTTPS. Federal agencies
implementing a web-based solution should refer to NIST SP 800-95 [SP800-95] and adhere toother federal policies regarding web-based services. Federal agencies are required to provide a
certiﬁcate that can be authenticated through PKIX to a well-known trust-anchor. An enterprise
may choose to retain control of its own trusted roots. In this case, DANE can be used to
conﬁgure a TLSA record and authenticate the certiﬁcate using the DNS (see Section 5.2.5).
7.3

Standalone Clients

For the purposes of this guide, a standalone client refers to a software component used by an end
user to send and/or receive email. Examples of such clients include Mozilla �underbird andMicrosoft Outlook. �ese components are typically found on a host computer, laptop or mobile
device. �ese components may have many features beyond basic email processing, but these are
beyond the scope of this document.
Sending requires connecting to an MSA or an MTA using SMTP. �is is discussed in Section
7.3.2. Receiving is typically done via POP3 and IMAP, 33 and mailbox management diﬀers ineach case.
7.3.1

Sending via SMTP

Email message submission occurs between a client and a server using the Simple Mail Transfer
Protocol (SMTP) [RFC5321], either using port 25, 465 or 587. �e client is operated by an end-

33 Other protocols (MAPI/RPC or proprietary protocols) will not be discussed.

80

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

user, and the server is hosted by a public or corporate mail service. Clients should authenticate
using client authentication schemes such as usernames and passwords or PKI-based
authentication as provided by the protocol.
It is further recommended that the connection between the client and MSA be secured using TLS[RFC5246] [RFC8314], associated with the full range of protective measures described in
Section 5.2.
7.3.2

Receiving via IMAP

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Email message receiving, and management occurs between a client and a server using theInternet Message Access Protocol (IMAP) protocol [RFC3501] over port 143 and 993. A client
may be located anywhere on the Internet, establish a transport connection with the server,
authenticate itself, and manipulate the remote mailbox with a variety of commands. Dependingon the server implementation, it is feasible to have access to the same mailbox from multiple
clients. IMAP has operations for creating, deleting and renaming mailboxes; checking for new
messages; permanently removing messages; parsing; searching; and selective fetching of
message attributes, texts and parts thereof. It is equivalent to the local control of a mailbox andits folders.
Establishing a connection with the server over TCP and authenticating to a mailbox with ausername and password sent without encryption is not recommended. IMAP clients should
connect to servers using TLS [RFC5246] [RFC8314], which should be associated with the fullrange of applicable protective measures described in Section 5.2.
7.3.3

Receiving via POP3

Before IMAP [RFC3501] was invented, the Post Oﬃce Protocol (POP, now POP version 3 orPOP3) had been created as a mechanism for remote users to connect to mailbox, download mail,and delete it oﬀ the server. It was expected at the time that access be from a single, dedicateduser, with no conﬂicts. Provision for encrypted transport was not made.
�e protocol went through an evolutionary cycle of upgrades, and the current instance, POP3
[RFC5034] is aligned with the Simple Authentication Security Layer (SASL) [RFC4422] andoptionally operated over a secure encrypted transport layer, TLS [RFC5246]. POP3 deﬁnes a
simpler mailbox access alternative to IMAP, without the same ﬁne control over mailbox ﬁlestructure and manipulation mechanisms. Users who access their mailboxes from multiple hosts
or devices should use IMAP clients instead of POP3, to maintain a synchronization of clientswith the single, central mailbox.
Clients with POP3 access should conﬁgure them to connect over TLS [RFC8314], which should
be associated with the full range of protective measures described above in Section 5.2, Email
Transmission Security.
Security Recommendation 7-1: IMAP and POP3 clients should connect to servers using
TLS [RFC5246] and be associated with the full range of protective measures described in81

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

Section 5.2, Email Transmission Security. Connecting with unencrypted TCP and authenticatingwith username and password is strongly discouraged.
7.4

Mailbox Security

�e security of data in transit is only useful if the security of data at rest can be assured. �ismeans maintaining conﬁdentiality at the sender and receiver endpoints of:••�e user’s information (e.g., mailbox contents), andPrivate keys.

Conﬁdentiality and the encryption for data in transit is discussed in Section 7.4.1, while theconﬁdentiality of data at rest is discussed in Section 7.4.2.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

7.4.1

Confidentiality of Data in Transit

A common element for users of TLS for SMTP, IMAP and POP3, as well as for S/MIME and
OpenPGP, is the need to maintain current and accessible private keys, as used for decryption ofreceived mail, and signing of authenticated mail. A range of diﬀerent users require access tothese disparate private keys:••

�e email server must have use of the private key used for TLS and the private key must
be protected.
�e end user (and possibly an enterprise security administrator) must have access to
private keys for S/MIME or OpenPGP message signing and key decipherment.

Special care is needed to ensure that only the relevant parties have access and control over therespective keys. For federal agencies, this means compliance with all relevant policy and bestpractice for the protection of key material [SP800-57pt1] and message contents (e.g., FOIA,
eDiscovery, etc.).
Security Consideration 7-2: Enterprises should establish a cryptographic key management
system (CKMS) for keys associated with protecting email sessions with end users. For federal
agencies, this means compliance with all relevant policy and best practice for the protection of
key material [SP800-57pt1].
7.4.2

Confidentiality of Data at Rest

�is publication is about securing email and its associated data. �is is one aspect of securing
data in transit. To the extent that email comes to rest in persistent storage in mailboxes and ﬁlestores, there is some overlap with NIST SP 800-111 [SP800-111].
�ere is an issue in the tradeoﬀ between accessibility and conﬁdentiality when using mailboxes
as persistent storage. End users and their organizations are expected to manage their own private
keys, and historical versions of these may remain available to enable the decryption of mailencrypted by communicating partners, and to authenticate cc: mail sent to partners, which havebeen also stored locally. Partners who sign their mail, and decrypt received mail, make their82

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

public keys available through certiﬁcates, or through DANE records (i.e., TLSA,OPENPGPKEY, SMIMEA) in the DNS. �ese certiﬁcates generally have a listed expiry date
and are rolled over and replaced with new certiﬁcates containing new keys. For people who use
their mailboxes as persistent, large-scale storage, this can create a management problem. If a
mail user’s expired keys cannot be found, historical encrypted messages cannot be read.
Email keys for S/MIME and OpenPGP should only be used for messages in transit. Messages
intended for persistent local storage should be decrypted, stored in user-controllable ﬁle storage,
and, if necessary, re-encrypted with user-controlled keys. For maximum security, all email
should be stored encrypted—for example, with a cryptographic ﬁle system.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Security Recommendation 7-3: Cryptographic keys used for encrypting data in persistentstorage (e.g., in mailboxes) should be diﬀerent from keys used for the transmission of email
messages.
7.5

Security Recommendation Summary

Security Recommendation 7-1: IMAP and POP3 clients should connect to servers using
TLS [RFC5246] and be associated with the full range of protective measures described in
Section 5.2, Email Transmission Security. Connecting with unencrypted TCP and authenticatingwith username and password is strongly discouraged.
Security Consideration 7-2: Enterprises should establish a cryptographic key management
system (CKMS) for keys associated with protecting email sessions with end users. For federal
agencies, this means compliance with all relevant policy and best practice for the protection of
key material [SP800-57pt1].
Security Recommendation 7-3: Cryptographic keys used for encrypting data in persistentstorage (e.g., in mailboxes) should be diﬀerent from keys used for the transmission of email
messages.

83

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILAppendix A—Acronyms

Selected acronyms and abbreviations used in this paper are deﬁned below.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

DHS

Department of Homeland Security

DKIM

DomainKeys Identiﬁed Mail

DMARC

Domain-based Message Authentication, Reporting and Conformance

DNS

Domain Name System

DNSSEC

Domain Name System Security Extensions

FISMA

Federal Information Security Management Act

FRN

Federal Network Resiliency

IMAPInternet Message Access Protocol

MDA

Mail Delivery Agent

MSA

Mail Submission Agent

MTA

Mail Transport Agent

MUA

Mail User Agent

MIME

Multipurpose Internet Message Extensions

NIST SPNIST Special Publication

PGP/OpenPGP

Pretty Good Privacy

PKI

Public Key Infrastructure

POP3

Post Oﬃce Protocol, Version 3

RR

Resource Record

S/MIME

Secure/Multipurpose Internet Mail Extensions

SMTP

Simple Mail Transport Protocol

SPF

Sender Policy Framework

TLS

Transport Layer Security

VM

Virtual Machine

VPN

Virtual Private Network
84

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILAppendix B—References
B.1

NIST Publications

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1[FIPS 201]

Federal Information Processing Standards Publication 201-2: Personal
Identity Veriﬁcation (PIV) of Federal Employees and Contractors. National
Institute of Standards and Technology, Gaithersburg, Maryland, August
2013. https://doi.org/10.6028/NIST.FIPS.201-2[SP800-45]

NIST Special Publication 800-45 version 2. Guidelines on Electronic Mail
Security. National Institute of Standards and Technology, Gaithersburg,
Maryland, February 2007. https://doi.org/10.6028/NIST.SP.800-45ver2[SP800-52]

NIST Special Publication 800-52 Revision 1. Guidelines for the Selection,
Conﬁguration, and Use of Transport Layer Security (TLS) Implementations.
National Institute of Standards and Technology, Gaithersburg, Maryland,
April 2014. https://doi.org/10.6028/NIST.SP.800-52r1[SP800-53]

NIST Special Publication 800-53 Revision 4. Security and Privacy Controls
for Federal Information Systems and Organizations. National Institute ofStandards and Technology, Gaithersburg, Maryland, April 2013.
https://doi.org/10.6028/NIST.SP.800-53r4[SP800-57pt1] NIST Special Publication 800-57 Part 1 Revision 4. Recommendation for
Key Management, Part 1: General. National Institute of Standards andTechnology, Gaithersburg, Maryland, January 2016.
https://doi.org/10.6028/NIST.SP.800-57pt1r4[SP800-57pt3] NIST Special Publication 800-57 Part 3 Revision 1. Recommendation for
Key Management, Part 3: Application-Speciﬁc Key Management Guidance.
National Institute of Standards and Technology, Gaithersburg, Maryland,
January 2015. https://doi.org/10.6028/NIST.SP.800-57pt3r1[SP800-81]

NIST Special Publication 800-81 Revision 2, Secure Domain Name System(DNS) Deployment Guide, National Institute of Standards and Technology,
Gaithersburg, Maryland, September 2013.
https://doi.org/10.6028/NIST.SP.800-81-2[SP800-95]

NIST Special Publication 800-95. Guide to Secure Web Services. National
Institute of Standards and Technology, Gaithersburg, Maryland, August
2007. https://doi.org/10.6028/NIST.SP.800-95[SP800-111]

NIST Special Publication 800-111. Guide to Storage Encryption
Technologies for End User Devices. National Institute of Standards andTechnology, Gaithersburg, Maryland, November 2007.
https://doi.org/10.6028/NIST.SP.800-111
85

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL[SP800-130]

NIST Special Publication 800-130. A Framework for Designing
Cryptographic Key Management Systems. National Institute of Standards
and Technology, Gaithersburg, Maryland, August 2013.
https://doi.org/10.6028/NIST.SP.800-130[SP800-152]

NIST Special Publication 800-152. A Proﬁle for U.S. Federal
Cryptographic Key Management Systems (CKMS). National Institute ofStandards and Technology, Gaithersburg, Maryland, October 2015.
https://doi.org/10.6028/NIST.SP.800-152

B.2This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1[RFC2045]

Core Email Protocols

N. Freed and N. Borenstein. Multipurpose Internet Mail Extensions(MIME) Part One: Format of Internet Message Bodies. Internet
Engineering Task Force Request for Comments 2045, November 1996.
https://datatracker.ietf.org/doc/rfc2045/[RFC2046]

N. Freed and N. Borenstein. Multipurpose Internet Mail Extensions(MIME) Part Two: Media Types Internet Engineering Task Force Request
for Comments 2046, November 1996.
https://datatracker.ietf.org/doc/rfc2046/[RFC2047]

N. Freed and N. Borenstein. Multipurpose Internet Mail Extensions(MIME) Part Three: Message Headers for Non-ASCII Text Internet
Engineering Task Force Request for Comments 2047, November 1996.
https://datatracker.ietf.org/doc/rfc2047/[RFC2822]

P. Resnick. Internet Message Format. Internet Engineering Task Force
Request for Comments 2822, April 2001.
https://datatracker.ietf.org/doc/rfc2822/[RFC3501]

M. Crispin. INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1. Internet Engineering Task Force Request for Comments 3501,
March 2003. https://datatracker.ietf.org/doc/rfc3501/[RFC3696]

J. Klensin. Application Techniques for Checking and Transformation ofNames. Internet Engineering Task Force Request for Comments 3696,
February 2004. https://datatracker.ietf.org/doc/rfc3696/[RFC5321]

J. Klensin. Simple Mail Transfer Protocol. Internet Engineering Task Force
Request for Comments 5321, April 2008.
https://datatracker.ietf.org/doc/rfc5321/[RFC5322]

P. Resnick. Internet Message Format. Internet Engineering Task Force
Request for Comments 5322, October 2008.
86

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

https://datatracker.ietf.org/doc/rfc5322/

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1[RFC7601]

M. Kucherawy. Message Header Field for Indicating Message
Authentication Status. Internet Engineering Task Force Request forComments 7601, August 2015. https://datatracker.ietf.org/doc/rfc7601/[RFC8314]

K. Moore and C. Newman. Cleartext Considered Obsolete: Use of
Transport Layer Security (TLS) for Email Submission and Access. Internet
Engineering Task Force Request for Comments 8314, August 2015.
https://datatracker.ietf.org/doc/rfc8314/[STD35]

J. Myers and M. Rose. Post Oﬃce Protocol - Version 3. Internet
Engineering Task Force Standard 35. May 1996.
https://datatracker.ietf.org/doc/rfc1939/

B.3

Sender Policy Framework (SPF)[HERZBERG
2009]

Amir Herzberg. 2009. DNS-based email sender authentication mechanisms:
A critical review. Computer. Security. 28, 8 (November 2009), 731-742.
https://doi.org/10.1016/j.cose.2009.05.002[RFC7208]

S. Kitterman. Sender Policy Framework (SPF) for Authorizing Use of
Domains in Email, Version 1. Internet Engineering Task Force Request forComments 7208, April 2014. https://datatracker.ietf.org/doc/rfc7208/

B.4

DomainKeys Identified Mail (DKIM)[RFC4686]

J. Fenton. Analysis of Threats Motivating DomainKeys Identiﬁed Mail
(DKIM). Internet Engineering Task Force Request for Comments 4686,
September 2006. https://datatracker.ietf.org/doc/rfc4686/[RFC5863]

T. Hansen, E. Siegel, P. Hallam-Baker and D. Crocker. DomainKeys
Identiﬁed Mail (DKIM) Development, Deployment, and Operations.
Internet Engineering Task Force Request for Comments 5863, May 2010.
https://datatracker.ietf.org/doc/rfc5863/[RFC6376]

D. Cocker, T. Hansen, M. Kucherawy. DomainKeys Identiﬁed Mail (DKIM)
Signatures. Internet Engineering Task Force Request for Comments 6376,
September 2011. https://datatracker.ietf.org/doc/rfc6376/[RFC6377]

M. Kucherawy. DomainKeys Identiﬁed Mail (DKIM) and Mailing Lists.
Internet Engineering Task Force Request for Comments 6377, September
2011. https://datatracker.ietf.org/doc/rfc6377/
87

NIST SP 800-177 REV. 1[RFC8463]

B.5

TRUSTWORTHY EMAIL

J. Levine. A New Cryptographic Signature Method for DomainKeys
Identiﬁed Mail (DKIM). Internet Engineering Task Force Request forComments 8463, September 2018. https://datatracker.ietf.org/doc/rfc8463/

Domain-based Message Authentication, Reporting and Conformance(DMARC)This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1[RFC6591]

H. Fontana. Authentication Failure Reporting Using the Abuse Reporting
Format. Internet Engineering Task Force Request for Comments 6591,
November 2007. https://datatracker.ietf.org/doc/rfc6591/[RFC7489]

M. Kucherawy and E. Zwicky. Domain-based Message Authentication,
Reporting, and Conformance (DMARC). Internet Engineering Task Force
Request for Comments 7489, March 2015.
https://datatracker.ietf.org/doc/rfc7489/

B.6

Cryptography and Public Key Infrastructure (PKI)[RFC3207]

P. Hoﬀman. SMTP Service Extension for Secure SMTP over Transport
Layer Security. Internet Engineering Task Force Request for Comments
3207, February 2002. https://datatracker.ietf.org/doc/rfc3207/[RFC3156]

M. Elkins, D. Del Torto, R. Levien and T. Roessler. MIME Security with
OpenPGP. Internet Engineering Task Force Request for Comments 3156,
August 2001. https://datatracker.ietf.org/doc/rfc3156/[RFC4422]

A. Melnikov and K. Zeilenga. Simple Authentication and Security Layer(SASL). Internet Engineering Task Force Request for Comments 4422, June
2006. https://datatracker.ietf.org/doc/rfc4422/[RFC4880]

J. Callas, L. Donnerhacke, H. Finney, D. Shaw and R. �ayer. OpenPGP
Message Format. Internet Engineering Task Force Request for Comments
4880, November 2007. https://datatracker.ietf.org/doc/rfc4880/[RFC5034]

R. Siemborski and A. Menon-Sen. The Post Oﬃce Protocol (POP3) Simple
Authentication and Security Layer (SASL) Authentication Mechanism.
Internet Engineering Task Force Request for Comments 5034, July 2007.
https://datatracker.ietf.org/doc/rfc5034/[RFC5091]

X. Boyen and L. Martin. Identity-Based Cryptography Standard (IBCS) #1:
Supersingular Curve Implementations of the BF and BB1 Cryptosystems
Internet Engineering Task Force Request for Comments 5091, December
88

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

2007. https://datatracker.ietf.org/doc/rfc5091/

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1[RFC5280]

D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk.
Internet X.509 Public Key Infrastructure Certiﬁcate and Certiﬁcate
Revocation List (CRL) Proﬁle. Internet Engineering Task Force Request forComments 5280, May 2008. https://datatracker.ietf.org/doc/rfc5280/[RFC5408]

G. Appenzeller, L. Martin, and M. Schertler. Identity-Based Encryption
Architecture and Supporting Data Structures. Internet Engineering Task
Force Request for Comments 5408, January 2009.
https://datatracker.ietf.org/doc/rfc5408/[RFC5409]

L. Martin and M. Schertler. Using the Boneh-Franklin and Boneh-Boyen
Identity-Based Encryption Algorithms with the Cryptographic Message
Syntax (CMS). Internet Engineering Task Force Request for Comments
5409, January 2009. https://datatracker.ietf.org/doc/rfc5409/[RFC5750]

B. Ramsdell and S. Turner. Secure/Multipurpose Internet Mail Extensions(S/MIME) Version 3.2 Certiﬁcate Handling. Internet Engineering Task
Force Request for Comments 5750, January 2010.
https://datatracker.ietf.org/doc/rfc5750/[RFC5751]

B. Ramsdell et. al. Secure/Multipurpose Internet Mail Extensions (S/MIME)
Version 3.2 Message Speciﬁcation. Internet Engineering Task Force
Request for Comments 5751, January 2010.
https://datatracker.ietf.org/doc/rfc5751/[RFC6066]

D. Eastlake 3rd. Transport Layer Security (TLS) Extensions: Extension
Deﬁnitions. Internet Engineering Task Force Request for Comments 6066,
January 2011. https://datatracker.ietf.org/doc/rfc6066/[RFC6698]

P. Hoﬀman and J. Schlyter. The DNS-Based Authentication of Named
Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA. Internet
Engineering Task Force Request for Comments 6698, August 2012.
https://datatracker.ietf.org/doc/rfc6698/[RFC6960]

S. Santesson, M. Myers, R. Ankney, A. Malpani, S. Galperin and C.
Adams. X.509 Internet Public Key Infrastructure Online Certiﬁcate Status
Protocol – OCSP. Internet Engineering Task Force Request for Comments
6960, June 2013. https://datatracker.ietf.org/doc/rfc6960/[RFC7218]

O. Gudmundsson, Adding Acronyms to Simplify Conversations about DNSBased Authentication of Named Entities (DANE), Internet Engineering Task
Force Request for Comments 7218, April 2014,
https://datatracker.ietf.org/doc/rfc7218

89

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1[RFC7671]

V. Dukhovni, W. Hardaker, The DNS-Based Authentication of Named
Entities (DANE) Protocol: Updates and Operational Guidance. Internet
Engineering Task Force Request for Comments 7671, October 2015.
https://datatracker.ietf.org/doc/rfc7671/[RFC7672]

V. Dukhovni, W. Hardaker, SMTP Security via Opportunistic DNS-Based
Authentication of Named Entities (DANE) Transport Layer Security (TLS).
Internet Engineering Task Force Request for Comments 7672, October
2015, https://datatracker.ietf.org/doc/rfc7672/[RFC7929]

P. Wouters. DNS-Based Authentication of Named Entities (DANE) Bindings
for OpenPGP. Internet Engineering Task Force Request for Comments
7929, August 2016. https://datatracker.ietf.org/doc/rfc7929/[RFC8162]

P. Hoﬀman, J. Schlyter. Using Secure DNS to Associate Certiﬁcates with
Domain Name for S/MIME. Internet Engineering Task Force Request forComments 8162, May 2017. https://datatracker.ietf.org/doc/rfc8162/[RFC8446]

E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.3.
Internet Engineering Task Force Request for Comments 8446, August
2018. https://datatracker.ietf.org/doc/rfc8446/[RFC8460]

D. Margolis, A. Brotman, B. Ramakrishnan, J. Jones and M. Risher. SMTP
TLS Reporting. Internet Engineering Task Force Request for Comments
8460, September 2018. https://datatracker.ietf.org/doc/rfc8460/[RFC8461]

D. Margolis, B. Ramakrishnan, J. Jones and A. Brotman. SMTP MTA
Strict Transport Security (MTA-STS) Internet Engineering Task Force
Request for Comments 8461, September 2018.
https://datatracker.ietf.org/doc/rfc8461/

B.7

Other

[BOD18-01]

Binding Operational Directive BOD-18-01 “Enhance Email and Web
Security”. Department of Homeland Security, October 2017.
https://cyber.dhs.gov/assets/report/bod-18-01.pdf[DOD2009]“Digital Signatures on Email Now a DoD Requirement,” Press Release,
Naval Network Warfare Command, February 2, 2009.

[FPKIKRP]

Federal PKI Key Recovery Policy. Federal Public Key Infrastructure
Policy Authority. Version 1.0, October 2017.
https://www.idmanagement.gov/wpcontent/uploads/sites/1171/uploads/fpki-krp-v1.0-10-6-2017.pdf

90

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1[GAR2005]

Simson L. Garﬁnkel and Robert C. Miller. 2005. Johnny 2: a user test of
key continuity management with S/MIME and Outlook Express. In
Proceedings of the 2005 symposium on Usable privacy and security(SOUPS '05). ACM, New York, NY, USA, 13-24.
https://doi.org/10.1145/1073001.1073003[M3AAWG]

M3AAWG Policy Issues for Receiving Email in a World with IPv6
Hosts. Messaging, Malware and Mobile Anti-Abuse Working Group.
September 2014.
https://www.m3aawg.org/sites/default/ﬁles/document/M3AAWG_Inbou
nd_IPv6_Policy_Issues-2014-09.pdf[REFARCH]

Electronic Mail (Email) Gateway Reference Architecture. Dept. ofHomeland Security Federal Network Resiliency Federal Interagency
Technical Reference Architectures. DRAFT Version 1.3, June 2015.
https://community.max.gov/display/DHS/Email+Gateway[RFC1034]

P. Mockapetris. DOMAIN NAMES - CONCEPTS AND FACILITIES.
Internet Engineering Task Force Request for Comments 1034.
November 1987. https://datatracker.ietf.org/doc/rfc1034/[RFC1035]

P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION. Internet Engineering Task Force Request forComments 1035. November 1987.
https://datatracker.ietf.org/doc/rfc1035/[RFC2505]

G. Lindberg. Anti-Spam Recommendations for SMTP MTAs. Internet
Engineering Task Force Request for Comments 2505. February 1999.
https://datatracker.ietf.org/doc/rfc2505/[RFC4033]

R. Arends, R. Austein, M. Larson, D. Massey and S. Rose. DNS
Security Introduction and Requirements. Internet Engineering Task
Force Request for Comments 4033. March 2005.
https://datatracker.ietf.org/doc/rfc4033/[RFC4034]

R. Arends, et. al. Resource Records for the DNS Security Extensions.
Internet Engineering Task Force Request for Comments 4034, March
2005. https://datatracker.ietf.org/doc/rfc4034/[RFC4035]

R. Arends, et. al. Protocol Modiﬁcations for the DNS Security
Extensions. Internet Engineering Task Force Request for Comments
4035, March 2005. https://datatracker.ietf.org/doc/rfc4035/[RFC5782]

J. Levine. DNS Blacklists and Whitelists. Internet Engineering Task
Force Request for Comments 5872, February 2010.
https://datatracker.ietf.org/doc/rfc5782/
91

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1[RFC5322]

P. Resnick. Internet Message Format. Internet Engineering Task Force
Request for Comments 5322, October 2008.
https://datatracker.ietf.org/doc/rfc5322/[RFC6186]

C. Daboo. Use of SRV Records for Locating Email Submission/Access
Services. Internet Engineering Task Force Request for Comments 6186,
March 2011. https://datatracker.ietf.org/doc/rfc6186/[THREAT1]

R. Oppliger. Secure Messaging on the Internet. Artech House, 2014.

[THREAT2]

C. Pﬂeeger and S. L. Pﬂeeger. Analyzing Computer Security: A
Threat/Vulnerability/Countermeasure Approach. Prentice Hall, 2011.

[WHITTEN1999]

Alma Whitten and J. D. Tygar. 1999. Why Johnny can't encrypt: ausability evaluation of PGP 5.0. In Proceedings of the 8th conference on
USENIX Security Symposium - Volume 8 (SSYM'99), Vol. 8. USENIX
Association, Berkeley, CA, USA, 14-14.
https://www.usenix.org/conference/8th-usenix-securitysymposium/why-johnny-cant-encrypt-usability-evaluation-pgp-50

92

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILAppendix C—Overlay of NIST SP 800-53 Controls to Email Messaging Systems
C.1

Introduction

The following is an overlay of the NIST SP 800-53 Rev. 4 controls and gives detail on how
email systems can comply with the applicable controls. This overlay partially follows the process
documented in SP 800-53r4 Appendix I [SP800-53]. Here, “email system” is taken to mean any
system (as defined by FIPS 199), that is said to generate, send, or store email messages for an
enterprise. This section attempts to identify individual controls (or control families) that are
relevant to email systems, and to select specific guidance that should be used to comply witheach control.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

This section does not introduce new controls that do not exist in SP 800-53 and does not declare
any control unnecessary for a given system and control baseline. This section only lists controlsthat directly relate to deploying and operating a trustworthy email service. Further guidance isgiven for each control to assist administrators in meeting compliance requirements.
C.2

Applicability

The purpose of this overlay is to provide guidance for securing the various email systems usedwithin an enterprise. This overlay has been prepared for use by federal agencies. It may be usedby nongovernmental organizations on a voluntary basis.
C.3

Trustworthy Email Overlay

The overlay breaks down NIST SP 800-53 Rev. 4 controls according to specific email security
protocols: Domain-based authentication (i.e., SPF, DKIM, DMARC, etc.), SMTP over TLS andend-to-end email security (i.e., S/MIME or OpenPGP). To avoid confusion as to which control
applies to which technology, these controls are only listed once, with a justification included toprovide more email-specific guidance as to why and how the control should apply to an email
system.
Just because a control is not explicitly listed below does not mean that the control (or control
family) is not applicable to an email system. Controls (or control families) that apply to all
systems for a given baseline would still apply. For example, the IA-7 CRYPTOGRAPHIC
MODULE AUTHENTICATION control could be said to apply to all systems that perform
some cryptographic function for a given baseline, but administrators should already be aware ofthis general control, and no additional special consideration is needed just for email systems. The
controls below should be seen as additional controls that should be applied for a give control
baseline. A general control family may be listed below to alert administrators that there could be
implications of the control family that impact email operations, so administrators should consider
how the email service should address the family as applicable.
The trustworthy email service-relevant controls are listed below. The control body and relevant
accompanying information is included to assist the reader, but the entire control is not included.
Readers are encouraged to consult NIST SP 800-53 Rev. 4 for the full text and all accompanying
material. In addition, a justification is included for each control (or control family) to state why
93

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

the control is included, how it applies to email, and to provide guidance from NIST SP 800-177(or another document) to comply with the control.

C.4

Control Baselines

The table below is taken from NIST SP 800-53 Rev. 4 Appendix D. It lists the control baselines
for the three risk levels: Low, Moderate and High. To this is added the new control
recommendations and extensions for the email system overlay. Additional requirements andcontrol extensions are listed in bold. Justification of the additions are listed below the table.
Table C-1: Overlay Control Baselines
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

CONTROL BASELINESLOWCONTROL

MODERATE

HIGH

Control Name

NumberAccess Control (AC)AC-1

ACCESS CONTROL POLICY AND
PROCEDURES

AC-1

AC-1

AC-1

AC-2

ACCOUNT MANAGEMENT

AC-2

AC-2 (1,2,3,4)

AC-2(1,2,3,4,
5,11,12,13)

AC-3

ACCESS ENFORCEMENT

AC-3

AC-3

AC-3

AC-4

INFORMATION FLOW
ENFORCEMENT

-

AC-4

AC-4

AC-5

SEPARATION OF DUTIES

-

AC-5

AC-5

AC-6

LEAST PRIVILEGE

AC-6 (1,2,5,9,10)

AC-6(1,2,3,5,9, 10)

AC-7

UNSUCCESSFUL LOGON ATTEMPTS

AC-7

AC-7

AC-7

AC-8

SYSTEM USE NOTIFICATION

AC-8

AC-8

AC-8

AC-9

PREVIOUS LOGON (ACCESS)NOTIFICATION

-

-

-

94

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

AC-10

CONCURRENT SESSION CONTROL

-

-

AC-10

AC-11

DEVICE LOCK-

AC-11(1)AC-11(1)AC-12

SESSION TERMINATION

-

AC-12

AC-12

AC-14

PERMITTED ACTIONS WITHOUTIDENTIFICATION OR
AUTHENTICATION

AC-14

AC-14

AC-14

AC-16

SECURITY AND PRIVACYATTRIBUTES

-

-

-

AC-17

REMOTE ACCESS

AC-17

AC-17(1,2,3,4)

AC17(1,2,3,4)

AC-18

WIRELESS ACCESS

AC-18

AC-18 (1)AC-18 (1,4,5)

AC-19

ACCESS CONTROL FOR MOBILE
DEVICES

AC-19

AC-19 (5)AC-19 (5)AC-20

USE OF EXTERNAL SYSTEMS

AC-20

AC-20 (1,2)

AC-20 (1,2)

AC-21

INFORMATION SHARING

AC-21

AC-21

AC-21

AC-22

PUBLICALY ACCESSIBLE CONTENT

AC-22

AC-22

AC-22

AC-23

DATA MINING PROTECTION

-

-

-

AC-24

ACCESS CONTROL DECISIONS

-

-

-

AC-25

REFERENCE MONITOR

-

-

-

Awareness and Training (AT)
AT-1

AWARENESS AND TRAINING
POLICY AND PROCEDURES

AT-1

AT-1

AT-1

AT-2

AWARENESS TRAINING

AT-2(1)

AT-2 (1,2)

AT-2 (1,2)

AT-3

ROLE-BASED TRAINING

AT-3

AT-3

AT-3

95

NIST SP 800-177 REV. 1

AT-4

TRUSTWORTHY EMAILTRAINING RECORDS

AT-4

AT-4

AT-4

Audit and Accountability (AU)This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

AU-1

AUDIT AND ACCOUNTABILITY
POLICY AND PROCEDURES

AU-1

AU-1

AU-1

AU-2

AUDIT EVENTS

AU-2

AU-2 (3)AU-2 (3)AU-3

COUNTENT OF AUDIT RECORDS

AU-3

AU-3 (1)AU-3 (1,2)

AU-4

AUDIT STORAGE CAPACITY

AU-4

AU-4

AU-4

AU-5

RESPONSE TO AUDIT PROCESSING
FAILURES

AU-5

AU-5

AU-5 (1,2)

AU-6

AUDIT REVIEW, ANALYSIS ANDREPORTING

AU-6

AU-6 (1,3)

AU-6(1,3,5,6)

AU-7

AUDIT REDUCTION AND REPORTGENERATION-

AU-7 (1)AU-7 (1)

AU-8

TIME STAMPS

AU-8

AU-8 (1)AU-8 (1)

AU-9

PROTECTION OF AUDITINFORMATION

AU-9

AU-9 (4)AU-9 (2,3,4)

AU-10

NON-REPUDIATION--

AU-10 (1)

AU-11

AUDIT RECORD RETENTION

AU-11

AU-11

AU-11

AU-12

AUDIT GENERATION

AU-12

AU-12

AU-12 (1,3)

AU-13

MONITORING FOR INFORMATIONDISCLOSURE

-

-

-

AU-14

SESSION AUDIT

-

-

-

AU-15

ALTERNATIVE AUDIT CAPABILITY

-

-

-

AU-16

CROSS-ORGNAZION AUDITING

-

-

-

96

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILASSESSMENT, AUTHORIZATION AND MONITORING (CA)This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

CA-1

ASSESSMENT, AUTHORIZATION
AND MONITORING POLICY AND
PROCEDURES

CA-1

CA-1

CA-1

CA-2

ASSESSMENTS

CA-2

CA-2 (1)CA-2 (1,2)

CA-3

SYSTEM INTERCONNECTIONS

CA-3

CA-3 (5)CA-3 (5)CA-5PLAN OF ACTION AND MILESTONES

CA-5

CA-5

CA-5

CA-6

AUTHORIZATION

CA-6

CA-6

CA-6

CA-7

CONTINUOUS MONITORING

CA-7

CA-7 (1)CA-7 (1)

CA-8

PENETRATION TESTING

-

-

CA-8

CA-9

INTERNAL SYSTEM CONNECTIONS

CA-9

CA-9

CA-9

CONFIGURATION MANAGEMENT (CM)CM-1

CONFIGURATION MANAGEMENTPOLICY AND PROCEDURES

CM-1

CM-1

CM-1

CM-2

BASELINE CONFIGURATION

CM-2

CM-2 (1,3,7)

CM-2(1,2,3,7)

CM-3

CONFIGURATION CHANGECONTROL-

CM-3 (2)CM-3 (1,2)

CM-4

SECURITY AND PRIVACY IMPACTANALYSIS

CM-4

CM-4

CM-4 (1)

CM-5

ACCESS RESTRICTIONS FORCHANGE-

CM-5

CM-5 (1,2,3)

CM-6

CONFIGURATION SETTINGS

CM-6

CM-6

CM-6 (1,2)

CM-7

LEAST FUNCTIONALITY

CM-7

CM-7 (1,2,4)

CM-7 (1,2,5)

CM-8

SYSTEM COMPONENT INVENTORY

CM-8

CM-8 (1,3,5)

CM-8(1,2,3,4,5)

97

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

CM-9

CONFIGURATION MANAGEMENT
PLAN

-

CM-9

CM-9

CM-10

SOFTWARE USAGE RESTRICTIONS

CM-10

CM-10

CM-10

CM-11

USER-INSTALLED SOFTWARE

CM-11

CM-11

CM-11

CONTINGENCY PLANNING

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

CP-1

CONTINGENCY PLANNING POLICYAND PROCEDURES

CP-1

CP-1

CP-1

CP-2

CONTINGENCY PLAN

CP-2

CP-2 (1,3,8)

CP-2(1,2,3,4,5,8)

CP-3

CONTINGENCY TRAINING

CP-3

CP-3

CP-3 (1)CP-4

CONTIGENCY PLAN TESTING

CP-4

CP-4(1)CP-4 (1,2)

CP-6

ALTERNATE STORAGE SITE-

CP-6 (1,3)

CP-6 (1,2,3)

CP-7

ALTERNATE PROCESSING SITE-

CP-7 (1,2,3)

CP-7(1,2,3,4)

CP-8

TELECOMMUNICATION SERVICES-

CP-8 (1,2)

CP-8(1,2,3,4)

CP-9

SYSTEM BACKUP

CP-9

CP-9 (1)CP-9(1,2,3,5)

CP-10

SYSTEM RECOVERY AND
RECONSTITUION

CP-10

CP-10 (2)CP-10 (2,4)

CP-11

ALTERNATE COMMUNICATIONPROTOCOLS

-

-

-

CP-12

SAFE MODE

-

-

-

CP-13

ALTERNATIVE SECURITY
MECHANISMS

-

-

-

IDENTIFICATION AND AUTHENTICATION (IA)98

NIST SP 800-177 REV. 1

IA-1

IDENTIFICATION AND
AUTHENTICATION POLICY AND
PROCEDURES

IA-2

TRUSTWORTHY EMAILThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

IA-1

IA-1

IA-1

IDENTIFICATION AND
AUTHENTICATION(ORGANIZATIONAL USERS)

IA-2(1,12)

IA-2(1,2,3,8,11,12)

IA-2(1,2,3,4,8,9,
11,12)IA-3

DEVICE IDENTIFICATION AND
AUTHENTICATION

-

IA-3

IA-3

IA-4

IDENTIFIER MANAGEMENT

IA-4

IA-4

IA-4

IA-5

AUTHENTICATOR MANAGEMENT

IA-5 (1,11)

IA-5 (1,2,3,11)

IA-5(1,2,3,11)

IA-6

AUTHENTICATOR FEEDBACK

IA-6

IA-6

IA-6

IA-7

CRYPTOGRAPHIC MODUELAUTHENTICATION

IA-7

IA-7

IA-7

IA-8

IDENTIFICATION AND
AUTHENTICATION (NONORGANIZATIONAL USERS)

IA-8(1,2,3,4)

IA-8 (1,2,3,4)

IA-8 (1,2,3,4)

IA-9

SERVICE IDENTIFICATION AND
AUTHENTICATION-

IA-9 (1)IA-9 (1,2)

IA-10

ADAPTIVE IDENTIFCATION AND
AUTHENTICATION

-

-

-

IA-11

RE-AUTHENTICATION

-

-

-

INCIDENT RESPONSE (IR)IR-1

INCIDENT RESOPNSE POLICY AND
PROCEDURES

IR-1

IR-1

IR-1

IR-2

INCIDENT RESPONSE TRAINING

IR-2

IR-2

IR-2 (1,2)

IR-3

INCIDENT RESPONSE TESTING-

IR-3 (2)IR-3 (2)IR-4

INCIDENT HANDLING

IR-4

IR-4 (1)IR-4 (1,4)

99

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

IR-5

INCIDENT MONITORING

IR-5

IR-5

IR-5 (1)IR-6

INCIDENT REPORTING

IR-6

IR-6 (1)IR-6 (1)IR-7

INCIDENT RESPONSE ASSISTANCE

IR-7

IR-7 (1)IR-7 (1)IR-8

INCIDENT RESOPNSE PLAN

IR-8

IR-8

IR-8

IR-9

INFORMATION SPILLAGE RESOPNSE

-

-

-

IR-10

INTEGRATED INFORMATIONSECURITY ANALYSIS TEAM

-

-

-

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

MAINTENANCE (MA)
MA-1

SYSTEM MAINTENANCE POLICYAND PROCEDURES

MA-1

MA-1

MA-1

MA-2

CONTROLLED MAINTENANCE

MA-2

MA-2

MA-2 (2)MA-3MAINTENANCE TOOLS-

MA-3 (1,2)

MA-3 (1,2,3)

MA-4

NONLOCAL MAINTENANCE

MA-4

MA-4 (2)MA-4 (2.3)

MA-5

MAINTENANCE PERSONNEL

MA-5

MA-5

MA-5 (1)

MA-6

TIMELY MAINTENANCE

-

MA-6

MA-6

MEDIA PROTECTION (MP)MP-1

MEDIA PROTECTION POLICY AND
PROCEDURES

MP-1

MP-1

MP-1

MP-2

MEDIA ACCESS

MP-2

MP-2

MP-2

MP-3

MEDIA MARKING

-

MP-3

MP-3

MP-4

MEDIA STORAGE

-

MP-4

MP-4

MP-5

MEDIA TRANSPORT-

MP-5 (4)MP-5 (4)100

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

MP-6

MEDIA SANITIZATION

MP-6

MP-6

MP-6 (1,2,3)

MP-7

MEDIA USE

MP-7

MP-7 (1)MP-7 (1)MP-8

MEDIA DOWNGRADING

-

-

-

PHYSICAL AND ENVIRONMENTAL PROTECTION (PE)This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

PE-1

PHYSICAL AND ENVIRONMENTAL
PROTECTION POLICY AND
PROCEDURES

PE-1

PE-1

PE-1

PE-2

PHYSICAL ACCESSAUTHORIZATIONS

PE-2

PE-2

PE-2

PE-3

PHYSICAL ACCESS CONTROL

PE-3

PE-3

PE-3 (1)PE-4

ACCESS CONTROL FOR
TRANSMISSION

-

PE-4

PE-4

PE-5

ACCESS CONTROL FOR OUTPUT
DEVICES

-

PE-5

PE-5

PE-6

MONITORING PHYSICAL ACCESS

PE-6

PE-6 (1)PE-6 (1,4)

PE-8

VISITOR ACCESS RECORDS

PE-8

PE-8

PE-8 (1)PE-9

POWER EQUIPMENT AND CABLING

-

PE-9

PE-9

PE-10

EMERGENCY SHUTOFF

-

PE-10

PE-10

PE-11

EMERGENCY POWER

-

PE-11

PE-11 (1)PE-12

EMERGENCY LIGHTING

PE-12

PE-12

PE-12

PE-13

FIRE PROTECTION

PE-13

PE-13 (3)PE-13 (1,2,3)

PE-14

TEMPERATURE AND HUMIDITYCONTROLS

PE-14

PE-14

PE-14

PE-15

WATER DAMAGE PROTECTION

PE-15

PE-15

PE-15 (1)101

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

PE-16

DELIVERY AND REMOVAL

PE-16

PE-16

PE-16

PE-17

ALTERNATE WORK SITE

-

PE-17

PE-17

PE-18

LOCATION OF SYSTEMCOMPONENTS

-

-

PE-18

PE-19

INFORMATION LEAKAGE

-

-

-

PE-20

ASSET MONITORING AND
TRACKING---

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

PLANNING (PL)PL-1

PLANNING POLICY AND
PROCEDURES

PL-1

PL-1

PL-1

PL-2

SYSTEM SECURITY AND PRIVACY
PLANS

PE-2

PL-2 (3)PL-2 (3)

PL-4

RULES OF BEHAVIOR

PL-4

PL-4 (1)PL-4 (1)

PL-7

CONCEPT OF OPERATIONS

-

-

-

PL-8

SECURITY AND PRIVACYARCHITECTURES

-

PL-8

PL-8

PL-9

CENTRAL MANAGEMENT

-

-

-

PERSONNEL SECURITY (PS)PS-1

PERSONAL SECUIRTY POLICY AND
PROCEDURES

PS-1

PS-1

PS-1

PS-2

POSITION RISK DESIGNATION

PS-2

PS-2

PS-2

PS-3

PERSONNEL SCREENING

PS-3

PS-3

PS-3

PS-4

PERSONNEL TERMINTATION

PS-4

PS-4

PS-4 (2)PS-5

PERSONNEL TRANSFER

PS-5

PS-5

PS-5

102

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

PS-6ACCESS AGREEMENTS

PS-6

PS-6

PS-6

PS-7

EXTERNAL PERSONNEL SECURITY

PS-7

PS-7

PS-7

PS-8

PERSONNEL SANCTIONS

PS-8

PS-8

PS-8

RISK ASSESSMENT (RA)This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

RA-1

RISK ASSESSMENT POLICY AND
PROCEDURES

RA-1

RA-1

RA-1

RA-2

SECUIRTY CATEGORIZATION

RA-2

RA-2

RA-2

RA-3

RISK ASSESSMENT

RA-3

RA-3

RA-3

RA-5

VULNERABILITY SCANNING

RA-5

RA-5 (1,2,5)

RA-5(1,2,4,5)

RA-6

TECHNICAL SURVEILLANCECOUNTERMEASURES SURVEY

-

-

-

SYSTEM AND SERVICE ACQUISITION (SA)SA-1

SYSTEM AND SERVICESACQUISITION POLICY AND
PROCEDURES

SA-1

SA-1

SA-1

SA-2

ALLOCATION OF RESOURCES

SA-2

SA-2

SA-2

SA-3

SYSTEM DEVELOPMENT LIFE
CYCLE

SA-3

SA-3

SA-3

SA-4

ACQUISITION PROCESS

SA-4 (10)

SA-4 (1,2,9,10)

SA-4 (1,2,9,
10)

SA-5

SYSTEM DOCUMENTATION

SA-5

SA-5

SA-5

SA-8

SECURITY AND PRIVACYENGINEERING PRINCIPLES

-

SA-8

SA-8

SA-9

EXTERNAL SYSTEM SERVICES

SA-9

SA-9 (2)

SA-9 (2)103

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

SA-10

DEVELOPER CONFIGURATIONMANAGEMENT

-

SA-10

SA-10

SA-11

DEVELOPER SECURITY TESTING
AND EVALUATION

-

SA-11

SA-11

SA-12

SUPPLY CHAIN RISK MANAGEMENT

-

-

SA-12

SA-13

TRUSTWORTHINESS

-

-

-

SA-14

CRITICALITY ANALYSIS

-

-

-

SA-15

DEVELOPMENT PROCESS,
STANDARDS, AND TOOLS

-

-

SA-15

SA-16

DEVELOPER-PROVIDED TRAINING

-

-

SA-16

SA-17

DEVELOPER SECURITY
ARCHITECTURE AND DESIGN

-

-

SA-17

SA-18

TAMPER RESISTANCE AND
DETECTION

-

-

-

SA-19

COMPONENT AUTHENTICITY

-

-

-

SA-20

CUSTOMIZED DEVELOPMENT OFCRITICAL COMPONENTS

-

-

-

SA-21

DEVELOPER SCREENING

-

-

-

SA-22

UNSUPPORTED SYSTEMCOMPONENTS

-

-

-

SYSTEM AND COMMUNICATIONS PROTECTION (SC)SC-1

SYSTEM AND COMMUNICATIONSPROTECTION POLICY AND
PROCEDURES

SC-2
SC-3

SC-1

SC-1

SC-1

APPLICATION PARTITIONING

-

SC-2

SC-2

SECURITY FUNCTION ISOLATION

-

-

SC-3

104

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

SC-4

INFORMATION IN SHARED SYSTEMRESOURCES

-

SC-4

SC-4

SC-5

DENIAL OF SERVICE PROTECTION

SC-5

SC-5

SC-5

SC-6

RESOURCE AVAILABLITY

-

-

-

SC-7

BOUNDRY PROTECTION

SC-7

SC-7 (2,3,4,7,8,
10)

SC-7
(3,4,5,7,8,
10,1118,21)

SC-8

TRANSMISSION CONFIDENTIALITY
AND INTEGRITY-

SC-8 (1)SC-8 (1)SC-10

NETWORK DISCONNECT

-

SC-10

SC-10

SC-11

TRUSTED PATH

-

-

-

SC-12

CRYPTOGRAPHIC KEYESTABLISHMENT AND
MANAGEMENT

SC-12

SC-12

SC-12 (1)SC-13

CRYPTOGRAPHIC PROTECTION

SC-13

SC-13

SC-13

SC-15

COLLABORATIVE COMPUTINGDEVICES AND APPLICATIONS

SC-15

SC-15

SC-15

SC-16

TRANSMISSION OF SECURITY ANDPRIVACY ATTRIBUTES

-

-

-

SC-17

PUBLIC KEY INFRASTUCTURE
CERTIFICATES

-

SC-17

SC-17

SC-18

MOBILE CODE

-

SC-18

SC-18

SC-19

VOICE OVER INTERNET PROTOCOL

-

SC-19

SC-19

SC-20

SECURE NAME/ADDRESSRESOLUTION SERVICE(AUTHORITATIVE SOURCE)

SC-20

SC-20

SC-20

SC-21

SECURE NAME/ADDRESSRESOLUTION SERVICE (RESURSIVE
OR CACHING RESOLVER)

SC-21

SC-21

SC-21

105

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

SC-22

ARCHITECTURE ANDPROVISIONING FOR NAME/ADDRESSRESOLUTION SERVICE

SC-23This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

SC-22

SC-22

SC-22

SESSION AUTHENTICITY

-

SC-23

SC-23 (5)SC-24

FAIL IN KNOWN STATE

-

-

SC-24

SC-25

THIN NODES

-

-

-

SC-26

HONEYPOTS

-

-

-

SC-27

PLATFORM-INDEPENDENTAPPLICATIONS

-

-

-

SC-28

PROTECTION OF INFORMATION AT
REST

-

SC-28

SC-28

SC-29

HETEROGENEITY

-

-

-

SC-30

CONCEALMENT AND
MISDIRECTION

-

-

-

SC-31

CONVERT CHANNEL ANALYSIS

-

-

-

SC-32

SYSTEM PARTITIONING

-

-

-

SC-34

NON-MODIFIABLE EXECUTABLE
PROGRAMS

-

-

-

SC-35

HONEYCLIENTS

-

-

-

SC-36

DISTRIBUTED PROCESSING AND
STORAGE

-

-

-

SC-37

OUT-OF-BAND CHANNELS

-

-

-

SC-38

OPERATIONS SECURITY

-

-

-

SC-39

PROCESS ISOLATION

SC-39

SC-39

SC-39

SC-40

WIRELESS LINK PROTECTION

-

-

-

106

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

SC-41

PORT AND I/O DEVICE ACCESS

-

-

-

SC-42

SENSOR CAPABILITY AND DATA

-

-

-

SC-43

USAGE RESTRICTIONS

-

-

-

SC-44

DETONATION CHAMBERS

SC-44

SC-44

SC-44

SYSTEM AND INFORMATION INTEGRITY (SI)This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

SI-1

SYSTEM AND INFORMAITONINTEGIRTY POLICY AND
PROCEDURES

SI-1

SI-1

SI-1

SI-2

FLAW REMEDIATION

SI-2

SI-2 (2)SI-2 (1,2)

SI-3

MALICIOUS CODE PROTECTION

SI-3

SI-3 (1,2)

SI-3 (1,2)

SI-4

SYSTEM MONITORING

SI-4

SI-4 (2,4,5)

SI-4 (2,4,5)

SI-5

SECURITY ALERTS, ADVISORIES,AND DIRECTIVES

SI-5

SI-5

SI-5 (1)SI-6

SECURITY AND PRIVACYFUNCTIONS VERIFICATION

-

-

SI-6

SI-7

SOFTWARE, FIRMWARE, AND
INFORMATION INTEGRITY-

SI-7 (1,7)

SI-7(1,2,5,7,14)

SI-8

SPAM PROTECTION-

SI-8 (1,2)

SI-8 (1,2)

SI-10

INFORMATION INPUT VALIDATION

-

SI-10

SI-10

SI-11

ERROR HANDLING

-

SI-11

SI-11

SI-12

INFORMATION MANAGEMENT AND
RETENTION

SI-12

SI-12

SI-12

SI-13

PREDICTABLE FAILURE
PREVENTION

-

-

-

SI-14

NONE-PRESISTENCE

-

-

-

107

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

SI-15

INFORMATION OUTPUT FILTERING

-

-

-

SI-16

MEMORY PROTECTION

-

SI-16

SI-16

SI-17

FAIL-SAFE PROCEDURES

-

-

-

SI-20

DE-IDENTIFICATION

-

-

-

C.5

Additional/Expanded Controls

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

AC-21 INFORMATION SHARING
Control:a. Facilitate information sharing by enabling authorized users to determine whether accessauthorizations assigned to the sharing partner match the access restrictions and privacy
authorizations on the information for [Assignment: organization-defined information
sharing circumstances where user discretion is required]; andb. Employ [Assignment: organization-defined automated mechanisms or manual processes]
to assist users in making information sharing and collaboration decisions.
Justification: If an enterprise has deployed DMARC and is collecting forensic reports (seeSection 4.6.5), administrators should make sure that any private data that may be contained in thereport is redacted and not divulged to unauthorized parties.

AT-2 AWARENESS TRAINING
Control: Provide basic security and privacy awareness training to system users (including
managers, senior executives, and contractors):a. As part of initial training for new users;b. When required by system changes; andc. [Assignment: organization-defined frequency] thereafter.
Control Enhancements:(1) AWARENESS TRAINING | PRACTICAL EXERCISES108

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILThe organization includes practical exercises in security awareness training thatsimulate actual cyber attacks.
Supplemental Guidance: Practical exercises may include, for example, no-notice social
engineering attempts to collect information, gain unauthorized access, or simulate theadverse impact of opening malicious email attachments or invoking, via spear phishingattacks, malicious web links.
Justification: Administrators should have training on how to use DMARC reporting to identify
and react to email borne attacks. See Section 4.6. All users of an email system should havetraining on how to identify and act to stop phishing attempts, opening malicious attachments andsocial engineering attacks using email. This could include looking for and noting the presence ofdigital signatures (S/MIME or OpenPGP), (see Section 5.3).
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

AU-10 NON-REPUDIATION
Control: The information system protects against an individual (or process acting on behalf of anindividual) falsely denying having performed [Assignment: organization-defined actions to becovered by non-repudiation].
Control Enhancements:(1) NON-REPUDIATION | ASSOCIATION OF IDENTIESThe information system:(a) Binds the identity of the information producer with the information to[Assignment: organization-defined strength of binding]; and(b) Provides the means for authorized individuals to determine the identity ofthe producer of the information.
Supplemental Guidance: This control enhancement supports audit requirements thatprovide organizational personnel with the means to identify who produced specificinformation in the event of an information transfer. Organizations determine and approve
the strength of the binding between the information producer and the information basedon the security category of the information and relevant risk factors(2) NON-REPUDIATION | VALIDATE BINDING OF INFORMATION PRODUCER
IDENTITY
The information system:(a) Validates the binding of the information producer identity to theinformation at [Assignment: organization-defined frequency]; and(b) Performs [Assignment: organization-defined actions] in the event of avalidation error.
109

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

Supplemental Guidance: This control enhancement prevents the modification of
information between production and review. The validation of bindings can be achieved,for example, by the use of cryptographic checksums. Organizations determine if
validations are in response to user requests or generated automatically.
(3) NON-REPUDIATION | CHAIN OF CUSTODY
The information system maintains reviewer/releaser identity and credentials within
the established chain of custody for all information reviewed or released.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Supplemental Guidance: Chain of custody is a process that tracks the movement ofevidence through its collection, safeguarding, and analysis life cycle by documenting
each person who handled the evidence, the date and time it was collected or transferred,
and the purpose for the transfer. If the reviewer is a human or if the review function is
automated but separate from the release/transfer function, the information systemassociates the identity of the reviewer of the information to be released with theinformation and the information label. In the case of human reviews, this control
enhancement provides organizational officials the means to identify who reviewed andreleased the information. In the case of automated reviews, this control enhancement
ensures that only approved review functions are employed.
(4) NON-REPUDIATION | VALIDATE BINDING OF INFORMATION REVIEWERIDENTITY
The information system:(a) Validates the binding of the information reviewer identity to theinformation at the transfer or release points prior to release/transfer
between [Assignment: organization-defined security domains]; and(b) Performs [Assignment: organization-defined actions] in the event of avalidation error.
Supplemental Guidance: This control enhancement prevents the modification of
information between review and transfer/release. The validation of bindings can beachieved, for example, by the use of cryptographic checksums. Organizations determine
validations are in response to user requests or generated automatically.
(5) (WITHDRAWN)
Supplemental Guidance:
Types of individual actions covered by non-repudiation include, for example, creating
information, sending and receiving messages, approving information (e.g., indicatingconcurrence or signing a contract). Non-repudiation protects individuals against later claims by:(i) authors of not having authored particular documents; (ii) senders of not having transmitted
messages; (iii) receivers of not having received messages; or (iv) signatories of not having signed
110

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

documents. Non-repudiation services can be used to determine if information originated from aparticular individual, or if an individual took specific actions (e.g., sending an email, signing acontract, approving a procurement request) or received specific information. Organizations
obtain non-repudiation services by employing various techniques or mechanisms (e.g., digital
signatures, digital message receipts).
Justification: Organizations using email for information transfer should use S/MIME or
OpenPGP to provide authentication of the original sender (via a digital signature). In addition,
the organization should provide an alternate means to publish sender digital signature certificatesso that receivers can validate email digital signatures. See Section 5.3.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

IA-9 SERVICE IDENTIFICATION AND AUTHENTICATION
Control: The organization identifies and authenticates [Assignment: organization-defined
information system services] using [Assignment: organization-defined security safeguards].
Control Enhancements:(1) SERVICE IDENTIFICATION AND AUTHENTICATION | INFORMATIONEXCHANGE

The organization ensures that service providers receive, validate, and transmit
identification and authentication information.
Justification: An organization should have certificates to authenticate MTAs that receive mailfrom external sources (i.e., the Internet) and for MTAs that host users’ inboxes that are accessed
via POP3, IMAP or Microsoft Exchange. See Section 2.3.
Control Extension:(2) The organization should provide additional methods to validate a given MTA’scertificate. Examples of this include DANE TLSA RRs (see Section 5.2.4) or SMTP
Strict Transport Security (Section 5.2.5).

IP-X INDIVIDUAL PARTICIPATION (potential of entire family)
Justification: Organizations that use incoming and/or outgoing email content scanning shouldhave a policy and set of procedures in place to make users aware of the organization’s email
policy. This scanning could be done for a variety of reasons (see Section 6.3.3). This includes
consent, privacy notice and the remediation taken when the violations of the policy are detected.

111

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

IR-X INCIDENT RESPONSE (potential of entire family)
Justification: Organizations deploying DMARC (see Section 4.6) may need to generate a newplan to handle DMARC forensic reports that indicate their domain is being spoofed as part of aphishing campaign against a third party. This is not necessarily an attack against theorganization, but an attack using the organization’s reputation to subvert one or more victims.
DMARC forensic reports can be used to identify these attacks that may have been unknown tothe organization previously.

PS-4 PERSONNEL TERMINATIONThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Control: The organization, upon termination of individual employment:
a. Disables information system access within [Assignment: organization-defined timeperiod];b. Terminates/revokes any authenticators/credentials associated with the individual;c. Conducts exit interviews that includes discussion of [Assignment: organization-defined
information security topics];
d. Retrieves all security-related organizational information system-related property;
e. Retains access to organizational information and information systems formerly controlled
by terminated individual; andf. Notifies [Assignment: organization-defined personnel or roles] within [Assignment:
organization-defined time-period].
Justification: This control is selected so that when an email administrator leaves a position, allcredentials that the administrator had access to are revoked. This includes key pairs used to with
SMTP over TLS (see Section 5.2), DKIM (see Section 4.5) and/or S/MIME key pairs.
In addition, when an organization terminates a third-party email service, administrators should
revoke any credentials that the third party may have had for the organizations. Examples of thisinclude DKIM keys used by third party senders stored in the organization’s DNS (see Section
4.5.11) and SPF entries used to authenticate third-party senders (see Section 4.4.4).

SC-7 BOUNDARY PROTECTION
Control: The information system:
112

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAILa) Monitors and controls communications at the external boundary of the system and at key
internal boundaries within the system;b) Implements subnetworks for publicly accessible system components that are [Selection:
physically; logically] separated from internal organizational networks; andc) Connects to external networks or systems only through managed interfaces consisting ofboundary protection devices arranged in accordance with an organizational security andprivacy architecture.
Control Extensions:(10) BOUNDARY PROTECTION | PREVENT UNAUTHORIZED EXFILTRATIONThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

The organization prevents the unauthorized exfiltration of information acrossmanaged interfaces.
Supplemental Guidance: Safeguards implemented by organizations to prevent
unauthorized exfiltration of information from information systems include, for example:(i) strict adherence to protocol formats; (ii) monitoring for beaconing from information
systems; (iii) monitoring for steganography; (iv) disconnecting external network
interfaces except when explicitly needed; (v) disassembling and reassembling packet
headers; and (vi) employing traffic profile analysis to detect deviations from thevolume/types of traffic expected within organizations or call backs to command andcontrol centers. Devices enforcing strict adherence to protocol formats include, forexample, deep packet inspection firewalls and XML gateways. These devices verify
adherence to protocol formats and specification at the application layer and serve to
identify vulnerabilities that cannot be detected by devices operating at the network ortransport layers. This control enhancement is closely associated with cross-domain
solutions and system guards enforcing information flow requirements.
(11) BOUNDARY PROTECTION | RESTRICT INCOMING COMMUNICATIONS
TRAFFICThe information system only allows incoming communications from [Assignment:
organization-defined authorized sources] to be routed to [Assignment: organizationdefined authorized destinations].
Supplemental Guidance: This control enhancement provides determinations that sourceand destination address pairs represent authorized/allowed communications. Suchdeterminations can be based on several factors including, for example, the presence ofsuch address pairs in the lists of authorized/allowed communications; the absence of suchaddress pairs in lists of unauthorized/disallowed pairs; or meeting more general rules for
authorized/allowed source and destination pairs.
Justification: Email systems should have incoming mail filters to detect, quarantine or reject
mail from known bad senders (e.g., known Spam or malicious senders). Email systems should
113

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

also implement outgoing mail filters to prevent sensitive data exfiltration and detect internal
hosts that may be compromised to send Spam using the organization’s reputation to spoof
victims.

SC-8 TRANSMISSION CONFIDENTIALITY AND INTEGRITY
Control: The information system protects the [Selection (one or more): confidentiality; integrity]of transmitted information.
Control Enhancements:
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1(1) TRANSMISSION CONFIDENTIALITY AND INTEGRITY | CRYPTOGRAPHIC OR

ALTERNATE PHYSICAL PROTECTION

The information system implements cryptographic mechanisms to [Selection (one ormore): prevent unauthorized disclosure of information; detect changes to information]
during transmission unless otherwise protected by [Assignment: organization-definedalternative physical safeguards].
Supplemental Guidance: Encrypting information for transmission protects informationfrom unauthorized disclosure and modification. Cryptographic mechanisms implemented
to protect information integrity include, for example, cryptographic hash functions whichhave common application in digital signatures, checksums, and message authentication
codes. Alternative physical security safeguards include, for example, protected distribution
systems.
Justification: Email systems should deploy security protocols to protect the integrity of email
messages and the confidentially of messages in transit. For integrity protection, email systems
should use DKIM (see Section 4.5) and/or S/MIME digital signatures (see Section 5.3) whensending messages. For confidentiality, email systems should use SMTP over TLS (see Section
5.2).

SC-23 SESSION AUTHENTICITY
Control: The information system protects the authenticity of communications sessions.
Supplemental Guidance: This control addresses communications protection at the session, versus
packet level (e.g., sessions in service-oriented architectures providing web-based services) andestablishes grounds for confidence at both ends of communications sessions in ongoing identitiesof other parties and in the validity of information transmitted. Authenticity protection includes,for example, protecting against man-in-the-middle attacks/session hijacking and the insertion of114

NIST SP 800-177 REV. 1

TRUSTWORTHY EMAIL

false information into sessions.
Control Enhancements:(5) SESSION AUTHENTICITY | ALLOWED CERTIFICATE AUTHORITIESThe information system only allows the use of [Assignment: organization-definedcertificate authorities] for verification of the establishment of protected sessions.
Supplemental Guidance: Reliance on certificate authorities (CAs) for the establishment of
secure sessions includes, for example, the use of Secure Socket Layer (SSL) and/or Transport
Layer Security (TLS) certificates. These certificates, after verification by their respective CAs,
facilitate the establishment of protected sessions between web clients and web servers.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-177r1

Justification: Prior to establishing a TLS connection for SMTP transmission of email, a sending
MTA should authenticate the certificate provided by the receiving MTA. This authentication
could be PKIX, or an alternative method (e.g., DANE, SMTP-STS, etc.). See Section 5.2 fordetails.

SC-44 DETONATION CHAMBERS
Control: The organization employs a detonation chamber capability within [Assignment:
organization-defined system, system component, or location].
Supplemental Guidance: Detonation chambers, also known as dynamic execution environments,
allow organizations to open email attachments, execute untrusted or suspicious applications, andexecute Universal Resource Locator (URL) requests in the safety of an isolated environment or avirtualized sandbox. These protected and isolated execution environments provide a means ofdetermining whether the associated attachments or applications contain malicious code. Whilerelated to the concept of deception nets, this control is not intended to maintain a long-term
environment in which adversaries can operate and their actions can be observed. Rather, it isintended to quickly identify malicious code and reduce the likelihood that the code is propagatedto user environments of operation (or prevent such propagation completely).
Justification: Incoming email and attachments from outside sources should be examined indetonation chambers to protect against malicious code or URLs contained in the email message.
See Section 6.

115