Table of contents
DMARC record example
Here is an example of a DMARC record:
v=DMARC1; p=reject; rua=mailto:dmarc.monitor@ar.folderly.com; ruf=mailto:dmarc.monitor@fr.folderly.com; fo=1; sp=quarantine;
What does the Folderly email test tool cover with regards to DMARC?
dmarc_dkim_alignment – DMARC DKIM From/Domain Alignment
dmarc_spf_alignment – DMARC SPF From/Domain Alignment
no_dmarc_record – DMARC DNS Record Existence
invalid_dmarc_version – Valid DMARC DNS Record version
invalid_dmarc_policy – Valid DMARC DNS Record policy
multiple_dmarc_records – Multiple DMARC DNS Record detection
dmarc_none_policy – DMARC DNS Record using the ‘none’ policy
Let’s break it down
“v=DMARC1;”
Version – This is the identifier that the receiving server looks for when it is scanning the DNS record for the domain it received the message from. If the domain does not have a txt record that begins with v=DMARC1, the receiving server will not run a DMARC check.
“p=reject;”
This tag indicates the policy action to be taken when an email fails DMARC authentication. In this case, it is set to "reject," which means that any email failing DMARC checks should be rejected and not delivered to the recipient's inbox.
p=none – This policy is often used when an organization is in the process of implementing DMARC. It doesn't instruct email receivers to take any specific action on emails that fail authentication. Instead, it's used for monitoring and collecting data on email authentication failures. The domain owner receives DMARC reports about these failures, allowing them to analyze and improve email authentication.
p=quarantine – With this policy, email receivers are instructed to place emails that fail DMARC checks into the recipient's spam or quarantine folder. These emails are not immediately rejected but are flagged as potentially suspicious. It's a more stringent policy than "None" as it can help protect recipients from potentially harmful emails.
p=reject – This is the strictest DMARC policy. It instructs email receivers to reject any email that fails DMARC checks, preventing it from reaching the recipient's inbox. This policy is designed to provide the highest level of protection against email spoofing and phishing, but it should be implemented carefully to avoid legitimate emails from being blocked.
The choice of DMARC policy depends on the domain owner's security requirements and email authentication setup. While "None" is often used initially for monitoring, many organizations eventually move to a "Quarantine" or "Reject" policy to enhance email security.
It's important to note that DMARC policies are not retroactive, meaning they apply only to emails sent after the DMARC record is published. Additionally, DMARC policies can impact legitimate email delivery, so they should be configured and tested carefully to avoid disrupting normal email flow. Monitoring and analyzing DMARC reports is crucial to ensure that legitimate senders aren't affected by the policy.
"rua=mailto:dmarc.monitor@ar.folderly.com"
The “rua” tag specifies the email address where aggregate DMARC reports should be sent. These reports provide information about email authentication results for the domain. In this case, reports are sent to "dmarc.monitor@ar.folderly.com."
"ruf=mailto:dmarc.monitor@fr.folderly.com"
The “ruf” tag specifies the email address where forensic DMARC reports should be sent. Forensic reports provide detailed information about individual email failures. They are typically sent to "dmarc.monitor@fr.folderly.com" in this configuration.
“fo=1;”
The “fo” (Failure Options) tag indicates the reporting options for failed email authentication. In this case, it is set to "1," which means that the domain owner requests that only failed authentication results be reported.
“sp=quarantine;”
The “sp ” tag specifies the policy action to be taken for subdomains of the domain. In this case, it is set to "quarantine," which means that for subdomains, emails failing DMARC checks should be placed in the recipient's quarantine or spam folder.
Keep in mind that:
DMARC policy is not just a quick email deliverability fix. You can improve your deliverability by deploying DMARC policy, but it is not a panacea.
The recommended DMARC policy to set for your domain depends on your organization's email security needs and your level of confidence in your SPF and DKIM setups. Here are some general recommendations:
"None" (p=none):
Use this policy initially if you are starting with DMARC.
It allows you to monitor email authentication failures without impacting email delivery.
Helps you collect data and gain insights into the sources of authentication failures.
"Quarantine" (p=quarantine):
Consider moving to this policy once you have a good understanding of your email traffic and have implemented SPF and DKIM correctly.
It instructs email receivers to place failed-authentication emails into the recipient's spam or quarantine folder.
It offers a moderate level of protection without outright blocking emails.
"Reject" (p=reject):
Implement this policy when you are confident in your email authentication setup and are prepared to block emails that fail DMARC checks.
It provides the highest level of protection against email spoofing and phishing.
Be cautious when transitioning to this policy to ensure that legitimate emails are not blocked
DMARC doesn’t protect inbound email streams. DMARC is not designed to protect inbound emails.
DMARC requires both SPF and DKIM to fail for it to act on a message.
As DMARC implementation becomes more mainstream, so will DMARC failures. Some applications or websites have features that allow users to send an email to themselves or a friend. The website or application often sends these emails from the user’s own email address (user@yahoo.com). Because of Yahoo’s DMARC policy, these messages will be rejected by any receiving server that does a DMARC check. This will also occur if an unauthorized user attempts to send mail for any domain that publishes a DMARC record with a p=”reject.”
See also