DMARC (Domain-based Message Authentication, Reporting, and Conformance) allows domain owners to publish protocols, suggesting to receiving servers how to handle SPF or DKIM authentication failures.
You can generate a DMARC record here.
Please, do not publish DMARC records for domains, which do not use either SPF or DKIM. Otherwise, you may get unpredictable results.
No changes are needed in the Mail Server for publishing your DMARC records.
DMARC configuration screen can be accessed from Security - DMARC in the Mail Server UI.
If the Use DMARC box is checked, the priority of handling received messages will be given to policy in the published DMARC record, if it exists. For example, if SPF fails, the Mail Server SPF setting is REJECT, but the policy for the sending domain is QUARANTINE, the message will be quarantined (go to the Spam folder), rather than rejected.
All other anti-spam features (all but SPF and DKIM) will operate as usual.
Reporting is a part of DMARC. Domain owner, through DMARC record, may request to receive aggregate reports of all mail that goes through your server, or reports each time DMARC fails.
The domain owner may request a frequency, how often they want to receive aggregate reports. Currently, the Mail Server does not honour that request. It always sends reports once a day, at midnight UTC.
Also, failure reports (also known as forensics reports), are currently not getting sent. They supposed to be sent each time DMARC fails, and cases, when they should be sent are defined in the DMARC report (in a "fo" parameter).
The subject line, file name, and format of aggregate reports are defined in rfc7489. Reports are sent as gzipped attachments.
Please let us know if you have further questions.
June 7 2021