What is DMARC

DMARC is one of the mechanisms designed to protect a company from phishing attacks using its domain name. This issue is relevant for any brand dealing with user personal data and payment accounts, with bank accounts, payment systems, mobile operators, social networks, and major online stores being the most commonly affected. The essence of a phishing attack lies in sending fraudulent emails pretending to be from a well-known company, effectively delivering malware to the user's device or redirecting them to a site where personal data, such as login credentials, credit card information, and phone numbers, can be stolen. These emails are disguised as legitimate communications, with a crucial role played by the use of the targeted company's primary domain.

How it works

DMARC operates based on the SPF and DKIM authentication protocols, verifying the correctness of SPF and DKIM checks and ensuring that the emails were genuinely sent from domains under the organization's control. The key functions of DMARC include authentication checks and the generation of reports.

What is checked:

• The sending IP address of the email is listed in the permitted SPF record.
• The DKIM check status is "pass," indicating a successful passage.

The results of the check update information in the reports:

• Data on the facts and results of the check is added to the aggregate report, which is sent by default once a day.
• A notification email is sent for each failed check in case of a negative outcome (DMARC check failure). Therefore, it's advisable to use a separate address to receive these reports, as there can be a significant number of them.

DMARC allows the sender to specify how to handle emails based on the check results. This is done through the specification of DMARC policies, which come in three types:

1. "None" – a monitoring policy used when starting to work with DMARC to understand which domains the emails are sent from.
2. "Quarantine" – a quarantine policy, with emails either sent to spam, subjected to stricter scrutiny, or marked as suspicious, depending on the email provider.
3. "Reject" – the strictest policy and the highest level of protection. With a "reject" policy, the sender instructs the email provider to block all emails that fail SPF and/or DKIM checks.

In short, when using DMARC, the recipient can be confident that the email is genuinely sent from the specified “From”-email address.

Recording syntax

DMARC has its own syntax, which informs the email provider about the need for checks and defines actions based on the results. There are two required parameters for use, and default values will be applied to the rest if you don't explicitly specify your parameter values.

Required parameters:

• v (version) – the protocol version, must be DMARC1. Used to indicate that this TXT record defines the DMARC policy. This parameter must come first in the record; otherwise, the email provider won't recognize the record as a whole.
• p (Requested Mail Receiver Policy) – the policy for handling emails that you specify for the email provider. The three possible options are described in the article above: none/quarantine/reject.

Based on these parameters, we get a minimally functional record:

v=DMARC1; p=none

Additional parameters:

1. rua – specifies the address to send aggregated reports. It is specified in the format rua=mailto:email@domain.com.
2. ruf – determines the address for sending reports on failed authentication checks. Each authentication check failure generates a report error email. So this email address may receive dozens, hundreds, or thousands of emails if a phishing attack is attempted on you or if there is a failure in your DNS/mail system and email authentication fails. The parameter format is ruf=mailto:email@domain.com.

The next block of parameters has default values that are used if the parameter is not explicitly specified in the DMARC record:

1. adkim (DKIM identifier alignment) – strict or relaxed DKIM alignment. With the strict parameter, a failed DKIM key check will result in the overall DMARC check failure. The default value is relaxed.
2. aspf (SPF identifier alignment) – strict or relaxed SPF alignment. Works similarly to the ADKIM check; the default value is relaxed.
3. rf (Report Format) – the format of the report on failed checks. By default, it takes the value AFRF (Authentication Failure Reporting Format).
4. ri (Reporting Interval) – the interval between sending aggregated reports, specified in seconds. By default, it is set to 86400 seconds (once a day).
5. pct (Percentage) – the percentage of messages to which the DMARC policy will be applied. Used for gradual implementation or testing of the DMARC policy; you can enable the policy for only 10% of emails and check the results of the reports to see if any expected emails are being rejected.
6. sp (Subdomain Policy) – the DMARC policy that will apply to subdomains. Different policies can be used for the main domain and subdomains. The default policy remains the same as for the main domain.
7. fo (Failure reporting options) – determines which types of failed checks will send reports to the domain owner. It can have the following values:
   • 0 – send a report if both SPF and DKIM checks fail. This is the default.
   • 1 – send a report if either the SPF or DKIM check fails.
   • d – send a report for each failed DKIM key check.
   • s – send a report for each failed SPF mechanism check.

Your record might look like the following if you use all the available parameters:

v=DMARC1; p=quarantine; rua=mailto:rua.email@domain.com; ruf=mailto:ruf.email@domain.com; fo=1; adkim=s; aspf=s; pct=40; rf=afrf; ri=3600; sp=reject