DMARC explained, how to add DMARC to your domain.
In this post I’ll be explaining what DMARC is, what it’s used for, and how you set up DMARC. Lots of people are asking about this at the moment, so it made sense to provide some information around this.
What is DMARC?
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance.
DMARC records are deployed as TXT DNS records.
The content of a DMARC record defines a policy. This policy is available for recipient mail servers to check to see what they should do with emails from your domain, should SPF and DKIM checks fail.
You define the DMARC policy according to how you want recipient mail servers to handle mails from your domain when SPF and/or DKIM checks fail. Yes, that’s right, you. You, the person that’s reading this!
Me?
Yes! That’s right! DMARC is your way of instructing recipient mail servers what to do under certain conditions.
Certain conditions?
Yes, that’s right, and for this to make sense, I’ll have to explain about two other types of mail specific DNS records.
DKIM and SPF records.
You can find an entire post that covers DKIM and SPF records here. I’ll summarise what DKIM and SPF records to here, though, but reading that post would be adivsable if you have the time.
DKIM and SPF records purpose is to minimise spam, and to help prevent from address spoofing. From address spoofing is when the from header of an email is forged. In a pratical context, this might be a spammer pretending to be you by putting your email address in the from header of an email. The email looks like it came from you, but it didn’t actually come from you and it wasn’t actually sent via your mail provider.
SPF and DKIM help spam and from address spoofing by defining the legitimate sources of emails from your domain and legitimising emails themeslves.
If DKIM and SPF checks pass, it’s pretty safe to say the email isn’t spam, and recipient providers are likely to accept these emails.
If DKIM and/or SPF checks fail, what happens then?
Your domain’s DMARC record is used to defined what happens if DKIM and/or SPF checks fail. The DMARC record can be used to tell recipient servers to junk or reject emails if they LOOK like they came from your domain, but didn’t actually come from the correct server.
SPF records.
SPF stands for Sender Policy Framework.
SPF records are also deployed as TXT DNS records.
What SPF records effectively do is define where emails with a from address in a domain should originate from.
To put this in practical terms, let’s say you have the following in place that send emails using a from address within your domain:
- An email address
- A website with a contact form
- An email marketing mail shot type service
In your domain’s SPF record, you should have these three “places” listed as valid sources of email from your domain.
If your website address is thisismywebsite.com, and you’re using the above, your domain’s SPF record effectively needs to say:
“Hey, mailserver, if you get an email with an @thisismywebsite.com from address it’s allowed to come from my email provider, my website, of my email marketing provider”
Obviously that’s not what an SPF record actually contains. In reality if:
- Your email is with office365
- Your website is hosted on 81.27.85.6
- You’re using Send In Blue for email marketing
Then your SPF record would look like this:
Name: thisismywebsite.com
Type: TXT
TTL:1440
Value: v=spf1 include:spf.protection.outlook.com +ip4:81.27.85.6 +include:sendinblue.com ~all
The forst line of the above (Name: thisismywebsite.com) is effectively the part that makes the “if you get an email with an @thisismywebsite.com from address…” statement.
This part:
Value: v=spf1 include:spf.protection.outlook.com +ip4:81.27.85.6 +include:sendinblue.com ~all
Is effectivelt what makes the “…it’s allowed to come from my email provider, my website, of my email marketing provider” statement.
As you can see, an SPF explictly states where emails with specific from addresses should originate from. This can be used by recipient mail servers to work out if emails have come from where they should.
DKIM records.
DKIM stands for DomainKeys Identified Mail.
DKIM records are also deployed as TXT DNS records.
DKIM is a little like SPF in the sense that it validates a source of emails from a domain, but it does more than this.
DIKM has a public and a private key.
The public key is the part of DKIM that’s advertised as a DNS TXT record.
The private key is held on the server that’s used to send emails. When an email is sent it’s “signed” with the private key.
When a recpient mail server receives an email with a DKIM signature, it can retrieve the publicly availble DKIM record from the sender’s domain DNS and use it to verify the signature on the message.
What this verification process does is ensure that the email was sent by the claimed sender and that it has not been tampered with during transit.
DKIM and SPF Together.
Together DKIM and SPF verify that the source where an email originated from is valid, that the email is valid, and that the email hasn’t been tampered with.
But what if DKIM and SPF checks fail? What does the recipient server do then?
That’s exactly what your DMARC record is used for: To tell the recipient mail server what it should do if SPF and DKIM checks fail.
Your DMARC policy.
As I’ve covered above, recpient mail servers will undertake DKIM and SPF checks.
To be able to deploy a DMARC record, you’re going to need to decide the following to establish your desired DMARC policy:
- If a recipient mail server should do nothing, qaurantine or reject emails.
- If the above should apply to both SPF and DKIM checks or just one or the other.
- If reports should be sent if DKIM or SPF checks fail, and if they should, to whom.
- If the above applies to just your domain, or to subdomains of your domain as well.
- To what percentage of emails should the policy be applied.
Once you’ve decided the above, you’re then in a postion to be able to define your DMARC record.
Your DMARC record.
There are a lot of online tools that you can use to generate a DMARC record based on the policy you’ve settled on.
If you haven’t yet settled on a policy you might consider revisting the section above.
Some of the tools that can be used to generate a DMARC record can be found here:
- MX Toolbox DMARC generator
- Dmarcian DMARC Wizard
- Easy DMARC generator
- Dmarcly DMARC generator
- Power DMARC generator
All of these tools work in the same way:
You enter your policy specific information, they then use this to generate a DMARC record for you, which will look something like this:
v=DMARC1;p=reject;sp=none;adkim=s;aspf=s;pct=100;fo=1;rf=afrf;ri=86400;rua=mailto:ralph@someguycalledralph.co.uk;ruf=mailto:ralph@ralphlucas
To add this, you’d use the DNS managment are for your domain, and what you’d add is:
Name: _dmarc.yourwebsite.com
Type: TXT
TTL: 1440 (this may vary)
Value: v=DMARC1;p=reject;sp=none;adkim=s;aspf=s;pct=100;fo=1;rf=afrf;ri=86400;rua=mailto:ralph@someguycalledralph.co.uk;ruf=mailto:ralph@someguycalledralph.co.uk
Because you’re deploying a dmarc record the record name tends to start with _dmarc and then be followed by your domain (as per the above: _dmarc.yourwebsite.com), but this may vary if you’re doing something like adding DMARC records to your domain that are specific to an email marketing company such as mailchimp.
If you’re using cPanel hosting, this would be carried out in the “Zone Manager” in you cPanel and you’d add the DMARC record using the above, like this:
It is also possible to manually create your own DMARC record, then deploy it in the same manner, but to be able to do this, you’ll need to understand the syntax of a DMARC record.
Example simple DMARC records.
Some providers will give you DMARC records (in some cases just to make you go away and stop asking them about DMARC!).
Some example DMARC records and a breif description of what they do follows. To gain a complete understanding of how DMARC records work, you’ll need to read the “DMARC record syntax” section.
Example DMARC records:
v=DMARC1;p=none;
This does nothing. This record means “this is a DMARC record with no DMARC policy”. If you’ve been given this record it’s either to get you to stop asking about DMARC, or to stop a reporting tool pointing out that you don’t have a DMARC record. It doesn’t serve any purpose other than this.
v=DMARC1;p=quarantine;fo=0;
This is the simplest most relaxed DMARC record. What this means is “Put emails in junk/spam folders if they fail DKIM and/or SPF checks, don’t report, don’t apply to subdomains”. You might use this if you want a DMARC policy, but you’re not completely sure if you’ve covered everything with your SPF and DKIM records.
v=DMARC1;p=reject;fo=0;
Again this is a simple DMARC record, but it’s less relaxed. This one means “reject emails if they fail DKIM and/or SPF checks, don’t report, don’t apply to subdomains”. You might use this if you want a DMARC policy to tell recipient mail servers to reject all emails, if they fail SPF and/or DKIM checks. You’ll need to ensure your SPF and DKIM records are set up correctly if you use this. If you wanted to be really strict you could use:
v=DMARC1;p=reject;pct=100;fo=0;
This would mean “reject emails if they fail DKIM and/or SPF checks, don’t report, don’t apply to subdomains, do this for 100% of emails from my domain”.
If you’d like some reporting with your DMARC, you could use:
v=DMARC1;p=quarantine;fo=1;fo=d;ri=86400;rua=you@yourdomain.com;ruf=you@yourdomain.com;
What this record means is “quarantine emails if they fail SPF/DKIM checks, generate failure reports, generate forensic reports, send the reports once a day, send the aggregate reporst to you@yourdomain.com and send the forensic reports to you@yourdomain.com”.
If you’re not sure about your SPF and DKIM records being correct and you want to recieve reports about failed emails (to allow you to see if there’s a problem with this policy) you might consider using a record of this nature.
DMARC record syntax.
The DMARC record syntax is really the “language” of a DMARC record, or knowing which parts of the DMARC record are used to define your policy, and how.
Let’s break down a DMARC record to allow us to see which parts define what aspect of your DMARC policy.
v=DMARC1;
This means “this is a DMARC record” all DMARC record values start with this. It’s always present.
p=
This defines the policy for dealing with emails that fail DMARC authentication checks (SPF and DKIM). Available options are:
p=none;
This tells the recipient mail serve to take no specific action (either quarantine or reject). This would be used if a DMARC record is being used to generate reports only, rather than take an action should SPF and /or DKIM checks fail.
p=quarantine;
This tells receiving email servers that they should treat emails that fail SPF and /or DKIM checks as suspicious and may choose to deliver them to the recipient’s spam or junk folder, rather than the inbox. This is a stricter policy than “none” but still allows some flexibility in delivery.
p=reject;
This tells receiving email servers should reject emails that fail SPF and /or DKIM checks. These emails should not be delivered to the recipient’s inbox or any other folder, instead, the receiving server should reject these emails (bounce them back to the sender). This is the most stringent policy and is often used when the domain owner wants to prevent unauthorized use of their domain for sending emails.
sp=
This means “subdomain policy”. It works in the same was as p= (policy) but it’s applied to subdomains instead of domains. Available options are:
sp=none;
This means that no specific action should be taken for messages that fail SPF and /or DKIM checks when they originate from subdomains. The parent domain’s DMARC policy will be applied to these messages.
sp=reject;
This tells resipient mail servers to reject emails from sudomains of your domain, should SPF and /or DKIM checks fail. These emails should not be delivered to the recipient’s inbox or any other folder, instead, the receiving server should reject these emails (bounce them back to the sender).
sp=quarantine;
This tells resipient mail servers to quarentine emails from sudomains of your domain (put them in junk or spam folders), should SPF and /or DKIM checks fail.
adkim=
This specifies the alignment mode for the DKIM (strict or relaxed), so the available options are:
adkim=s;
This means “strict DKIM alignment”. In strict alignment mode, the DKIM signature’s d= (domain) value must exactly match the domain found in the “From” header of the email for DKIM alignment to pass. If there’s any mismatch, DKIM alignment fails.
adkim=r;
This means “relaxed DKIM alignment”. In relaxed alignment mode, DKIM alignment passes if the DKIM signature’s d= value is a subdomain of the domain found in the “From” header of the email. This allows for more flexibility in DKIM alignment, accommodating scenarios where emails are sent from subdomains.
aspf=s
This specifies the alignment mode for the SPF (strict or relaxed), and it works in the same way as adkim, just for SPF instead of DKIM, so the available options are:
aspf=s;
This means “strict SPF alignment”. In strict alignment mode, the domain specified in the SMTP envelope (often referred to as the “return-path” or “MAIL FROM” domain) must exactly match the domain found in the “From” header of the email for SPF alignment to pass.
aspf=r;
This means “relaxed SPF alignment”. In relaxed alignment mode, SPF alignment passes if the domain specified in the SMTP envelope is a subdomain of the domain found in the “From” header of the email.
pct=
This defines the percentage of messages subjected to filtering, based on the domain’s DMARC policy. The number after the = sign could be anything between 0 and 100.
This tag allows domain owners to gradually implement their DMARC policy without fully enforcing it immediately, which can be helpful for monitoring and gradual deployment.
If “pct=100” is specified, it means that 100% of messages failing the DMARC check should be subjected to the specified DMARC policy (specified by the “p=” tag).
If “pct=50” is specified, it means that only 50% of messages failing the DMARC check should be subjected to the specified DMARC policy, and the other 50% can be delivered as usual.
If “pct=0” is specified, it means that none of the messages failing the DMARC check should be subjected to the specified DMARC policy. This effectively puts the DMARC policy in monitoring mode, where no action is taken based on the policy.
fo=
This stands for “Failure Options.” It specifies how the message’s failure reports should be handled when the DMARC check fails.
The fo= tag has several possible values, allowing domain owners to customize their DMARC reporting.
fo=0;
This value indicates that no failure reports should be generated if the DMARC check fails.
fo=1;
This value indicates that failure reports should be generated and sent via email to the addresses specified in the “ruf” tag (Reporting URI for Forensic reports).
fo=d;
This value indicates that failure reports should be generated and sent via email to the addresses specified in the “rua” tag (Reporting URI for Aggregate reports) if the message fails DMARC, and additionally, forensic reports should be generated if the message fails DMARC and either SPF or DKIM checks.
fo=s;
This value is similar to “fo=d” but specifies that only the sender part of the message (including SPF, DKIM, and DMARC results) should be included in forensic reports, instead of the entire message.
These options provide domain owners with control over the level of detail and the type of reporting they receive when DMARC failures occur.
rf=
This defines the format of generated reports.
rf=afrf
This indicates that Authentication Failure Reporting Format (AFRF) should be used for generating failure reports. AFRF is a structured format defined by RFC 5965, which provides a standardized way of reporting authentication failures.
ri=
This means “reporting interval” and the value after the = is defined in seconds.
It specifies the interval (in seconds) at which aggregate reports should be sent by receivers to the addresses specified in the “rua” tag.
An “ri=86400;” would means that aggregate reports should be sent once every 86,400 seconds, which is equivalent to once per day.
rua=
This stands for “Reporting URI for Aggregate reports.” It specifies the URI (Uniform Resource Identifier) where aggregate reports about DMARC authentication results should be sent. Typically this is an email address, for example rua=you@yourdomain.com; although you can use multiple email addresses separatd by commas.
Aggregate reports provide statistical data about email authentication results, including information about which sending domains are authenticating using SPF and/or DKIM, how many messages pass or fail DMARC checks, and other relevant details.
ruf=
This stands for “Reporting URI for Forensic reports.” It specifies the URI (Uniform Resource Identifier) where forensic reports about failed DMARC authentication should be sent. Typically this is an email address, for example ruf=you@yourdomain.com; although you can use multiple email addresses separatd by commas.
Forensic reports provide detailed information about individual email messages that fail DMARC checks, including the headers and body of the message.
The main difference between “Reporting URI for Forensic reports” (ruf) and “Reporting URI for Aggregate reports” (rua) lies in the type of information they provide and the purpose they serve.
Forensic Reports (ruf):
- Forensic reports provide detailed information about individual email messages that have failed DMARC authentication checks.
- These reports typically include the full contents of the email, including headers and body, allowing domain owners to investigate the specifics of authentication failures.
- Forensic reports are valuable for diagnosing and troubleshooting issues related to email authentication failures, such as identifying the source of spoofed emails or misconfigured email servers.
Aggregate Reports (rua):
- Aggregate reports provide statistical data aggregated over a period of time (such as a day) about DMARC authentication results for a domain.
- These reports include summarized information about the volume of email sent, how many messages passed or failed DMARC checks, which sending sources were authenticated using SPF and/or DKIM, and other relevant statistics.
- Aggregate reports help domain owners monitor the overall health and effectiveness of their email authentication practices and identify trends or patterns in email authentication failures.
Forensic reports offer detailed information about individual failed authentication events, aiding in troubleshooting and identifying specific issues, while aggregate reports provide summarized statistical data about DMARC authentication results
In Conclusion:
- DMARC records are effectively an instructional (to recipient mail servers) and reporting (to you) mechanism.
- A DMARC policy is dictated by how you want recipeint mail servers to handle emails from your domain.
- DMARC policies instruct recipient mail servers how to handle emails from your domain if SPF and/or DKIM checks fail.
- You’ll need to have DKIM and SPF records in place for DMARC to function.
- The purpose of DKIM, SPF and DMARC is to minimise spam, and from address spoofing.