Please note that this content has been relocated to the FedRAMP Help Center. For the most current version, please visit the Help Center.
Author: FedRAMP Knowledge Base
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
| |
| DMARC Record without Any Errors |
|---|
| fedramp.gov DMARC record:
|
| 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
The minimum properties have not been set.
|
| subdomain.example.com
| This example is missing rua parameter pointing to reports@dmarc.cyber.dhs.gov Corrected subdomain.example.com:
|
Resources
- 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.
- 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.
- “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.
- 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.
- “Add a DMARC Record” is a Google help page that offers a stepped approach to enabling DMARC thoughtfully.
- “Use DMARC to validate email in Office 365” provides Microsoft Office 365-related guidance for implementing DMARC on outbound and inbound mail delivery.
- “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
- BOD 18-01: Enhance Email and Web Security , defines agency requirements and how DMARC should be deployed.
- FedRAMP Agency Authorization Review Report Template
- DMARC.org is an initiative under the Trusted Domain Project focused on DMARC education, and development of the standard.
