Putting DMARC Into Practice
The detailed process for implementing DMARC using Agari DMARC Protection is the remainder of this guide; however, the high-level process is as follows: domain owners who wish to become DMARC-compliant need to perform 3 activities, repeating as necessary for each domain they plan to protect:
Publish a DMARC record
To begin collecting feedback from receivers, publish a DMARC record as a TXT record with a domain name of “_dmarc.<your-domain.com>”:
“v=DMARC1; p=none; rua=mailto:dmarc-feedback@<your-domain.com>;
Doing so will cause DMARC-compliant receivers to generate and send aggregate feedback to “dmarc-feedback@<your-domain.com>”. The “p=none” tag lets receivers know that the domain owner is only interested in collecting feedback.
Deploy email authentication: SPF and DKIM
Deployment of SPF involves creating and publishing an SPF record that describes all of the servers authorized to send on behalf of an email domain. Small organizations usually have simple SPF records, where complex organizations often maintain SPF records that authorize a variety of data-centers, partners, and 3rd-party senders. DMARC-supplied aggregate feedback can help identify legitimate servers while bootstrapping an SPF record.
Deployment of DKIM requires domain owners to configure email servers to insert DKIM-Signatures into email and to publish public keys in the DNS. DKIM is widely available and supported by all major email vendors. DMARC-supplied aggregate feedback can help identify servers that emit email without DKIM signatures.
Ensure that Identifier Alignment is met
DMARC-supplied aggregate feedback can be used to identify where underlying authentication technologies are generating authenticated domain identifiers that do not align with the Email Domain. Correction can be rapidly made once misalignment is identified.
Why Implementing DMARC is Challenging
Poor Visibility
Most companies don’t realize how complex their email ecosystem is until they begin getting aggregate data from DMARC reporting. Standard reporting comes in the form of individual XML files that specify domain names, IP addresses and authentication details. While many tools can parse and visualize this XML data, making sense of the stream and understanding what subsequent actions to take to improve the authentication status of domains is very difficult and error prone, requiring a deep understanding of email flows.
Discovering & Authorizing 3rd Party Senders
The most challenging step of the DMARC journey is understanding all of your third party senders and ensuring that legitimate senders are authenticating properly. On average, customers have 64% of legitimate emails sent through 3rd parties such as Salesforce.com, Marketo, or MailChimp.
The cost of “doing it wrong”
Despite the emergence of new messaging platforms, email continues to be the most critical vehicle for communication and digital engagement for organizations. Incorrectly configuring authentication can lead to false positives, deliverability issues, and brand damage. Taking the final step to a Reject policy can be a daunting prospect if the business impact of undeliverable email is unknown or cannot be predicted.
Specifying “Authentic” Email
Agari DMARC Protection and the DMARC specification allow you to identify and authorize legitimate (approved) senders who send mail “from” your domain differently from illegitimate senders who may be abusing your brand.
What You’ll Be Doing
While DMARC implementation involves a level of technical understanding of the specifications and how to use them, it also involves administration, management, and communication. Over time, you are likely to gain an intimate understanding of email senders, both internal and external to your organization.
Moving toward a DMARC policy of “p=reject”
DMARC is initially implemented by adding TXT record in the DNS record for your domain. The file contains properties and values that you edit to specify how DMARC applies policies for the domains that you control.
Your goal in the process of implementing DMARC is to move, ultimately toward a policy (labeled 'p') of 'p=reject'. A reject policy tells email receivers that all non-compliant emails should be discarded. However, the DMARC specification contains a variety of policies to afford a gradual implementation. without impacting your mail flow. Allowing for incremental deployment and strengthening of DMARC policies was a primary design goal for the specification. See How DMARC Works.
You start with a simple “monitoring-mode” record for a sub-domain or domain that requests DMARC receivers to send you statistics about messages they see using your (sub-)domain. You can do this even before you’ve implemented SPF or DKIM in your messaging infrastructure (though until they are in place you won’t be able to move beyond this step).
As you introduce SPF (Build and Propose a New SPF Record) and DKIM (DomainKeys Identified Mail), the reports will provide the numbers and sources of messages that pass these checks, and those that don’t. You can easily see how much of your legitimate traffic is or is not covered by them, and troubleshoot any problems. You’ll also begin to see how many fraudulent messages are being sent, and where from.
When you believe that all or most of your legitimate traffic is protected by SPF and DKIM, you can implement a “quarantine” policy — you’re now asking DMARC receivers to put messages using your domain that fail both of these checks into the local equivalent of a spam folder. You can even request that only a percentage of your email traffic have this policy applied – you’ll still get the statistical reports that allow you to see what’s happening to your messages.
Eventually as any implementation problems are addressed, you can increase that percentage to 100% at whatever pace you’re comfortable with. In the end, all messages that fail the DMARC checks should be going to the spam folder instead of your customers’ inboxes.
DMARC prerequisites
Before you start with your DMARC implementation using DMARC Protection, you will need to perform the following tasks:
Ensure you have access to DMARC Protection.
Your Agari representative should have provided access for at least one user account to DMARC Protection, located at bp.agari-eu.com.
Contact Agari support https://www.
Agari.com/support/
The one user account is an administrative account; additional user accounts (with varying roles and permissions for delegated administrative or read-only rights) can be created from this original account. For details, see User Accounts.
Gather a list of domains
You will need a list of domains and sub-domains that you plan to protect for your organization. This list should include the primary domain for your organization, that is, the one most associated with your organization and the one most used for sending email (for example: coltrane.net), as well as any defensive or test domains that your organization owns and maintains (for example: blue.coltrane.net, coltrane-soprano.net, coltrane-tenor.net, a-love-supreme.net, etc.). Keep in mind any history of mergers and acquisitions, along with specific instances where domains were created and used to distinguish products and processes.
Obtain the ability to make DNS changes
You will need the ability to make changes to the Domain Name System (DNS) records for the domains you plan to protect. The DMARC authentication protocol (as well as the SPF and DKIM protocols) relies on DNS services in order to perform authentication. You’ll need to make changes to DNS throughout the process of securing your domains — from getting initial data to flow into DMARC Protection, to modifying your DMARC policies from monitor to reject.
Compile a list of Stakeholders
The process for authenticating all outbound email for your organization may involve a large number of groups, depending on the size of your organization. For example, you may have:
- A marketing team that sends email blasts to potential customers by using third-party software.
- A support team that communicates with existing customers both directly and through support software.
- A business continuity team tasked with sending order confirmations or receipts automatically from back-end systems.
All teams need to be aware of requirements for authentication of the email they send on behalf of your organization — as well as the deliverability issues if they fail to authenticate properly as DMARC policies you enable become more stringent. Communicate early and often throughout this process!
References
Here is a video reference
https://www.brighttalk.com/webcast/10593/104965/dmarc-whiteboard-session-for-engineers