DMARC is great. It allows you to publish your email sending policies, and those are used to prevent phishing emails using your domain. On top of that, it also provides reporting facilities that give you insights on your email delivery.
Implementing DMARC on new domains is straightforward. You just start with the most strict rules straight away, since you have total control of who is sending emails on your behalf.
However, that is not that simple if you have an established domain.
If you domain email is already up and running, with several hundreds of messages being sent per week, many email sources, such as on-premises corporate email gateways, outsourced email services (Mailchimp, Sendgrid, etc.), roaming users, etc., then setting up DMARC is challenging.
Not that setting up DMARC is difficult. It is not.
The challenge lies in managing the process in a way that allows you to move forward with the implementation in a timely manner, while keeping your email stack secure, and up and running.
Not to mention while keeping your users happy.
In this post series we will be introducing the 5-Stages DMARC Setup process. The 5-Stages DMARC Setup is a step by step process to set up DMARC on an established domain in a way that won’t disrupt email flow, while keeping your users happy.
Also, in the series you will get a good overview of all aspects of DMARC deployment. The series also serves as reference in case you struggle while setting up DMARC on busy domains.
Notice that by “busy domain” we mean any domain with a moderate number of emails that may be disrupted by an unplanned deployment of DMARC. The goal here is not, by no means, imply that there’s a certain amount of email traffic on which this process cannot be applied anymore. In fact the 5-Stages DMARC Setup process can be applied to any domain that has any traffic.
Lastly, this series also serves as a tutorial of the 5-Stages DMARC Setup process. Throughout the posts we will be documenting the application of the process to an established, busy domain having all the challenges mentioned above.
Before we begin, there’s a few important points we need to talk about.
You don’t need to be an absolute expert in email and DMARC to follow these posts. However, we expect some basic knowledge of how email and SMTP work. Understanding of core concepts of SPF, DKIM, and DMARC is also assumed.
If you struggle with some concept or terminology, you can use the search box in the blog to find pages explaining them. A good place to start is with the basic series, such as What is SPF?, What is DKIM?, and What is DMARC?.
If you don’t find the concepts in our blog, feel free to use your favorite search engine. Fortunately all the topics we’re going to cover are open Internet standards, and there is plenty of information about them available on the web.
Lastly, you can always contact us and ask. We’re more than happy to help you.
Changes to DNS zones can take double-digit hours to propagate. Big email services, such as Gmail and Microsoft 365, take at least a day to send DMARC reports. Email volumes can be seasonal, with a frequency of weeks or months.
All this means that for a successful DMARC setup there will be a lot of waiting.
It is not that it is going to take a lot of time from you. It is just that wait times for changes to take effect are long, and you cannot rush them.
Just to give you an idea, we recommend clients to wait at least two weeks at most phases of the 5-Stages DMARC Setup process. This is to give time not only for DNS changes to propagate fully, but also to capture weekly seasonality in their emailing (for example, higher email volumes on Mondays).
Of course, if you send a big volume of emails at longer intervals, you should adapt wait times accordingly. For example, if your domain sends a monthly newsletter, at least two months of data collecting at each stage is advised.
Fortunately you don’t need to wait to read this post series. You can follow the application of 5-Stage DMARC Setup to a real-life domain as you read these pages. We have already done all the waiting for you.
The data you will see in the tutorial part of this series is from a DMARCPal client account with email volume in the range of several thousands emails a week. These are business-to-customer emails, with recipient domains all over the Internet. They also have a marketing email list, with sporadic emailing to another few thousands addresses. The client domain is hosted on Google Workspace.
For privacy reasons, the account was cloned, and host names, IP addresses, DKIM selectors, and any other identifying information were replaced with example values. The main domain (plus all subdomains and fully qualified host names) were renamed to example.com, or to subdomains of example.com. IP addresses belonging to the account were changed to the private 192.168.0.0/16 network. External host names were renamed to domain under the .test TLD, and IP address to the 10.0.0.0/8 network. All data relationships were kept, so you can relate names and network addresses on all screens and reports. We will call the company Example Inc. throughout this post series.
We will be using DMARCPal for DMARC report collection, data querying, and tools support. Although this process can be carried out with in-house tools — or even by direct analysis of raw DMARC reports in XML format –, using a DMARC processing and analytics tool saves a lot of time, and makes the process way easier. The screenshots you will see throughout the series were all taken from DMARCPal Console. They should be self-explanatory for anyone that knows the basic concepts of email and DMARC.
Ready? Let’s move on to our second post in the series: DMARC setup stages