Complete _DMARC Guide

In the digital world, email communication is key. But how do you ensure that your emails aren’t marked as spam or become targets for scammers? The solution lies in the _DMARC record. Setting up a DMARC record is very simple, so it’s important to take a few minutes to read, set up, and be secure.

What is a _DMARC record and why is it important?

_DMARC (Domain-based Message Authentication, Reporting & Conformance) is an innovative standard that helps domain owners protect their email domains from various threats, such as phishing and spoofing attacks. With the help of DKIM and SPF records, _DMARC verifies the authenticity of every email message sent from your domain.

Phishing is a type of online scam where attackers try to fraudulently obtain sensitive information, such as usernames, passwords, or credit card details, from an unsuspecting user. Phishing attacks typically use fake emails, websites, or messages that appear to come from trusted sources.

Spoofing refers to the practice of disguising communication so it appears to come from a trusted source when it actually comes from an attacker.

The importance of DMARC lies in its ability to protect the reputation of your email domain. When your email has a correctly set DMARC record, recipients can be confident that the message is coming from a legitimate source.

How do DMARC, DKIM, and SPF complement each other?

To understand DMARC, we first have to understand how it relies on DKIM and SPF:

• DKIM (DomainKeys Identified Mail): This is a method by which email messages are “signed” using a private key on your server. When the message reaches the recipient, it is decoded using a public key available as a DNS record. If the signature matches, the email is legitimate.
• SPF (Sender Policy Framework): This record defines which servers can send emails on behalf of your domain. When recipients receive an email, they can check the SPF record to confirm that the message comes from an approved server.

DMARC uses both of these systems to verify the authenticity of an email. If the message passes both tests, it is considered authentic. If not, the DMARC policy decides what happens next.

How to set up a _DMARC record with cPanel?

Using cPanel, the procedure is as follows:

1. Log in to cPanel: Sign in to your cPanel account.
2. Access the ‘E-mail Deliverability‘ tool: This is the central place for managing email authentication.
3. Add a _DMARC record: Click on “Add Record” and select the record type “_DMARC”.

Key components of a _DMARC record:

Besides the already mentioned parameters, there are several other key components that you can configure:

The main components of the DMARC record and their explanations are:

1. v=DMARC1
   • Description: This declaration marks the record as a DMARC record. It’s mandatory for every DMARC record.
   • Variation: Always “DMARC1” for current DMARC records
2. p=
   • Description: The policy you want to enforce for emails that don’t pass DMARC checks.
   • Variations:
     • none: No actions taken, but reports will be sent.
     • quarantine: Messages are directed to quarantine (e.g., to the spam folder).
     • reject: The message is rejected before it reaches the user.
3. sp=
   • Description: Policy for subdomains. If not specified, the main policy will also apply to subdomains.
   • Variations: Same as for “p=” (none, quarantine, reject).
4. rua=
   • Description: Address where aggregate reports about emails will be sent.
   • Variations: The address must be in email form (e.g., mailto:[email protected]).
5. ruf=
   • Description: Address where reports about failed authentication checks will be sent.
   • Variations: The address must be in email form.
6. pct=
   • Description: Percentage of messages that you want the policy to apply to. Useful when you want to gradually introduce DMARC to avoid potential issues.
   • Variations: A number between 0 and 100.
7. adkim=
   • Description: DKIM alignment.
   • Variations:
     • r: relaxed alignment.
     • s: strict alignment.
8. aspf=
   • Description: SPF alignment.
   • Variations:
     • r: relaxed alignment.
     • s: strict alignment.
9. ri=
   • Description: Frequency of report sending.
   • Variations: Number in seconds (e.g., 86400 for daily reports).

How a _DMARC record looks:

v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s;

Here, we see that p=none, which means it doesn’t take any action if the SPF and DKIM checks aren’t passed. The next item is rua, which means reports should be sent to that email address. The fields adkim and aspf are set to ‘s‘, meaning they are strict, i.e., they must be valid.

This is a good example of what a DMARC record should look like when testing if everything is properly set up. You will receive reports at the email you’ve specified, allowing you to check if everything is successfully and correctly set up. Once you confirm everything is working as it should, you can change the “p=” value to ‘reject‘, fully protecting your domain so no one can falsely represent themselves as you.

How a DMARC report looks

When you receive the file, it will be packaged in a .gz format. You can unpack it using any program (like 7zip), and you’ll obtain an .xml file that you can open however you wish. Depending on who has been sending emails (whether it’s just us or if someone tried to misuse our domain), the length of this report will vary.

Here’s a website where you can input your XML to see it neatly organized if the textual display isn’t suitable for you: WEBSITE

Here’s an example:

<record>
    <row>
      <source_ip>127.1.1.1</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <envelope_to>outlook.com</envelope_to>
      <envelope_from>amazonses.com</envelope_from>
      <header_from>somedomain.net</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>somedomain.net</domain>
        <selector>iopjubzv7og2mvw7h</selector>
        <result>pass</result>
      </dkim>
      <dkim>
        <domain>amazonses.com</domain>
        <selector>sokbgaapuuanpimv</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>amazonses.com</domain>
        <scope>mfrom</scope>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

Here’s what we see:

For this domain, the policy_evaluated for SPF is marked as ‘fail‘. Thus, if our ‘p=‘ value was set to ‘reject‘, no one would be able to receive an email from us. It’s essential first to configure it correctly. Even though the SPF record below indicates ‘pass’, the overall evaluation does not pass.

In this specific example that was intentionally shown, both DKIM and SPF are indicated as correct, but the email sending isn’t. This suggests that some PHP script was used for sending emails directly from the website, where the sending setup wasn’t correctly configured. As a result, even though the DNS settings are correct, the check fails.

You can expect frequent and more substantial reports from servers depending on how much you send. If you no longer wish to receive these notifications, simply remove the rua= field.

If you’re confident and everywhere it indicates that the sending was successful (it’s vital to check specifically for your IP), then you can set the p= value to ‘reject’, preventing the misuse of your email.

Conclusion

You shouldn’t take the security of your email domain lightly. DMARC, along with DKIM and SPF, provides robust protection against threats that can damage your reputation and the trust of your clients. If you’re using cPanel, there’s no reason not to set up a DMARC record immediately.