DNS Records - DMARC – Critical Impact

What is DMARC?

DMARC (Domain-based Message Authentication Reporting and Conformance) tells a receiver what to do when authentication is missing or failing for a specific From: header domain and to strictly obey your SPF and DKIM records. DMARC was once used as a security measure for senders vulnerable to spoofing and phishing but now it is required by Google and Yahoo to ensure your messages are being delivered. DMARC requires correct implementation with an ESP to ensure your delivery isn't affected.

Does My Domain Need DMARC?

If you are able to complete sender authentication for your domain, you will have your SPF and DKIM records in place. Since SPF and DKIM are required for DMARC, any forged emails will likely be rejected or go to spam anyway.

For an email to pass DMARC, it needs to either pass and align SPF (Sender Policy Framework) or pass and align DKIM (DomainKeys Identified Mail) - it does not need to pass and align both protocols. So although you may see some SPF alignment failures in DMARC reports, the messages are still passing DMARC Compliance because it passes and aligns through the DKIM protocol.

However, in recent ISP email standard changes, it is now required to have a DMARC record. There are different types of DMARC record policies: none, quarantine, and reject. The "none" DMARC record policy (p=none) will take no action on messages that fail the DMARC check. It's mainly used as a placeholder policy for reporting. A reject (p=reject) or quarantine (p=quarantine) policy is a much stricter DMARC policy and we do not recommend it.

DMARC offers you a way to see who is attempting to impersonate your domain, assuming you have the software on your side to process DMARC, and assuming an email trying to impersonate your domain is sent to an email server that can handle DMARC and also reports the forged emails. This can be useful if you send a lot of emails to free email addresses e.g. Gmail, Yahoo, AOL, etc… AND have issues with people trying to forge your from address.

Please note that improper DMARC implementation (with anything other than a p=none policy) can cause issues with delivery to some corporate email servers. Since corporate email servers tend to go through several layers of mail servers e.g. one to log the mail (for compliance), spam filters and link checkers, etc…, it changes the email header and it won't match the DMARC rules you have in place.

When adding a DMARC record, we highly recommend setting the policy to "none" (p=none), otherwise it could potentially reject messages sending through our services.

Here is an example DMARC Record value below. Please change the mailto value to the appropriate, valid email address to receive reporting at your company.

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

This DMARC record is comprised of three parts that are required to send through CI:

v: The DMARC version
p: The DMARC policy. Instructs the receiving mail server what to do with messages that don’t pass authentication.
rua: Email address to receive reports about DMARC activity for your domain. The email address must include "mailto:". For example: mailto:example@example.com

Check your DMARC record using this third-party tool: Check DMARC Record

If you are adding a DMARC record and need further assistance, please contact our support team.

Common DNS/Hosting Provider Documentation