What is DMARC?

DMARC stands for “Domain-based Message Authentication, Reporting & Conformance”. DMARC is an email authentication policy that builds on the well-established SPF and DKIM protocols. Just like SPF and DKIM, it helps prevent spam, phishing and email spoofing.

DMARC is designed to protect an email sender from advanced threats that can cause a data breach. It allows an email sender to outline and create their own authentication practises and specify exactly what actions you want to take when an email fails its authentication.

A DMARC record can be configured to send reports based on what emails are failing or passing “alignment”. More information on this later in this guide.

How does it work?

Note: It’s recommended you have a basic understanding of SPF and DKIM for this guide. A multitude of information can be found online about both SPF and DKIM email protocols.

Have you ever found yourself in a situation where you’ve received a legitimate looking email from a domain that turned out to be fraudulent? This is known as Email Spoofing.

DMARC can help prevent this type of attack by notifying the receiving server that their messages are protected by SPF and or DKIM. If a message then fails SPF/DKIM authentication, the DMARC record will advise the receiving mail server on what do with the message. We call this “alignment”. (A further explanation of this is in the “How is a DMARC record structured?” section.)

Note: DMARC should not be used as a replacement to SPF and DKIM, but instead should be used to build on them.

How is a DMARC record structured?

Similar to SPF and DKIM, DMARC is added via your domain DNS settings in the form of a TXT record.

In the following section, we’ll use an example DMARC Record, and then explain what each part of the record means. It’s worth noting that not all parts of the record are required, and many are optional.

You’ll need to specify a “Host” field in your DNS. The format for this starts with _DMARC. Followed by your domain name. E.g., if your domain is example.com, the Host will look like:

_DMARC.example.com

Example DMARC Record:

V=DMARC1; p=quarantine; pct=90; rua=mailto:email@example.com ruf=mailto:mail@mail.com; sp=reject; adkim=r; aspf=s

But what does each section mean?

V=DMARC1; (required)

This specifies that the DNS record is a DMARC record. Without this prefix, or with it being spelt/formatted incorrectly, the DMARC record will be ignored and will be ineffective.

P=quarantine; (required)

This section tells the receiving email server what to do if it fails SPF/DKIM alignment. The options for this section are:

• None – This should be used if you wish to understand and gain visibility on your emails without making changes.
• Quarantine – Advises the receiving email server to treat the email as suspicious. Most commonly, the email will land in their spam folder.
• Reject – This will request that the receiving email server outright rejects the email if it fails SPF/DKIM alignment.

Pct=90; (optional)

PCT is an optional tag and can be omitted from your record if you do not require it. This tag tells the receiving email server what percentage of emails the policy applies to. E.g., if you set this figure to 90%, such as in our example, the receiving email server will treat 90% of emails and ignore the other 10%.

It’s an effective method of checking your DMARC is working as expected.

Rua; + ruf; (optional)

The RUA report provides a high-level view of all email traffic Sent in an XML file format. This can commonly be opened in an application such as Microsoft Excel.

The RUF report gives a comprehensive overview of email messages that have failed DMARC checks. The report is sent in plain text format.

Both reports require a specified email address, as in the example above.

Sp=reject; (optional)

SP defines your subdomain policy.E.g. if you send from a subdomain such as mail@mail.example.com then you can outline an individual policy for subdomains. The same policy types apply as p= so please refer to this section for all options.

adkim=; (optional)

This section is setting the alignment rules for DKIM. It’s important to only specify these policies if you have an active DKIM record. If you’re unsure, we recommend leaving this blank.

Successful alignment will occur when your emails parent domain matches the “Header Form” domain.  For more information on this, we recommend researching how DKIM works.

You can specify the alignment to either Relaxed (adkim=r;) or Strict (adkim=s;).

Relaxed – A relaxed alignment means that the DKIM domain and Header From(located within the header of each sent email) must be an exact match or must match a child domain. This includes subdomains (e.g. email.example.com).

Strict – Selecting a strict alignment means that the DKIM domain and Header From domain must be an exact match. If you were to use a subdomain for example, then the DMARC record check should fail here and it will follow your policy set in Policy Failure Action section.

aspf=; (optional)

This section is similar to adkim; but specifies the alignment for an SPF record.

The options of defining both relaxed (r) and strict (s) are the same, including their result.

It’s once again important to only setup this section if you have a valid SPF record present. If you’re unsure, it’s recommended to leave this section blank.

Why do I need DMARC?

DMARC is completely optional, and it’s up to you to decide it you need it or not.

As a rule, DMARC is a requirement if your bulk sending emails, particularly to Google and Yahoo users.

It’s also beneficial to set up the reporting tools mentioned earlier in this guide. It can be helpful to understand what’s happening to your emails, and to make sure they’re reaching as many people as possible.

Is there a tool that can create a DMARC Record for me?

Yes! We’ve developed a tool that can generate a record for you, and if your nameservers are with us, it can even input it into your DNS records for you!

How To Add DMARC