A mail receiver pulls up the DMARC reporting requests for the domain contained in the RFC5322/From header of an email. It examines the ‘rua’ and ‘ruf’ tags discovered and does an authorization check to verify whether the domains listed as report recipients (in the mail to:) have approved (‘consented’) to accept reports for this RFC5322/From domain.Transmitting domain specifies a distinct domain (in its ‘rua’ and ‘ruf’ tags) to whom reports should be transmitted is referred to as report authorization. The destination domain (report receiver) must have a record that basically states “yes, I may accept reports on behalf of the sender domain”. Reports should not be transmitted to that domain if this authorization records does not exist on the recipient side.
Every 24 hours, DMARC aggregate reports are received that include the origination data of your emails, including the source IP address from which your email was created, as well as the results of your SPF and DKIM verification. The data from aggregate reports are utilized to identify and authorize all of your valid email sources.When an email from your domain fails both the authentication techniques, SPF and DKIM, DMARC forensic reports are generated. It comprises information indicating that there is a problem with a certain source, mainstream, or transmitting IP. These reports are optional, and you will not receive them for every failure.
Verifying External Destinations
It is possible to select destinations for certain reports that are beyond the domain owner’s power when making the request. This enables domains that do not have mail servers to request reports and have them routed to a location where they can receive and process them.Without checks, a bad actor might publish a DMARC policy records requesting that reports be forwarded to a victim address, then send a significant amount of mail that would fail both DKIM and SPF checks to a broad number of destinations, flooding the victim with unwelcome reports. As a result, a verification method has been incorporated.
For example, if a DMARC policy query for “blue.example.com” included “rua=mailto:reports@red.example.net”, the host derived from the latter (“red.example.net”) does not match “blue.example.com”. A TXT query is made for “blue.example.com. report. dmarc.red.example.net”. If just one response contains the tag “v=DMARC1”, the relationship between the two is proven. If just one response contains the tag “v=DMARC1”, the relationship between the two is proven.
Furthermore, “red.example.net” has the option to override the report destination specified by “blue.example.com” if necessary. If the aforementioned procedure fails to ensure that the external reporting was approved by the Report Receiver, the URI MUST be disregarded by the Mail Receiver that generates the report. Furthermore, if the confirming record has a URI with a host that is different from the domain publishing the override, the Mail Receiver creating the report MUST NOT create a report to either the original or the override URI.
EmailAuth automates DMARC for you and sends you DMARC reports. It also has a DMARC record generator and an analyzer for your domain. Head to EmailAuth today for all your email authentication needs.
