A DMARC record is part of your Domain Name System (DNS) record, which is responsible for routing Internet traffic. Additional information, such as your domain’s DMARC record—a text entry within the DNS record that informs the world about your email domain’s policy based on the specified SPF and DKIM protocols—can be included in the DNS.

Set up a DMARC record for each domain you want to monitor before you can start generating and visualizing DMARC data. You can use our DMARC generator if you need help setting up your DMARC record.

Prerequisites Before creating DMARC record

Before creating DMARC records it’s a good idea to test DKIM and SPF. 

• Creating an SPF record
• Creating a DKIM record

Create the record

DMARC is a system which allows email recipients to make better decisions depending on the reputation of the sender domain. It provides a platform for the sending side to publish policies to improve spam and phishing efficacy, essentially developing domain reputations. This aids in the provision of recommendations for dealing with messages that do not conform to the policies provided by the sender domain.

DMARC is aimed at:

• Reducing false negatives
• Providing authentication reports
• Applying sender policies at the receiving end
• Reducing phishing
• Being scalable

An SPF and DKIM record must be published on the transmitting domain before DMARC may be used. You can configure DMARC by adding policies to your domain’s TXT records once the SPF and DKIM records are in place (the same way in which you published your SPF and DKIM records). Your TXT record name should read something similar to “_dmarc.your_domain.com.” Please replace the “your_domain.com” with your own domain.

Since DMARC policies are published as TXT records, they specify what an email recipient should do when it receives non-aligned messages.

When establishing a TXT record, the name of a DMARC record is “_dmarc,” which generates a TXT record like _dmarc.mydomain.com or _dmarc.mydomain.net.

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”

DMARC Implementation

Since the DMARC configuration recognizes that scaling out the deployment all at once can be difficult for certain organisations, 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. Monitor your daily reports.

Once 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 the files and spamfeed is an important component of maintenance.

It is 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.

A conservative deployment cycle would resemble:

1. Monitor all.
2. Quarantine 1%.
3. Quarantine 5%.
4. Quarantine 10%.
5. Quarantine 25%.
6. Quarantine 50%.
7. Quarantine all.
8. Reject 1%.
9. Reject 5%.
10. Reject 10%.
11. Reject 25%.
12. Reject 50%.
13. Reject all.

Delete the percentages from your policies when you are about to finish the DMARC deployment so that the full action of “quarantine” and “reject” is now working at 100%. 

Conclusion

After you have published DMARC records, DMARC data will start to be created in the form of reports within a day or two, giving you insights into how your domains handle email. These reports are based on XML and might be difficult to read and comprehend for humans.

If you receive a lot of reports, you will quickly realize that manually posting them every day is not feasible. ProDMARC specializes in processing these reports and determining the measures that must be taken in order for DMARC to be distributed more simply throughout an organization. If you have not started your DMARC project yet, we encourage you to get in touch with our experts at ProDMARC for better guidance.
ProDMARC helps you implement email authentication with DMARC to stop fraudsters from misusing your domain. Get Started with top-class cybersecurity solutions for your business at Progist.