Skip to main content

Configure Domain-based Message Authentication, Reporting & Conformance (DMARC)

Updated

Intended Audience: CSP technical teams, 3PAOs, Agency Reviewers

Published: July 2024

Objective: Clarify the process for implementing and documenting Domain-based Message Authentication, Reporting, and Conformance (DMARC) in a FedRAMP Authorized (or seeking authorization) Cloud Service Offering (CSO)

Overview

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is an email authentication protocol that helps to detect and prevent email spoofing. By consistently using DMARC for emails sent by, or on behalf of the federal government, people and organizations that receive federal email can have high confidence that these emails are legitimate and official. The Cybersecurity and Infrastructure Security Agency (CISA) required the use of DMARC by federal agencies as one of the many BOD 18-01  requirements for all sending email domains. This KBA is specific to the FedRAMP DMARC requirements based on BOD 18-01.

Requirement

FedRAMP requires enforceable DMARC policies on all cloud service offerings (CSOs) that send emails on behalf of the Federal Government. This might include notifications of business processing events; sending questionnaire links to respondents; and initial customer user provisioning, or customer password resets.

How do I meet this requirement?

The email domain used in the FROM: field of an email must have an associated DNS record that includes a valid DMARC policy that instructs email servers to reject all unvalidated email, and instructs email servers to notify CISA of rejected emails.

More technical detail is included in the implementation section below, but the basic requirements are that the DMARC record must be valid and include the following parameters:

  • p=reject
  • either pct=100 or pct not specified (defaults to 100)
  • rua email addresses must include mailto:reports@dmarc.cyber.dhs.gov

This must be documented in SI-8 in the SSP Appendix A per the FedRAMP Rev5 High and Moderate baselines. For Low and LiSaaS, it should be documented under SI-5.

Implementation

Actions for CSPs and Independent Assessors

At minimum, each second-level CSO domain’s (and subdomains’) and CSO mail-sending hosts’ DMARC configuration policy used to send email on behalf of the government, as defined above, should be checked for:

  • The sending FROM: domain or subdomain has the appropriate DMARC record policy
  • Outgoing email is appropriately configured to ensure alignment between the DMARC policy and SPF and/or DKIM.

Usually CSPs will use a unique domain, or subdomain for FedRAMP-related emails from the CSP’s corporate domain to prevent corporate email from also reporting to DHS. Such as fedsaas.com or fed.saas.com.

How to check if a DMARC record is valid?

Select a “dmarc record checker” (for convenience, three are provided in the Resources list below), and check the FROM: domain with one or more available tools. In particular, check for:

  • Lack of errors returned by the testing tool
  • A policy set to reject (p=reject)
  • A percentage set to 100% (pct=100 either explicitly or implicitly by the default)
  • Destination for aggregate reports includes DHS (rua parameter includes mailto:reports@dmarc.cyber.dhs.gov)

Actions for Agencies

Please see BOD 18-01  section on DMARC for additional information.

How to check if outgoing email is appropriately configured?

Send an email through the CSO to a known address where the receiving email server evaluates inbound email against the sending domain’s SPF/DKIM/DMARC records. Review the email headers for appropriate content, for example:

  • If SPF is configured on the FROM: domain, look for a corresponding spf=pass header
  • If DKIM is configured on the FROM: domain, look for a corresponding dkim=pass header

Note that while it is encouraged to implement both SPF and DKIM, only one is required for a compliant DMARC implementation.

Examples and Common Issues

DMARC implementation is a common FedRAMP authorization issue, as CSP implementations often fail to meet BOD 18-01  requirements.

Example of a properly configured DMARC record for fedramp.gov

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

dig txt _dmarc.fedramp.gov

; <<>> DiG 9.10.6 <<>> txt _dmarc.fedramp.gov

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5307

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 512

;; QUESTION SECTION:

;_dmarc.fedramp.gov. IN TXT

;; ANSWER SECTION:

_dmarc.fedramp.gov. 10800 IN TXT "v=DMARC1; p=reject; pct=100; fo=1; ri=86400; rua=mailto:dmarcreports@gsa.gov,mailto:reports@dmarc.cyber.dhs.gov; ruf=mailto:dmarcfailures@gsa.gov"

;; Query time: 56 msec

;; SERVER: 8.8.8.8#53(8.8.8.8)

;; WHEN: Tue Jun 18 09:23:38 EDT 2024

;; MSG SIZE rcvd: 205
DMARC Record without Any Errors

fedramp.gov DMARC record:

  • v=DMARC1;
  • p=reject;
  • pct=100;
  • fo=1;
  • ri=86400;
  • rua=mailto:dmarcreports@example.com,mailto:dmarcreports@gsa.gov,mailto:reports@dmarc.cyber.dhs.gov;
  • ruf=mailto:dmarcfailures@gsa.gov/li>

This example includes p=reject,pct=100, rua=mailto:reports@dmarc.cyber.dhs.gov and is a valid DMARC record

Examples of a misconfigured DMARC record and a properly configured DMARC record

DMARC Record with Error Issue(s)

subdomain.example.com

Result: No DMARC Record Found

There is no DMARC record

There is no DMARC version set

  • V=DMARC1

The minimum properties have not been set.

  • p=reject
  • either pct=100 or pct not specified (defaults to 100)
  • rua email addresses must include mailto:reports@dmarc.cyber.dhs.gov

subdomain.example.com

  • v=DMARC1;
  • p=reject;
  • pct=100;
  • fo=1;
  • ri=86400;
  • rua=mailto:dmarcreports@example.com;
  • ruf=mailto:dmarcfailures@example.com

This example is missing rua parameter pointing to reports@dmarc.cyber.dhs.gov

Corrected subdomain.example.com:

  • v=DMARC1;
  • p=reject;
  • pct=100;
  • fo=1;
  • ri=86400; rua=mailto:dmarcreports@example.com,reports@dmarc.cyber.dhs.gov
  • ruf=mailto:dmarcfailures@example.com

Initial and Ongoing Authorization Considerations

This section outlines factors that FedRAMP considers related to initial and ongoing maintenance of FedRAMP packages.

DMARC Configuration Overview Authorization Impact
Acceptable for FR Authorization

Based on reviews of the DMARC:

  • The DMARC record is valid in DNS
  • A policy set to reject (p=reject)
  • A percentage set to 100% (pct=100 either explicitly or implicitly by the default)
  • Destination for aggregate reports includes DHS (rua parameter includes mailto:reports@dmarc.cyber.dhs.gov)

These are the requirements as directed by BOD 18-01  and the FedRAMP baselines (See Resources for testing tools).

Will not delay authorization

Based on review of sample outgoing emails received onto an email server that checks DMARC:

  • If SPF is configured on the FROM: domain, look for a corresponding “spf=pass” header
  • If DKIM is configured on the FROM: domain, look for a corresponding dkim=pass header

While it is encouraged to implement both SPF and DKIM, only one is required for a compliant DMARC implementation

  
FR Authorization possible with open POA&M item

Any deviation from Acceptable DMARC configurations

[see Analyzing Examples]

POA&M may be required to be documented as a post authorization action
FR Authorization probably delayed until remediated
n/a n/a n/a

Resources

  1. Special Publication 800-177 Rev 1, Trustworthy Email , issued in February 2019 by the National Institute of Standards and Technology. Section 4 discusses the protocols and techniques a sending domain can use to authenticate valid email senders for a given domain.
  2. Businesses Can Help Stop Phishing and Protect their Brands Using Email Authentication , issued in 2017 by the Federal Trade Commission’s Bureau of Consumer Protection; identifies the benefits of implementing DMARC.
  3. “DMARC Guide”  from Global Cyber Alliance is a one-off SPF , DKIM , and DMARC  policy analyzer and record creator. Provides guidance to organizations through the process of creating a DMARC policy.
  4. Commercial and free services exist (including at least one FedRAMP Authorized DMARC service) that help derive intelligence from DMARC reports. The below examples are provided for convenience only and are not FedRAMP-endorsed.
    1. https://easydmarc.com/tools/dmarc-lookup 
    2. https://dmarcian.com/domain-checker/ 
    3. https://www.proofpoint.com/us/cybersecurity-tools/dmarc-spf-creation-wizard 
    4. https://mxtoolbox.com/dmarc.aspx 
  5. “Add a DMARC Record”  is a Google help page that offers a stepped approach to enabling DMARC thoughtfully.
  6. “Use DMARC to validate email in Office 365”  provides Microsoft Office 365-related guidance for implementing DMARC on outbound and inbound mail delivery.
  7. “How to align with SPF and DMARC for your domain if you use a lot of 3rd parties to send email as you”  describes a vendor-agnostic approach to herding third-party
  8. BOD 18-01: Enhance Email and Web Security , defines agency requirements and how DMARC should be deployed.
  9. FedRAMP Agency Authorization Review Report Template
  10. DMARC.org  is an initiative under the Trusted Domain Project focused on DMARC education, and development of the standard.

Related articles

Comments

0 comments

Please sign in to leave a comment.

GSA logo

FedRAMP.gov

official website of the GSA’s Technology Transformation Services

Looking for U.S. government information and services?
Visit USA.gov