Goal

Goal of article is to explain what DMARC is and how it helps protect email senders and recipients from spam, spoofing, and phishing.

Product

• Mobile Marketing Cloud

  • Email Campaigns

What is DMARC

DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol that is designed to give email domain owners the ability to protect their domain from unauthorized 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.

Implementing 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 authorized 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: Analyze 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 offer 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 unauthorized 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.

Creating the 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:

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

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.

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

It's recommended to check your DMARC record on dmarcian.com or any other DMARC checker tool to ensure it's properly configured and working.

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 analyzing 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 organization that is publishing the report, such as the organization'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 reason for the message, if it's an autoreply 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 unauthorized use and email spoofing.