You’ve spent so much time protecting the sending reputation of your email program, but what about your corporate environment? Doesn’t it deserve the same type of anti-fraud methods you’ve implemented for your marketing and/or transactional emails? One way you can be an anti-fraud champion is by educating your company about SPF, DKIM, and DMARC.
Setting up a DMARC record for any sending environment should follow the same basic enforcement principles – start in monitor mode, progress to quarantine mode, and graduate to reject mode to stop the fraudulent emails from reaching the inbox or bulk/spam folders. Though, you may find that you spend more time in monitor mode with your corporate environment, as there may be multiple third-party senders you’re unaware of. For example, perhaps employee benefits, retirement planning, and/or time management system are sent from several third-party MTAs that use your sending domain. So take your time auditing your DMARC reports to ensure that you’ve properly accounted for all the authorized IPs and domains.
Although there’s no one size fits all DMARC record for corporate environments, you may find the following example helpful.
- Say, you are the domain owner for example.com.
- WageWorks is an authorized third-party sender that emails on your behalf, but from their own MTAs.
- You delegated authority for them to send email from wage.example.com, which will show up in their From: and Return-Path: email headers.
- WageWorks creates and publishes an SPF record for wage.example.com in their DNS.
- You update the SPF record for example.com, so that WageWorks’ IPs have been listed.
- You create a DKIM private/public key pair. You give WageWorks the private key and you publish the public key in the wage.example.com zone file.
- You are responsible for creating the DMARC record, not WageWorks because your record will cover example.com and wage.example.com when you create the DMARC record listed below. Ensure that WageWorks doesn’t create a DMARC record too, especially if it contradicts your policies.
- You’ll create an entry in DNS for the zone file with:
- The DMARC record will look like this:
“v=DMARC1; p=none; rua=mailto:email@example.com”
- Always start the DMARC record with the version (v), as it is a required tag.
- Set the policy (p) to monitor mode (none).
- Request for aggregate reports (rua) in the beginning, as many people often find the forensic reports (ruf) challenging to fully understand due to the magnitude of data that is included.
- If you want WageWorks to also receive the reports, add their email address as well so that it looks like this:
“v=DMARC1; p=none; adkim=r; aspf=r; rua=mailto:firstname.lastname@example.org, mailto:email@example.com”
- At this point, you might be wondering about domain identifier alignment, because example.com and wage.example.com aren’t exactly identical. It is actually considered to be “aligned” by default. This can get confusing, but bear with me. There are these optional DMARC tags, called aspf and adkim, that can be adjusted to force domain misalignment when undergoing the SPF and DKIM checks. If these tags are set to strict (s) mode, then the WageWorks emails would fail DMARC because example.com and wageworks.example.com would be considered misaligned. However, the default setting is relax (r), which makes it aligned. Since the aspf and adkim tags are optional in the first place and we want its default values, there’s no need for us to include it in the DMARC record.
What other situations have you encountered with your corporate environment?