Secure Your Email with DMARC

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a security mechanism that works alongside SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to help protect email domains from being used in phishing and spoofing attacks.

Implementing DMARC alongside SPF and DKIM allows domain owners to specify a policy as to how emails from their domain should be handled if the recipient server fails to validate and authenticate the checks performed by SPF and DKIM.

Why is DMARC Important?

The main reason that DMARC is important is how it can help to protect your email domain from being used in phishing and spoofing attacks against your organisation, your customers, or others.

Essentially, consider DMARC to be a way to tell recipient email servers what to do if an email fails SPF or DKIM checks. It is a way to enforce your email authentication policies and ensure that only legitimate emails from your domain are delivered to recipients.

How Does DMARC Work?

The way DMARC works is by allowing a domain owner to publish a public policy that defines how their email recipients should handle emails that fail SPF and/or DKIM validation. This policy is published as a TXT record in the DNS settings for the domain (e.g. _dmarc.yourdomain.com).

There are a number of different configurations that can be set within a DMARC policy, which allows some flexibility with how strict the policy is, or to allow granular control over subdomains and reporting options.

A basic DMARC policy may look something like this:

v=DMARC1; p=quarantine; rua=mailto:example@example.com; ruf=mailto:example@example.com; fo=1; pct=100

In this example:

• v=DMARC1 specifies the version of DMARC being used.
• p=quarantine indicates that emails that fail DMARC checks should be treated as suspicious and placed in the recipient’s spam or junk folder. Other options include none (no action taken) and reject (emails that fail the DMARC checks are rejected outright).
• rua=mailto:... specifies the email address where aggregate reports should be sent. These reports provide information about how many emails passed or failed DMARC checks.
• ruf=mailto:... specifies the email address where forensic reports should be sent. These reports provide detailed information about individual emails that failed DMARC checks.
• fo=1 indicates that a forensic report should be sent if either SPF or DKIM fails.
• pct=100 indicates that the policy should be applied to 100% of emails from the domain. This can be configured to a lower percentage (e.g., pct=50) to gradually roll out the DMARC policy.

With the TXT record deployed, recipient email servers will check incoming emails against the DMARC policy and take the appropriate action based on the policy defined.

Each of the received emails contain a “From” header that indicates the domain that the email is purportedly from. The recipient server will check the SPF and DKIM records for that domain to see if the email passes either of those checks. If the email fails both checks, the recipient server will then refer to the DMARC policy published in the DNS for that domain to determine how to handle the email.

Setting Up and Configuring a DMARC Policy

There are many more DMARC options in the form of a key-value pair that can be configured to suit your organisation’s needs. Below are the different options that can be set within a DMARC policy:

The fo option can be useful to help reduce the volume of forensic reports that are sent, especially when first implementing DMARC. For example, setting fo=1 will generate a report if either SPF or DKIM fails, whereas setting fo=0 will only generate a report if both checks fail.

This feature can be set to include multiple options by combining them with a colon (e.g., fo=1:d would generate a report if either SPF fails or if DKIM fails).

Whilst the recommended setting for this is fo=1, the full options for this are:

• 0: Generate a report if both SPF and DKIM fail.
• 1: Generate a report if either SPF or DKIM fails.
• d: Generate a report if DKIM fails.
• s: Generate a report if SPF fails.

Example DMARC Policies

Say you would like to implement a DMARC policy that does not implement any policy for the root domain, but applies a quarantine policy to all subdomains, and you would like to receive aggregate reports at email@example.com. Your DMARC record would look something like this:

v=DMARC1; p=none; sp=quarantine; rua=mailto:email@example.com;

As another example, if you wanted to implement a DMARC policy for strict SPF alignment, but not for DKIM, you could use the following DMARC record:

v=DMARC1; p=reject; aspf=s; adkim=r;

Benefits of Implementing DMARC

1. Protects Against Email Spoofing: DMARC helps prevent attackers from sending emails that appear to come from your domain, reducing the risk of phishing attacks and protecting your brand and domain reputation.
2. Improves Email Deliverability: By implementing DMARC, you can improve the deliverability of your legitimate emails, as recipient servers are more likely to trust emails that pass DMARC checks.
3. Provides Visibility: DMARC provides reporting features that allow domain owners to monitor email traffic and identify potential issues with email authentication.
4. Enhances Security Posture: Implementing DMARC is a proactive step towards enhancing your organisation’s overall security posture and protecting sensitive information.

What DMARC Cannot Do

Whilst DMARC is a strong addition to an existing security posture, it is a piece of a larger puzzle and not a single solution to email security. It requires (ideally) both SPF and DKIM to be implemented correctly to be effective.

DMARC cannot protect against all types of email-based attacks, such as those using similar looking domain names (e.g. microsoft.com and rnicrosoft.com) or attacks that do not involve email spoofing, such as malware or ransomware delivered through email attachments or links.

Additionally, DMARC does not protect against attacks that originate from compromised email accounts within your organisation. If an attacker gains access to a legitimate email account, they can send emails that can pass the SPF, DKIM, and DMARC checks.

Previous Post SPF Email Security: Protect Your Domain from Spoofing

Next Post DKIM Email Security: Authenticate Your Emails