Why do I need a DMARC record?

Why do I need a DMARC record?

DMARC, or Domain-based Message Authentication Reporting and Conformance, is a mechanism designed for authenticating email messages. It involves setting up policies that guide receiving email servers on how to handle messages after verifying a domain’s Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) records, which are supplementary authentication methods for emails.

The primary purpose of DMARC and other email authentication methods is to thwart email spoofing. Given that every email address is associated with a domain (the part after the “@” symbol), malicious entities may attempt to send unauthorised emails from a domain, akin to using a false return address on a letter. This fraudulent activity, such as phishing attacks, can be mitigated by employing DMARC, DKIM, and SPF collectively, resembling a background check for email senders to validate their authenticity.

To illustrate, if a spammer sends an email from “trustworthy@example.com” without authorization to use the “example.com” domain, DMARC, SPF, and DKIM can expose this unauthorized attempt, allowing email servers to mark the message as spam or refuse delivery.

A DMARC policy dictates the actions to be taken after SPF and DKIM checks. Depending on whether an email passes or fails these checks, the DMARC policy specifies whether to mark it as spam, block it, or deliver it to the intended recipient. While email servers may still label emails as spam without a DMARC record, having one provides clearer instructions on when to do so.

For instance, an example.com domain policy could be expressed as:

“If an email fails the DKIM and SPF tests, mark it as spam.”

However, these policies are not articulated as human-readable sentences; instead, they are represented as machine-readable commands. The corresponding DMARC policy might appear as:

v=DMARC1; p=quarantine; adkim=s; aspf=s;

Breaking down this example, v=DMARC1 indicates the presence of a DMARC policy, while p=quarantine instructs email servers to quarantine emails that fail DKIM and SPF. The optional settings adkim=s and aspf=s denote strict checks for DKIM and SPF, respectively.

To heighten the strictness of the policy, the administrator could adjust it to:

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

This signifies that if an email fails the DKIM and SPF tests, it should not be delivered.

A DMARC report is a crucial component, allowing administrators to receive information about emails that pass or fail DKIM or SPF. These reports aid in adjusting DMARC policies based on legitimate email failures or potential spam activities. An example.com administrator might include the following in the DMARC policy to send reports to a third-party service:

v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:example@third-party-example.com;

A DMARC record, stored in the Domain Name System (DNS) as a DNS TXT record, encapsulates a domain’s DMARC policy. It contains machine-readable commands that define how emails from that domain should be treated.

Even domains that do not actively send emails should have a DMARC record to prevent spammers from exploiting the domain. The DMARC policy for such domains should typically reject all emails failing SPF and DKIM checks.

Still confused? We can set it all up for you, hassle-free…….