DMARC ehk Domain-based Message Authentication Reporting and Conformance combines SPF and DKIM technologies into a single set of rules to mitigate the risk of email address spoofing.
DMARC allows a domain administrator to specify, using the TXT records of a DNS name server, specific rules to which all emails originating from a [From:] source address associated with its domain must conform. For example, it is possible to specify whether a letter must be signed using DKIM technology, sent from an IP address according to SPF policy, or both conditions must be met at the same time. In addition, it is possible to describe in general terms what to do with messages that do not comply with DMARC rules.
By default, a DMARC rule, created by Zone, allows the recipient of the mail to accept it even if one of the above checks fails.
But it is possible to set it more strictly. For example, it is possible to make the DKIM signature mandatory by using the adkim=s tag in the DMARC DNS record. If this is combined with the p=reject, which in turn represents the policy, then the servers serving the recipient of this rule-violating mail should not accept any rule-violating mail.
However, it is up to each server administrator to decide how email servers handle emails with DMARC policies. For example, not all servers with a p=reject policy may always reject emails, regardless of the policy set. However, most major providers such as Gmail, Office365 and the new Zone email platform do.
Name server record
Going into more detail, DMARC policy is configured with a special TXT record named _dmarc subdomain, for example _dmarc.example.com. The content of this TXT record consists of nimi=väärtus tags separated by semicolons.
Example:
"v=DMARC1;p=reject;rua=mailto:dmarcreports@example.com;"
In My Zone control panel, you can activate the DMARC policy from the Email -> DKIM / SPF / DMARC menu.
By default, v=DMARC1; p=quarantine TXT entry is added, but if desired, the policy can be made stricter.
Policies
The Policy tag defines the strictness of the DMARC rule. In the DNS record, this is described using the p= tag. Possible tag values are:
none– no specific policy is given to the server receiving the message;quarantine– quarantine, the recipient server should place the rule-breaking message in the spam folder or add a flag to indicate that the message is suspicious;reject– the server receiving the message should reject the message that violates the rules.
NB! The policy tag p= must be configured in the TXT record immediately after the version v=!
It is advisable to gradually move to a stricter implementation of the DMARC policy: none->quarantine->reject.
DKIM and SPF stringency
adkim= and aspf= tags can be used to configure whether the rules for DKIM and SPF are relaxed or strict. The default value for both is ‘relaxed’. However, if the value is set to ‘strict’ (=s), theadkim=s tag requires the receiving server to require all messages to be signed by DKIM, and the aspf=s tag requires messages to be sent from the IP addresses configured in the SPF DNS record. For a loose (default) policy, at least one of these must be correct.
We recommend that you think very carefully before making your settings stricter to ensure that all mails sent out from your domain meet these conditions!
Reports
One notable feature of the DMARC rules is the ability to request reports from email servers that have received mail on your domain.
PS! Reporting is intended for advanced users and we recommend reading the more detailed DMARC documentation before enabling reporting! For example here.
fo=by configuring the tag you can specify which reports are sent.rf=by configuring the tag you can specify the format of the bug report.ri=by configuring the tag you can specify how often the report is sent (default is 24h).rua=by configuring the tag you can specify the e-mail address to which the report should be sent, this must be in the formatmailto:dmarcreports@example.com. NB! This e-mail address should be in the same domain, otherwise a separate TXT record must be added for the e-mail address of the report in the domain zone. However, this is a topic for advanced users.
Additional information
- Keep in mind that the DMARC policy affects the emails From: (header from) header. However, the SPF check applies to the sender of the envelope (envelope from). If these domains are different and the message does not have a DKIM signature, the DMARC check will fail! This will affect the sending and forwarding of copies of the email, as SRS will change the envelope from.
- The DMARC documentation talks about
pct=tag, which is supposed to specify the percentage of emails to which the DMARC policy should be applied. In reality, we have not encountered a situation where this percentage has any effect and it is not necessary to add it. - Dedicated service providers (such as https://dmarcian.com/) are available to collect and analyse DMARC reports, but we would point out that many of their reports are very technical and difficult to interpret.
- DMARC only applies to messages with a single From: address (technically, according to the RFC, there can be more than one From address in a book, but in reality this is not very common).