Understanding DMARC

DMARC, or Domain-based Message Authentication, Reporting and Conformance, is an email authentication protocol that works alongside Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM).

What makes DMARC unique is it allows senders to indicate messages are protected and tells receiving mail servers what to do if authentication methods do not pass. This makes DMARC is one of the best defenses against email spoofing.

How DMARC works

DMARC records reside on the DNS of your subdomain in the form of a text record. The P tag, or policy tag, can be configured to one of three options:

v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com

The above example is a DMARC record for Google.com. Note that the policy tag is set to reject. This means that emails sent from a Google or Gmail address in the “from” field that are not sent from Google’s infrastructure will be rejected outright and will result in a bounce. Note: DMARC references the SPF record. If you choose to implement a DMARC record on the DNS record of your subdomain, it is important to ensure that the SPF record points to WhatCounts as an allowed facilitator of your mail.
For testing purposes, we recommend starting with the policy tag of None as this will ensure that your campaigns are not rejected in the event of a configuration error.

Is DMARC required for delivery?

DMARC is not required to deliver email messages. The need for spoof and phishing prevention has led a high number of senders to adopt DMARC, especially in the financial services and banking industry. Yet to this point DMARC is not a technical prerequisite of inbox delivery. In respect to the required email authentication protocols, DKIM and SPF are adhered to and implemented by WhatCounts.

What to consider before setting up a DMARC record

If you choose to use DMARC, be sure you understand the ramifications. If not properly implemented, you could end up with a lot of mail that bounces or goes into the junk folder. This may occur when senders fail to set up the DMARC or other authentication records properly.

Remember, the DMARC record points to the SPF. If the SPF has no reference to your email service provider or any subdomains or IPs connected with WhatCounts, the receiving mail server will quarantine or reject mail based on parameters set within the DMARC record. In this situation the sender’s own record may cause their mail to go into the spam folder or bounce.

Before you attempt to implement a DMARC policy, you must first ensure that your SPF record is properly configured. If you have a subdomain set up with WhatCounts, we have the SPF piece covered for you. If you are sending from a WhatCounts subdomain and you intend to add DMARC to your own private domain, you will need to be sure that the SPF record identifies WhatCounts as the facilitator of your mail to avoid bounces or spam folder placement. A DMARC policy is a great way to improve and monitor the protection of domains from fraudulent emails. If you choose to set up a DMARC record, be sure to follow the best practices in this article.