Getting started with DMARC

It is important to first assess the size and complexity of your organization’s email infrastructure. Email domains are a shared resource within most organizations, with use spanning multiple departments, third-party vendors, and even the organization’s own internet-facing applications. Because domains are shared, a successful DMARC project requires strong cross-departmental communication and clear domain management processes.

When deploying DMARC, it’s best to roll it out across all of an organization’s domains instead of focusing on individual domains. Deploying DMARC across your entire domain portfolio provides organizational visibility, and managers get new tools to ensure all email is sent in compliance with the organization’s standards.

To begin, gather a list of all of your organization’s domains so you can systematically put DMARC into place. It will also be important to understand who in the organization uses the domains and has ownership of the third party vendors for that domain, as you will need their support so mailstreams are not disrupted

A DMARC policy allows a domain owner to indicate that their messages are protected by SPF and/or DKIM, and tells the recipient what to do if none of these are verified on a particular piece of email, such as marking it as junk mail or rejecting delivery of the message. Domain owners can set their DMARC policy (referred to as “p=”) to determine what is done to non-compliant email:

• Monitoring (p=none) no impact on mail flows (only DMARC feedback is collected).
• Quarantine (p=quarantine) messages that fail DMARC (e.g. move to the spam folder)
• Reject (p=reject) messages that fail DMARC (don’t accept the mail at all).

DMARC policies typically start at a state of p=none, which is a monitoring phase that gives visibility into how your domain is being used and how SPF and/or DKIM are functioning, and moves towards a policy of p=reject.

Before advancing your DMARC policy, make sure that all of your sources are in alignment, where the domain found in the “From:” header must match the domain validated by SPF and/or the source domain found in a valid DKIM signature.

To start generating DMARC data, you must first publish a DMARC record for each domain you wish to monitor. dmarcian’s DMARC Record Wizard makes it easy to create a DMARC record.

A DMARC record exists as part of your Domain Name System (DNS) record, which routes traffic on the internet. Your domain’s DMARC record is a text entry within the DNS record that tells the world your email domain’s policy based on the configured SPF and DKIM protocol. The DMARC record also indicates an address where DMARC reports should be sent—part of the valuable feedback DMARC provides.

Here are instructions on how to publish a DMARC record with your DNS host.

Once you’ve published DMARC records, DMARC data will typically begin to generate within a day or two in the form of reports that give you insight into the way your domains are handling email.

These reports are XML-based and can be difficult for humans to read and make sense of, especially when they can number in the thousands.

dmarcian’s DMARC Management Platform specializes in processing these reports and identifying areas of improvement so that DMARC can be more easily deployed throughout an organization. You can test dmarcian’s platform over a free, 14-day trial. We categorize sources of email and present you with DMARC compliance status (based on email sources, DKIM and SPF), and we alert you if there are any potential threats to or abuse on your domains.

The p=reject DMARC policy instructs email receivers to refuse email that fails DMARC. By default, email that fails under a reject policy is not accepted. The p=reject policy is the ultimate control to prevent unauthenticated messages from being delivered from your domain. Read more about advancing your DMARC policy.