What is a DMARC record and How to Set it Up?

What is DMARC

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is an email-validation system designed to protect your domain from unauthorized use, such as email spoofing. The purpose of DMARC is to enable email domain owners to protect their domain from being misused for email phishing scams, email spoofing, and other cybercrimes. It builds on two existing protocols, SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail), to improve and authenticate the legitimacy of an email.

Understanding DMARC

DMARC enhances the email authentication process by leveraging the established SPF and DKIM protocols. The authentication process is a series of checks that an email goes through to verify its legitimacy before it reaches the recipient’s inbox. This process is crucial in determining whether an email is genuinely from the sender it claims to be from or if it’s a potential threat.

SPF and DKIM play pivotal roles in this authentication process. SPF allows domain owners to define which mail servers are authorized to send mail on behalf of their domain. When an email is received, the recipient’s server checks the SPF record to confirm that the email originated from a listed server. This helps to prevent spammers from sending emails with a forged “From” address that appears to be from your domain.

DKIM adds an additional layer of security by attaching a digital signature to outgoing emails. This signature is verified against a public cryptographic key that is published in the domain’s DNS records. The presence of a valid DKIM signature indicates that the email has not been altered in transit, providing a form of integrity check in addition to the SPF‘s authorization check.

DMARC ties these two protocols together by specifying a policy that the domain owner wants email receivers to follow when handling emails that fail SPF and DKIM checks. It also specifies how the domain owner wants to be informed of these failures, allowing them to take action if necessary. The DMARC policy is communicated through a TXT record in the domain’s DNS and is checked by the recipient’s server after SPF and DKIM evaluations.

The email authentication process works as follows: when an email is sent, the sending server attaches a DKIM signature and sends the email on its way. The recipient’s server retrieves the SPF record to verify the sending server’s authorization and checks the DKIM signature to ensure the email’s integrity. If both checks pass and align with the domain stated in the email’s “From” header, the email is considered authenticated. If either check fails or there is a misalignment, the recipient’s server refers to the DMARC policy to decide whether to deliver, quarantine, or reject the email.

By setting a DMARC policy, domain owners can instruct receiving servers to quarantine or reject unauthenticated emails, thereby reducing the likelihood of their domain being used for email-based threats. Moreover, the reporting aspect of DMARC provides insights into both legitimate and unauthorized email activities, enabling domain owners to refine their email security measures over time.

The Structure of a DMARC Record

A DMARC record is a TXT record in your domain’s DNS zone that follows a specific syntax. This syntax includes several tags that define the DMARC policy and how it should be enforced.

Key Parameters of a DMARC Record

The “p” tag in a DMARC record indicates the policy that should be applied to emails that fail DMARC checks. The possible values for this tag are:

• none: The domain owner requests no specific action be taken on mail that fails the DMARC check. This setting is typically used for monitoring and collecting data without impacting email delivery.
• quarantine: Emails that fail the DMARC check will be treated as suspicious. Depending on the recipient’s email server, these messages may end up in the SPAM folder.
• reject: This policy instructs the receiving email server to reject emails that fail the DMARC check outright, preventing them from being delivered to the recipient’s inbox.

The “sp” tag specifies the policy for subdomains and can take the same values as the “p” tag. If the “sp” tag is not specified, the policy specified in the “p” tag will apply to subdomains as well.

The “rua” tag is used to specify an email address where aggregate reports of DMARC failures are sent, while the “ruf” tag is for forensic reports that provide more detailed information about individual failures. These reports are crucial for understanding and improving your email authentication setup.

The “pct” tag defines the percentage of messages that are subjected to the DMARC policy, which is useful for gradually implementing policy changes. For example, “pct=20” means that only 20% of failing emails will be acted upon according to the specified DMARC policy.

The “adkim” and “aspf” tags define the alignment mode for DKIM and SPF, respectively. The possible values are “r” for relaxed and “s” for strict. Relaxed alignment allows partial matches (such as subdomains), while strict alignment requires an exact match between the domain in the header and the domain in the SPF/DKIM records.

For example, a DMARC record might look like this:

v=DMARC1; p=quarantine; sp=none;
rua=mailto:dmarc-reports@example.com;
ruf=mailto:dmarc-failures@example.com; pct=100; adkim=r; aspf=r;

This record requests that emails failing DMARC checks be quarantined, with no specific policy for subdomains, instructs to send aggregate reports to dmarc-reports@example.com, send failure reports to dmarc-failures@example.com, applies the policy to 100% of failing messages, and uses relaxed alignment for both DKIM and SPF.

How to Set Up and Implement a DMARC Record in DNS

To set up a DMARC record, you’ll need to create a TXT DNS record in your domain’s DNS zone. Most hosting providers offer a DNS Zone Editor feature, allowing you to control the DNS records for your domain. It’s important to remember that DNS modifications must be made from the account that holds the authoritative DNS zone for your domain. No matter which hosting service you use, your domain must be pointed by Name servers to that location. Only this way the modifications to the DNS zone will actually have any effect.

If your domain’s DNS is managed with SiteGround, a basic DMARC record was created automatically for your domain in the domain’s DNS zone when you created your website. To change it, follow these steps:

1. Log in to your SiteGround Client Area and go to the Site Tools for the website you want to manage.
2. Navigate to Domain > DNS Zone Editor.
   

   

3. Select your domain name from the drop down.
4. In the Manage DNS Records section, find the existing DMARC record. It should be a TXT type record, that starts with “v=DMARC1”.
5. Click the pencil icon next to it to edit it.
6. In the popup that appears, in the Value field, enter your DMARC record, such as “v=DMARC1; p=none; rua=mailto:your-email@example.com;” replacing your-email@example.com with the email address where you want to receive reports.
   

   

7. Click on the Create button to add the record.

After adding the DMARC record, it may take some time for the changes to propagate across the internet before they have effect.

Best Practices for DMARC Records

When implementing DMARC records, it’s important to start with a policy of “none” to monitor how your emails are being handled without affecting their delivery. This initial monitoring phase allows you to collect data on your email streams and ensure that legitimate emails are authenticated correctly. Gradually, you can move to more restrictive policies like “quarantine” or “reject” as you become more confident in your email authentication processes.

Regularly review your DMARC reports to identify any configuration issues or unauthorized use of your domain. Keep your “rua” and “ruf” tags up to date to ensure you’re receiving these valuable reports. Additionally, educate your team about the importance of DMARC and ensure that all email senders within your organization comply with SPF and DKIM standards.

Conclusion

Implementing a DMARC record is a critical step in securing your email communications and protecting your domain from abuse. By setting up a DMARC policy, you can specify how email receivers should handle emails that fail authentication checks, thus preventing phishing attacks and domain spoofing. With the rise of email-based threats, adopting DMARC is not just recommended; it’s becoming a necessity for responsible domain management.

DMARC FAQs

1. What happens if I don’t set up a DMARC record for my domain? Without a DMARC record, you have no control over how receiving mail servers handle emails that appear to come from your domain but fail SPF or DKIM checks. This could lead to your domain being used in phishing attacks without your knowledge.
2. How often should I check my DMARC reports? It’s a good practice to check your DMARC reports regularly, at least once a week when you’re first implementing DMARC. As you become more familiar with the patterns in your email traffic, you might adjust the frequency.
3. Can DMARC prevent all types of email spoofing? While DMARC significantly reduces the risk of direct domain spoofing, it doesn’t prevent all types of email spoofing, such as ‘cousin’ domain attacks or display name deception. It should be used as a part of a comprehensive email security strategy, not as a sole method of defense.
4. Is there a risk of legitimate emails being rejected with a DMARC “reject” policy? Yes, if legitimate emails do not pass SPF or DKIM checks, they could be rejected. That’s why it’s crucial to start with a “none” policy and ensure that your legitimate email streams are properly authenticated before moving to a “reject” policy.
5. Do all email service providers support DMARC? Most major email service providers support DMARC, but there may be some that do not fully implement the protocol. Thus not all servers that handle the emails for the recipients of your messages may follow the instructions you have configured in the DMARC record.