With DMARC, domain owners publish a policy in their DNS records, specifying what actions should be taken when an incoming email fails authentication checks.
When setting up DMARC, you can include specific tags in your DNS records to define your policy and reporting preferences. These tags include information like the policy to be enforced (p tag), the percentage of emails to apply the policy to (pct tag), and the email address to which DMARC reports should be sent (rua and ruf tags).
This documentation provides information about the mandatory and optional tags to configure when adding a DMARC record to your domain, what they mean, the expected value for them, and their default value. You will also find examples of DMARC configurations according to your use-case.
DMARC policies specify how receiving email servers should handle messages that fail authentication checks (SPF and/or DKIM) for the domain. The three main DMARC policies are:
none: no action is taken by the receiving mail servers based on DMARC authentication results. This policy allows domain owners to assess the impact of DMARC enforcement on their email traffic without risking legitimate emails being blocked or sent to spam. It is used for monitoring and collecting data without impacting email delivery.
quarantine: suspicious emails that fail DMARC authentication are marked as spam or sent to a quarantine folder by the receiving mail server.
reject: emails that fail the DMARC authentication are rejected by the receiving mail server, and not delivered. This policy provides maximum protection against email spoofing or phishing attacks.
DMARC also evaluates whether an email message passes or fails based on how closely the domain specified in the From: header of the email matches the domain authenticated by either SPF or DKIM. This is referred to as alignment. There are two alignment modes you can configure:
r: with relaxed alignment mode, DMARC considers the alignment to be valid if the domain specified in the From: header of the email matches the domain authenticated by SPF or DKIM. This mode is useful if you use multiple email sources for a single domain.
s: with strict alignment mode, DMARC requires that both SPF and DKIM alignments pass for the message to be considered aligned. This means that the domain specified in the From: header of the email must exactly match the domains authenticated by both SPF and DKIM. Strict alignment provides a higher level of assurance that the email originated from the claimed sender domain.
Emails sent from sources not configured in your SPF record, or that do not have a DKIM will be rejected if you use the p=reject policy.
| Tag | Description | Mandatory | Values expected | Default value |
|---|---|---|---|---|
v | Indicates the DMARC version. | Yes | DMARC1 | x |
p | Indicates the policy to apply when/if a check fails. | Yes | none, quarantine, or reject | x |
sp | Indicates the subdomain policy to apply when/if a check fails. | No | none, quarantine, or reject | x |
adkim | Defines the DKIM alignment mode. | No | r (relaxed mode) or s (strict mode) | r |
aspf | Defines the SPF alignment mode. | No | r (relaxed mode) or s (strict mode) | r |
pct | Percentage of messages from the domain owner’s mail stream to apply the DMARC policy to. | No | Integer from 0 to 100 | 100 |
DMARC reporting involves the collection and analysis of DMARC reports generated by receiving mail servers. These reports provide domain owners with valuable insights into their email authentication status, including authentication successes, failures, and sources of spoofed emails. There are two main types of DMARC reports:
rua): aggregate reports provide data about a domain’s email authentication activity. These reports include information such as the volume of emails received, the percentage of emails that pass or fail DMARC checks, and the sources of failed authentication.ruf): forensic reports provide detailed information about individual email messages that fail DMARC authentication. They include the complete headers and body of the failed emails, details of the authentication checks performed, and any errors encountered.| Tag | Description | Mandatory | Values expected | Default value |
|---|---|---|---|---|
fo | Provides requested options for failure report generation. | No | 0, 1, d, or s. Read the dedicated RFC documentation to understand what these values mean. | 0 |
rf | Defines the format to use for message-specific failure reports. | No | Read the dedicated RFC documentation to find out about the expected value. | afrf |
ri | Indicates a request to receivers to generate aggregate reports separated by the requested number of seconds. | No | Number in seconds. | 86400 |
rua | Comma-separated addresses to which aggregate feedback is sent. | No | x | x |
ruf | Comma-separated addresses to which message-specific failure information is to be reported. | No | x | x |
Below are a few examples of DMARC configuration scenarios for inspiration to configure your DMARC.
The following DMARC configuration is the most basic one. It is commonly used for monitoring purposes rather than enforcing specific actions on incoming emails.
v=DMARC1 indicates the version of the DMARC protocol being used (version 1).p=none sets the DMARC policy to “none” meaning that no specific action should be taken based on the DMARC policy. This policy is typically used for monitoring purposes.rua=mailto:mydomain@example.com specifies the email address to which aggregate reports should be sent (mydomain@example.com).This configuration might be useful if you want to start implementing DMARC gradually, without immediately enforcing strict policies that could potentially affect your email deliverability. It allows you to monitor email authentication results and gather data without impacting the flow of incoming emails.
The following DMARC configuration provides a moderate level of protection against fraudulent emails while still allowing legitimate emails to be delivered.
v=DMARC1 indicates the version of the DMARC protocol being used (version 1).p=quarantine sets the DMARC policy to “quarantine”, meaning that suspicious emails should be treated with caution and possibly moved to the recipient’s spam or junk folder.rua=mailto:mydomain@example.com specifies the email address to which aggregate reports should be sent (mydomain@example.com).This configuration might be useful if you want to provide a moderate level of protection against fraudulent emails without immediately rejecting them. It protects your recipients from potentially harmful emails while still allowing legitimate messages to be delivered, with additional scrutiny.
The following DMARC configuration allows you to prioritize email security, and take strong action against fraudulent or unauthorized emails.
v=DMARC1 indicates the version of the DMARC protocol being used (version 1).p=reject sets the DMARC policy to “reject”, meaning that suspicious emails should be rejected outright and not delivered to the recipient’s inbox.rua=mailto:mydomain@example.com specifies the email address to which aggregate reports should be sent (mydomain@example.com).ruf=mailto:mydomain-forensic@example.com specifies the email address to which forensic reports should be sent (mydomain-forensic@example.com).Emails sent from sources not configured in your SPF record, or that do not have a DKIM will be rejected if you use the p=reject policy.
This configuration might be useful if you want to ensure that only legitimate emails from authenticated sources are delivered to recipients’ inboxes, while providing valuable reporting data to monitor and improve email authentication practices.
The following DMARC configuration shows you how to enforce strict email authentication policies with robust reporting mechanisms, and multiple email addresses to receive aggregate reports.
v=DMARC1 indicates the version of the DMARC protocol being used (version 1).p=reject sets the DMARC policy to “reject”, meaning that suspicious emails should be rejected outright and not delivered to the recipient’s inbox.rua=mailto:mydomain@example.com,mailto:mydomain-dev@example.com specifies the email addresses to which aggregate reports should be sent.sp=reject sets the subdomain policy to “reject,” meaning that emails failing DMARC checks for subdomains should be rejected.pct=80 specifies that the DMARC policy should be applied to 80% of incoming emails.fo=1 sets the failure options to “1” meaning that suspicious emails should be treated with caution.adkim=s sets the DKIM alignment mode to strict. This means that you are requiring that the DKIM authentication mechanism passes with exact alignment, to pass DMARC authentication. This provides a higher level of assurance that the email originated from the claimed sender and has not been tampered with in transit.aspf=s sets the SPF alignment mode to strict. This means that you are requiring that the SPF authentication mechanism passes with exact alignment, to pass DMARC authentication. This provides a higher level of assurance that the email originated from the claimed sender and has not been tampered with in transit.Emails sent from sources not configured in your SPF record, or that do not have a DKIM will be rejected if you use the p=reject policy.
This configuration might be useful if you want to enforce strict authentication policies while also maintaining visibility into email traffic through comprehensive reporting. It ensures that only legitimate emails from authenticated sources are delivered while providing insights into potential authentication failures and security threats.