Content:
DMARC (Domain-based Message Authentication, Reporting and Conformance) acts as an extension to SPF and DKIM, providing a mechanism to alert the server owner to SPF/DKIM failures.
As such, it requires those two to be configured first. If you haven’t done this yet, check out our articles to get these set up.
The DMARC record instructs the recipient on how to proceed, should SPF or DKIM fail. While recipient’s inbox spam filter could mark such email as spam, DMARC can prevent the email from even getting that far.
Adding a DMARC DNS Record
DMARC lives entirely in a DNS record; there’s nothing to set up on our machine.
v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; adkim=s; aspf=s;Again, this record is made of several parts, which will be explained below.
- v=DMARC1: DMARC version number, set to 1.
- p=none: DMARC policy to apply. Can be either ‘none’, ‘quarantine’ or ‘reject’.
- rua=mailto:dmarc@example.com: Email address for which aggregate feedback is sent.
- ruf=mailto:dmarc@example.com: Email address for which message-specific (forensic) feedback is sent.
- adkim=s: Sets the DKIM alignment mode, can be either ‘s’ (strict) or ‘r’ (relaxed).
- aspf=s: Sets the SPF alignment mode, can be either ‘s’ (strict) or ‘r’ (relaxed).
There’s a lot to digest here, but fortunately, it’s pretty straightforward.
Setting the DKIM/SPF Alignment Modes
The final two settings, adkim and aspf, define how strictly the DKIM and SPF records are matched. This is important when sending emails from subdomains.
The strict setting requires an exact domain match with the corresponding record, while relaxed only requires a match on the base domain.
For example, if our DKIM record is set up for example.com, emails from admin@example.com will pass in both strict and relaxed mode. An email sent from admin@marketing.example.com, however, will only pass the relaxed test. The strict test will fail due to the full domain not being an exact match.
For this reason, it is generally recommended to set these to relaxed, unless you’re certain strict will not cause issues. For our setup, strict will be fine.
Relaxed mode is the default – if you want to use relaxed mode, adkim and aspf can be removed from the DMARC record entirely.
Adding Feedback Email Addresses
Our command includes two options which specify an email address.
The first of these, rua, is used by the recipient to send feedback on the checking process, informing them of the outcome of the DKIM/SPF checks. This feedback is aggregated, and usually sent daily, covering the emails sent during this period.
The second, ruf, is similar to the rua. However, the address specified here will be provided email-specific responses to checks. This can be useful to see the exact emails that failed checks, and ensure that no legitimate emails are failing.
It’s important to note that many email providers do not use the ruf feedback mechanism. As the specific email is forwarded as part of the message, it opens up potential privacy concerns, as emails will be sent to the specified address without the knowledge of the sender or recipient.
They don’t have to be set to the same email address; that has been done here for convenience.
Make a note of the email address(es) set here, as we’ll need to make sure we set up the mailbox(es) later on.
Setting the DMARC Response Policy
The final option, p, sets the DMARC response policy. This will instruct the email server checking the record how to proceed with an email that has failed the checks.
With this set to none, the receiving server is instructed to ignore the failed checks, and accept the email as normal. With this setting, DMARC is effectively set to reporting only – failure reports will still be sent, but no action additional action will be taken.
The quarantine setting will tell the server to treat the email as spam.
If the reject setting is used, the server is told to reject the message outright. The email will never reach the recipient’s mailbox.
It’s important to note that a setting of none doesn’t mean the email won’t be flagged as spam – it just means the reason the email is flagged as spam won’t be due to DMARC. Email filters set up on the receiving server will still act as usual.
Creating and Testing the Record
Once you’ve decided on the settings you wish to use, add the DMARC record to your domain’s DNS records.
As with SPF and DKIM, you’ll need to add this as a plain text record, unless your host has a specific DMARC option.
With the record added, head to MX Toolbox to test the record.
If you’ve chosen to set the DMARC policy to none, you’ll get an amber light in the bottom section of the test. This is fine – it’s just letting you know the policy is not active.
Otherwise, you should see a green result, as above. If not, double check the syntax of your record. There’s not a whole lot to check here, so there shouldn’t be any issues.
DMARC is not currently widely used, as it is a fairly recent development. Many implementations still err on the side of caution, with weaker settings as in the example created above. Due to the consequences of an incorrectly configured reject setup (emails never reaching the recipient), it is important to thoroughly test your setup before committing to a stricter configuration.
DMARC could evolve to become a powerful spam-fighting tool in the future, as adoption increases.