Enhance Email and Web Security
This page contains a web-friendly version of the Department of Homeland Security’s Binding Operational Directive 18-01, “Enhance Email and Web Security”, and provides technical guidance and best practices to assist in its implementation.
For an overview of this directive’s requirements, review the checklist.
Federal agency “cyber hygiene” greatly impacts user security. By implementing specific security standards that have been widely adopted in industry, federal agencies can ensure the integrity and confidentiality of internet-delivered data, minimize spam, and better protect users who might otherwise fall victim to a phishing email that appears to come from a government-owned system.
Based on current network scan data and a clear potential for harm, this directive requires actions related to two topics: email security and web security.
A. Email Security
When enabled by a receiving mail server, STARTTLS signals to a sending mail server that the capability to encrypt an email in transit is present. While it does not force the use of encryption, enabling STARTTLS makes passive man-in-the-middle attacks more difficult.
SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) allow a sending domain to effectively “watermark” their emails, making unauthorized emails (e.g., spam, phishing email) easy to detect. When an email is received that doesn’t pass an agency’s posted SPF/DKIM rules, DMARC (Domain-based Message Authentication, Reporting & Conformance) tells a recipient what the domain owner would like done with the message.
Setting a DMARC policy of “reject” provides the strongest protection against spoofed email, ensuring that unauthenticated messages are rejected at the mail server, even before delivery. Additionally, DMARC reports provide a mechanism for an agency to be made aware of the source of an apparent forgery, information that they wouldn’t normally receive otherwise. Multiple recipients can be defined for the receipt of DMARC reports.
B. Web Security
Hypertext Transfer Protocol (HTTP) connections can be easily monitored, modified, and impersonated; HTTPS remedies each vulnerability. HTTP Strict Transport Security (HSTS) ensures that browsers always use an https:// connection, and removes the ability for users to click through certificate-related warnings.
In 2015, OMB M-15-13 required all existing Federal websites and web services to be accessible through a secure connection (HTTPS-only, with HSTS). In 2017, the .gov registry began automatically preloading new federal .gov domains as HSTS-only in modern browsers.
Federal agencies must make more progress on HTTPS and HSTS deployment, including by removing support for known-weak cryptographic protocols and ciphers. According to DHS’s Cyber Hygiene scanning data, seven of the ten most common vulnerabilities seen across federal agency networks at the issuance of this directive would be addressed through complying with the required actions in this directive related to web security.
II. Required Actions
All agencies are required to:
- Within 30 calendar days after issuance of this directive, develop and provide to DHS an “Agency Plan of Action for BOD 18-01” to:a. Enhance email security by:
i. Within 90 days after issuance of this directive, configuring:
- All internet-facing mail servers to offer STARTTLS, and
- All second-level agency domains to have valid SPF/DMARC records, with at minimum a DMARC policy of “p=none” and at least one address defined as a recipient of aggregate and/or failure reports.
ii. Within 120 days after issuance of this directive, ensuring:
- Secure Sockets Layer (SSL)v2 and SSLv3 are disabled on mail servers, and
- 3DES and RC4 ciphers are disabled on mail servers.
iii. Within 15 days of the establishment of centralized National Cybersecurity & Communications Integration Center (NCCIC) reporting location, adding the NCCIC as a recipient of DMARC aggregate reports.
iv. Within one year after issuance of this directive, setting a DMARC policy of “reject” for all second-level domains and mail-sending hosts.
b. Enhance web security by:
i. Within 120 days after issuance of this directive, ensuring:
- All publicly accessible Federal websites and web services provide service through a secure connection (HTTPS-only, with HSTS),
- SSLv2 and SSLv3 are disabled on web servers, and
- 3DES and RC4 ciphers are disabled on web servers.
- Identifying and providing a list to DHS of agency second-level domains that can be HSTS preloaded, for which HTTPS will be enforced for all subdomains.
- Upon delivery of its Agency Plan of Action for BOD 18-01 within 30 days of this directive per required action 1, begin implementing that plan.
- At 60 calendar days after issuance of this directive, provide a report to DHS on the status of that implementation. Continue to report every 30 calendar days thereafter until implementation of the agency’s BOD 18-01 plan is complete.
III. DHS Actions
- DHS will review each Agency Plan of Action for BOD 18-01 upon receipt, and contact agencies with any concerns.
- DHS will coordinate agency-provided lists of domains for HSTS preloading with DotGov.
- DHS will rely on its National Cybersecurity Assessments & Technical Services team scanning for tracking and verifying progress.
- DHS will notify agencies when the NCCIC establishes a central location for the collection of agency DMARC aggregate reports, described above at II(1)(a)(iii).
- DHS will provide additional guidance through a DHS BOD coordination call and other engagements and products following the issuance of this directive.
IV. Potential Budgetary Implications
DHS understands that compliance with this BOD could result in budgetary implications. Agency Chief Information Officers (CIOs) and procurement officers should coordinate with the agency Chief Financial Officer (CFO), as appropriate.
Introduction to Email Authentication
The Department of Homeland Security seeks to incentivize the thoughtful deployment of email authentication technologies and generally increase the security of messages to and from government agencies. Email that fraudulently uses a Federal domain should be easy to detect.
This section is a recital and elaboration of key points in two recent Federal documents:
- Special Publication 800-177, Trustworthy Email, which the National Institute of Standards and Technology issued in September 2016
- Businesses Can Help Stop Phishing and Protect their Brands Using Email Authentication, issued in March 2017 by the Federal Trade Commission’s Bureau of Consumer Protection based on a study performed by the Office of Technology Research and Investigation
What is email authentication?
“Email authentication” refers to a set of technologies that enable:
- a domain owner to assert control over its domains, making them harder to successfully spoof in email.
- the recipient of an email to have reasonable confidence that a message which purports to be from a given domain is genuine or not.
Email authentication can impede the delivery of phishing emails that attempt to play off an organization’s domain names. This protects:
- the sender’s reputation and keeps likely-harmful emails out of recipient mailboxes.
- the public who might receive authoritative-sounding emails claiming to be from a .gov address.
- internal government users who may rely on information that appears to come, e.g., from an important colleague.
There are three predominant forms of email authentication technology: SPF, DKIM, and DMARC. Conceptually, each operate similarly:
- When an email arrives at a recipient mail server, it queries the sending domain’s DNS to check for relevant email authentication records.
- If email authentication records are found, the server evaluates the email it received against the email authentication records and makes a determination: deliver it, deliver it but mark it as questionable, or discard it altogether.
See SP 800-177, section 4 for a detailed technical description.
What are the standards that enable email authentication?
SPF & DKIM
In effect, both these techniques allow a sending domain to “watermark” emails from their domain, making spoofed emails easier to detect.
However, there is no inherent or widely-implemented mechanism in either standard to signal what a recipient should do with messages that fail SPF/DKIM validation. DMARC serves this role.
Domain-based Message Authentication, Reporting and Conformance, or DMARC, serves three primary functions:
- Authentication: It verifies alignment between the domain listed in the email address that gets displayed to an email recipient and the outcome of SPF and DKIM authentication checks.
- Reporting: It enables a reporting mechanism so an email sender can validate their email authentication setup is working as expected.
- Conformance: It allows a domain owner to establish what the final disposition of email that fails email authentication checks should be.
Alignment and Conformance
Different than the
RFC5321.From address that is sent in the initial SMTP transaction, the
RFC5322.From address (also known as the
message-From address) is typically the email address that is represented as the sender in email clients. DMARC requires “alignment” between the domain in this very visible address and the domains that are authenticated in SPF and DKIM. This alignment can be “strict” (an exact match) or “relaxed” (must be a subdomain of the parent domain). Alignment is fully tunable in DMARC, with different options for SPF and DKIM alignment. DMARC’s default for alignmentis “relaxed”.
In order to satisfy DMARC filtering, at least one of either SPF or DKIM must “pass” their authentication checks and be in alignment with the domain in the
If not, DMARC allows a sender to set one of three separate policy states for email disposition:
- block delivery of unauthenticated messages (noted in the DMARC record as
- place unauthenticated messages in the recipient’s junk email folder (
- specify no guidance on how to treat unauthenticated messages (
p=none). This setting should be viewed as a temporary policy setting before getting to
p=reject, and is only meaningful when coupled with reporting.
In other words, by using DMARC, a sending domain can instruct receiving email servers to block delivery of all unauthenticated messages – such as phishing messages – that claim to be from the sending domain.
DMARC also enables a sending domain to request that participating email providers send it automatically generated reports about authentication results, thereby enabling the sending domain to monitor whether its SPF and DKIM policies are working properly.
In addition to monitoring proper configuration, this is valuable information one would not normally receive: if an attacker spoofs your domain, they are not likely to copy you on the spoofed email.
More detailed information about DMARC can be found in SP 800-177, section 4.6 and RFC 7489.
What are DMARC reports?
DMARC reports are summaries of email authentication results that are automatically sent by participating email providers. They detail what the email provider saw from your domain over a given period of time, and facilitate the process of graduating to
There are two kinds of reports:
- aggregate reports
- failure reports (sometimes called forensic reports)
Both reports provide information like the sending and receiving email domains, the DMARC policy that the email recipient discovered and applied, the identifier that was evaluated by SPF and/or DKIM and whether it was in alignment, the number of successful authentications, and the totals for all messages received. Aggregate reports are normally delivered once daily from mail receivers, whereas failure reports are sent immediately after an authentication failure. Failure reports include additional information about identity alignment, and can even include much of the body of the email and email headers; this can lead to an unintended exposure of private information. Failure reports are only sent by a handful of ISPs, none of which are US-based.
In 2015, the White House Office of Management and Budget (OMB) issued memorandum M-15-13, “A Policy to Require Secure Connections across Federal Websites and Web Services”, and a companion site at https.cio.gov. This policy requires all publicly-accessible Federal websites and web services to enforce the use of Hypertext Transfer Protocol Secure (HTTPS), and to use HTTP Strict Transport Security (HSTS).
The memo details why HTTPS and HSTS are so important:
The unencrypted HTTP protocol does not protect data from interception or alteration, which can subject users to eavesdropping, tracking, and the modification of received data… Unencrypted HTTP connections create a privacy vulnerability and expose potentially sensitive information about users of unencrypted Federal websites and services. Data sent over HTTP is susceptible to interception, manipulation, and impersonation. This data can include browser identity, website content, search terms, and other user-submitted information.
HSTS …instruct[s] compliant browsers to assume HTTPS going forward. This reduces insecure redirects, and protects users against attacks that attempt to downgrade connections to plain HTTP.
Over the last two years, this policy’s implementation has enabled the federal government to outpace the private sector in the deployment of HTTPS.
M-15-13 also contemplates that “[p]rotocols and web standards improve regularly” and that “Federal websites and services should deploy HTTPS in a manner that allows for rapid updates to certificates, cipher choices (including forward secrecy), protocol versions, and other configuration elements.”
BOD 18-01 directs agencies to make more progress on HTTPS and HSTS deployment, including by removing support for known-weak cryptographic protocols and ciphers. These are:
- SSLv2: Released in 1995. Most modern clients do not support SSLv2, but the DROWN attack demonstrated that merely serving SSLv2 enables the inspection of traffic encrypted with more modern TLS versions.
- SSLv3: Released in 1996. Considered to be insecure after the POODLE attack was published in 2014. Turning off SSLv3 effectively removes support for Internet Explorer 6.
BOD 18-01 requires that these protocols and ciphers cease being offered on internet-facing web and email servers.
The directive also requires that agencies identify and provide a list to DHS of agency second-level domains that can be HSTS preloaded. Agencies should review their list of second-level domains (including any not yet using the .gov top-level domain, as required by M-17-06) and analyze which can be preloaded.
This page provides implementation guidance for Binding Operational Directive 18-01 (BOD 18-01), which requires certain email and web security actions from Federal agencies.
- Within 30 days of BOD issuance (November 16th, 2017), submit an “Agency Plan of Action” to FNR.BOD@hq.dhs.govand begin implementing the plan.
- At 60 days (December 15th, 2017) after BOD issuance (and at every 30 days until full implementation), provide a status report of plan implementation to FNR.BOD@hq.dhs.gov.
- Within 90 days (January 15, 2018) of BOD issuance:
- Configure all internet-facing mail servers to offer STARTTLS.
- Configure all second-level domains to have valid SPF/DMARC records, with at minimum a DMARC policy of “p=none” and at least one address defined as a recipient of aggregate and/or failure reports.
- By 120 days (February 13, 2018) after BOD issuance:
- Ensure all publicly accessible Federal websites and web services provide service through a secure connection (HTTPS-only, with HSTS).
- Identify agency second-level domains that can be HSTS preloaded, and provide a list to DHS at FNR.BOD@hq.dhs.gov.
- Disable SSLv2 and SSLv3 on web and mail servers.
- Disable 3DES and RC4 ciphers on web and mail servers.
- Within 15 days of the establishment of a centralized NCCIC reporting location, add DHS as a recipient of DMARC aggregate reports (
- Within one year (October 16, 2018) of BOD issuance, set a DMARC policy of “reject” for all second-level domains and mail-sending hosts.
Frequently Asked Questions
Answers to other common compliance questions appear below.
What is the scope of BOD 18-01?
The Directive applies to internet-facing agency information systems, which encompasses those systems directly managed by an agency as well as those operated on an agency’s behalf. Its primary focus is on agency mail and web infrastructure, regardless of domain suffix.
What is a second-level domain?
A “second-level domain” is the domain name your organization has directly registered, inclusive of the top-level domain. In the example
www.dhs.gov, the second-level domain is
Some examples of top-level domains (TLDs; sometimes called “public suffixes”) are
.com. OMB memorandum M-17-06 requires that federal agencies use the
How does the web security requirement in BOD 18-01 differ from M-15-13?
BOD 18-01 incorporates parallel language to M-15-13 with regard to HTTPS deployment. The Compliance Guide at https.cio.gov should be consulted in implementing HTTPS and HSTS.
BOD 18-01 also mandates two additional steps:
- The disabling of old SSL versions (SSLv2 and SSLv3) and legacy cipher suites (3DES and RC4). In 2014, NIST marked SSLv2/v3 and RC4 as “not approved”, and in 2017, NIST urged all users of 3DES to migrate as soon as possible.
- Requiring a review of second-level domains that can be submitted for HSTS preloading and to submit this list to DHS.
Preloading a domain enforces the use of HTTPS across an entire zone, and is technical compliance with the HTTPS usage requirements of BOD 18-01. Preloading allows agencies to avoid inventorying and configuring an HSTS policy for every individual subdomain, though this necessarily impacts all subdomains present on the domain, including intranet subdomains. Thus, all subdomains will need to support HTTPS in order to remain reachable for use in major browsers. Even with these two obstructions, preloading a domain can be a reality with coordinated effort.
Second-level .gov domains that are only used to redirect visitors to other websites and are not used on intranets are excellent preloading candidates. However, DHS strongly recommends that federal agencies perform a thorough evaluation of those domains that are highly trafficked or otherwise have significant value. Those are likely to be the domains that citizens and intra-agency users stand to benefit most from the always-HTTPS approach that preloading provides.
My device is HTTPS already and doesn’t natively support HSTS. Can DHS mark this a false positive?
HSTS is intended to protect users, not servers. Even if a device is HTTPS-only and doesn’t respond over port 80, for as long as HTTP remains the default protocol for browsers and other HTTP clients, users are at risk from insecure redirects. Without HSTS, clients may still issue HTTP requests even when the server does not support them, and an attacker with an on-path vantage point can redirect or spoof these requests for malicious purposes.
The best mitigation for this threat is to preload your domains.
We encourage you to request that your vendors support HSTS in their products. Some federal agencies have had success in these requests, and DHS is happy to assist you in the request.
How should the list of second-level domains to be preloaded be shared with DHS?
You are encouraged to preload your domains yourself and then to report the set of preloaded domains to DHS in your Agency Plan of Action.
Where preloading directly is infeasible (for example, when HTTP is only served on subdomains, not on the ‘www’ of the base domain or at the domain root directly), you should include domains to preload in your Agency Plan of Action and DHS will coordinate the preloading with the DotGov program.
What process should be followed in order to implement email authentication?
For all second-level domains and all mail-sending hosts generally, make a plan to implement SPF, DKIM (mail-senders only), and DMARC, with a goal of setting
p=reject on all second-level domains.
NIST Special Publication 800-177, section 4.6.1 recommends:
When implementing email authentication for a domain for the first time, a sending domain owner is advised to first publish a DMARC [resource record] with a “none” policy before deploying SPF or DKIM. This allows the sending domain owner to immediately receive reports indicating the volume of email being sent that purports to be from their domain. These reports can be used in crafting an email authentication policy that reduces the risk of errors.
See the Resources page for implementation case studies.
What are the ramifications of setting subdomain policies?
Subdomains can have their own
p= policy set (e.g., at
_dmarc.subdomain.domain.gov), but otherwise they inherit the
p=policy set at the second-level domain or, if present, the subdomain policy (
sp=) at the second-level domain.
p=reject at the second-level domain is intended by the Directive so as to cascade throughout the zone, protecting all subdomains against spoofing. This is thwarted, though, when a policy weaker than
p=reject is set on any subdomain directly or via an
sp= tag set on a second-level domain.
While you work to properly authenticate email sent from subdomains, it is reasonable to set weaker-than-reject
p=policies on subdomains or by setting an
sp= on second-level domains. However, at one year after BOD issuance, the second-level domain must be at
p=reject with no
sp= policies set at the second-level domain nor subdomains with explicit policies less restrictive than
What should be done with domains that do not send mail?
Even if you do not send mail from your domain, anyone can spoof it to give the appearance that mail is coming from you. Setting a DMARC policy of
p=reject signals to recipient mail servers to reject any email purportedly sent from the domain, protecting your reputation and your stakeholders from likely malicious actors.
The following steps should be taken for second-level domains that don’t send mail:
- Set a DMARC policy of
p=reject. But before setting
p=reject, you are strongly encouraged to first set a policy of
p=none, specify a target address to receive DMARC reports at, and then review DMARC reports to confirm that no authorized mail is sent from the domain. Once you’ve confirmed that authorized email would not be interfered with, move the DMARC policy to
- An SPF “null record” should be added in DNS. A null record tells recipients that this domain sends no mail, and looks like this:
DMARC policies set at a second-level domain act as a wildcard, covering subdomains generally, including non-mail-sending domains. When a domain’s DMARC policy is set to
p=reject, it is not necessary to specify SPF “null records” on every active domain in the zone, though doing so is not harmful.
How can I receive DMARC reports?
You can configure a target address for DMARC report delivery by specifying for
rua= (aggregate) or
ruf= (failure) DMARC tags. You should receive reports from participating email providers within 48 hours.
Where should DMARC reports be sent?
Specify an email address where DMARC reports can be reviewed regularly. A DMARC record can indicate multiple addresses where reports should be sent; see RFC 7489, section 6.2.
A DMARC record that follows this recommendation, as set on
_dmarc.example.gov, looks like this:
This DMARC record has a policy of
none and requests that DMARC aggregate reports be sent to firstname.lastname@example.org. These reports, as well as failure reports, should be utilized to assist in the process of getting to
Commercial services exist that help derive intelligence from DMARC reports, though their use is not required to receive or read DMARC reports.
DHS DMARC reporting location
Federal agencies must add DHS NCCIC as an aggregate report recipient. The address that must be included is
Sending DMARC reports to more than one location
You are encouraged to receive your own DMARC reports in addition to sending them to DHS.
When crafting this portion of the DMARC record, take care that a) only one
rua= is defined, b) each address has its own
mailto:, and c) email addresses are separated by a comma. The
rua portion of the DMARC policy record could look like the following:
You should also note that while receivers must support the ability to send to at least two reporting addresses, a limit can be imposed beyond two. See RFC 7489, section 6.2, or an example at appendix B.2.4.
Sending DMARC reports to a different domain than your own
Sending DMARC reports to a domain different than the one requesting reports requires additional configuration at the intended recipient’s DNS. In order to mitigate a denial of service threat whereby someone could request DMARC reports be sent to arbitrary domains, an intended recipient of DMARC reports must signal its willingness to accept another domain’s reports with a DNS TXT record with the value
v=DMARC1 at a URI that follows this syntax:
For example, when mail is delivered that appears to come from
example.gov, the recipient mail server queries for a TXT record at
_dmarc.example.gov. It might find something like this:
Here, the aggregate report for
example.gov has been requested to be sent to
example.net. Seeing that these are different domains, the recipient mail server will query for a TXT record at
example.gov._report._dmarc.example.net. If it finds a TXT record starting with the value
v=DMARC1, then example.net will be considered a legitimate recipient for example.gov’s DMARC reports.
More details can be found at SP 800-177, section 4.6.6, and RFC 7489, section 7.1 (with Appendix B.2.3).
Can email authentication hinder my organization’s ability to deliver email?
Yes. You should thoughtfully deploy these technologies and plan your implementation carefully.
In particular, deploying DKIM and DMARC without adequate planning can cause negative impacts:
- Mailing lists that use older listserv software are known to cause issues with DKIM-signed mail. This is because DKIM digitally signs mail; if mailing list software modifies email headers or the body of the email, the signature at the recipient will not match. Where possible, update the listserv software.
- The challenges around “indirect email flows”, where email is sent via intermediaries (mailing lists, account forwarding) is recognized as an issue, and the Internet Engineering Task Force is working on a new protocol called ARC, Authenticated Received Chain. While still in draft, ARC is already being validated by some of the largest email providers in the world.
- Additional details, including workarounds, are detailed in SP 800-177, section 4.6.7, including workarounds.
- A DMARC policy of
p=reject tells recipients to drop mail that does not match the specified SPF and DKIM policies. While this has no impact on domains that don’t send mail, it will cause cause delivery failure when there is a policy mismatch; indeed, that is its purpose.
Does the Directive require email authentication checks before mail delivery?
BOD 18-01 requires email authentication be performed by sending domains. Evaluating inbound email against the sending domain’s SPF/DKIM/DMARC records are strongly recommended, but not explicitly required.
Does the Directive require the use of DKIM?
BOD 18-01 requires federal agencies to set a DMARC policy of
p=reject, which can be achieved without the use of DKIM. However, doing so is ultimately a policy decision for your organization to decide upon.
- “DMARC Guide” from Global Cyber Alliance, is a one-off SPF, DKIM, and DMARC policy analyzer and record creator.
pshtt are DHS open-source Python scanners to check for SPF/DMARC/STARTTLS usage and HTTPS best practices, respectively.
parsedmarc is a Python package and CLI tool that can parse aggregate and forensic DMARC reports, and optionally send them to an Elasticsearch instance where they can be visualized using premade Kibana dashboards.