Table of contents
DMARC record example
Here is an example of a DMARC record–this is SendGrid’s DMARC record:
v=DMARC1\;p=none\;rua=mailto:dmarc@sendgrid.com\;ruf=mailto:dmarc@sendgrid.com\;rf=afrf\;pct=100
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=none”
Policy – The policy you select in your DMARC record will tell the participating recipient email server what to do with mail that doesn’t pass SPF and DKIM, but claims to be from your domain. In this case, the policy is set to “none.” There are 3 types of policies you can set:
p=none – Tell the receiver to perform no actions against unqualified mail, but still send email reports to the mailto: in the DMARC record for any infractions.
p=quarantine – Tell the receiver to quarantine unqualified mail, which generally means “send this directly to the spam folder.
”p=reject – Tell the receiver to completely deny any unqualified mail for the domain. With this enabled, only mail that is verified as 100% being signed by your domain will even have a chance at the inbox. Any mail that does not pass is denied— not bounced—so there’s no way to catch false positives.
"rua=mailto:dmarc@folderly.com"
This part tells the receiving server where to send aggregate reports of DMARC failures. Aggregate reports are sent daily to the administrator of the domain that the DMARC record belongs to. They include high-level information about DMARC failures but do not provide granular detail about each incident. This can be any email address you choose.
"ruf=mailto:dmarc@folderly.com"
This part tells the receiving server where to send forensic reports of DMARC failures. These forensic reports are sent in real-time to the administrator of the domain that the DMARC record belongs to and contain details about each individual failure. This email address must be from the domain that the DMARC record is published for.
“rf=afrf”
Reporting format. This part tells the receiving server what kind of reporting the policyholder wants. In this case rf=afrf means aggregate failure reporting format.
“pct=100”
Percent – This part tells the receiving server how much of their mail should be subjected to the DMARC policy’s specifications. You can choose any number from 1-100. In this case, if the p= was set to reject, 100% of the mail that fails DMARC would be rejected.
There are a number of other mechanisms that can be included in a DMARC record. A few notable ones include:
“sp=” This part would tell the receiving server whether or not to apply the DMARC policy to sub domains.
“adkim=” This sets the DKIM alignment. It can either be set to “s” for strict or “r” for relaxed. Strict means the DKIM portion of DMARC authentication will only pass if the d= field in the DKIM signature EXACTLY matches the from domain. If it is set to relaxed, messages will pass the DKIM portion of the DMARC authentication if the DKIM d= field matches the root domain of the from address.
“ri=” This sets the interval for how often you want to receive aggregate reports about DMARC failures.
Keep in mind that:
DMARC is not a quick deliverability fix. Just deploying a DMARC policy is not just a quick email deliverability fix. By deploying and enforcing a DMARC policy, your deliverability can improve; however, this is not a guarantee.
Immediately enforcing a reject policy is not a good idea. We strongly discourage enforcing a reject policy when starting. When companies encounter a phishing attack, they immediately lock down their email channel by placing a DMARC record and enforcing a 100% p=reject policy. This is effective in blocking phishing attacks. However, it will also lead to legitimate emails being lost. DMARC Analyzer advises to start with a p=none policy and monitor the results. This process can take 1-12 months.
DMARC does not 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