Domain-based Message Authentication, Reporting & Conformance (DMARC) is an email authentication, policy, and reporting protocol. It builds on the widely deployed SPF and DKIM protocols, adding linkage to the author (From:) domain name, published policies for recipient handling of authentication failures, and reporting from receivers to senders, to improve and monitor protection of the domain from fraudulent email.
To leverage the DMARC protection, the sender domain owner should publish corresponding SPF, DKIM, DMARC records to DNS, send the message from the designated hosts or sign the message before sending; the message receiver (MTA, MUA) should get the instructions, including alignment criteria and actions in the record, combined with the local settings to do the verification and take necessary actions. For more details on DMARC, refer to RFC7489.
In this guide, we will introduce the DMARC feature in Trend Micro Email Security (EMS), how to use it, and how to solve problems or violations.
Introduction on Trend Micro Email Security DMARC
Trend Micro Email Security DMARC feature will prevent the spoofed messages by checking these two sides:
- DMARC-SPF. It does an SPF checking and its alignment matches between RFC5321.MailFrom domain and RFC5322.From domain.
- DMARC-DKIM. It does a DKIM checking and its alignment matches between RFC5322.From domain and "d" tag in signature.
When either DMARC-SPF or DMARC-DKIM side gets a "Pass" result, the DMARC will also get a "Pass" result. If both sides get a "Fail" result, the configured action will be taken.
The EMS DMARC feature contains two (2) modes - default and enforced. The two modes differ in the DMARC pass criteria, which is stricter in the Enforced Mode compared to the default.
- Default Mode. After enabling the feature, all senders are under this mode by default.
- Enforced Mode. If the sender is added to the Enforced Peers list, it will be under this mode.
The following list describes the acronyms and definitions for the terms used throughout this document:
| Term | Definition |
|---|---|
| UI | User Interface |
| RFC | Request for Comments |
| SPF | Sender Policy Framework |
| DKIM | Domain Keys Identified Mail |
| envelop sender RFC5321.MailFrom | The field value of "Mail From:" command described in RFC5321. For example, "Mail From: <test@example.com>", envelop sender is test@example.com. |
| header sender RFC5322.From | The field value of "From:" header described in RFC5322. For example, "From: <test@example.com>", header sender is test@example.com. |
| Organization domain | The main domain combined with the domain extension, found by checking a list of public DNS suffixes, and adding the next DNS label. For example, "a.b.c.d.example.com.au" and "example.com.au" will have the same organizational domain, because there is a registrar that offers names in ".com.au" to customers. |
The SPF checking follows the SPF protocol, using the connecting IP of the message to compare with the designated hosts in sender’s SPF record, and the result could be Pass, Fail, SoftFail, None, Netural, PermError, and TempError. For more details on these results, refer to RFC7208.
Only the Pass or Fail result can show the actual relationship between the sender and the connecting IP. The other results can lead to a different final result. To avoid confusion, clear the intermediate status that asks the sender to correct the SPF DNS record, if possible.
The SPF alignment match has two (2) modes - relaxed mode and strict mode. This is decided by the "aspf" tag in sender’s DMARC DNS record, "r" for relaxed mode and "s" for strict mode. If it is in strict mode, the RFC5321.MailFrom domain should be the same as RFC5322.From domain. If it is in relaxed mode, the RFC5321.MailFrom domain should be the same organization domain with RFC5322.From domain. The result will be Pass or Fail.
The DKIM checking follows the DKIM protocol. It checks the signatures in the message to verify whether the message is modified during the transmission. The result may be Pass, Fail, or None. For more details on the results, refer to RFC 8601. If the result is None, it means Trend Micro Email Security was not able to verify any signatures in the message due to any of these reasons:
- There is no DKIM signature at all.
- The signature has invalid syntax.
- There is no valid public key for the corresponding signature.
- Signature is signed by a third-party domain, which means the "d" tag is not the same organization domain with RFC5322.From.
The Pass or Fail result determines whether the message was changed or not, while the None result could lead to a different final result. To avoid confusion, clear the intermediate status that asks the sender to correct the DKIM DNS record and sign the message with the correct identity, if possible.
The DKIM alignment match has two (2) modes - relaxed mode and strict mode. This is determined by the "adkim" tag in sender DMARC DNS record, "r" for relaxed mode, and "s" for strict mode. If it is in strict mode, the RFC5322.From domain should be the same as the "d" tag in the signature. If it is in relaxed mode, the RFC5322.From domain should be the same organization domain with the "d" tag in the signature. The result could be Pass, Fail, or None.
Default Mode
Trend Micro Email Security DMARC passing criteria in the Default Mode is lenient. When the result is unclear, the messages will still be kept and will not be blocked. Below is the process flowchart:
The following tables show the final result for DMARC-SPF and DMARC-DKIM.
| DMARC-SPF Result | |||
|---|---|---|---|
| No. | SPF Check | Alignment | DMARC-SPF |
| 1 | Pass | Pass | Pass |
| 2 | Pass | Fail | Fail |
| 3 | Fail | Pass | Fail |
| 4 | Fail | Fail | Fail |
| 5 | None/Netural/SoftFail/PermError/TempError | Pass | None/Netural/SoftFail/PermError/TempError |
| 6 | None/Netural/SoftFail/PermError/TempError | Fail | Fail |
| DMARC-DKIM Result | |||
|---|---|---|---|
| No. | DKIM Check | Alignment | DMARC-DKIM |
| 1 | Pass | Pass | Pass |
| 2 | Pass | Fail | Fail |
| 3 | Fail | Pass | Fail |
| 4 | Fail | Fail | Fail |
| 5 | None | None | None |
Based on the results above, the DMARC result will be Pass if there is no apparent Fail result. The detailed results are as follows:
| No. | DMARC-SPF | DMARC-DKIM | DMARC |
|---|---|---|---|
| 1 | Pass | * | Pass |
| 2 | * | Pass | Pass |
| 3 | None/Netural/SoftFail/PermError/TempError | None | Pass |
| 4 | None/Netural/SoftFail/PermError/TempError | Fail | Fail |
| 5 | Fail | Fail | Fail |
| 6 | Fail | None | Fail |
* The asterisk represents all the possible results.
Enforced mode
The passing criteria in this mode is stricter compared to the default. The sender must publish the DMARC DNS record and unclear result is treated as Fail. Below is the process flowchart:
The following tables show the final result for DMARC-SPF and DMARC-DKIM.
| DMARC-SPF Result | |||
|---|---|---|---|
| No. | SPF Check | Alignment | DMARC-SPF |
| 1 | Pass | Pass | Pass |
| 2 | Pass | Fail | Fail |
| 3 | Fail | Pass | Fail |
| 4 | Fail | Fail | Fail |
| 5 | None/Netural/SoftFail/PermError/TempError | Pass | Fail |
| 6 | None/Netural/SoftFail/PermError/TempError | Fail | Fail |
| DMARC-DKIM Result | |||
|---|---|---|---|
| No. | DKIM Check | Alignment | DMARC-DKIM |
| 1 | Pass | Pass | Pass |
| 2 | Pass | Fail | Fail |
| 3 | Fail | Pass | Fail |
| 4 | Fail | Fail | Fail |
| 5 | None | None | Fail |
Based on the results above, the DMARC result will be Pass if there is a Pass result in either side. The detailed results are as follows:
| No. | DMARC-SPF | DMARC-DKIM | DMARC Record | DMARC |
|---|---|---|---|---|
| 1 | Pass | * | Y | Pass |
| 2 | * | Pass | Y | Pass |
| 3 | Fail | Fail | Y | Fail |
| 4 | * | * | N | Fail |
* The asterisk represents all the possible results.
Trend Micro Email Security DMARC actions are similar with the actions for other features, including Do not intercept, Quarantine, and Delete. These actions can be configured from the web console.
However, according to DMARC protocol, the action for DMARC can also be specified by the sender. In order to follow the sender’s instruction, Trend Micro Email Security DMARC action configuration creates a mapping between them. The action can be configured separately for different "p" tag values in sender’s DMARC DNS record and even for no DMARC DNS record. For example, you can configure the action as Quarantine if the "p" tag is "None" and configure the action as Do not intercept if there is no DMARC record.
There are some actions that can be taken in the middle of the process, such as x-header insertion, tag subjection, and notification. It could be used to show the DMARC violation, especially the x-header insertion that adds an x-header in the message, which will be helpful to solve the violation.
Using Trend Micro Email Security DMARC
To use the DMARC protection, enable the feature on the web console and configure the actions that Trend Micro Email Security will take when the DMARC violation happens. Follow the procedure in this article to enable the DMARC: Adding DMARC Settings.
However, due to its complicated mail flow, not all senders can implement the DMARC protocol completely and correctly. Below are some sample scenarios:
- The network topology is unclear for senders, making it difficult to confirm their mail servers in a short time.
- The sender is sending mails via third-party that is incompatible with DMARC.
- The sender does not sign all the messages to prevent high usage of system resource or due to business consideration.
- There may be DNS query issue due to a network problem or DNS limitation (e.g. too many DNS lookup in a SPF record).
In order to ensure smooth mail traffic with DMARC, it is recommended to apply the DMARC in a step-by-step manner. Start from a small scope, then gradually move to a bigger scope. Here are the best practices in implementing DMARC:
- Apply the DMARC protection to one of the managed domains. At the beginning, only the messages for that specific domain will be affected. If the violations of that domain are positive, DMARC protection can then be applied to another domain, and so on.
- Set the DMARC action from bypass to intercept. All actions can be set first as 'Do not intercept' so messages will not be blocked. When all violations are positive, you may change it to intercept (e.g. Quarantine or Delete) based on the requirements.
- Configure the DMARC mode from default to enforced. Senders may opt to use Soft Fail for SPF result or choose not to sign the messages for some reason. If all the violations are positive and the senders confirmed to follow the DMARC authentication requirements, add those senders into the Enforced Peers list to enable the Enforced Mode. The checking will then be stricter and the spoofed messages will be blocked.
Solving the DMARC violations
After applying the DMARC authentication, violations will be inevitable. Some are positive, while others are false positive only. False positive violations may cause legitimate emails to be blocked and delayed, affecting the business process, thus it is important to eliminate such violations.
DMARC aims to protect the senders from impersonation. Therefore, the senders should be responsible to meet the requirements for DMARC authentication. To avoid being cheated by a fake sender, the receiver should also encourage their peer senders to adhere with DMARC protocols.
DMARC violations may happen while checking the SPF, SPF alignment, DKIM, DKIM alignment, and DNS record.
- SPF checking failure. To eliminate this, the sender should publish a correct SPF DNS record with all the designated hosts, and send messages from those hosts only. If the hosts are changed, the DNS record must be updated. See Sender Policy Framework Record.
- SPF alignment mismatch. To resolve this, the sender should always send the messages with the same envelop sender (RFC5321.MailFrom) and header sender (RFC5322.From), or at least they have the same organization domain.
When using a third-party in sending mails, make sure that they use the correct information from the original sender (e.g. RFC5321.MailFrom).
For null sender, there are two ways to solve it. One is to sign the message to let the DMARC have a Pass result. Another way is to correct Helo domain to be aligned with the header sender (RFC5322.From).
- DKIM checking failure. To eliminate this, the sender should publish a correct DNS record with DKIM public key, and sign the messages with corresponding identity before sending. The signing identity should be the header sender (RFC5322.From) or at least with same organization domain. Otherwise, EMS will not verify those third-party signatures.
Another popular reason is that the signature is signed in a future time. The sender server should install NTP or other tools to keep the right time synced to avoid this issue.
- DKIM alignment mismatch. To resolve this, sign the message directly with header sender (RFC5322.From), at least with same organization domain. Otherwise, EMS will get a None result, which is treated as failed in Enforced Mode.
Messages sent via third-party will get signed in the third-party. Thus, the sender should communicate with the third-party to use the correct identity same as the header sender (RFC5322.From).
If there is no DMARC DNS record, the sender should publish a correct DMARC DNS record.
