When MDaemon queries DNS for a DMARC record, the record may contain various tags indicating that the domain owner wishes to receive DMARC reports regarding messages claiming to be from that domain. The options on the DMARC Reporting screen are for designating whether or not you wish to send DMARC aggregate or failure reports to the domains whose DMARC records request them, and for specifying the meta-data those reports will contain. The options on this screen are only available when the "Enable DMARC verification and reporting" option is enabled on the DMARC Verification screen. Further, the DMARC specification requires the use of STARTTLS whenever it is offered by report receivers. You should therefore enable STARTTLS if possible.
DMARC Reporting
Send DMARC aggregate reports
Enable this option if you are willing to send DMARC aggregate reports to domains who request them. When a DMARC DNS query on an incoming message's From: domain indicates that its DMARC record contains the "rua=" tag (e.g. rua=mailto:dmarc-reports@example.com), then that means the domain owner wishes to receive DMARC aggregate reports. MDaemon will therefore store DMARC related information about the domain and about the incoming messages claiming to be from that domain. It will log the email addresses to which the aggregate report should be sent, the verification methods used for each message (SPF, DKIM, or both), whether or not the message passed or failed, the sending server, its IP address, the DMARC policy applied, and so on. Then, each day at Midnight UTC MDaemon will use the stored data to generate each domain's report and send it to the designated addresses. Once the reports are sent, the stored DMARC data is cleared and MDaemon will start the whole process again.
|
MDaemon does not support the DMARC report interval tag (i.e. "ri=") for aggregate reporting. MDaemon will send aggregate reports each day at Midnight UTC, to any domain for which it has compiled DMARC data since the last time the DMARC reports were generated and sent. |
Send aggregate reports now
Click this button if you wish to generate and send a batch of aggregate reports from the currently stored DMARC data, instead of waiting until MDaemon does so automatically at the next Midnight UTC batch event. This sends the reports immediately and clears the stored DMARC data, exactly like what happens each day at Midnight UTC. MDaemon will then begin storing DMARC data again until the next Midnight UTC event, or until you click the button again, whichever come first.
|
Because MDaemon must be running at Midnight UTC to send aggregate reports and clear stored DMARC data automatically, if you have MDaemon shut down at that time then no reports will be generated and the DMARC data will not be cleared. DMARC data collection will continue whenever MDaemon is running again, but reports will not be generated and data will not be cleared until the next Midnight UTC event, or until you click the "Send aggregate reports now" button. |
Send DMARC failure reports (reports are sent as incidents occur)
Enable this option if you are willing to send DMARC failure reports to domains who request them. When a DMARC DNS query on an incoming message's From: domain indicates that its DMARC record contains the "ruf=" tag (e.g. ruf=mailto:dmarc-failure@example.com), then that means the domain wishes to receive DMARC failure reports. Unlike aggregate reports, these reports are created in real-time as the incidents which trigger them occur, and they contain extensive detail regarding each incident and the errors that caused the failure. These reports can be used for forensic analysis by the domain's administrators to correct problems with their email system configuration or identify other problems, such as ongoing phishing attacks.
The type of failure that will trigger a failure report is dependent upon the value of the "fo=" tag in the domain's DMARC record. By default a failure report will only be generated if all of the underlying DMARC checks fail (i.e. both SPF and DKIM fail), but domains can use various "fo=" tag values to indicate that they wish to receive the reports only if SPF fails, only if DKIM fails, if either fail, or some other combination. Consequently, multiple failure reports can be generated from a single message depending upon the number of recipients in the DMARC record's "ruf=" tag, the value of the "fo=" tag, and number of independent authentication failures that are encountered for the message during processing. If you wish to limit the number of recipients to which MDaemon will send any given report, use the "Honor up to this many DMARC 'rua' and 'ruf' recipients" option below.
For the report format, MDaemon will only honor the rf=afrf tag (Authentication Failure Reporting Using the Abuse Reporting Format), which is the DMARC default. All reports are sent in this format, even if a domain's DMARC record contains the rf=iodef tag.
|
In order to support DMARC failure reporting, MDaemon fully supports: RFC 5965: An Extensible Format for Email Feedback Reports, RFC 6591: Authentication Failure Reporting Using the Abuse Reporting Format, RFC 6652: Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format, RFC 6651: Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting, and RFC 6692: Source Ports in Abuse Reporting Format (ARF) Reports. When the DMARC "fo=" tag requests reporting of SPF related failures, MDaemon sends SPF failure reports according to RFC 6522. Therefore, that specification's extensions must be present in the domain's SPF record. SPF failure reports are not sent independent of DMARC processing or in the absence of RFC 6522 extensions. When the DMARC "fo=" tag requests reporting of DKIM related failures, MDaemon sends DKIM failure reports according to RFC 6651. Therefore, that specification's extensions must be present in the DKIM-Signature header field, and the domain must publish a valid DKIM reporting TXT record in DNS. DKIM failure reports are not sent independent of DMARC processing or in the absence of RFC 6651 extensions. |
Honor up to this many DMARC 'rua' and 'ruf' recipients (0 = no limit)
If you wish to limit the number of recipients to which MDaemon will send any given DMARC aggregate report or DMARC failure report, specify the maximum number here. If a DMARC record's "rua=" or "ruf=" tag contains more addresses than your designated limit, then MDaemon will send a given report to the listed addresses, in order, until the maximum number of addresses is reached. By default there is no limit set.
Email a copy of all reports to:
Enter one or more comma-separated email addresses here to send them a copy of all DMARC aggregate and DMARC failure reports (fo=0 or fo=1 only).
DMARC Report Meta-Data
Use these options to specify your company or organization's meta-data, which will be included with the DMARC reports you send.
Organization name
This is the entity responsible for producing the DMARC reports. It must be one of your MDaemon domains. Choose the domain from the drop-down list.
Contact email
Use this option to specify local email addresses that report receivers can contact about problems with the report. Separate multiple addresses with a comma.
Contact information
Use this option to include any additional contact information for report receivers, such as a website, a phone number, or the like.
Report return-path
This is the SMTP return path (bounce address) used for report messages that MDaemon sends, in case there are delivery problems. Use noreply@<mydomain.com> to ignore such problems.
See:
