DMARC, or Domain-based Message Authentication, Reporting, and Conformance is a protocol that utilizes SPF and DKIM protocols to help authenticate emails and prevent spoofing. The protocol is built using a TXT-type record in the domain’s DNS zone.
The Internet Engineering Task Force (IETF) – RFC7489 – when defining and using DMARC, considered two goals: first, to specify and announce the actions that should be taken by the recipient when checking the SPF and DKIM factors of the email, and second, to send a report of the check result from the destination email server to the domain owner.
How Does the DMARC Record Work?
As we mentioned, DMARC uses the SPF and DKIM protocols which can be defined in the domain’s DNS zone file to help authenticate received email and to prevent its falsification. To put it simply, the SPF record has a list of allowed IP addresses that the domain administrator can use to serve as an email server. Using the DKIM record, we authenticate the sender, and the content of the sent message is not altered during transmission. This procedure is made possible by encrypting and providing the public key.
This general process of DMARC function involves the following steps:
- The domain administrator sets policies necessary for email authentication on the destination side through a TXT record in the domain’s DNS zone file, along with the actions the recipient must take in the event of violating these policies. In other words, DMARC records are created in this step, followed by SPF or DKIM.
- When the target user gets an email, through the DNS check of the email sender’s domain name within the From section of the email header, the user gets notified of the policies defined for DMARC and what is required for SPF and DKIM checks for that domain. At that point, the receiving server will evaluate 3 factors in the received email:
If the DKIM check is successful or not. A positive result of this check can mean that the email sender’s identity is not forged, but not necessarily!
If the IP address of the email received is present in the list of allowed items in the SPF record of the domain or not.
If the domain name listed in the sender section of the header of the received email is the same as the domain name listed in each SPF and DKIM records.
- Depending on the checks performed in the previous two steps, the recipient email server decides whether to accept, reject, or quarantine the received email following the procedures specified in the DMARC record.
- A report on the results of the checks conducted on the emails is sent by the recipient servers to the email address provided in the DMARC record.
Structure of the DMARC Record
The DMARC record is stored in the DNS zone configuration file of the domain. It is a special type of TXT record. Let’s take a look at an example of it to familiarize yourself with its general structure.
As you can see, this record begins with _dmarc.mydomain.com. _dmarc refers to the record protocol, and mydomain.com represents the domain name where we want to define the DMARC record in the DNS zone file.
- TTL is the time that DNS servers keep data for this record.
- TXT indicates the type of DNS record.
However, what should be done in practice is defined in the Values section. We specify the type of protocol we wish to use in the TXT record in the v=DMARC1 tag. Thus, the name DMARC is written here. In addition, the number 1 indicates the version of the protocol. Keep in mind that the values are written in uppercase.
You can use one of the values quarantine, none, and reject in the p part, which is the policy. The value in p specifies what action to take if either SPF or DKIM checks fail. In none mode, which means validating incoming mail in any mode, no matter the results of the SPF and DKIM checks and the matching domain addresses in the From section, the email will be sent to the recipient’s inbox. Note that in this case, a report about the situation will only be sent to the address of the owner of the email server domain that was specified in the rua and ruf sections. In the quarantine mode, suspicious emails will be moved to the recipient’s spam folder along with the report. And in reject mode, the arrival of unconfirmed emails from checks and not matching the domain address of the From section will be completely blocked.
The aspf and adkim tags will be used to specify the degree of matching of the address in the From section of the received email with the domain names provided in the SPF and DKIM records. This matching can be relaxed, meaning that even the subdomains of a domain are assumed to be allowed, or it can be strict, which means that the name and the level of the domains have to match exactly. In the default mode and with no such tags inserted, the r or relaxed value is used for them. For applying the strict setting, the values of adkim and aspf should be set equal to s.
rua=mailto:dmarc-aggregate@mydomain.com or Reporting URI(s) for aggregated data represents the address to which the recipient email server sends a full report of the emails it has received from your domain, at regular intervals and on a specified schedule, such as daily. Now, these alleged domains may be genuine and authorized by you or those who pretend to be you and send emails from you. If the latter is the case, then you can use these reports to determine future SPF blacklists of abusive domain names and IP addresses. The report will include any rejections or approvals of SPF, DMARC and DKIM policies allowing the domain administrator to further make decisions to mitigate spam and impersonation.
The ruf=mailto:dmarc-afrf@mydomain.com tag or reporting URI(s) for error data, however, is an address that will only be sent when emails are received by the recipient that violates DMARC policies and SPF and DKIM checks. In contrast to the regular and scheduled rua report, this report will be sent immediately and when any type of error occurs; as a result, the domain administrator, in this case, should expect to receive a large number of emails. Furthermore, unlike rua, this tag will provide more information about the errors that have occurred.
Note that the v tag has to be specified first, followed by the p tag. You can specify the other tags, which are optional, in any order. Also, to ensure that the DMARC protocol works as it should, it is important to specify the rua tag with a valid email address.
Setting the DMARC Record in the ArvanCloud User Panel
You can register a sample record in the ArvanCloud panel after selecting the domain in the user panel and then clicking DNS Records and creating a new TXT record.