What Is DMARC? How Does DMARC Work?

May 2, 2024

Table of Contents

Introduction

In today’s digital landscape, email has become an indispensable communication tool for individuals and organisations. However, with the increasing reliance on email comes a growing concern for email security. Cybercriminals often exploit vulnerabilities in email systems to carry out malicious phishing attacks, email spoofing, and domain impersonation, which can lead to significant financial losses and damage to an organisation’s reputation.

To combat these threats, organisations must implement robust email authentication measures. One such measure is DMARC (Domain-based Message Authentication, Reporting & Conformance), a powerful protocol that helps protect domains from unauthorised use and email spoofing.

In this comprehensive guide, we will explore the world of DMARC, its functionality, components, and best practices for implementation. Whether you are an IT professional tasked with securing your organisation’s email infrastructure or a business owner looking to safeguard your domain’s reputation, this guide will provide you with the knowledge and tools necessary to implement DMARC and effectively enhance your email security posture.

By the end of this article, you will clearly understand how DMARC works, its benefits, and how to set it up for your domain. You will also learn about advanced DMARC considerations and how to leverage DMARC reporting to monitor and troubleshoot email authentication issues.

The History of DMARC

DMARC (Domain-based Message Authentication, Reporting & Conformance) was created to combat the growing problem of email spoofing and phishing attacks. While SPF and DKIM laid the groundwork for email authentication, email senders and receivers still lacked effective standardisation and cooperation in implementing these mechanisms.

In 2010, a group of leading email service providers, financial institutions, and technology companies formed the DMARC.org consortium. The founding members included Google, Microsoft, Yahoo!, PayPal, AOL, Agari, Cloudmark, eCert, and Return Path. They aimed to create a standardised framework to build upon the existing SPF and DKIM protocols to provide a more comprehensive and reliable email authentication solution.

The DMARC specification was first published in 2012 as a draft standard. It outlined a mechanism for email senders to specify their email authentication policies and for email receivers to provide feedback on the authentication results. This collaborative approach aimed to help email senders improve their authentication practices and enable email receivers to make more informed decisions about the trustworthiness of incoming emails.

Since its introduction, DMARC has gained widespread adoption among organisations of all sizes and industries. Major email providers like Google, Microsoft, and Yahoo! have implemented DMARC support, and many governments, financial institutions, and large enterprises have embraced DMARC as a critical component of their email security strategies.

Over the years, the DMARC specification has undergone several updates and improvements based on feedback from the email community. The DMARC.org consortium continues to enhance the standard and promote its adoption worldwide.

One notable milestone in the history of DMARC was the release of the BIMI (Brand Indicators for Message Identification) specification in 2019. BIMI builds upon DMARC to provide a way for organisations to display their verified brand logos alongside authenticated emails in supporting email clients. This visual indicator helps enhance brand recognition and trust for recipients.

Today, DMARC has become an essential tool in the fight against email fraud and phishing. It has helped organisations protect their brands, reduce the impact of email-based attacks, and improve email communication’s overall security and trustworthiness.

As email threats continue to evolve, the DMARC community remains committed to refining and expanding the standard to meet the ever-changing needs of email senders and receivers worldwide.

Understanding DMARC For Email

DMARC is an email authentication protocol that builds upon two existing mechanisms: SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). It provides domain owners with a way to protect their domain from unauthorised use, mitigate email spoofing, and gain visibility into how their domain is being used in the email ecosystem.

At its core, DMARC allows domain owners to publish a policy instructing email receivers on handling messages that fail SPF and DKIM authentication. By publishing a DMARC record in the domain’s DNS (Domain Name System), domain owners can specify whether they want unauthenticated messages to be delivered, quarantined, or rejected outright.

First, we must examine and understand DMARC’s two key components, SPF and DKIM, to fully grasp how it works.

SPF Record (Sender Policy Framework)

SPF is an email authentication mechanism that allows domain owners to specify which email servers are authorised to send emails on behalf of their domain. By publishing an SPF record in the domain’s DNS, domain owners can list their legitimate email servers’ IP addresses or hostnames.

When an email is received, the receiving server performs an SPF check by comparing the sender’s IP address against the SPF record of the domain claimed in the email’s “From” address. If the IP address matches one of the authorised servers listed in the SPF record, the email passes SPF authentication. If not, the email fails SPF authentication, indicating that it may be a spoofed or fraudulent message.

SPF helps prevent email spoofing by ensuring that only authorised servers can send emails on behalf of a domain. However, it has limitations, such as not protecting against header modifications or forwarded messages.

DKIM Record (DomainKeys Identified Mail)

DKIM is another email authentication mechanism that uses cryptographic signatures to verify the authenticity and integrity of email messages. When domain owners enable DKIM, their email servers sign outgoing messages with a private key. The corresponding public key is published in the domain’s DNS as a DKIM record.

When an email is received, the receiving server retrieves the DKIM record from the sender’s domain and uses the public key to verify the signature. If the signature is valid, it proves that the email originated from the claimed domain and hasn’t been modified in transit.

DKIM helps establish trust in email communication by ensuring that messages haven’t been tampered with and that they come from the domain they claim to be from. However, like SPF, DKIM alone is insufficient to prevent all email spoofing forms.

By combining SPF, DKIM, and DMARC, domain owners can establish a comprehensive email authentication strategy that leverages the strengths of each mechanism while providing a clear policy for handling messages that fail authentication.

Benefits of DMARC

Implementing DMARC offers several significant benefits for organisations looking to secure their email communication:

Protecting Brand Reputation: By preventing attackers from spoofing your domain, DMARC helps maintain the trust and credibility associated with your brand. This reduces the risk of your customers and partners falling victim to fraudulent emails that appear to come from your organisation.
Reducing Phishing and Spam: DMARC makes it harder for attackers to use your domain in phishing and spam campaigns. When receiving email servers, check for DMARC alignment and apply your DMARC policy; they can identify and filter out unauthorised emails, reducing the chances of these malicious messages reaching end-users inboxes.
Improving Email Deliverability: By demonstrating your commitment to email authentication and security, DMARC can enhance your email deliverability. Receiving email servers are more likely to trust and deliver emails from domains with properly implemented DMARC, reducing the chances of your legitimate emails being marked as spam.
Gaining Visibility into Email Traffic: DMARC reporting provides valuable insights into your email ecosystem. By analysing DMARC reports, you can identify legitimate email sources, detect misconfigurations or unauthorised use of your domain, and track the effectiveness of your email authentication policies.
Meeting Compliance Requirements: Many industry regulations and standards, such as the Payment Card Industry Data Security Standard (PCI DSS) and the National Institute of Standards and Technology (NIST) guidelines, recommend or require the use of email authentication mechanisms like DMARC. By implementing DMARC, you can demonstrate compliance with these requirements and strengthen your overall security posture.
Fostering Collaboration and Trust: DMARC encourages collaboration among email senders and receivers to improve email authentication practices. By participating in the DMARC ecosystem, you contribute to the overall security and trust of the global email infrastructure, benefiting both your organisation and the wider email community.
Mitigating Financial Losses: By reducing the risk of successful phishing attacks and email fraud, DMARC can help prevent financial losses associated with business email compromise (BEC) and other email-based scams. This is particularly important for organisations that regularly process financial transactions or handle sensitive customer data.

Implementing DMARC is a critical step in securing email communication, protecting your organisation’s reputation, and fostering trust with your customers and partners. By understanding and leveraging DMARC’s benefits, you can build a strong case for its adoption and gain stakeholders’ support.

DMARC Record Anatomy

A DMARC record is a TXT record published in your domain’s DNS. It contains the DMARC policy and other configuration settings that tell email receivers how to handle messages that fail DMARC authentication. Let’s break down the components of a DMARC record and see how they work together.

DMARC Record Format

A DNS DMARC record follows a specific format and consists of key-value pairs separated by semicolons. Here’s an example of a DMARC record:

v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=r; aspf=r; pct=100; ri=86400

Let’s explain each part of the record:

v=DMARC1: This specifies the DMARC version. Currently, the only valid value is “DMARC1”.
p=reject: This is the DMARC policy, which can be set to “none”, “quarantine”, or “reject”. It instructs email receivers on how to handle messages that fail DMARC authentication.
rua=mailto:[email protected]: This specifies the email address where aggregate reports should be sent. Aggregate reports provide a daily summary of DMARC authentication results.
ruf=mailto:[email protected]: This specifies the email address where forensic reports should be sent. Forensic reports contain details about individual messages that failed DMARC authentication.
fo=1: This is the failure reporting option, which can be set to “0,” “1,” or “d.” It determines when forensic reports should be generated (e.g., for all failures, failures with misaligned identifiers, or failures with malformed DMARC records).
adkim=r: This specifies the DKIM alignment mode, which can be set to “r” (relaxed) or “s” (strict). Relaxed alignment allows subdomains to match, while strict alignment requires an exact match.
aspf=r: This specifies the SPF alignment mode, which is similar to DKIM alignment.
pct=100: This is the percentage of messages to which the DMARC policy should be applied. It can be used for gradual rollout, with values ranging from 1 to 100.
ri=86400: This is the reporting interval specified in seconds. It determines how frequently aggregate reports should be sent.

Publishing a DMARC Record

To publish a DMARC record, you need to add it as a TXT record in your domain’s DNS. The record should be named “_dmarc” followed by your domain name. For example, if your domain is “example.com”, the DMARC record should be published at “_dmarc.example.com”.

Here’s an example of how the DMARC record would look in your DNS zone file:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=r; aspf=r; pct=100; ri=86400"

Once you’ve added the DMARC record to your DNS, email receivers that support DMARC can retrieve the record and apply your DMARC policy to incoming messages.

It’s important to note that while the example above includes all the common DMARC tags, not all of them are mandatory. The minimum required tags for a valid DMARC record are “v” and “p”. The other tags can be added based on your specific requirements and preferences.

DMARC Policies

DMARC policies are the cornerstone of the DMARC framework. They allow domain owners to specify how email receivers should handle messages that fail SPF and DKIM authentication. By publishing a DMARC policy in the domain’s DNS, domain owners can instruct email receivers to deliver, quarantine, or reject unauthenticated messages.

There are three main DMARC policies that domain owners can choose from:

None Policy

The “none” policy is the most permissive DMARC policy. When a domain publishes a “none” policy, it instructs email receivers to deliver all messages, regardless of whether they pass or fail SPF and DKIM authentication. However, the receiving server will still generate DMARC reports, allowing the domain owner to monitor email traffic and identify potential authentication issues.

The “none” policy is often used during the initial stages of DMARC implementation. It allows domain owners to gather data on their email ecosystem without impacting email deliverability. By analysing DMARC reports generated under the “none” policy, domain owners can identify legitimate email sources and troubleshoot authentication problems before moving to a stricter policy.

Quarantine Policy

The “quarantine” policy is a more protective DMARC policy. When a domain publishes a “quarantine” policy, it instructs email receivers to treat messages that fail SPF and DKIM authentication as suspicious. Typically, these messages are placed in the recipient’s spam folder or quarantined for further review.

The “quarantine” policy balances email deliverability and security. It allows legitimate emails that pass authentication to be delivered while mitigating the risk of spoofed or fraudulent messages reaching recipients’ inboxes.

Domain owners can gradually transition from a “none” policy to a “quarantine” policy once they have addressed any authentication issues identified during the initial monitoring phase. This gradual approach helps minimise the risk of legitimate emails being incorrectly quarantined.

Reject Policy

The “reject” policy is the most strict DMARC policy. When a domain publishes a “reject” policy, it instructs email receivers to reject any messages that fail SPF and DKIM authentication outright. Rejected messages are typically bounced back to the sender with a failure notification.

The “reject” policy provides the highest level of protection against email spoofing and domain impersonation. Rejecting all unauthenticated messages ensures that only legitimate emails from authorised sources are delivered to recipients.

However, implementing a “reject” policy requires careful planning and preparation. Domain owners must ensure that all legitimate email sources are properly authenticated and aligned with DMARC before enabling a “reject” policy. Failure to do so may result in legitimate emails being rejected, causing disruption to email communication.

It’s recommended that the domain owner gradually move from a “quarantine” policy to a “reject” policy once they have established confidence in their email authentication setup and minimised false positives.

In addition to selecting the appropriate DMARC policy, domain owners can also specify reporting options in their DMARC record. DMARC reporting provides valuable insights into email traffic and authentication results, helping domain owners monitor and troubleshoot their email ecosystem.

DMARC Reporting

DMARC reporting is an important component of the DMARC framework. It provides domain owners with valuable insights into their email ecosystem, allowing them to monitor email traffic, identify authentication issues, and detect potential email spoofing attempts.

When a domain publishes a DMARC record, it can specify reporting options instructing email receivers to send DMARC reports back to the domain owner. These reports contain information about email messages that claim to originate from the domain, including authentication results and message metadata.

There are two types of DMARC reports:

Aggregate Reports

Aggregate reports provide a high-level overview of a domain’s email traffic over a specified period, typically 24 hours. These reports are generated by email receivers and sent to the email address specified in the domain’s DMARC record.

An aggregate report contains statistical data about the email messages that claimed to originate from the domain, including:

The number of messages received
The number of messages that passed SPF and DKIM authentication
The number of messages that failed SPF and DKIM authentication
The DMARC policy action applied to failed messages (none, quarantine, or reject)

Aggregate reports are generated in an XML format and can be parsed using DMARC report analysis tools. By analysing aggregate reports, domain owners can gain insights into the overall health of their email authentication setup, identify trends, and detect anomalies that may indicate email spoofing attempts.

Example Aggregate Report

Aggregate reports provide a daily summary of DMARC authentication results for your domain. They are sent in an XML format and contain valuable data to help you monitor your DMARC implementation and identify potential issues. Here’s an example of an aggregate report:

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
    <report_metadata>
        <org_name>Example Mail Receiver</org_name>
        <email>[email protected]</email>
        <report_id>1234567890</report_id>
        <date_range>
            <begin>1622505600</begin>
            <end>1622591999</end>
        </date_range>
    </report_metadata>
    <policy_published>
        <domain>example.com</domain>
        <adkim>r</adkim>
        <aspf>r</aspf>
        <p>reject</p>
        <pct>100</pct>
    </policy_published>
    <record>
        <row>
            <source_ip>192.0.2.1</source_ip>
            <count>100</count>
            <policy_evaluated>
                <disposition>none</disposition>
                <dkim>pass</dkim>
                <spf>pass</spf>
            </policy_evaluated>
        </row>
        <identifiers>
            <header_from>example.com</header_from>
        </identifiers>
        <auth_results>
            <dkim>
                <domain>example.com</domain>
                <result>pass</result>
            </dkim>
            <spf>
                <domain>example.com</domain>
                <result>pass</result>
            </spf>
        </auth_results>
    </record>
</feedback>

Let’s break down the key parts of the aggregate report:

<report_metadata>: This section contains information about the report itself, including the email receiver that generated the report, the email address where the report was sent, a unique report ID, and the date range covered by the report.
<policy_published>: This section includes the DMARC policy published for the domain when the report was generated. It shows the DKIM and SPF alignment modes, the policy (p=reject), and the percentage of messages the policy was applied to (pct=100).
<record>: This section contains the actual authentication results for the messages received during the reporting period. Each <row> represents a unique combination of the sending IP address and the DMARC authentication results.
- <source_ip>: The server’s IP address that sent the messages.
- <count>: The number of messages received from the source IP address.
- <policy_evaluated>: The DMARC policy evaluation results for the messages, including the disposition (none, quarantine, or reject) and the DKIM and SPF authentication results.
- <identifiers>: The domain identified in the “From” header of the messages.
- <auth_results>: The detailed DKIM and SPF authentication results for the messages.

By analysing the data in aggregate reports, you can gain insights into your email traffic, identify sources of authenticated and unauthenticated messages, and troubleshoot any DMARC failures.

Forensic Reports

Forensic reports, or failure reports, provide detailed information about individual email messages that failed DMARC authentication. These reports are triggered when an email fails SPF or DKIM authentication and the domain’s DMARC policy is set to “quarantine” or “reject”.

A forensic report includes the full content of the failed email message, including headers and body. This detailed information allows domain owners to investigate and troubleshoot specific authentication failures.

Forensic reports are sent in real-time to the email address specified in the domain’s DMARC record. Due to the sensitive nature of the information in these reports, you must ensure that the recipient’s email address is secure and properly monitored.

Domain owners can comprehensively understand their email authentication landscape by leveraging aggregate and forensic reports. Regular monitoring and analysis of DMARC reports enable domain owners to:

Identify and remediate SPF and DKIM authentication issues
Detect and mitigate email spoofing attempts
Ensure the effectiveness of their DMARC policy
Maintain a secure and trustworthy email ecosystem

It’s important to note that DMARC reporting is not limited to a domain’s top-level domain. Subdomains can also publish their own DMARC records and specify separate reporting options, allowing for granular monitoring and control over email authentication.

Implementing DMARC Enforcement

Implementing DMARC for your domain is crucial in securing your email ecosystem and protecting your brand from email spoofing and domain impersonation. While the process may seem daunting initially, breaking it down into manageable steps can help ensure a smooth and successful implementation.

Preparing Your Infrastructure

Before implementing DMARC, you must lay a solid foundation by ensuring your email infrastructure is properly set up with SPF and DKIM. These two authentication mechanisms form the basis of DMARC and are necessary for it to function effectively.

Start by identifying all legitimate email sources for your domain, including your own mail server, third-party email service providers, and any other systems that send email on behalf of your domain. Ensure that each source has a valid SPF record and is properly configured for DKIM signing.

If you haven’t already implemented SPF and DKIM, now is the time to do so. Contact us if you need help.

Gradual Rollout

Once your SPF and DKIM foundations are in place, it’s time to start your DMARC implementation. It’s highly recommended to take a phased approach, gradually increasing the strictness of your DMARC policy over time. This gradual rollout allows you to monitor and troubleshoot any issues arising without disrupting email deliverability.

Start publishing a DMARC record for your domain with a “none” policy. This policy instructs email receivers to perform DMARC checks but not take any action on failed messages. Instead, the receivers will generate aggregate reports and send them to the email address specified in your DMARC record.

Monitor these reports closely for a period of time, typically a few weeks, to gain insights into your email traffic and identify any authentication issues. Look for discrepancies between your legitimate email sources and those reported in the aggregate reports.

Once you have addressed any identified issues and feel confident in your SPF and DKIM setup, you can gradually move to a “quarantine” policy. This policy instructs receivers to quarantine messages that fail DMARC authentication, typically by placing them in the recipient’s spam folder.

Continue monitoring DMARC reports under the “quarantine” policy, and when you are ready, transition to a “reject” policy. The “reject” policy provides the highest level of protection by instructing receivers to reject any messages that fail DMARC authentication outright.

Monitoring and Adjusting

DMARC implementation is not a one-time event but rather an ongoing process. It’s crucial to continuously monitor your DMARC reports and adjust your setup as needed.

Review your aggregate reports regularly to identify any new legitimate email sources or authentication issues that may have arisen. Investigate and resolve any anomalies promptly to maintain the effectiveness of your DMARC implementation.

Keep an eye on your email deliverability rates and feedback from recipients. If you notice a sudden increase in bounced or quarantined messages, it may indicate an authentication issue that needs to be addressed.

Consider using DMARC monitoring and analysis tools to streamline the process of reviewing reports and identifying potential problems. These tools can help automate the parsing and analysis of DMARC reports, providing actionable insights and alerts.

Remember, implementing DMARC is a collaborative effort involving your IT team, email service providers, and any third parties that send emails on your behalf. Maintain open communication and coordination with these stakeholders to ensure a smooth and successful DMARC rollout.

DMARC Alignment

DMARC alignment is an important concept in the DMARC framework. It refers to the consistency between the domain used in an email’s “From” header and the SPF and DKIM authentication domain. Proper alignment is necessary for DMARC to function effectively and accurately determine the legitimacy of an email message.

Identifier Alignment

DMARC relies on two types of identifier alignment: SPF alignment and DKIM alignment.

SPF alignment requires that the domain used in an email’s “From” header matches the domain used in the SPF check. In other words, the domain claiming responsibility for the email must be the domain that authorised the sending IP address through its SPF record.

DKIM alignment, on the other hand, requires that the domain used in the “From” header matches the domain used in the DKIM signature. This ensures that the domain claiming responsibility for the email is the same domain that has signed the email with its DKIM private key.

DMARC allows for two levels of identifier alignment: strict and relaxed.

Strict alignment requires an exact match between the “From” and SPF/DKIM domains.
Relaxed alignment allows for subdomains to match. For example, if the “From” domain is “example.com,” a relaxed alignment would consider “mail.example.com” as a match.

The alignment record specifies the DMARC mode and can be set differently for SPF and DKIM. It’s common to start with relaxed alignment during the initial stages of DMARC implementation and gradually move towards strict alignment as the email infrastructure matures and is properly aligned.

Example of DMARC Alignment

To illustrate the concept of DMARC alignment, let’s consider an example:

Suppose you receive an email with the following characteristics:

From: [email protected]
SPF: Pass (IP address authorised by example.com’s SPF record)
DKIM: Pass (Signed by mail.example.com)

Now, let’s examine the alignment for both SPF and DKIM:

SPF Alignment:
- The “From” domain (example.com) matches the domain used in the SPF check (example.com).
- This satisfies both strict and relaxed SPF alignment.
DKIM Alignment:
- The “From” domain (example.com) does not exactly match the domain used in the DKIM signature (mail.example.com).
- This satisfies relaxed DKIM alignment but fails strict DKIM alignment.

In this example, if the DMARC record, for “example.com”, specifies relaxed alignment for both SPF and DKIM (aspf=r; adkim=r), the email would pass DMARC alignment. However, if the DMARC record specifies strict alignment for DKIM (aspf=r; adkim=s), the email would fail DMARC alignment due to the mismatch between the “From” domain and the DKIM signing domain.

By understanding and properly configuring DMARC alignment, you can ensure that your email authentication mechanisms work together effectively to protect your domain from spoofing and unauthorised use.

Subdomain Alignment

DMARC alignment also extends to subdomains. By default, a DMARC policy published at the organisational domain level (e.g., “example.com”) does not apply to its subdomains (e.g., “newsletter.example.com” or “support.example.com”).

To ensure comprehensive protection across your email ecosystem, it’s important to consider subdomain alignment. You can achieve this by either:

Publishing separate DMARC records for each subdomain, allowing for granular control and monitoring.
Specify a policy for all subdomains using the “sp” tag in the organisational domain’s DMARC record.

When using the “sp” tag, you can set a policy for subdomains that is different from the one specified for the organisational domain. This flexibility allows you to enforce stricter or more relaxed subdomain policies based on their specific requirements.

Example of a DMARC Policy with Subdomain Policy (sp) Tag

Here’s an example of a DMARC policy that includes the “sp” tag to specify a policy for subdomains:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]; fo=1; adkim=r; aspf=r; pct=100; ri=86400"

In this example:

The DMARC policy is published at “_dmarc.example.com”, indicating that it applies to the organisational domain “example.com”.
The policy for the organisational domain is set to “reject”, meaning that email receivers should reject any messages from “example.com” that fail DMARC authentication.
The “sp” tag is set to “quarantine”, which means that email receivers should quarantine (e.g., send to the spam folder) any messages from subdomains of “example.com” that fail DMARC authentication.
The reporting options, alignment modes, and other settings are similar to the previous examples.

Using the “sp” tag, you can define a separate subdomain policy without publishing individual DMARC records for each subdomain. This approach simplifies the management of DMARC for organisations with multiple subdomains while still allowing for granular control over subdomain policies.

Remember that if you have specific subdomains requiring a policy or settings different from the one specified by the “sp” tag, you can still publish separate DMARC records for those subdomains to override the subdomain policy.

Using the “sp” tag in combination with separate subdomain DMARC records provides a flexible and comprehensive approach to managing DMARC alignment across your entire domain hierarchy.

Example of a Subdomain DMARC Record

Let’s consider an example to demonstrate how DMARC can be implemented at the subdomain level. Suppose your organisation’s primary domain is “example.com”, and you have a subdomain “newsletter.example.com” that sends marketing emails.

To protect your subdomain from email spoofing and ensure DMARC compliance, you can publish a separate DMARC record for the subdomain. The DMARC record for “newsletter.example.com” would look like this:

_dmarc.newsletter.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; fo=1; adkim=r; aspf=r; pct=100; ri=86400"

In this example:

The DMARC record is published at “_dmarc.newsletter.example.com”, indicating that it applies specifically to the “newsletter.example.com” subdomain.
The policy is set to “reject”, meaning that email receivers should reject any messages from this subdomain that fail DMARC authentication.
The reporting options, alignment modes, and other settings are similar to the example we provided for the organisational domain.

By publishing a separate DMARC record for the subdomain, you can enforce a specific policy and monitor DMARC compliance for emails sent from “newsletter.example.com” while maintaining different policies or settings for your organisational domain and other subdomains.

This granular approach to DMARC implementation allows you to tailor your email authentication strategy based on the unique requirements and risks associated with each subdomain.

Proper subdomain alignment helps maintain a consistent email authentication and security level across your entire domain hierarchy. It prevents attackers from exploiting subdomains with weaker or nonexistent DMARC policies.

By ensuring proper identifier alignment and extending DMARC policies to subdomains, you can strengthen the overall effectiveness of your DMARC implementation. Alignment helps email receivers make accurate decisions about the legitimacy of email messages and reduces the risk of email spoofing and domain impersonation.

Common DMARC Misconceptions

While DMARC is a powerful tool for enhancing email security, some common misconceptions exist about its capabilities and limitations. Let’s address these misconceptions to ensure a clear understanding of what DMARC can and cannot do.

Misconception: DMARC alone prevents all email spoofing. Reality: DMARC is not a standalone solution for preventing all forms of email spoofing. It works in conjunction with SPF and DKIM to provide a comprehensive email authentication framework. While DMARC helps reduce the risk of domain spoofing, it does not protect against other types of email-based attacks, such as those originating from compromised accounts or domains without DMARC records.
Misconception: Implementing DMARC guarantees 100% email deliverability. Reality: DMARC does not guarantee perfect email deliverability. Even with a properly implemented DMARC setup, legitimate emails may be accidentally flagged as spam or rejected due to misconfigurations, incorrect alignment, or overly strict policies. Monitoring DMARC reports and adjusting policies gradually to minimise false positives and ensure optimal deliverability is important.
Misconception: DMARC eliminates the need for other email security measures. Reality: DMARC is just one layer of email security. It should be used in conjunction with other security measures, such as spam filters, malware scanners, and user education. DMARC primarily focuses on authenticating the sender’s identity and does not address the content of the email itself. Therefore, it’s crucial to have a multi-layered approach to email security.
Misconception: DMARC is difficult to implement and requires technical expertise. Reality: While DMARC implementation does require some technical knowledge, it is not overly complex. Many email service providers and IT solutions offer DMARC setup guides and tools to simplify the process. Additionally, there are numerous resources, including online forums and communities, where you can seek guidance and support from experienced DMARC practitioners.
Misconception: DMARC is only relevant for large organisations. Reality: DMARC is important for organisations of all sizes. Small businesses and even individuals with their own domains can benefit from implementing DMARC. Email spoofing and domain impersonation can target any domain, regardless of its size or popularity. By implementing DMARC, you can protect your brand, maintain trust with your audience, and prevent your domain from being used for fraudulent activities.
Misconception: DMARC reports are not actionable or useful. Reality: DMARC reports provide valuable insights into your email ecosystem. They help you identify authentication issues, monitor email traffic patterns, and detect potential spoofing attempts. By regularly analysing DMARC reports, you can troubleshoot problems, fine-tune your policies, and strengthen your email security posture. Ignoring DMARC reports can lead to missed opportunities for improvement and an increased risk of email-based threats.

By dispelling these common misconceptions, we aim to understand DMARC’s capabilities and limitations better. DMARC is a powerful tool that can significantly enhance your email authentication and protect your domain from spoofing and impersonation when used correctly and combined with other email security measures.

DMARC and Privacy Regulations

When implementing DMARC, you must consider the potential impact on privacy and ensure compliance with relevant data protection regulations, such as the General Data Protection Regulation (GDPR) in the European Union and the Protection of Personal Information Act (POPI) in South Africa.

DMARC reports, particularly forensic reports, can contain personal information about email senders and recipients. This information may include email addresses, IP addresses, and message contents. As a result, the collection, storage, and processing of DMARC reports must be handled in accordance with applicable privacy laws.

Here are some key considerations for managing DMARC reporting in compliance with GDPR, POPI, and other privacy regulations:

Data Minimisation: Collect only the minimum amount of personal information necessary for DMARC authentication and reporting purposes. Use aggregate reports instead of forensic reports whenever possible, as they contain less personal information.
Data Retention: Establish a data retention policy that specifies how long DMARC data will be stored and when it will be deleted. Only retain data for as long as necessary to fulfil the purposes of DMARC implementation and comply with legal obligations.
Data Security: Implement appropriate technical and organisational measures to protect the security and confidentiality of DMARC data, such as encrypting data in transit and at rest, restricting access to authorised personnel only, and regularly monitoring for security breaches.
Transparency: Provide clear and accessible information to email senders and recipients about your DMARC implementation, including what data is being collected, how it is being used, and how individuals can exercise their privacy rights.
Legal Basis: Ensure that you have a valid legal basis for collecting and processing DMARC data, such as legitimate interests or consent, and that you can demonstrate compliance with applicable data protection laws.
Cross-Border Transfers: If DMARC data is being transferred outside of the country or region where it was collected, ensure that appropriate safeguards are in place to protect the data, such as standard contractual clauses or binding corporate rules.
Third-Party Providers: If you are using third-party services or solutions for DMARC implementation, ensure that they comply with applicable data protection laws and that you have appropriate data processing agreements.

By addressing these considerations and incorporating privacy principles into your DMARC implementation, you can demonstrate a commitment to data protection and build trust with your email recipients.

It’s important to note that the specific privacy requirements and best practices may vary depending on the jurisdictions in which you operate and the nature of your email ecosystem. Therefore, it’s always a good idea to consult with legal and privacy experts to ensure your DMARC implementation fully complies with applicable laws and regulations.

Advanced DMARC Considerations

As you become more familiar with DMARC and gain experience in its implementation, you may want to explore advanced features and considerations to enhance your email security posture further. Let’s discuss some of these advanced topics.

BIMI (Brand Indicators for Message Identification)

BIMI is an emerging standard built upon DMARC to indicate email authenticity visually. When a domain implements BIMI, it allows email providers to display the domain’s verified logo next to authenticated emails in the recipient’s inbox.

To enable BIMI, you need to:

Have a valid DMARC policy in place with a policy of “quarantine” or “reject”.
Create a BIMI DNS record specifying the location of your verified logo image.
Undergo a verification process with a trusted third party to validate your logo and ensure it meets BIMI guidelines.

By implementing BIMI, you can enhance your brand’s visibility, build trust with email recipients, and provide an additional layer of assurance that the email is legitimate.

DMARC Failure Reporting

DMARC failure reporting goes beyond the standard aggregate and forensic reports to provide more detailed information about failed DMARC checks. Failure reports can help you identify and diagnose SPF, DKIM, and alignment issues more effectively.

To enable failure reporting, you need to include the “ruf” (Reporting URI for Failure) tag in your DMARC record. This tag specifies the email address where failure reports should be sent.

Failure reports contain valuable information, such as:

The specific reason for the DMARC failure (e.g., SPF check failed, DKIM signature invalid)
The IP address and hostname of the sending server
The DKIM selector and domain used for signing
The full email headers of the failed message

Analysing failure reports lets you quickly identify misconfigurations, unauthorised sending sources, or other issues that may impact your email authentication.

DMARC and Indirect Email Flows

Indirect email flows, such as mailing lists, forwarders, and mailbox providers that modify email content can challenge DMARC alignment. When an email is forwarded or modified, the original DKIM signature may break, causing DMARC failures.

To mitigate this issue, you can consider the following approaches:

Implement DKIM signing on the forwarding or modifying service to re-sign the email with a valid DKIM signature aligned with the “From” domain.
Use the “Sender” or “On-Behalf-Of” headers to separate the original sender from the forwarder, allowing for proper alignment.
Work with mailing list providers and forwarders to ensure they have DMARC-compliant practices in place.

It is important to regularly test and monitor your DMARC setup to identify and address any issues related to indirect email flows.

Integrating DMARC with Other Security Solutions

DMARC is most effective when integrated with other email security solutions and broader security infrastructure. Consider the following integrations:

SIEM (Security Information and Event Management) systems to centralise DMARC reporting data and correlate it with other security events.
Threat intelligence platforms to enrich DMARC data with context about potential threats and suspicious activities.
Automated incident response workflows to trigger actions based on DMARC failures or suspicious patterns.

By integrating DMARC with your existing security solutions, you can better understand your email security posture and respond to threats more effectively.

As DMARC continues to evolve, staying informed about the latest advancements, best practices, and tools is essential. Engaging with the DMARC community, attending relevant conferences, and following industry publications can help you stay current and maximise your DMARC implementation.

In the next section, we will provide some useful resources and references to assist you further in your DMARC journey.

Business Email Compromise (BEC) vs. Email Spoofing

While DMARC is an effective tool for combating email spoofing, it’s important to understand the difference between spoofing and Business Email Compromise (BEC) attacks.

What is Business Email Compromise (BEC)?

Business Email Compromise (BEC) is a type of cyber attack that targets organisations to induct fraudulent payments or steal sensitive information. In a BEC attack, the attacker gains access to a legitimate email account within the organisation, often through methods like phishing, malware, or weak passwords.

Once the attacker has control of the email account, they can send emails that appear to be from a trusted source, such as a senior executive, financial officer, or vendor. These emails often instruct recipients to transfer funds, change payment details, or provide confidential data.

How BEC Differs from Email Spoofing

The key difference between BEC and email spoofing lies in the origin of the fraudulent emails:

In email spoofing, the attacker sends emails with a forged “From” address, making it appear that the email is coming from a legitimate source. However, the email is not sent from the claimed source’s server.
In BEC attacks, the attacker uses a compromised email account to send emails from the organisation’s actual email server. The “From” address is legitimate because the email originates from a genuine email account.

DMARC’s Role in Mitigating BEC Risks

While DMARC is primarily designed to prevent email spoofing, it can still play a role in mitigating the risks associated with BEC attacks:

DMARC can help prevent attackers from spoofing your domain in BEC attacks targeting other organisations. By implementing a strict DMARC policy, you make it harder for attackers to use your domain to deceive others.
DMARC alignment can help detect when an email account has been compromised. If a BEC attacker uses a compromised account to send emails with misaligned “From” domains, DMARC can flag these emails as suspicious.
DMARC reporting can provide visibility into email traffic originating from your domain, including potential BEC attacks. By monitoring DMARC reports, you can identify anomalies and investigate suspicious activity.

However, it’s important to note that DMARC alone is not sufficient to prevent BEC attacks. Organisations should implement additional security measures, such as:

Enabling multi-factor authentication (MFA) for email accounts
Regularly training employees to recognise and report phishing attempts
Implementing strong password policies and encouraging the use of password managers
Monitoring for and quickly responding to suspicious account activity
Establishing clear procedures for verifying and authorising financial transactions

By combining DMARC with these additional security best practices, organisations can create a multi-layered defence against both email spoofing and BEC attacks.

In Closing

By implementing DMARC, you proactively protect your organisation from email spoofing, phishing attempts, and domain impersonation. DMARC not only safeguards your brand reputation but also enhances the trust and confidence of your email recipients.

Remember, DMARC is not a set-and-forget solution. It requires ongoing monitoring, analysis, and adjustment to ensure its effectiveness. Regularly reviewing your DMARC reports, staying informed about the latest trends and best practices, and collaborating with your IT team and email service providers are essential for maintaining a secure email ecosystem.

As you embark on your DMARC journey, embrace the learning process and don’t hesitate to seek support from the DMARC community. The resources provided in this guide will serve as valuable companions, offering in-depth knowledge, practical tools, and expert insights to guide you along the way.

By implementing DMARC and following the best practices outlined in this guide, you are joining a global effort to combat email fraud and create a safer email environment for everyone. Your commitment to email security benefits your organisation and contributes to the email ecosystem’s overall integrity.

Email security is a shared responsibility. By adopting DMARC, you are protecting your domain and contributing to a safer email landscape for all. Together, we can make email a trusted and reliable communication channel for businesses and individuals alike.

Stay vigilant, stay informed, and secure your email domain with DMARC.

Additional Resources

We have compiled a list of useful resources and references to support your DMARC implementation further and expand your knowledge. These resources will provide you with in-depth information, best practices, and tools to help you along your DMARC journey.

Official DMARC Documentation: The official DMARC website (https://dmarc.org/) provides comprehensive documentation, including the DMARC specification, deployment guidelines, and frequently asked questions. It is an essential resource for anyone implementing DMARC.
EasyDMARC: EasyDMARC (https://easydmarc.com/) is a web-based tool that simplifies the process of analysing DMARC reports. It provides a user-friendly interface to visualise and interpret DMARC data, helping you identify issues and track your DMARC progress.
Dmarcian: Dmarcian (https://dmarcian.com/) offers a range of DMARC tools and services, including a DMARC report analyzer, a DMARC record generator, and a DMARC monitoring platform. Their resources section provides helpful guides, whitepapers, and webinars on DMARC implementation.
Global Cyber Alliance DMARC Setup Guide: The Global Cyber Alliance (https://www.globalcyberalliance.org/) has developed a step-by-step guide to help organisations implement DMARC. The guide covers the entire process, from understanding DMARC concepts to publishing and monitoring DMARC records.
DKIM Validator: DKIM Validator (https://dkimvalidator.com/) is a tool for validating DKIM signatures and troubleshooting DKIM-related issues. It can be helpful when diagnosing DMARC failures related to DKIM alignment.
SPF Surveyor: SPF Surveyor (https://www.kitterman.com/spf/validate.html) is a web-based tool for validating and analysing SPF records. It checks for syntax errors, evaluates the SPF policy, and provides recommendations for improvement.
DMARC.org Mailing List: DMARC.org maintains a mailing list (https://dmarc.org/participate/) where DMARC practitioners, researchers, and enthusiasts can engage in discussions, ask questions, and share experiences. Joining the mailing list can provide valuable insights and support from the DMARC community.
Online DMARC Training: Several online learning platforms, such as Udemy and Coursera, offer DMARC-specific training courses. These courses can provide structured learning and hands-on exercises to help you better understand DMARC concepts and implementation.
Industry Conferences: Attending industry conferences focused on email security, such as the M3AAWG (Messaging, Malware, and Mobile Anti-Abuse Working Group) meetings or the RSA Conference, can provide valuable opportunities to learn from experts, network with peers, and stay updated on the latest DMARC trends and best practices.

These resources will complement the knowledge gained from this guide and help you navigate the intricacies of DMARC implementation. Remember, implementing DMARC is an ongoing process that requires continuous monitoring, analysis, and refinement. By leveraging these resources and staying proactive, you can strengthen your email authentication and protect your domain from email spoofing and fraudulent activities.

dmarc