Why set up a DMARC record?

You have probably heard of an SPF record. With an SPF record, the recipient knows whether the mail server that sent the original message was allowed to send this mail.

If you want to know more about an SPF record, we recommend reading the following article.

So much for the impact of an SPF record ... but what about the sender's email address? This is where the DMARC policy comes in.
By setting up a DMARC(Domain-based Message Authentication, Reporting and Conformance) record with correct "policy," the receiving mail server can also check how a From: e-mail address should be handled and how it should be reported to the administrator of the sending mail server.

What exactly does a DMARC policy do?

A DMARC policy allows a sender to indicate that their domain name is secured with SPF and/or DKIM records and tells the recipient what to do if none of these authorization methods succeed.

A policy will determine what happens in case the SPF and/or DKIM value does not match correctly: reject the e-mail message or quarantine the message.

What is alignment?

A term that often comes up in DMARC configuration is "alignment."
Specifically, it refers to the relationship between the From: e-mail address visible to the client and the address used between the servers.
When both match, the addresses are aligned and will be handled correctly by the DMARC policy. If not, the DMARC policy will fail and reporting rules may or may not take effect.

What does a DMARC DNS record look like?

A minimal DMARC record is "present" in the domain name zone, but does not contain a specific policy.

nslookup -type=TXT _dmarc.yourdomain.be

This can return the following basic policy:

_dmarc.yourdomain.be. IN TXT "v=DMARC1; p=none;"

The above is the simplest DMARC record you can set up: it has no impact on the delivery of your e-mail but offers no protection.
If you optionally add a reporting line (see below) you can be kept informed of any feedback.

A base record with reporting:

_dmarc.yourdomain.be. IN TXT "v=DMARC1; p=none; rua=mailto:postmaster@yourdomain.be;"

This delivers a summary report to postmaster@yourdomain.be in the form of an XML file.

A more complete and complex DMARC record might look like this:

_dmarc.yourdomain.be. IN TXT "v=DMARC1; p=quarantine; pct=25; fo=0; adkim=r; aspf=r; rua=mailto:postmaster@yourdomain.be;"

Specifically:

v: the version of the DMARC protocol.

p: the applied policy, it can be none, quarantine (informs the recipient that the message that does not answer the check should be treated as suspicious, so it can be tagged or put in a spam/junk folder) and finally reject (reject the message that does not answer the check).

pct: the percentage of mail that should be quarantined in this case: 25% will be treated as suspicious, 75% will be assigned the policy "none" and thus pass. By increasing the percentage you can make the policy stricter.

fo: the fo value is optional and stands for "failure reporting options" and specifies the type of reports to be sent. Possible values are:
f=0: send a report if all underlying authentication mechanisms refuse to let the mail through (default).
f=1: send a report if one of the underlying authentication mechanisms (SPF or DKIM) refuse to let the mail through (recommended) .
f=d: generate a report if the DKIM signature was incorrect, regardless of alignment.
f=s: generate a report if the SPF record gives an error, regardless of alignment.
The fo paremeter can also be combined, if you want to receive different types of reports, for example. The values must then be placed with : in the record: f=0:1:s.

adkim: this can be "r" or "s" and means that the DKIM rules are "strict" or "relaxed".

aspf: this can be "r" or "s" and means that the SPF rules are "strict" or "relaxed".

rua: this indicates where the summary reports should arrive, in this case it is mailto:postmaster@yourdomain.be so mails with XML reports will arrive at postmaster@yourdomain.be.

How to deploy a DMARC policy?

It is best to implement a DMARC policy gradually to avoid problems with mail delivery.
Each policy has its own consequences and limitations:

p=none: gives no protection, mails will always be sent and may include basic reporting.

p=quarantine: introducing partial protection and an important step in rolling out a correct policy, will also inform the recipient what to do with suspicious messages.

p=reject: the highest level of protection, conveys to recipients that all suspicious mails from your domain will be immediately rejected and rejected messages can be sent back to the sender.

We therefore recommend starting with a simple policy such as:

_dmarc.yourdomain.be. IN TXT "v=DMARC1; p=none; rua=mailtopostmaster@yourdomain.be;"

And gradually increase this to:

_dmarc.yourdomain.be. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailtopostmaster@yourdomain.be;"

And then build out a reject policy:

_dmarc.yourdomain.be. IN TXT "v=DMARC1; p=reject; pct=1; rua=mailtopostmaster@yourdomain.be;"

You can increase the percentage as the configuration runs (e.g., from 1% to 25%, to 50% and so on).
Attention, a “reject” policy of 100% means that mails whose records are not aligned will be rejected, this also means that sent mails will not arrive if the configuration is not correct!

Need help setting up a correct DMARC record?

Setting a DMARC DNS record is not easy and can potentially have major consequences for the delivery of mail correspondence to your domain name.

Therefore, when in doubt, take the safe bet and contact a Kinamo specialist to guide you in setting up a correct DMARC strategy and policy.