- Store secrets in AWS Secrets Manager - Fri, Mar 17 2023
- Install Windows 10 / 11 22H2 without Microsoft account - Tue, Feb 28 2023
- Configuring IPvlan networking in Docker - Fri, Feb 24 2023
Reporting is useful for administrators to develop detailed insights into who is sending emails on behalf of your domain and how emails are being treated by receiving mail servers. In a nutshell, DMARC protects your domain from abuse by email phishing and spoofing scams.
Together, SPF, DKIM, and DMARC ensure that no third party sends forged emails on your domain's behalf.
How DMARC works
Like SPF and DKIM, DMARC also requires you to publish a TXT record in the domain's DNS, but its syntax is slightly complicated. The DMARC record contains a policy that instructs the receiving mail servers on how to handle the email messages sent from your domain. When a mail server receives an email message, it verifies whether the incoming message passes the SPF and DKIM. If the email passes the SPF and DKIM checks, the message is considered DMARC compliant. If the message is not compliant, the receiving mail server will either deliver, quarantine, or reject the message, depending on the policy configured in the DMARC record.
Understanding the DMARC record syntax
Like DKIM records, DMARC records follow a specific syntax. The following table contains an example of a DMARC record.
| TYPE | NAME | VALUE |
| TXT | _dmarc.company.com | v=DMARC1; p=reject; rua=mailto:postmaster@company.com; ruf=mailto:postmaster@company.com; sp=quarantine; adkim=s; aspf=s; pct=100 |
Keep the following in mind regarding the Name field in the DMARC record:
- All DMARC preferences are stored in a subdomain named _dmarc. Thus, the name of the DKIM record has to start with _dmarc.
- Depending on your DNS registrar, you might have to append the domain name, so ultimately the Name part of the record becomes _dmarc.company.com. If your registrar automatically appends the domain name, make sure you only type _dmarc in the Name field.
- When a receiving mail server wants to validate DMARC for a message, it will query DNS for the subdomain _dmarc.company.com.
The Value of a DMARC record is a bit complicated. The following screenshot provides an overview:
Understanding various parts of the DMARC record
These are the most important tags in a DMARC record:
- v=DMARC1: Indicates that a DMARC version 1 record is used.
- p= prefix: Defines the DMARC policy. See the DMARC policies section below for details.
- The rua tag specifies the email address in URI format (mailto:) to generate aggregated XML reports periodically. Multiple email addresses can be specified in a comma-separated format (e.g., rua=mailto:postmaster@company.com,mailto:reports@company.com).
- The ruf tag specifies the email address in the same format as the rua tag and is used to generate forensic reports for the email messages failing the DMARC check.
- The adkim tag specifies the DKIM alignment mode. In relaxed mode (denoted by "r"), the subdomains of the parent domain can be treated as DKIM-aligned. However, in strict mode (denoted by "s"), the exact match of domain names is required in the from address and in DKIM-signing ("d=" tag in message signature). The default alignment mode is relaxed.
- The aspf tag specifies the SPF alignment mode. The modes are the same as for the adkim tag. In relaxed mode, the SPF-authenticated domain and the from address domain must have the same parent domain, allowing subdomains to be considered aligned. In strict mode, only an exact match is required to be considered SPF aligned.
- The pct tag defines the percentage of emails to which the DMARC policy is applied. If you set pct=100 the DKIM policy is applied to all emails.
- The optional fo tag is used to specify forensic options. The allowed values are 0 to generate reports if both DKIM and SPF fail, 1 if either DKIM or SPF fails, d if DKIM fails, and s if SPF fails.
- The optional ri tag is used to specify the reporting interval that defines how often you want to receive the aggregate XML reports on the address defined in the rua tag. The default value is 86400 seconds, which is equivalent to 24 hours.
DMARC policies
Three DMARC policies exist:
- Monitor policy: The monitor policy is denoted by p=none in the TXT record. It tells the receiving mail servers to send the reports only to the address specified in the RUA or RUF tag of the DMARC record and not to take any action on the email messages that fail the DMARC check. This policy is recommended in the initial configuration for production domains to prevent important emails from failing because of false positives.
- Quarantine policy: The quarantine policy is denoted by p=quarantine. It tells the receiving mail servers to quarantine the email messages that fail the DMARC check and sends the aggregated reports and failure reports to the defined addresses.
- Reject policy: The reject policy is denoted by p=reject. It tells the receiving mail servers to reject the messages that fail the DMARC check and sends the aggregated reports and failure reports to the defined addresses.
Publishing a DMARC record
Before configuring DMARC, make sure that both the SPF and DKIM records are properly configured for your domain. To create the DMARC record, log on to your domain registrar's DNS management console and create a TXT record. The following screenshot shows how to publish a DMARC record in the Cloudflare DNS:
Publishing DMARC records in the Cloudflare DNS
Validating DMARC policy
After publishing the DMARC record in DNS, you could use DMARC Checker to verify that your DMARC record does not contain errors. The following screenshot shows the results of a DMARC validation:
Checking the DMARC record for errors using the DMARC checker
Alternatively, you could send an email from your domain to a gmail.com address and view the email headers to verify the DMARC status. In Gmail, open the email message that you just sent, click the three dots in the right corner, and select Show original.
Viewing the status of SPF DKIM and DMARC for a message in Gmail
If you see PASS next to the SPF, DKIM, and DMARC fields, your domain is completely protected from email spoofing and scams. If someone tries to send emails on behalf of your domain, these spoofed email messages will be handled by the receiving emails according to the DMARC policy.
Final notes
DMARC is a powerful tool for preventing email spoofing. However, implementing a DMARC policy in a hurry can cause false positives, as legit email messages might fail to be delivered. Thus, I recommend starting with a DMARC with policy (p=none) and gradually changing it to quarantine (p=quarantine). If you have verified for some time that no problems have occurred, you can move on to reject (p=reject). Organizations sometimes take up to six months before enforcing a reject policy. This helps you understand the email flow in your domain with the help of the aggregated and forensic reports that you receive.
Furthermore, notice that a DMARC policy is a request—not an obligation—which essentially means that by setting up a DMARC policy in your domain, you're requesting that the receiving mail servers indicate how to handle the email messages that come from (or pretend to have come from) your domain. But in the end, it solely depends on the receiving mail server to honor your DMARC policy.
Most mail servers will honor your policy and handle the email messages accordingly, but be aware that server admins can override the DMARC policy with their local policy. This essentially means that a receiving mail server could still deliver a forged email message due to a local policy, even though it was supposed to be rejected as per your DMARC policy.
