What is DMARC and how do you implement it?

On October 3, 2023, Google and Yahoo announced new email delivery prerequisites that will be mandatory by February 2024. For senders who dispatch more than 5,000 emails daily to Gmail addresses, Google will mandate fulfilling a set of authentication measures to ensure secure email delivery to Gmail inboxes. Although Yahoo has not specified a minimum sending threshold, it will align with Google's criteria.

The prescribed requirements include:

• Implementation of both SPF and DKIM

• Sending emails with a 'From' domain aligning with either the SPF or DKIM domains

• Sending from a domain with a DMARC policy of at least p=none

• Valid forward and reverse DNS (FCrDNS)

• Incorporating a one-click unsubscribe mechanism (RFC 8058)

• Maintaining a low spam reported rate

For a detailed list of requirements, you can refer to Google's help article. While CM.com will oversee most of the mandatory requirements, we require your assistance in adding the DMARC.

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol designed to give email domain owners the ability to protect their domain from unauthorised use, known as email spoofing. DMARC allows a domain owner to publish a policy in their DNS records that specifies which mechanisms (e.g. SPF, DKIM) are used to authenticate email messages sent from their domain and also provides a mechanism for receiving reports of messages that pass or fail DMARC evaluation.

How to implement DMARC?

Implementing DMARC involves several steps:

Perform an audit of your domain's email infrastructure

Before you can implement DMARC, you need to have a good understanding of how email is being sent from your domain. This includes identifying all of the servers and applications that are sending email on behalf of your domain, as well as any third-party services that are being used to send email.

Set up SPF and DKIM

DMARC builds on top of existing email authentication mechanisms such as SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). These protocols allow you to specify which servers are authorised to send email on behalf of your domain and to cryptographically sign email messages to prove that they were sent from your domain.

Publish a DMARC policy

Once you have set up SPF and DKIM, you can create a DMARC policy that specifies how email receivers should handle messages that fail DMARC evaluation. The policy is published in your domain's DNS records.

Monitor DMARC reports

Once you have published a DMARC policy, email receivers will begin sending you reports about how your domain's email is being handled. These reports will provide information about which messages are passing or failing DMARC evaluation, as well as other details about the messages.

Take action based on DMARC reports

Analyse the data in the DMARC reports to identify any issues with email spoofing and take appropriate action.

Monitor and update your DMARC policy

Monitor the effectiveness of your DMARC policy over time and make adjustments as needed.

Keep DNS records up-to-date

Keep your DNS records up-to-date, in case you make any changes to your email infrastructure or update your DMARC policy.

It's important to remember that DMARC is a continuous process and requires ongoing monitoring, maintenance and updates. If you are not familiar with the technical details of email infrastructure and DNS, It's recommended to hire an email security provider or a domain registrar that offers DMARC implementation services, they can help you to implement and maintain a DMARC policy for your domain.

By implementing DMARC, domain owners can protect their domain from unauthorised use and prevent their domain from being used to send spam or phishing emails. This helps to protect the domain owner's reputation and can reduce the likelihood of their domain being blacklisted by email providers. Additionally, DMARC can help to protect the recipients of email messages sent from a domain, by allowing them to more easily identify and reject messages that are likely to be spam or phishing attempts.

How to create a DMARC record

To add a DMARC record to your DNS, you will need to create a TXT record that includes your DMARC policy. The format of the DMARC record is as follows:

This record contains several different rules, each of which is used to specify a different aspect of your DMARC policy. Here's an explanation of each of the rules in the example record:

• v=DMARC1: This is the version of DMARC that is being used.

• p=reject: This rule specifies the action that email receivers should take when a message fails DMARC evaluation. In this example, the action is "reject", which means that email receivers should reject messages that fail DMARC evaluation.
  (This action should be implemented after ensuring that all email flows are properly authenticated.)

• sp=none: This rule specifies the action that email receivers should take when a message fails DMARC evaluation but the domain owner's policy is "none".

• pct=100: This rule specifies the percentage of messages that should be subject to DMARC evaluation. In this example, 100% of messages will be subject to DMARC evaluation.

• rua=mailto:[email protected]: This rule specifies the email address to which aggregate reports should be sent.

• ruf=mailto:[email protected]: This rule specifies the email address to which forensic reports should be sent.

• fo=1: This rule specifies that the domain owner would like to receive a failure report when a message fails DMARC evaluation but passes SPF or DKIM evaluation.

• adkim=r: This rule specifies that strict alignment should be used for DKIM evaluation.

• aspf=r: This rule specifies that strict alignment should be used for SPF evaluation.

Once you have created your DMARC record, you will need to add it to your domain's DNS records. The process for adding a TXT record to your DNS will vary depending on your DNS provider, so you will need to consult their documentation for specific instructions.

What is a DMARC report?

The DMARC report typically includes the following information:

• The domain for which the report was generated

• The reporting period for the report (i.e. the start and end dates for the data in the report)

• The number of messages that passed or failed DMARC evaluation for the domain

• Information about the SPF and DKIM authentication results for the messages

• The IP addresses and other identifying information for the servers that sent the messages

• Additional details about the messages, such as the subject lines and recipient addresses

Parsing DMARC reports involves analysing the data in the reports to understand how email sent from a domain is being authenticated and to identify any potential issues with email spoofing. DMARC reports are typically sent in XML format and developers can use XML parsing libraries to extract the data from the reports.

Once you have parsed the DMARC report and extracted the data, you can use the data to identify any issues with email spoofing, such as messages that are failing DMARC evaluation or messages that are coming from unexpected sources.

You can also use the data to monitor the effectiveness of your domain's DMARC policy over time and make adjustments as needed.

A DMARC report typically contains a lot of information, and it can be quite complex, here is an example of a full DMARC report that illustrates some of the key elements:

<feedback>
  <report_metadata>
    <org_name>example.com</org_name>
    <email>mailto:[email protected]</email>
    <extra_contact_info>https://example.com/dmarc</extra_contact_info>
    <report_id>1234567890</report_id>
    <date_range>
      <begin>2022-01-01</begin>
      <end>2022-01-31</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>reject</p>
    <sp>none</sp>
    <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>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
    <extensions>
      <reason>
        <type>forwarded</type>
        <comment>This message was forwarded from another address.</comment>
      </reason>
      <reason>
        <type>autoreply</type>
        <comment>This message is an automatic reply.</comment>
      </reason>
    </extensions>
  </record>
  <record>
    <row>
      <source_ip>192.0.2.2</source_ip>
      <count>50</count>
      <policy_evaluated>
        <disposition>reject</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>fail</result>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>fail</result>
      </spf>
    </auth_results>
    <extensions>

Here's a breakdown of the key elements in the example report:

• <report_metadata>: This section provides information about the organisation that is publishing the report, such as the organisation's name and contact information, the unique report ID, and the date range for which the report covers.

• <policy_published>: This section includes the DMARC policy that was published by the domain owner for the domain in question. The "p" value of "reject" means the domain owner has instructed email receivers to reject any messages that fail DMARC evaluation, the "pct" value of "100" means that 100% of the messages will be subject to the DMARC evaluation.

• <record>: This section includes information about the messages that were sent during the reporting period, such as the IP address of the server that sent the message and the number of messages sent from that IP. The <policy_evaluated> section also includes the results of the SPF and DKIM evaluations for the message, and the <auth_results> section includes the details of the authentication results.

• <identifiers>: This section includes the header "from" field of the message, it's the domain that is being claimed as the sender.

• <extensions>: This section includes additional information about the message such as the reason for the message, if it's an auto-reply or a forwarded message for example.

• <reason>: This section includes the type of reason for the message and a comment.

As demonstrated, the implementation of DMARC is a complex process that requires a thorough understanding of email infrastructure and DNS, but it is crucial for ensuring the security of your business and domain by protecting against unauthorised use and email spoofing.