DMARC

• DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a mechanism that tells a receiving email server what to do based on the SPF and DKIM authentication checks.
  • DMARC checks whether the domain passes the SPF and DKIM authentication checks and that the email's "From" field is aligned with the SPF and DKIM authenticated domains.
    • DMARC only checks for alignment if the authentication passes first.
  • If an email's "From" domain is aligned with either the SPF or DKIM authenticated domains, then it can be delivered.
• DMARC Alignment requirements can be "Relaxed" or "Strict"
  • Relaxed means email from a matching root-level (or organization level) domain will align
    • e.g., marketing.example.com will align with example.com
  • Strict means that the domain in the email must exactly match the authenticated domain
    • e.g., marketing.example.com would fail to align with example.com
• Delivery aggregate and failure reports can be sent to designated email addresses for review
  • These reports are critical for troubleshooting and setup.
    • failure/forensic reports are not generated by many mailbox providers for GDPR/privacy regulation compliance, so you may be stuck with aggregate reports
  • DMARC can also be configured in purely an audit mode without SPF and DKIM; no action is taken, but you get reports on who is sending emails on your domain's behalf and whether they succeed for fail authentication.
  • Reports can be analyzed using DMARC Report Analyzer, which can ingest and process manually downloaded reports or connect automatically to an email account to download reports.
    • If you do not have an easy way to process these reports or create an account to receive them, services like DMARC Report^[1] offer free report monitoring for a single domain and up to 10,000 email reports per month.
    • Additionally, Cloudflare offers free DMARC report management for domains configured with their service.
• There will most likely only be one DMARC TXT record on your DNS host.
  • Like SPF, it applies to all emails sent from your domain, and not to specific hosts like DKIM
  • The sp tag can be used to apply a different policy action on subdomains
    • However, if you want more granularity (like different aggregate/failure report addresses), you can add another record for that subdomain.
• DMARC verifies authentication by requiring alignment with either SPF or DKIM, specifies a policy instructing receivers how to handle unauthorized senders, and generates XML reports sent to the domain owner for Accounting.

DMARC Implementation

Configuring DMARC is easy, but can cause you the most headaches because it's what authorizes email to be delivered, and a misconfiguration can stop your email in its tracks. Therefore, it's highly recommended that you first configure your DMARC policy to none to take no action on emails for the first couple of weeks, using the reports generated to make sure everything is getting delivered as expected, and then to add a quarantine or reject policy and maybe ramp up implementation through the pct tag.

Below is an example of a DMARC TXT record:

1. Name: _dmarc
2. Type: TXT
3. TTL: 3600
4. Value: v=DMARC1; p=quarantine; sp=reject; pct=100; aspf=r; adkim=r; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; fo=1; ri=43200

Let's break it down.

1. Name: _dmarc.example.com
   1. _dmarc
      1. Signifies this a DMARC TXT entry
   2. Note that you do not typically need to enter the root domain here; however, if you did a DMARC lookup for example.com, you would see the entry as _dmarc.example.com
      1. Only one DMARC record needs to exist for the apex domain, but you can add more records for different subdomains to take different actions; for example, _dmarc.mailer.example.com
2. Type: TXT
   1. This is a text record (as opposed to A, CNAME, etc.)
3. TTL: 3600
   1. The time to live is 1 hour (3600 seconds)
   2. This is an expiration date for the DMARC record, and helps DNS servers maintain up-to-date records.
4. Value: v=DMARC1; p=quarantine; sp=reject; pct=100; aspf=r; adkim=r; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; fo=1;
   1. v=DMARC1
      1. DMARC version 1; at present, there is only one version.
   2. ;
      1. The separator between tags.
      2. Spaces and tabs can make entries more readable, but are completely optional.
   3. p=quarantine
      1. The Policy applied to emails which fail their SPF and DKIM authentication checks
      2. There are three options:
         1. none: No action is taken
            1. Typically used while configuring email security and collecting reports.
         2. quarantine: Emails which fail authentication should be treated with suspicion and sent to the spam/junk folder
            1. This allows the recipient server to still receive and process unauthenticated mail, just treats them with suspicion
         3. reject: Instructs the receiving server to outright reject any mail that fails authentication.
            1. This is the most secure, but can also be the most problematic if a configuration changes or something goes wrong.
   4. sp=reject
      1. The policy for subdomains; if sp is not stated in the record, then the policy described by p is inherited by its subdomains.
         1. Setting sp may be helpful to set a stricter policy if there are no subdomains, or a looser policy if configuring a subdomain for mail.
         2. Some receiving servers don't check the root domain for a DMARC policy to inherit; playing it safe and adding a DMARC record for your subdomains is not a bad idea.
      2. Creating a distinct DMARC policy for a subdomain (e.g., _dmarc.mailer.example.com) takes precedence over the sp policy designation.
         1. To reiterate, sp only applies to a subdomain if there isn't a more specific DMARC policy created for it.
   5. pct=100
      1. The percent of unauthenticated emails to apply the policy to.
         1. e.g., pct=20 would only apply the p=reject policy to 20% of emails which fail authentication
      2. This is helpful during a slow rollout to make sure not all email flow stops.
      3. Default is 100, and does not need to be explicitly written.
   6. aspf=r
      1. SPF alignment requirements
         1. r is relaxed, and only the root/organizational domain must match
            1. Relaxed is the default value for both aspf and adkim, and does not need to be explicitly stated
         2. s is strict, and domains must match exactly
   7. adkim=r
      1. DKIM alignment requirements; see aspf for details.
   8. rua=mailto:dmarc-reports@example.com
      1. Identifies the email address to which recipient servers should send delivery aggregate reports
      2. Each address must begin with mailto:, and multiple addresses can be specified if separated by a comma.
         1. e.g., rua=mailto:address1@example.com,mailto:address2@contoso.com
      3. Aggregate reports contain basic information and include successful and failed delivery information
   9. ruf=mailto:dmarc-failures@example.com
      1. Identifies the email address to which recipient servers should send individual delivery forensic failure reports
      2. Forensic failure reports contain detailed information about failed deliveries to assist with triage and troubleshooting.
         1. However, most major providers highly redact or suppress ruf records for privacy and GDPR compliance.
   10. fo=1
       1. The failure reporting option specifies what generates a forensic report .
          1. 0 is default, and only requests forensic reports on DMARC failure.
          2. 1 requests a report for any SPF or DKIM failure, which is helpful for triage and troubleshooting during initial setup.
          3. d generates a report only when DKIM authentication (not alignment)
          4. s generates a report when SPF fails.
       2. You can select multiple options with a colon (e.g., fo=0:d)
       3. Reminder: many mailbox providers don't send forensic/failure reports for GDPR compliance.
   11. ri=43200
       1. The "report interval" is the time in seconds you request receivers to generate reports.
          1. The default is 24 hours (86400 seconds), and 12 hours as configured here.
       2. Most providers ignore this, and send reports every 24 hours or more based on their own infrastructure.
          1. "DMARC implementations MUST be able to provide daily reports and SHOULD be able to provide hourly reports when requested. However, anything other than a daily report is understood to be accommodated on a best-effort basis."^[4]

Sending Reports to a Different Domain

If you are sending DMARC reports to another domain for analysis, you will need to create a TXT record on that domain's name server to identify each sending domain.^[5]

For example:

1. Type: TXT
2. Name: sendingdomain.com._report._dmarc.receivingdomain.com
   1. For example, if the MSP AcmeIT.com was configured to receive and manage DMARC reports for example.com, the record would be example.com._report._dmarc.acmeit.com
3. Value: "v=DMARC1"
   1. Just indicates the version of DMARC

The TXT record name identifies the domain generating the report (sendingdomain.com), followed by ._report._dmarc and the domain receiving the reports (.receivingdomain.com).
The TXT record value just identifies the DMARC version ("v=DMARC1")

dig

Metadata

Sources

RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)
dmarc.org – Domain Message Authentication Reporting & Conformance
DMARC - Wikipedia
Learn and Test DMARC
Use DMARC to validate email, setup steps - Microsoft Defender for Office 365 | Microsoft Learn
The DMARC ‘fo’ tag options and their ideal use cases – DMARC Report

Tools

DMARC Report Analyzer
GitHub - techsneeze/dmarcts-report-parser: A Perl based tool to parse DMARC reports from an IMAP mailbox or from the filesystem, and insert the information into a database. ( Formerly known as imap-dmarcts )

Tags

#defs_sec