This blog is the final part of three in our blog series on DMARC.
If you are a business sending transactional emails, you need to ensure that the recipient is receiving a verified email from you or your business and is not malicious. This can be done by implementing one or more forms of email authentification. The benefits of DMARC in email authentication are apparent, with the ability to eliminate fraudulent emails before they reach their intended target and provide immediate insight into businesses email threat landscape.
Adopting and configuring DMARC is not easy, and the tedious setup can easily be subject to error. The entire DMARC lifecycle can take up to 3 to 6 months before businesses can effectively see the results.
Here is an example of the typical lifecycle for DMARC:
There is a misconception that DMARC configuration is not used as many email gateways are not configured to validate DMARC compliance. The actual concept suggests that DMARC would help in protecting a companies domain. It would act as evidence in case of any legal matters raised against the domain.
There is also a myth in the current world that DMARC is complex architecture to implement; however, the DMARC compliance journey is one of the easiest non-intrusive and no business impact to start and achieve level 1 policy compliance. The next level of policy quarantine and rejection may have a business impact, but if the environment is known and procedures defined, target compliance can be achieved within 6months duration.
DMARC is DNS published record that should be created as a text record. The DMARC record should be published in the external DNS so that all the receiving email gateways and email service provider can look at those records and take appropriate action on the email.
DMARC Syntax
"v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@example.com; ruf=mailto:dmarc@example.com; adkim=r; aspf=r; rf=afrf;"
The below table shows the various tags to be used in the DMARC record to be published in the DNS:
| Tag | Tag Value | Name | Description |
| v | DMARC1 | Version | Identifies the record retrieved as a DMARC record. It must be the first tag in the list. |
| p | reject | Policy | Policy to apply to email that fails the DMARC test. Valid values can be 'none', 'quarantine', or 'reject'. |
| pct | 100 | Percentage | Percentage of messages from the Domain Owner's mail stream to which the DMARC policy is to be applied. A valid value is an integer between 0 to 100. |
| fo | 1 | Forensic Reporting | Provides requested options for the generation of failure reports. Valid values are any combination of characters '01ds' separated by ':'. |
| ri | 3600 | Reporting Interval | Indicates a request to Receivers to generate aggregate reports separated by no more than the requested number of seconds. A valid value is a 32-bit unsigned integer. |
| rua | mailto:dmarc@example.com, mailto:dmarc_rua@example.com | Receivers | Addresses to which aggregate feedback is to be sent. Comma-separated plain-text list of DMARC URIs. |
| ruf | mailto:dmarc@example.com, mailto:dmarc_ruf@example.com | Forensic Receivers | Addresses to which message-specific failure information is to be reported. Comma-separated plain-text list of DMARC URIs. |
| adkim | r | Alignment Mode DKIM | Indicates whether strict or relaxed DKIM Identifier Alignment mode is required by the Domain Owner. Valid values can be 'r' (relaxed) or 's' (strict mode). |
| aspf | r | Alignment Mode SPF | Indicates whether strict or relaxed SPF Identifier Alignment mode is required by the Domain Owner. Valid values can be 'r' (relaxed) or 's' (strict mode). |
| rf | afrf | Forensic Format | Format to be used for message-specific failure reports. Valid values are 'afrf' and 'iode |
DMARC Policies
- Monitor policy: p=none
The first policy is the none (monitor) policy: p=none. The DMARC policy none instructs email receivers to send DMARC reports to the address published in the RUA or RUF tag of the DMARC record. his is known as a Monitoring only policy because with this (recommended starting) policy you gain insight into your email channel. The none policy will give insight into the email channel but does not instruct email receivers to handle emails failing the DMARC checks differently, therefore it is also known as the monitor policy. The none policy only gives insight into who is sending email on behalf of a domain and will not affect the deliverability.
- Quarantine policy: p=quarantine
The second policy is the quarantine policy: p=quarantine. Besides sending DMARC reports, the DMARC policy quarantine instructs email receivers to put emails failing the DMARC checks in the spam folder of the receiver. Emails that pass the DMARc checks will be delivered to the primary inbox of the receiver. The quarantine policy will already mitigate the impact of spoofing, but spoof emails will still be delivered to the receiver (in the spam folder).
- Reject policy: p=reject
The third policy is the reject policy: p=reject. The DMARC policy reject. Besides sending DMARC reports, the DMARC policy reject instructs email receivers to not deliver emails failing the DMARC checks at all. Emails that pass the DMARC checks will be delivered in the primary inbox of the receiver. This policy mitigates the impact of spoofing. Since the DMARC policy reject makes sure all incorrect setup emails (spoofing emails) will be deleted by the email receiver and not land in the inbox of the receiver.
Note: For DMARC to function correctly you need to publish the SPF and DKIM record in the DNS as well. The SPF record would have the IP Address of all the Email gateway servers which is used to send emails for the domain. The DKIM record would be a public key generated from the email gateway server which would associate all the emails sending from the gateway with the corresponding private key.
SPF record syntax
The below sample shows the SPF record to be published in the DNS
Sample: "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all"
| Tag | Tag Value | Description |
| Spf1 | SPF | Identifies the record retrieved as a SPF record. It must be the first tag in the list. |
| Ip4 | ip4:x.x.x.x/24 | IP Address Subnet associated with email gateway. |
| a | A Record | If used on its own then it uses the A record of the current domain (a). If you put a domain or host name after it then it uses that A record(a:domain.com). This allows you to update your DNS without having to make a change to the SPF record. |
| include | Include_spf.example.com | This tag allows the inclusion of another domain or sub domain's entire spf record. |
| exists | Exists.example.com | This tag performs an A record lookup on the domain used to see if one exists. If the A record exists then this passes. |
| all | ~all | This tag MUST go at the end of your record and provides instruction of what a recipient should do if there is not a match to your SPF record. There are 3 common options used that allow a sender to tell the user to reject mail that does match the record (-all), treat mail as suspicious (~all), and a neutral recommendation (?all) which leaves it up to the recipient. In most cases, treating the mail as suspicious will work (~all) since it will generally cause non-matching messages to be marked as spam. |
DKIM record syntax
The below sample shows the DKIM record which would be a text record with the public key generated from the email gateway.
<selector(s=)._domainkey.domain(d=)>. TXT v=DKIM1; p=<public key>
Sample: dk1024-2012._domainkey.returnpath.com. 600 IN TXT "v=DKIM1\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1TaNgLlSyQMNWVLNLvyY/neDgaL2oqQE8T5illKqCgDtFHc8eHVAU+nlcaGmrKmDMw9dbgiGk1ocgZ56NR4ycfUHwQhvQPMUZw0cveel/8EAGoi/UyPmqfcPibytH81NFtTMAxUeM4Op8A6iHkvAMj5qLf4YRNsTkKAV;
| Tag | Description |
| .domainkey | Identifies the record retrieved as a DKIM record. It must be the first tag in the list. |
| V= | Indicates the version of the signature specification. The value should always be set to 1. |
| A= | Indicates the algorithm used to generate the signature. The value should be rsa-sha256. Senders with reduced CPU capabilities may use rsa-sha1. However, using rsa-sha1 is discouraged due to potential security risks. |
| s- | Indicates the selector record name used with the domain to locate the public key in DNS. The value is a name or number created by the sender. |
| b= | The hash data of the headers listed in the h= tag; this hash is also called the DKIM signature and encoded in Base64. |
| bh= | The computed hash of the message body. The value is a string of characters representing the hash determined by the hash algorithm. |
| d= | Indicates the domain used with the selector record (s=) to locate the public key. The value is a domain name owned by the sender. |
| h= | A list of headers that will be used in the signing algorithm to create the hash found in the b= tag. The order of the headers in the h= tag is the order in which they were presented during DKIM signing, and therefore is also the order in which they should be presented during verification. The value is a list of header fields that won't change or be removed. |
Ready to implement DMARC compliance and move towards protecting your domains from anti-spoofing and fraud?
The Missing Link, as a security provider, provides professional services to help clients on the journey of DMARC compliance. We partner with key email gateway service providers to analyse the DMARC reports and compliance in a more executive format.
As a security service provider, The Missing Link can help your business achieve the DMARC policy reject maturity level in a specified timeframe and can help in clarifying the misconceptions and myths around DMARC.
