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.
The objective of this stage is to collect data so we get to know how email from the domain flows and, in parallel, make sure that all DMARC-related records are properly set up.
For this you run the domain with a permissive DMARC policy (i.e. p=none) and reporting enabled.
You should wait at least two weeks in this stage to capture any seasonality in email volume. As explained in the first post, if you send a large volume of emails periodically, you should adjust wait times accordingly.
For example, if you have a monthly newsletter, you should collect data for at least two month so you can fully capture your newsletter email flow.
For low email volume domains, it is recommended that you wait until a significant number of messages is collected. The exact number depends on how email is used by domain users, but in general anything less than 100 emails is too low.
In parallel to collecting data, you should keep adjusting your DNS records as you get insights from incoming DMARC reports.
You do the above by checking your records periodically, and looking at failing SPF checks. Failing DKIM selector should be checked too. You adjust your SPF record by adding legitimate servers to it. Failing DKIM selectors and records should be adjusted on the DNS and/or sending server too. Make sure you update the control worksheet with any changes you make.
If you are using DMARCPal, you can use the Failure Report to easily list servers with the most SPF, DKIM, and DMARC failed checks, and make the necessary adjustments to your DNS records.
When you’re confident that all senders were collected, that all DKIM-enabled servers are properly configured, and all failed DMARC records you see in DMARCPal are coming from unknown senders (probably phishing attempts), you’re ready to advance to the next stage.
Example.inc weeks one and two — surveying & adjusting
We’ve been operating example.com in survey & adjust mode for a few days. So far we have got some insights from DMARC reports that allowed us to adjust our worksheet and DNS records.
The first thing we do after receiving a few DMARC reports is check DMARCPal’s Failure Report looking for top senders that have failed DMARC checks. We do this to easily spot any server we missed when collecting all authorized servers.
Indeed, we’re able to discover a low volume server sending emails that were failing both SPF and DKIM checks.
After some investigation we discover that the IP belongs to a monitoring server, and all emails are basically system notifications. We then add the server IP to the SPF record, and update our worksheet.
We decide not to set up DKIM on this server, since the emails already have a @example.com “From” line, therefore they will pass DMARC, because SPF will pass and will be in alignment.
After a few more days, we notice that many emails from a specific domain are being flagged. Actually we’re seeing failed checks from many hosts from this domain. The domain name, too, is from a big email marketing company.
Strangely enough, the emails are passing SPF and DKIM — they’re just not passing DMARC, because the domains aren’t in alignment. This raises a red flag. We go check this further.
After some investigation, we discover that this email service is used for marketing purposes. However, there’s an issue…
The emailing server service is not set up for emailing using example.com. Actually it sends email using another unrelated domain, but all emails are sent with a “From” header using example.com.
In other words, emails headers look like this:
Envelope-From: bounces@crm.example.net
From: marketing@example.com
DKIM-Signature: (...); d=crm.example.net; (...)
Subject: ....That’s why we’re seeing those records in example.com’s DMARC reports. We clearly see that the domains are different, so DMARC won’t align.
The emailing service indeed provides a SPF record we could include that would authorize their servers to send example.com emails. However, we found that there is no way to use example.com in the envelope sender, so trying that would be pointless — DMARC won’t pass, even if SPF would authorize their servers.
Ideally we should be able to specify the signing domain for DKIM. This way we could set it to example.com, and DKIM checks would pass and be in alignment.
However, the emailing service does not allow us to do that.
At the end of the day, we decide to change the “From” address in the emails to use the domain configured in the email service. The example.com address is moved from the “From” header to a “Reply-To” header.
This solution will avoid those emails being rejected by DMARC when we change to a more strict policy for example.com.
This is how the final email headers look like:
Envelope-From: bounces@crm.example.net
From: marketing@crm.example.net
Reply-To: marketing@example.com
DKIM-Signature: (...); d=crm.example.net; (...)
Subject: ....After applying this change, we let the domain run with until the rest of the planned date for this stage.
We then reach the last day of this stage without any modification to our sender and DKIM selector list. We are ready to advance to the next stage of the DMARC setup process.
Next: Stage 3 — Test & adjust
