Learn how to set up a DMARC record

A DMARC record setup consists mainly of mandatory and non-mandatory parts. For the DMARC record to function, a receiving mailserver must know two things: a) what type of record it is and b) what policy must be implemented.

An important aspect of a record is that it is case-sensitive and that spacing is sometimes allowed and sometimes not. So pay close attention to where these rules apply!
Setting mandatory components in the DMARC record
At the beginning of your new DMARC record you will always find the version of the record. In the record, this is currently noted as v=DMARC1. We use the first version of DMARC. This mandatory component must also be in front, otherwise it must be ignored according to the specification.

The second mandatory part is the policy, so to speak. In this policy you state what the receiving mailserver may do with e-mails that do not conform to your SPF and DKIM record.

Are you at the beginning of the DMARC implementation and do you not yet have a complete overview of all e-mail flows on behalf of your company? Then it is advisable to start with a 'none' policy with reporting. This way, you will gradually gain insight into all e-mail flows, without losing important e-mails because of a strict policy.
If you want to block e-mail flows that do not originate from your company, but which do reach customers in your name, you will need to implement a stricter policy. You will need to know which addresses are allowed to send e-mail in your name and then apply 'quarantine' or 'reject' as a policy. The end result of your policy is then p=none, p=quarantine or p=reject.

Non-mandatory components
However, just a "v=DMARC1, p=none" is not enough. By setting your DMARC record this way, you still let everything through and have no insight into your e-mail flows. To create insight, you can use the so-called rua and ruf tags. These both ensure that the receiving mailserver sends back reports about the e-mails it receives.

DMARC reporting
rua is generic feedback based on received e-mails. ruf provides a detailed report for messages that did not pass the check. The report is sent back by receiving mail servers to the address shown behind this tag. You may want to keep rua ('aggregate feedback') and ruf ('message specific failure information') separate, for example when two different parties use the information.

When using a platform such as Flowmailer, where reporting is made transparent on the basis of this feedback, it may be desirable to keep both addresses the same.

On the other hand, it may be the case that you wish to receive the feedback at several addresses. In that case, several e-mail addresses can be placed behind the tag, separated by a comma:

For example: "rua=dmarc@flowmailer.net, dmarc@jouwdomein.nl"
Next, you can determine for which reason you want to receive forensic reporting. The fo tag can be used for this. This tag indicates which type of report should be sent back by the mail server. The fo-tag is not mandatory, nor is it for receiving mailservers. It is possible that you will get other reports than the ones you have set up.

You can set four types of reporting for the fo-tag:

0: Generates a report if all mechanisms fail (SPF and DKIM). This type is set by default when using the ruf tag.
1: Generates a report when a single mechanism fails.
d: Only when DKIM fails, a report is sent.
s: Only when SPF fails, a report is sent.
fo=1 is the strictest type because it takes all mechanisms seriously and sends a report even on a single failure.

Setting DMARC on Subdomains
You can also include a few things in the record for the policy to be applied. Sometimes you have to deal with subdomains that you want to secure differently than the main domain. For example, if you send your monthly invoices via 'invoices.jouwbedrijf.nl' and you have a 'reject' policy on jouwbedrijf.nl, you can create a separate policy for the invoices. You do this by using the sp tag, which works the same as the p tag. If you set the sp-tag to none, quarantine or reject, the receiving mailserver knows it has to do something different with those e-mails than with e-mails from your main domain.

Policy on subdomain
Next, you can also determine per mechanism how strict authentication is. For both SPF and DKIM you can specify that the authentication must be relaxed or strict. Strict means that authentication is only successful if the data in the e-mail exactly matches the data as specified in the DNS settings. This means that a subdomain can no longer email in the name of the main domain. Relaxed is a bit more flexible in this respect.

Example: if your DMARC record includes the domain 'jouwbedrijf.org' you can also send emails from the subdomain 'news.jouwbedrijf.org'. So normally those emails will arrive perfectly unless your SPF and DKIM authentication is set to strict. Relaxed will just let this email through.
The tags used for these policies are aspf and adkim respectively: strict(s) and relaxed(r). So your apsf=s and your adkim=r.

A final setting that you can apply in your DMARC record is the percentage that should be subject to the policy. This setting is designed to allow the domain owner to slowly implement a reject policy, rather than all or nothing. The percentage (pct tag) can logically be set between 0 and 100, with a default of 100% (pct=100).