Compliance Guidance

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.


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.

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 should be consulted in implementing HTTPS and HSTS.

BOD 18-01 also mandates two additional steps:

  1. 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.
  2. 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.

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.

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.

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.

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, looks like this:

"v=DMARC1; p=none;;"

This DMARC record has a policy of none and requests that DMARC aggregate reports be sent to These reports, as well as failure reports, should be utilized to assist in the process of getting to p=reject.

Commercial services exist that help derive intelligence from DMARC reports, though their use is not required to receive or read DMARC reports.

Sending DMARC reports to others

Where cloud service providers or other contracted email service providers are utilized, sending DMARC reports to a domain different than the one requesting reports is possible with additional configuration. The intended recipient of DMARC reports must signal its willingness to accept the domain’s reports with a DMARC TXT DNS record of the following syntax:


For example, an original message sent from is authenticated with a DMARC record: IN TXT "v=DMARC1; p=reject;"

The recipient then queries for a DMARC TXT RR at and checks the rua tag includes the value to insure that the address specified in the sending domain owner’s DMARC record is the legitimate receiver for 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).

DHS DMARC report collector

As indicated in BOD 18-01, DHS will stand up a service that can receive and process DMARC reports that will collate details into your Cyber Hygiene reports. The address will be shared in late 2017.

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:

What should be done with domains that do not send mail?

DMARC policies set at a second-level domain act as a wildcard, covering subdomains generally, including non-mail-sending domains.

With DMARC p=reject, it is not necessary to specify SPF “null records” on every active domain in the zone, though doing so is not harmful.

Additionally, since mail clients check for a DMARC policy at the sending subdomain first, it is possible to set a separate DMARC policy at (for example) even with the stronger policy at the second-level domain.