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 EMS' DMARC
EMS' DMARC feature will prevent the spoofed messages by checking following two sides:
- DMARC-SPF: SPF check and its alignment match between RFC5321.MailFrom domain and RFC5322.From domain.
- DMARC-DKIM: DKIM check and its alignment match between RFC5322.From domain and “d” tag in signature.
Either DAMRC-SPF or DMARC-DKIM side gets a Pass result, the DMARC will also get a Pass result. If the both sides get a Fail result, the configured action will be taken.
EMS’ DMARC feature contains two modes, the default mode and the enforced mode.
- Default mode: after the feature is enabled, 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 difference of the two modes is the DMARC pass criteria in the enforced mode will be stricter than the default mode.
The following list describes the acronyms and definitions for terms used throughout this document:
| Term | Definition |
|---|---|
| UI | User Interface |
| RFC | Request for Comments |
| SPF | Sender Policy Framework |
| DKIM | DomainKeys 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 check follows the SPF protocol, using the connecting IP of the message to compare with the designated hosts in sender’s SPF record, and the check result may be Pass, Fail, SoftFail, None, Netural, PermError, and TempError. Refer to RFC7208 about detailed explanation for these results.
Only the Pass or Fail result is definitely to show the actual relationship between sender and the connecting IP. But others are meaningless which will have different understandings leading to different final results. To avoid confusing, it is better to clear such intermediate status that ask sender to correct the SPF DNS record if possible.
The SPF alignment match has two modes, which is decided by the “aspf” tag in sender’s DMARC DNS record, “r” for relaxed mode and “s” for strict mode. If it is strict mode, the RFC5321.MailFrom domain should be same as RFC5322.From domain; if it is relaxed mode, the RFC5321.MailFrom domain should be same organization domain with RFC5322.From domain. The alignment check result will be Pass and Fail.
The DKIM check follows the DKIM protocol, checking the signatures in the message to verify whether the message is modified during the transmission, and the check result may be Pass, Fail, None. Refer to RFC8601 about detailed explanation for Pass and Fail result. But the None result in EMS has been extended as that EMS does not verify any signatures in the message, it may be caused by following reasons:
- No DKIM signatures at all.
- Syntax invalid signatures.
- No valid public key for corresponding signature.
- Signature is signed by 3rd-party domain, that means the “d” tag is not same organization domain with RFC5322.From.
Only the Pass or Fail result is definitely to show the message’s non-change or not. But the None result is meaningless which will have different understandings leading to different final result. To avoid confusing, it is better to clear such intermediate status that ask the sender to correct the DKIM DNS record and sign the message with correct identity if possible.
The DKIM alignment match has two modes, which is decided by the “adkim” tag in sender DMARC DNS record, “r” for relaxed mode and “s” for strict mode. If it is strict mode, the RFC5322.From domain should be same as “d” tag in the signature; if it is relaxed mode, the RFC5322.From domain should be same organization domain with “d” tag in the signature. The alignment check result will be Pass, Fail and None. None result is suitable for the situation that DKIM result is None.
Default mode
EMS’ DMARC pass criteria in default mode is relaxed, the unclear result will keep, and the message will not be blocked due to unclear result. The determine flow will be as following:
The final result for DMARC-SPF and DMARC-DKIM side will be as following:
| Result of DMARC-SPF side | |||
|---|---|---|---|
| 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 |
| Result of DMARC-DKIM side | |||
|---|---|---|---|
| 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 above results of DMARC-SPF and DMARC-DKIM side, the DMARC result will be Pass if there is no apparent Fail result, the results in details will be as following: (* for all possible results)
| 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 |
Enforced mode
EMS’ DMARC pass criteria in enforced mode is strict, the sender must publish the DMARC DNS record and the unclear result will be treated as Fail. The determine flow will be as following:
The final result for DMARC-SPF and DMARC-DKIM side will be as following:
| Result of DMARC-SPF side | |||
|---|---|---|---|
| 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 |
| Result of DMARC-DKIM side | |||
|---|---|---|---|
| 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 above results of DMARC-SPF and DMARC-DKIM side, the DMARC result will be Pass if there is Pass result in either one side, the results in details will be as following: (* for all possible results)
| No. | DMARC-SPF | DMARC-DKIM | DMARC Record | DMARC |
|---|---|---|---|---|
| 1 | Pass | * | Y | Pass |
| 2 | * | Pass | Y | Pass |
| 3 | Fail | Fail | Y | Fail |
| 4 | * | * | N | Fail |
EMS’ DMARC actions are as actions for other features, containing do not intercept, quarantine and delete, and can be configured by customer from UI console.
But as DMARC protocol says, the action for DMARC can be specified by the sender, so in order to obey the sender’s instruction, EMS’ DMARC action configuration is a mapping between them. The action can be configured separately for different “p” tag values in sender’s DMARC DNS record and 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 middle actions, such as x-header insertion, tag subjection, and notification, they can be used to show the DMARC violation happens, especially the x-header insertion will insert an X-header in message to record the DMARC information for this message, which will be helpful to solve the violation.
How to use EMS’ DMARC
To use EMS’ DMARC protection, just enable the feature on the UI console, and configure the actions which EMS will take when the DMARC violation happens.
Follow the procedure in this article to enable the DMARC: Adding DMARC Settings.
But due to complicated mail flow environment, not all the senders implement the DMARC protocol completely and correctly, such as:
- Network topology is not so clear for sender, it is hard for them to confirm their mail servers at a short time.
- Sender is sending mails via 3rd-party, but some of them are not DMARC compatible.
- To avoid the high system resource usage, or due to some business consideration, sender will not sign all the messages.
- Due to some network issue, sometimes there may be DNS query issue.
- Due to some DNS limitations, for example too many DNS look-up in a SPF record, sometimes there may be DNS query issue when the sender update the DNS.
So there may be a lot of violations at the beginning which may cause a lot of messages being intercept, even the annoying emotion to use DMARC.
So in order to reduce the impact to mail traffic due to unfamiliar with the protocol, it is preferred that apply the protection step by step, start from monitoring and end with preventing spoofed messages.
Some or all of the following plans can be taken, start from a small scope to a big one, from the non-intercept action to an intercept one, and from the default mode to enforced mode.
EMS’ DMARC protection can be applied to one of the managed domains, so that at the beginning only the messages for that domain will be affected, and experience can be accumulated to solve the DMARC violations.
If all of the violations of that applied domain are positive, DMARC protection can be applied to another domain, even the whole account with the “Default” label.
All of the DMARC actions can be configured as do not intercept, so that at the beginning all of the messages will not be blocked even DMARC violates. So that solving the violations will not affect the mail traffic.
After all the violations are positive, DMARC actions can be changed to intercept, such as quarantine and delete, according to the requirements.
As described above, the default DMARC mode is relaxed, but it is just a compromise for those senders who are not easy to implement DMARC, such as use a Softfail but not Fail for SPF result due to complex network topology, do not sign the messages due to some reason.
After all the violations are positive, and confirmed with the senders who will always obey to the DMARC authentication requirements, that means the senders will send messages from definite hosts or sign the messages with corresponding identity all the time for every message, it is better to put those satisfied senders into “Enforced Peers” list to enable enforced mode, so that the check will be strict, and the spoofed message will be blocked without hesitation.
Solve the DMARC violations
After applying the DMARC authentication, the violations will be inevitable, some of them are positive but some of them are false positive, it will be a great work to let the world be clean.
As for those positive violations, there is nothing to be good but take necessary action on them, it is just the effect and aims of DMARC. But as for those false positive violations, they may cause the legitimate messages to be blocked and delayed, affecting the business or order, so it is important to eliminate such violations.
DMARC is to protect senders from impersonation, so the senders should take responsibility to meet the DMARC authentication demand as possible as they can. To not be cheated by the fake sender, the receivers should push their peer sender, especially for those VIP partners to make sure the sending messages are satisfied with DMARC authentication.
DMARC violations may happens in SPF check, the SPF alignment check, the DKIM check, the DKIM alignment and no DMARC DNS record.
To eliminate the SPF check failure, the sender should publish a correct SPF DNS record with all the designated hosts, and send the messages from those hosts only. Of course, if the hosts are changed, adding or removing, the DNS record should be updated.
As for how to create SPF record, here is a guide from internet for reference.
To eliminate the SPF alignment mismatch, the simple way is that the sender should always send the messages with same envelop sender(RFC5321.MailFrom) and header sender(RFC5322.From), at least they are with same organization domain. There is no evident advantage, except cheating the receiver, to send a message with different envelop sender and header sender, especially for those business messages.
Sending via 3rd-party
Now many messages are sent by 3rd-party organizations, but they are also different in the sending behavior. Some of them can use the information for the original sender, such as RFC5321.MailFrom, the SPF alignment will match for such situation; but some of them do not, at least by default, so the sender need to communicate with the 3rd-party organization to try to use the correct information.
Null sender
Null sender is a special scenario for SPF alignment check, there are two possible ways to solve this. One is to sign the message, so that the DMARC will be a Pass result due to DMARC-DKIM side pass. The other one is to correct the Helo domain to be align with header sender (RFC5322.From).
To eliminate the DKIM check failure, the sender should publish a correct DNS record with DKIM public key, and sign the messages with corresponding identity before sending.
As for signing the messages, the signing identity should be the header sender (RFC5322.From) or at least with same organization domain. Otherwise, EMS will not verify such those 3rd-party signatures. Another popular reason for DKIM check failure 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.
As for how to add DKIM public key DNS record, it is different to generate the key for different platforms or providers, here is a guide from EMS online help if customer is using EMS’ DKIM signing feature.
To eliminate the DKIM alignment mismatch, the simple way is that sign the message directly with header sender (RFC5322.From) , at least with same organization domain. Otherwise, EMS will get a None result for DKIM alignment check, which is treated as failure in enforced mode.
Sending via 3rd-party
Messages sent via 3rd-party will get signed in the 3rd-party, the signing behavior is also different. Some of them support sign using the identity same as header sender(RFC5322.From), the DKIM alignment will match for such situation; but some of them do not, at least by default, so the sender need to communicate with the 3rd-party organization to try to use the correct the identity.
No DMARC DNS record
The sender should publish a correct DMARC DNS record, otherwise EMS will get a DMARC failure in enforced mode.
