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.gov and 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?
- What is a second-level domain?
- How does the web security requirement in BOD 18-01 differ from M-15-13?
- My device is HTTPS already and doesn’t natively support HSTS. Can DHS mark this as a false positive?
- How should the list of second-level domains to be preloaded be shared with DHS?
- What process should be followed in order to implement email authentication?
- What are the ramifications of setting subdomain policies?
- What should be done with domains that do not send mail?
- How can I receive DMARC reports?
- Where should DMARC reports be sent?
- Can email authentication hinder my organization’s ability to deliver email?
- Does the Directive require email authentication checks before mail delivery?
- Does the Directive require the use of DKIM?
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
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?
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:
"v=DMARC1; p=none; rua=mailto:email@example.com;"
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 adding an additional
rua, each address requires its own
mailto:, and the addresses are then separated by a comma. The
rua portion of the DMARC policy record could look like the following:
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:
_dmarc.example.gov. IN TXT "v=DMARC1; p=reject; rua=mailto:reports.example.net"
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.
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=rejecttells 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.