The basics of DMARC

To authenticate your domain, you need to add an SPF (Sender Policy Framework) and a DKIM (DomainKeys Identified Mail) record to your domain’s DNS settings.

Google and Yahoo have announced new rules for bulk email senders effective February 2024, requiring those who send 5,000+ emails in a day to set up another security protocol, DMARC (Domain-based Message Authentication, Reporting & Conformance).

DMARC is an email authentication, policy, and reporting protocol that is set up on the DNS settings of a domain as a TXT record. It provides validation of the origin of the emails by inspecting the sender's IP address. 

A DMARC policy can help protect a domain from direct domain spoofing through DKIM and SPF identifier alignment. In other words, if the DKIM and/or SPF record of an email message that claims to be from your domain fails to pass, the DMARC policy tells the recipients’ email servers what to do with it. This helps identify fraudulent emails from legitimate emails and prevents scams from occurring.

It is recommended to set up a DMARC policy if you frequently send high volumes of emails (around 5k+), if your sending domain has a high risk of being spoofed or if you want to track any outgoing emails sent on behalf of your domain via the reporting functionality it provides.

If you want to use DMARC, we recommend that you employ the services of DMARC consulting companies to set this type of DNS record up properly for you, to reduce any potential negative impact on your email delivery.

A DMARC record verifies that the domain in the Header/From field (the sender email) is the actual sender of the message by comparing it to one or both domains found in the DKIM or SPF record.

To make sure these domains are aligned, the domain used to create the DKIM signature should match the Header/From domain, and the SPF verifies that the sending server's IP address has been approved by the owner of the domain specified in the SMTP MailFrom command.

You can set the alignment to be one of the following:

• Strict - the domains must be an exact match.

• Relaxed - the domains can have different subdomains of the same root domain.

A DMARC record is made up of several tags. Some are required and some are optional. 

An example of a basic DMARC record:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Required tags

The following tags have to be included in a DMARC record for it to be valanchor:

• v - Identifies the record as DMARC and it must be listed at the beginning. It is always DMARC1.

• p - Indicates the policy that you have chosen for your record. This policy will be applied by the email mailbox providers when your email fails DMARC authentication and alignment checks. 

There are three DMARC policies that you can use according to your needs:

• p=none - Known as the monitor policy, it doesn’t tell the recipients’ email servers to do anything, but it allows you to track the emails that are being sent on your domain’s behalf. 

• p=quarantine - Tells the recipients’ email servers to send the message to the junk or spam folder if it fails the DMARC check. It also tracks all of the emails that are sent on your behalf.

• p=reject - Tells the recipients’ email servers to reject all emails that fail the DMARC check. This results in having these emails bounce and not being delivered to any folder of the recipient. It also tracks all of the emails that are sent on your behalf. 

Optional tags

These tags provide additional options that help customize the DMARC record and its report functionality:

• rua=mailto:address@domain.com - Specifies the email address where complete reports should be sent by participating email mailbox providers. These daily reports help identify malicious activity and potential authentication issues in your domain. 

• fo - It lets email mailbox providers know that you want samples of the text sent in the emails that failed SPF and/or DKIM. There are four value options:

  • 0 - Create a DMARC failure report if both SPF and DKIM fail to generate an aligned PASS result. This is the default.

  • 1 - Create a DMARC failure report if the SPF or DKIM record generates any other type of alignment result that is not PASS. This is recommended.

  • d - Create a DKIM failure report if the email’s signature failed its evaluation, despite the alignment’s result.

  • s - Create an SPF failure report if the email’s SPF failed its evaluation, despite the alignment result.

• ruf=mailto:address@domain.com - Specifies the email address where forensic (message-level) reports should be sent by participating email mailbox providers. These reports are more detailed and are delivered after a DMARC authentication failure has been detected. 

• rf - This is the format for message failure reports. The default is afrf (Authenticate Failure Reporting Format, which is the only value supported for now.

• ri - The number of seconds that need to pass before the next report is sent by participating email mailbox providers. The default value of seconds is 86400, which is one full day.

• sp - It indicates one of the three requested policies for all subdomains where the email fails DMARC authentication and alignment checks. It’s recommended when the owner of the domain wants different policies for the primary domain and all of its subdomains. If this tag is not used for subdomains, then the primary policy set up in the p tag will be applied to the primary domain and all of its subdomains.

• pct - The percentage of emails that will include the DMARCauthentication. This tag is useful to test the impact and effect of the policy as it is gradually implemented.

• adkim - It indicates whether the DKIM identifier alignment is strict or relaxed. The default is relaxed. 

• aspf - It indicates whether the SPF identifier alignment is strict or relaxed. The default is relaxed.

To maintain reputable email security, DMARC aggregate reports provide details about the authentication status of messages sent on behalf of a domain. They allow the domain owner to see which emails sent from their domain have passed or failed the SPF and DKIM authentication.

While these reports do not include any information about the sending email, they can include:

• Details about the source that sent it

• The domain name used

• The sender IP address

• The number of messages sent on a particular date

• The DKIM and SPF sending domain 

• The result of the DKIM and SPF authentication

• The policy that was applied by the email receiver 

To start receiving these aggregate reports, make sure your DMARC record includes the RUA tag ( rua=mailto:address@domain.com ). DMARC reporting organizations can send the reports to this email address.

To learn more about how DMARC works, check dmarc.org.

To authenticate your domain, you need to add an SPF (Sender Policy Framework) and a DKIM (DomainKeys Identified Mail) record to your domain’s DNS settings.

Although not required in the authentication process, some users decide to also add a DMARC policy on their DNS settings to further protect their domains from spoofing and phishing email attacks.

It's important to understand both the benefits and potential downsides of implementing a DMARC record, as improper implementation can lead to emails not being delivered to their intended recipients.

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance (RFC 7489). It is an email authentication, policy, and reporting protocol that is set up on the DNS settings of a domain as a TXT record. It provides validation of the origin of the emails by inspecting the sender's IP address. 

A DMARC policy can help protect a domain from direct domain spoofing through DKIM and SPF identifier alignment. In other words, if the DKIM and/or SPF record of an email message that claims to be from your domain fails to pass, the DMARC policy tells the recipients’ email servers what to do with it. This helps identify fraudulent emails from legitimate emails and prevents scams from occurring.

It is recommended to set up a DMARC policy if your sending domain has a high risk of being spoofed or if you want to track any outgoing emails sent on behalf of your domain via the reporting functionality it provides.

If you want to use DMARC, we recommend that you employ the services of DMARC consulting companies to set this type of DNS record up properly for you, to reduce any potential negative impact on your email delivery.

A DMARC record verifies that the domain in the Header/From field (the sender email) is the actual sender of the message by comparing it to one or both domains found in the DKIM or SPF record.

To make sure these domains are aligned, the domain used to create the DKIM signature should match the Header/From domain, and the SPF verifies that the sending server's IP address has been approved by the owner of the domain specified in the SMTP MailFrom command.

You can set the alignment to be one of the following:

• Strict - the domains must be an exact match.

• Relaxed - the domains can have different subdomains of the same root domain. 

A DMARC record is made up of several tags. Some are required and some are optional. 

An example of a basic DMARC record:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Required tags

The following tags have to be included in a DMARC record for it to be valanchor:

• v - Identifies the record as DMARC and it must be listed at the beginning. It is always DMARC1.

• p - Indicates the policy that you have chosen for your record. This policy will be applied by the email mailbox providers when your email fails DMARC authentication and alignment checks.

There are three DMARC policies that you can use according to your needs:

• p=none - Known as the monitor policy, it doesn’t tell the recipients’ email servers to do anything, but it allows you to track the emails that are being sent on your domain’s behalf. 

• p=quarantine - Tells the recipients’ email servers to send the message to the junk or spam folder if it fails the DMARC check. It also tracks all of the emails that are sent on your behalf.

• p=reject - Tells the recipients’ email servers to reject all emails that fail the DMARC check. This results in having these emails bounce and not being delivered to any folder of the recipient. It also tracks all of the emails that are sent on your behalf. 

Optional tags

These tags provide additional options that help customize the DMARC record and its report functionality:

• rua=mailto:address@domain.com - Specifies the email address where complete reports should be sent by participating email mailbox providers. These daily reports help identify malicious activity and potential authentication issues in your domain. 

• fo - It lets email mailbox providers know that you want samples of the text sent in the emails that failed SPF and/or DKIM. There are four value options:

  • 0 - Create a DMARC failure report if both SPF and DKIM fail to generate an aligned PASS result. This is the default.

  • 1 - Create a DMARC failure report if the SPF or DKIM record generates any other type of alignment result that is not PASS. This is recommended.

  • d - Create a DKIM failure report if the email’s signature failed its evaluation, despite the alignment’s result.

  • s - Create an SPF failure report if the email’s SPF failed its evaluation, despite the alignment result.

• ruf=mailto:address@domain.com - Specifies the email address where forensic (message-level) reports should be sent by participating email mailbox providers. These reports are more detailed and are delivered after a DMARC authentication failure has been detected. 

• rf - This is the format for message failure reports. The default is afrf (Authenticate Failure Reporting Format, which is the only value supported for now.

• ri - The number of seconds that need to pass before the next report is sent by participating email mailbox providers. The default value of seconds is 86400, which is one full day.

• sp - It indicates one of the three requested policies for all subdomains where the email fails DMARC authentication and alignment checks. It’s recommended when the owner of the domain wants different policies for the primary domain and all of its subdomains. If this tag is not used for subdomains, then the primary policy set up in the p tag will be applied to the primary domain and all of its subdomains.

• pct - The percentage of emails that will include the DMARC authentication. This tag is useful to test the impact and effect of the policy as it is gradually implemented.

• adkim - It indicates whether the DKIM identifier alignment is strict or relaxed. The default is relaxed. 

• aspf - It indicates whether the SPF identifier alignment is strict or relaxed. The default is relaxed.

To maintain reputable email security, DMARC aggregate reports provide details about the authentication status of messages sent on behalf of a domain. They allow the domain owner to see which emails sent from their domain have passed or failed the SPF and DKIM authentication.

While these reports do not include any information about the sending email, they can include:

• Details about the source that sent it

• The domain name used

• The sender IP address

• The number of messages sent on a particular date

• The DKIM and SPF sending domain 

• The result of the DKIM and SPF authentication

• The policy that was applied by the email receiver 

To start receiving these aggregate reports, make sure your DMARC record includes the RUA tag ( rua=mailto:address@domain.com ). DMARC reporting organizations can send the reports to this email address.

To learn more about how DMARC works, check dmarc.org.