We can configure DMARC to receive reports from email servers that get emails from your domain. Your DMARC record can specify where to send these reports. You can use the information in these reports to fine-tune your email authentication policy to permit only trusted senders to send emails on behalf of your email domain.

With the help of this reporting mechanism, email receivers can tell you:

• whether the email they received from your domain passed or failed authentication.
• which servers or third-party senders are using your domain to send emails.
• which servers or services are sending messages that fail DMARC.
• what DMARC actions the receiving server takes on unauthenticated email messages from your domain. The action will be based on the DMARC policy configured in your DMARC record.

The aggregate reports are XML documents that contain IP addresses, domain names and authentication information for emails that the receiver has seen sending as that domain. These XML reports can be hundreds or thousands of lines long, depending on how many email messages are sent from that domain around the world. You may have to invest additional time and resources to perform a technical analysis of the reports to consider if you need to update SPF, DKIM and DMARC records to ensure that the services are properly authorised.

Note: Instead of manually parsing the massive amount of XML-based IP address data that you get in DMARC reports, there are third-party service providers who can help you with DMARC aggregate report analysis and turn them into an easily readable list of named services.

Note: To update your DNS records for SPF, DKIM and DMARC, you need to contact your service provider (domain registrar) and ask them to make the changes required to align with your analysis.

DMARC policy enforcement
A DMARC record with policy 'p=reject' is the stricter enforcement. The stricter enforcement better protects your domain from spoofing. However, the recommendation is to follow the below guidelines:

• It is recommended that you start with policy 'p=none' then analyse DMARC reports at this level for some time to identify whether they require any action to allow your third-party senders (if any) for your domain.
• When you are confident and understand your organisation's email flow and authentication from the reports, you need to update your DMARC record and move to the policy 'p=quarantine'. Again, you need to be in this level for some time and analyse reports before you move to the stricter DMARC policy.
  Note: We would recommend a minimum of six weeks at each level above to allow for the monthly processing to take place and identified, but possibly longer if that period spans a school holiday.
• Finally, you need to get to DMARC policy enforcement, i.e. move to policy 'p=reject'.

Update SPF record for your domain
The primary purpose of analysing aggregate reports is to identify legitimate email sources which fail authentication checks. Messages sent from servers that are not included in your SPF record can fail authentication. Check your SPF record to ensure that it includes all IP addresses and domains that are allowed to send emails from your domain. If all legitimate sources are not included, you will have to update your SPF record so that emails from these legitimate sources pass authentication next time. To update the SPF record for your domain, please refer to the relevant links below:

• Microsoft 365
• Google Workspace

DKIM checks
You need to check if all the messages sent from your domain are failing DKIM checks. If so, probably there is a problem with your DNS DKIM record. You will have to verify and update the DKIM key published.

To troubleshoot Google Workspace DKIM issues, please refer to the link: Troubleshoot DKIM issues.

To verify if DKIM signing is configured properly for Microsoft® 365™, please refer to the link: Confirm DKIM signing.