DMARC simplified: What you need to know now

It’s finally happened. DMARC has officially become a required part of email marketing best practices.

If you’re like most people, you likely haven’t heard of DMARC before the announcement of Google and Yahoo’s new changes.

While DMARC has been a suggestion within email best practices for years, it has also been seen more as an advanced setup piece usually reserved for big corporations and the like.

Thanks to Google and Yahoo, that has changed, and DMARC is now something every email marketer should be aware of.

What is DMARC?

According to dmarc.org, “DMARC, which stands for ‘Domain-based Message Authentication, Reporting & Conformance’, is an email authentication, policy, and reporting protocol.”

What is that in layman's terms?

DMARC is a DNS (Domain Name System) record added to a domain to do several things related to the usage of the domain in email sending:

1. It sets authentication expectations for the domain when sending emails

2. It advises on what should happen to any emails sent without proper authentication with that domain 

3. It requests a report of all mail sent to providers that fails authentication  

It’s a very versatile and powerful tool.

To meet the requirements of DMARC, the traffic must be authenticated, which can be done with either SPF or DKIM on the sending domain. (If you need to know more about SPF, DKIM, and authentication, you can find out more in this series.)

Why is DMARC important?

DMARC is the next stage of domain control, specifically in attempting to give power back to domain owners against those misusing their domain.

When done correctly, DMARC helps stop bad actors who are attempting to spoof/pretend to be the domain owner for scamming purposes.

Before DMARC, the domain owner had no control over these kinds of activities. 

Now, with DMARC, some if not most of the bad traffic can be affected/stopped.

Google and Yahoo (mailbox providers that are known to receive and filter out millions of problematic emails a day) are now requiring this element to be in place to help in their fighting efforts against this type of abuse.

What is required for Google and Yahoo's changes?

While they suggest a stricter setting, Google and Yahoo’s current requirement for this is simple and low-impacting for new DMARC users.

First, you will need to make sure authentication is set up on your domain via SPF and/or DKIM.

Then, you will need to set up the following DMARC record on your DNS:

This simple policy will make sure that you don’t have issues delivering mail to users at these providers once the new requirement is active.

It’s important to note, though, that this DMARC policy is so neutral and limited that it does nothing to help in the way that DMARC was designed, so it is suggested to go beyond this and set up a more hefty DMARC policy.

Other elements to help strengthen your DMARC policy:

• “p=quarantine” OR “p=reject” — Quarantine or reject policy

  • These policies guide providers to either filter to spam (quarantine) or outright bounce (reject) any messages failing authentication

  • NOTE: This should only be done once a sender is confident they have identified and authenticated all of their organization’s mail streams that use their domain

• “Pct=50% “ — Policy enforcement percent 

  • This allows new DMARC users to test out stricter policies at a smaller level to test that all authorized mail streams are properly authenticated

• “rua=mailto:reportmailbox@example.com” — Set up a mailbox to receive DMARC failure reports

  • You can use an already existing mailbox or use a service that aggregates and formats mass reports into an easier-to-read format

There are more tags and elements available for control but these are a great place to start. You can check out other resources online if you want to level up your DMARC setup even further.

What’s most important right now?

While much has been discussed, it’s important to at least be familiar with the basics of DMARC and have a simple “p=none” record in place as a proverbial “step in the right direction,” at least according to Google and Yahoo. 

This gives space and opportunity for the industry at large to grow more used to this piece of technology and be ready to upgrade it to a higher level when the time comes…and the time will come. 

The industry must evolve. Bad actors are growing smarter, so the industry as a whole must grow to protect against it.

I’m sure you still have many questions. Please see below for common questions I’ve seen around the industry related to this.

DMARC FAQs:

• What tools can I use to set up DMARC?

  • https://dmarc.org/resources/deployment-tools/

• What tools can I use to check my DMARC?

  • https://emailstuff.org/dmarc/check/

  • https://dmarcian.com/dmarc-inspector/

• What’s the minimum setup I need to comply with Google/Yahoo requirements?

• Do I need both SPF and DKIM authentication to meet DMARC’s requirements?

  • The short answer is no, though having both gives a strong backup should one or the other fail for some temporary technical reason. You only need one of either SPF or DKIM alignment on the domain. However, SPF alignment requires alignment via the Return Path domain, which if you are unfamiliar could prove a problem depending on what platform you use. 

    • The best advice is the following:

      • Set up DKIM on your sending domain

      • If possible, set up SPF alignment in the Return Path with your domain

      • (Ortto’s Custom Domain feature already does both by default)

• What policy should I have in place?

  • Value of “p=none”

    • No rejection or spam-filtering of unauthorized mail from the domain; this is ideal for the beginning stages of DMARC/authentication setup so as to not cause issues for organizational traffic still not authenticated yet

  • Value of “quarantine”

    • Spam-filtering of unauthorized mail; great for testing that all authorized mail streams are properly authenticated, though bad actors are still able to get spoofed messages delivered 

  • Value of “reject”

    • A majority blocking of bad actors from misuse of domain; great for those who have verified all authorized mail streams are properly authenticated

• Should I use a pct tag in my DMARC record?

  • The percent tag is meant to be a testing tool allowing a domain owner to only request partial action taken against a stream of unauthenticated mail. It can be very helpful for those who want to test the water on a stricter DMARC policy; however, it should be known that not all mailbox providers honor the pct tag. Those that don’t will simply honor the policy fully rather than partially

• What happens if I set up a quarantine or reject policy by accident?

  • You can easily edit your DMARC record in your DNS settings to “p=none” or whatever policy you desire

• Does the DMARC policy have to be set up per subdomain?

  • By default, a general DMARC policy set up on the root or organizational domain will cover all subdomains above it unless either:

    • A separate DMARC record is set up on a subdomain

    • A subdomain policy is included in the root domain’s DMARC record (sp=strict, requires strict DKIM/SPF alignment on the subdomain level rather than simply on either sub or root domain levels)

• Why am I getting an error related to “External Domains in your DMARC are not giving permission for your reports to be sent to them”?

  • If you are getting this error or not receiving authentication failure reports, then it is likely that you either:

    • Don’t have a “rua” tag in your DMARC record

    • Haven’t authorized the domain in the email address from the rua tag to receive DMARC reports for this domain

      • See this excerpt

• What do the various failures in my DMARC report mean?

  • You will want to check with your reporting provider to understand their tools more comprehensively but the following are some of the most common failures:

    • DMARC failed — Neither SPF or DKIM were authenticated on the DMARC domain

    • SPF failed — SPF failed to authenticate

    • DKIM failed — DKIM failed to authenticate

    • SPF alignment failed — SPF failed to authenticate on the DMARC domain

      • This can mean a different domain passed SPF but it wasn’t the important, DMARC domain

    • DKIM alignment failed — DKIM failed to authenticate on the DMARC domain

      • This can mean a different domain passed DKIM but it wasn’t the important, DMARC domain

• What about BIMI?

  • BIMI is a fantastic tool that builds off of DMARC to allow better brand visibility for authenticated traffic. However, BIMI is not currently a requirement, is minimally supported currently, and has higher cost/setup requirements that are not worth discussing at this stage. Once DMARC is up and running, please feel free to research BIMI as a possible way to upgrade your marketing traffic with better branding visibility