A DNS txt record published in your public DNS is known as a DMARC record. This is a DMARC record, as indicated by the DMARC version tag. The receiver would be able to recognize this as your DMARC record if they query your public DNS.
The policy tag is the DMARC policy you set for DMARC emails that fail SPF and DKIM authentication; in other words, it’s the action you recommend to your email recipients when they receive emails that you haven’t approved as legitimate. Depending on the results of your DMARC report study, you can choose from three different policies.
The email address to which you want DMARC aggregate reports sent is the DMARC aggregate tag. These reports are usually sent to a DMARC analyzer for further review. They provide information about the origins of your emails as well as the results of your SPF and DKIM authentication on the email receivers’ end. This data is used to classify and authenticate all valid email sending sources.
ProDMARC assists you in quickly generating DMARC records. You can generate a sample DMARC record with ProDMARC. You configure DMARC by applying policies to your domain’s DNS records in the form of TXT records once SPF and DKIM are in place (just like with SPF or DKIM).
DMARC was aimed at:
- Reducing false negatives
- Providing authentication reports
- Apply sender policies at the receiving end
- Reduce phishing
- Be scalable
1. Example
“v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@dmarcdomain.com”
In this scenario, the sender defines the policy as such that the receiver outright rejects all non-aligned messages and sends a report about the rejections to a specific email address. If the sender were to use the “quarantine” setting in the policy, it would look like:
“v=DMARC1;p=quarantine;pct=100;rua=mailto:postmaster@dmarcdomain.com”
and would request the action to quarantine on the receiving end of the message. In the next example, if a message claims to be from your domain.com and fails DMARC, no action is taken. Instead, these messages will then show up in your daily aggregate report sent to
“v=DMARC1; p=none; rua=mailto:postmaster@your_domain.com”
Here is a sample where the message fails DMARC, then quarantines it 5% of the time.
“v=DMARC1; p=quarantine; pct=5; rua=mailto:postmaster@your_domain.com”
In this sample, the policy is set to reject the message 100% of the time and send the daily report to the specified address of dmarc@your_domain.com.
“v=DMARC1; p=reject; rua=mailto:postmaster@your_domain.com, mailto:dmarc@your_domain.com”.
2. Common tags used in DMARC TXT records:
| TagName | Required | Purpose | Sample |
| v | required | Protocol Version | v=DMARC1 |
| p | required | Protocol for Domain | p=quarantine |
| pct | optional | % of message subjected to filtering | pct=20 |
| rua | optional | Reporting UTIof aggregate report | rua=mailto:postmstr@domain.com |
| sp | optional | Policy for subdomains of the domain | sp=r |
| ASPF | optional | Alignment mode for SPF | aspf=r |
Only the v (version) and p (policy) tags are required. Three possible policy settings are available:
- none – Take no action. Only log the affected messages in the daily report.
- quarantine – Mark affected messages as spam.
- reject – Cancel the message at the SMTP layer.
The study in which sender records are compared to SPF and DKIM signatures is known as DMARC alignment mode. There are two options for values: a relaxed “r” or a rigid “s.” Partial matches, such as subdomains, are allowed with some relaxation, whereas strict matches demand an exact match.
If you use the optional rua tag, make sure to include an email address where the regular updates will be sent.
3. Deploy your DMARC policy slowly
Since the DMARC specification recognizes that scaling out the deployment all at once can be difficult for certain organizations, there are some built-in methods for “throttling” the DMARC processing so that complete deployment can be achieved in stages over time.
The first step is to keep an eye on your traffic and reports. Assess the vulnerabilities (where messages are sent without being digitally signed or from invalid source IP addresses) and use SPF and DKIM records to address them.
As you become more comfortable with the findings from your regular aggregate reports, you will adjust the action on your policies to start quarantining. You can do this by using DMARC to change your TXT record to use the “quarantine” action. Keep an eye on your daily reports.
After you’ve been tracking your traffic and regular reports for a while and are certain that the sources seen sending traffic on behalf of your domain are all digitally signed, you can proceed to the next phase, which is modifying the policy to use the “reject” tag to completely deploy DMARC. Monitoring your reports and your spam feed is an essential part of maintenance for DMARC compliance.
It’s also worth noting that the pct tag, which is optional, can be used to sample your DMARC implementation in increments. Since 100% is the norm, setting “pct=20” in your DMARC TXT record causes one-fifth of all messages affected by the policy to receive the disposition rather than all of them. When you want to quarantine and reject mail, this setting is particularly useful. Start with a lower percent to begin with, and increase it every few days.
When you are ready to complete the DMARC setup, remove the percentages from your policies so that the full action of “quarantine” and “reject” is now functioning at 100%. As always, monitor your daily reports.
4. Use a user-friendly DMARC analyzing software
ProDMARC is a user-friendly DMARC email protection solution that acts as your expert guide to help you move as quickly as possible to a reject policy. ProDMARC is a SaaS solution that enables organizations to handle complex DMARC deployments with ease. Across all email networks, the solution offers 360-degree visibility and governance. Contact us for the best email authentication solutions.