Domain-based Message Authentication, Reporting & Conformance (DMARC) is a specification designed to help reduce email message abuse, such as incoming spam and phishing messages that misrepresent their origins by forging the message's From: header. DMARC makes it possible for domain owners to use the Domain Name System (DNS) to inform receiving servers of their DMARC policy, which is how they want those servers to handle messages that purport to be sent from their domain but cannot be authenticated as having actually come from it. This policy, which is retrieved by the receiving server via a DNS query while processing the incoming message, can state that the server should quarantine or reject messages that do not align with the policy, or take no action at all (i.e. let the message proceed normally). In addition to the policy, the domain's DMARC DNS record can also contain requests for the server to send DMARC reports to some, outlining the number of incoming messages purporting to be from that domain and whether or not they passed or failed authentication, and with details about any failures. DMARC's reporting features can be useful for determining the effectiveness of your email authentication procedures and how frequently your domain name is being used in forged messages.
Under the Sender Authentication section of the Security Settings dialog, there are three screens for configuring MDaemon's DMARC verification and reporting features: DMARC Verification, DMARC Reporting, and DMARC Settings.
DMARC Verification
As part of the DMARC verification process, MDaemon performs a DMARC DNS query on the domain found in the From: header of each incoming message. This is done to determine whether or not the domain uses DMARC, and if so, to retrieve its DMARC DNS record, which contains its policy and other DMARC related information. Additionally, DMARC utilizes SPF and DKIM to validate each message and requires it to pass at least one of those tests in order to pass DMARC verification. If the message passes then it will proceed normally through the rest of MDaemon's delivery and filtering processes. If it fails, however, then the fate of the message is determined by a combination of the domain's DMARC policy and how you have configured MDaemon to deal with those messages.
If a message fails DMARC verification and the DMARC domain has a policy of "p=none" then no punitive action will be taken and normal message processing will continue. Conversely, when the DMARC domain has a restrictive policy of "p=quarantine" or "p=reject," MDaemon can optionally filter the message automatically to the receiving user's spam (i.e. junk e-mail) folder. You can also choose to have MDaemon reject the failed message completely when the domain is using the "p=reject" policy. Additionally for failed messages with restrictive policies, MDaemon will insert the "X-MDDMARC-Fail-policy: quarantine" or "X-MDDMARC-Fail-policy: reject" header, depending on the policy. This makes it possible for you to use the Content Filter to perform some action based on the presence of those headers, such as sending the message to a specific folder for further scrutiny.
DMARC Verification is enabled by default and recommended for most MDaemon configurations.
DMARC Reporting
When MDaemon queries DNS for a DMARC record, the record may contain tags indicating that the domain owner wishes to receive DMARC aggregate or failure reports regarding messages claiming to be from that domain. The options on the DMARC Reporting screen are for designating whether or not you are willing to send the requested types of reports, and for specifying the meta-data those reports should contain. Aggregate reports are sent daily at Midnight UTC and failure reports are sent per message, as each incident occurs that triggers the report. Reports are always sent as zipped XML file attachments, and there are various parsing tools available online that can make them easy for the recipients to view.
By default MDaemon does not send aggregate or failure reports. If you are willing to send either type of report, enable its corresponding options on the DMARC Reporting screen.
DMARC Settings
The DMARC Settings screen contains various options for including certain info in DKIM reports, logging DMARC DNS records, and updating the Public Suffix file used by MDaemon for DMARC.
DMARC Verification and Mailing Lists
Because the purpose of DMARC is to ensure that the domain found in a message's From: header hasn't been forged, the sending server must be permitted to send messages on behalf of that domain. This can pose a unique problem for mailing lists, because it is common for lists to distribute messages on behalf of list members from outside domains, and yet leave the From: header unchanged. This means that when a receiving server attempts to use DMARC verification on one of these messages, the message will have been sent by a server that is not officially affiliated with the From: header domain. If the DMARC domain happens to be using a restrictive DMARC policy, this could cause the message to be quarantined or even rejected by the receiving server. In some cases this could also cause the recipient to be removed from the list's membership. To circumvent this problem, when MDaemon finds that a messages for a list is coming from a domain with a restrictive DMARC policy, MDaemon will replace the message's From: header with the mailing list's address. Alternatively, you can configure MDaemon to refuse to accept any message for a list when it is from a domain with a restrictive policy. This latter option would effectively make it impossible for a user from a domain with a restrictive policy to post a message to the list. The option to replace the From: header is located on the mailing list editor's Headers screen. The option to reject messages is located on the Settings screen.
Using DMARC for Your MDaemon Domains
If you would like to use DMARC for one of your own domains, meaning that you want receiving mail servers that support DMARC to use DMARC to verify messages claiming to be from you, then you must first ensure that you have created properly formatted SPF and DKIM DNS records for the domain; you must have at least one of those options working correctly to use DMARC. If you are using DKIM then you must also configure MDaemon's DKIM Signing options to sign the domain's messages. Additionally, you must create a DMARC DNS record for the domain. By querying DNS for this specially formatted TXT record, the receiving server can determine your DMARC policy and various optional parameters such as: the mode of authentication you use, whether or not you wish to receive aggregate reports, the email address to which reports should be sent, and others.
Once you have properly configured DMARC and have begun to receive DMARC XML reports, there are a variety of online tools you can use to read those reports and diagnose any potential problems. For your convenience there is also a DMARC Reporter tool provided for you in the \MDaemon\App\ folder. See DMARCReporterReadMe.txt for instructions on how to use it.
Defining a DMARC TXT Resource Record
The following is an overview of the most basic, commonly used components of a DMARC record. For more detailed information, or for information on more advanced configurations, see: www.dmarc.org.
Owner Field
The Owner (also called "Name" or "left-hand") field of the DMARC resource record must always be _dmarc, or it can take the form _dmarc.domain.name if you wish to specify the domain or subdomain to which the record applies.
Example:
DMARC record for the domain example.com
_dmarc IN TXT "v=DMARC1;p=none"
This record would apply to emails from user@example.com or any subdomains of example.com, such as user@support.example.com, user@mail.support.example.com, and so on.
_dmarc.support.example.com IN TXT "v=DMARC1;p=none"
This record would only apply to emails from user@support.example.com, not to emails from, for example, user@example.com.
_dmarc.support IN TXT "v=DMARC1;p=none"
This record would apply to emails from: user@support.example.com, user@a.support.example.com, user@a.b.support.example.com, and so on.
DMARC Record Tags and Values
Required Tags
Tag |
Value |
Notes |
v= |
DMARC1 |
The is the Version tag, which must be the first tag in the DMARC specific text portion of the record. Although other DMARC tag values are not case sensitive, the value of the v= tag must have the uppercase value: DMARC1. Example: _dmarc IN TXT "v=DMARC1;p=none" |
p= |
none quarantine reject |
This is the Policy tag, which must be the second tag in the DMARC record, following the v= tag. p=none means that the receiving server should take no action based on results of the DMARC query. Messages that fail the DMARC check should not be quarantined or rejected based on that failure. They could still be quarantined or rejected for other reasons, such as for failing spam filter tests or other security checks unrelated to DMARC. Using p=none is sometimes called "monitoring" or "monitor mode" because you can use it with the rua= tag to receive aggregate reports from recipient domains about your messages, but those messages will not be penalized by the domains for failing to pass the DMARC check. This is the policy to use until you have thoroughly tested your DMARC implementation and are sure you are ready to move on to the more restrictive p=quarantine policy. p=quarantine is the policy to use when you want other mail servers to treat a message as suspicious when its From: header says that it is coming from you but the message fails the DMARC check. Depending upon the server's local policy, this could mean subjecting the message to additional scrutiny, placing it into the recipient's spam folder, routing it to a different server, or taking some other action. p=reject indicates that you want the receiving server to reject any message that fails DMARC verification. Some servers, however, may still accept these message but quarantine them or subject them to additional scrutiny. This is the most restrictive policy and should generally not be used unless you have total confidence about your email policies and the types of messages or services you wish to allow your accounts to use. For example, if you wish to allow your users to join 3rd party mailing lists, use mail forwarding services, utilize "share this" features on websites, or the like, then using p=reject would almost certainly cause some legitimate messages to be rejected. It could also cause some users to be automatically dropped or banned from certain mailing lists. Example: _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:dmarc-report@example.net" |
Optional Tags
All of the tags listed below are optional. When any of these tags are not used in a record then their default values are assumed.
Tag |
Value |
Notes |
sp= |
none quarantine reject — Default: If sp= is not used, the p= tag applies to the domain and subdomains. |
This tag is for specifying a policy to be used for subdomains of the domain to which the DMARC record applies. For example, if this tag is used in a record that has scope over example.com, then the policy designated in the p= tag will apply to messages from example.com and the policy designated in the sp= tag will apply to messages from subdomains of example.com, such as mail.example.com. If this tag is omitted from the record, the p= tag will apply to the domain and its subdomains. Example: _dmarc IN TXT "v=DMARC1;p=quarantine;sp=reject" |
rua= |
Comma-separated list of email addresses to which DMARC aggregate reports should be sent. The addresses must entered as URIs in the form: — Default: none If this tag is not used then no aggregate reports will be sent. |
This tag indicates that you wish to receive DMARC aggregate reports from servers who receive messages claiming to be From: a sender at your domain. Specify one or more email addresses as URIs in the form: mailto:user@example.com, separating multiple URIs with commas. Example: _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:user01@example.com,mailto:user02@example.com" Ordinarily these addresses will be at the domain covered by this record. If you wish to send reports to an address at some other domain, then that domain's DNS zone file must also contain a special DMARC record indicating that it will accept DMARC reports for the domain. Example record at example.com: _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:non-local-user@example.net" Required record at example.net: example.com._report._dmarc TXT "v=DMARC1" |
ruf= |
Comma-separated list of email addresses to which DMARC failure reports should be sent. The addresses must entered as URIs in the form: — Default: none If this tag is not used then no failure reports will be sent. |
This tag indicates that you wish to receive DMARC failure reports from servers who receive messages claiming to be From: a sender at your domain, when the conditions specified in the fo= tag have been met. By default, when there is no fo= tag specified, failure reports are sent when the message fails all DMARC verification checks (i.e. fails both SPF and DKIM). Specify one or more email addresses as URIs in the form: mailto:user@example.com, separating multiple URIs with commas. Example: _dmarc IN TXT "v=DMARC1;p=quarantine;ruf=mailto:dmarc-failures@example.com" Ordinarily these addresses will be at the domain covered by this record. If you wish to send reports to an address at some other domain, then that domain's DNS zone file must also contain a special DMARC record indicating that it will accept DMARC reports for the domain. Example record at example.com: _dmarc IN TXT "v=DMARC1;p=quarantine;ruf=mailto:non-local-user@example.net" Required record at example.net: example.com._report._dmarc TXT "v=DMARC1" |
For more extensive information on the DMARC specification, see: www.dmarc.org.
See:
