TOP mistakes when setting up DMARC reports
These statistics were accumulated over several years in the mail antispam filter project at MeroLabs. The system receives and sends tens of thousands of reports per day.
Submitting
- Send from real-life mailboxes.
Many people send reports from addresses to which, in case of any problems, the bounce cannot be received. And even worse, you can run into additional problems with delivery.
- Lack of normal DKIM signatures and SPF rules.
Many people send reports from anywhere and anyhow. Because of this, you can run into antispam rules, in which incoming letters can be checked for all the necessary conditions, as in regular letters.
Receiving
If you do not control receipts, you can end up on the list of suspended recipients. The danger is that even after the error is corrected, removing an address from the list often requires contact with the sender. Accordingly, the further resumption of receiving these reports from various services is highly questionable.
- Not enough space in the mailbox.
This error is very common. Even large services are susceptible.
- The mailbox or domain does not exist.
What’s the point of doing this configuration?
- The mailbox is only available within the corporate domain.
There is no such meaning at all. Since the whole point of DMARC reports is to receive reports from third-party services.
- Specifying an address to a system that automatically responds to all incoming messages
This generates additional workload and useless reports that will indicate the delivery statuses of that one auto-response.
- Too aggressive antispam
It could be anything at this point. There were even situations where it was forbidden to accept gzip and xml files.
- Wrapping addresses in spam traps
When making such a decision, you need to ask about the adequacy of the person who made it. Only a clinic will help here.