This is a continuation post covering a process to setup DMARC on active domains. Visit A (sane) DMARC setup process for busy email domains to know more about this post series.
Mistakes can happen.
An updated DKIM selector record may be missing a semicolon. Someone in a rush could mistype the domain of your marketing email sender in your SPF record. Those small errors could make your DNS record invalid, which can make compliant servers ignore them entirely.
These situations can not only disrupt your email deliverability, but also open your domain for forged emails and phishing attacks.
And since nobody is going to report those errors to you (DMARC has no provision for that), your email deliverability can be hurt, and your domain can stay unprotected for a long time before someone notices it.
This can severely damage your email domain reputation.
That’s why it is important to you adopt a process that monitors and journals your SPF, DKIM, and DMARC records.
The most basic monitoring you can do is to check your DNS records and try to find any errors that may render them invalid.
Journaling helps in that you can always review previous versions of a DNS record to compare changes. Reverting to a “safe” set of records is also possible.
You can do all that manually. For example, you can send and email to yourself with old DNS records whenever you change them. This will create a track record you can check in case you need to debug email issues.
Doing it manually may not work well, though. It is so easy to miss a change. This get more complicated if you heavy many people managing your domain’s email.
Ideally you should use a tool to automate this, We are talking here about tools that check your domain everyday and notify you when they find any errors that may make those records non-compliant. Keeping an automated history of DNS records can also be very useful.
Example.inc week six and beyond – monitoring the domain
To monitor example.com DNS records to quickly discover errors, we will be using DMARCPal monitoring tools. Actually, in DMARCPal we don’t need to do anything to enable monitoring – it is enabled by default.
Since stage 1 of the DMARC setup process we’ve been using a single account to manage example.com. To make the process more robust, we ask key email admins to create separate DMARCPal accounts, so we can share example.com management. This way, if the monitoring detects any errors on DNS records, all accounts sharing access will receive a notification email.
On top of that, we use the domain timeline to inspect all DNS record changes detected by DMARCPal. This frees us from the task of journaling changes manually.
Many weeks have passed. Every now and then we go back to the console to check domain email flow, and any unexpected behaviour.
So far, everything is good for Example Inc. Scammers are having a hard time spoofing @example.com emails.
And that’s the end of our post series.
We hope that the series was useful to showcase the 5-Stage DMARC Setup process, and how it can be used to safely deploy DMARC on busy domains.
As we saw, deploying DMARC on a active domain requires some attention, but is perfectly doable. As long as you make sure you follow a consistent process like the one we described here, the risks of impacting domain email deliverability is close to none.
Happy emailing!
