{% extends "admin/base_site.html" %} {% load i18n %} {% block meta_title %}{% trans "DMARC aggregate feedback report" %}{% endblock %} {% block title %}{% trans "DMARC aggregate feedback report" %}{% endblock %} {% block extrahead %} {% endblock %} {% block breadcrumbs %} {% endblock %} {% block content %}

{% trans "DMARC aggregate feedback report" %}

Report filter

 
  • Period: /
  • Only errors
  • Filter source organisation / ip address
  • Disposition
What is DMARC aiming to achieve?
Allows senders and receivers to improve and monitor protection of their domain from fraudulent email by building on and adding reporting to the widely deployed SPF and DKIM protocols.
How do aggregate feedback reports help?
Feedback reports provide a mechanism to monitor and improve mail handling.
How does django-dmarc make implementing DMARC easier?
Collecting feedback reports is automated, allowing easier filtering, with an option to download and use the data in a spreadsheet.
Can I get detailed information about failures?
Yes, set the ruf attribute and a detailed report will be sent for each failure. See the RFC for details.

The DMARC specification https://tools.ietf.org/html/rfc7489

Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1

DomainKeys Identified Mail (DKIM) Signatures

DMARC
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.
adkim
Indicates whether strict or relaxed DKIM Identifier Alignment mode is required by the Domain Owner. Valid values are as follows:
  • r: relaxed mode (default)
  • s: strict mode
AFRF
Authentication Failure Reporting Format
aspf
Indicates whether strict or relaxed SPF Identifier Alignment mode is required by the Domain Owner. Valid values are as follows:
  • r: relaxed mode (default)
  • s: strict mode
Authenticated Identifiers
Domain-level identifiers that are validated using authentication technologies are referred to as "Authenticated Identifiers".
Author Domain
The domain name of the apparent author, as extracted from the RFC5322 From field.
DomainKeys Identified Mail (DKIM)
DKIM is an email authentication method designed to detect email spoofing. It allows the receiver to check that an email claimed to come from a specific domain was indeed authorized by the owner of that domain. It is intended to prevent forged sender addresses in emails, a technique often used in phishing and email spam.
DMARC Policy Record
Domain Owner DMARC preferences are stored as DNS TXT records in subdomains named "_dmarc". For example, the Domain Owner of "example.com" would post DMARC preferences in a TXT record at "_dmarc.example.com". Similarly, a Mail Receiver wishing to query for DMARC preferences regarding mail with an RFC5322.From domain of "example.com" would issue a TXT query to the DNS for the subdomain of "_dmarc.example.com".
Domain Owner
An entity or organization that owns a DNS domain. The term "owns" here indicates that the entity or organization being referenced holds the registration of that DNS domain. Domain Owners range from complex, globally distributed organizations, to service providers working on behalf of non-technical clients, to individuals responsible for maintaining personal domains. This specification uses this term as analogous to an Administrative Management Domain as defined in [EMAIL-ARCH]. It can also refer to delegates, such as Report Receivers, when those are outside of their immediate management domain.
fo

Failure reporting options.

Provides requested options for generation of failure reports. Report generators MAY choose to adhere to the requested options. This tag's content MUST be ignored if a "ruf" tag (below) is not also specified. The value of this tag is a colon-separated list of characters that indicate failure reporting options as follows:

  • 0: Generate a DMARC failure report if all underlying authentication mechanisms fail to produce an aligned "pass" result. (default)
  • 1: Generate a DMARC failure report if any underlying authentication mechanism produced something other than an aligned "pass" result.
  • d: Generate a DKIM failure report if the message had a signature that failed evaluation, regardless of its alignment.
  • s: Generate an SPF failure report if the message failed SPF evaluation, regardless of its alignment.
Identifier Alignment
When the domain in the RFC5322.From address matches a domain validated by SPF or DKIM (or both), it has Identifier Alignment.
Mail Receiver
The entity or organization that receives and processes email. Mail Receivers operate one or more Internet- facing Mail Transport Agents (MTAs).
Organizational Domain
The domain that was registered with a domain name registrar. In the absence of more accurate methods, heuristics are used to determine this, since it is not always the case that the registered domain name is simply a top-level DNS domain plus one component (e.g., "example.com", where "com" is a top-level domain).
p
Requested Mail Receiver policy. Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. Policy applies to the domain queried and to subdomains, unless subdomain policy is explicitly described using the "sp" tag. This tag is mandatory for policy records only, but not for third-party reporting records. Possible values are as follows:
  • none: The Domain Owner requests no specific action be taken regarding delivery of messages.
  • quarantine: The Domain Owner wishes to have email that fails the DMARC mechanism check be treated by Mail Receivers as suspicious. Depending on the capabilities of the Mail Receiver, this can mean "place into spam folder", "scrutinize with additional intensity", and/or "flag as suspicious".
  • reject: The Domain Owner wishes for Mail Receivers to reject email that fails the DMARC mechanism check. Rejection SHOULD occur during the SMTP transaction. See Section 10.3 for some discussion of SMTP rejection methods and their implications.
pct
Percentage of messages from the Domain Owner's mail stream to which the DMARC policy is to be applied. However, this MUST NOT be applied to the DMARC-generated reports, all of which must be sent and received unhindered. The purpose of the "pct" tag is to allow Domain Owners to enact a slow rollout enforcement of the DMARC mechanism. The prospect of "all or nothing" is recognized as preventing many organizations from experimenting with strong authentication-based mechanisms.
Report Receiver
An operator that receives reports from another operator implementing the reporting mechanism described in this document. Such an operator might be receiving reports about its own messages, or reports about messages related to another operator. This term applies collectively to the system components that receive and process these reports and the organizations that operate them.
rf
Format to be used for message-specific failure reports. The value of this tag is a list of one or more report formats as requested by the Domain Owner to be used when a message fails both [SPF] and [DKIM] tests to report details of the individual failure. For this version, only "afrf" (the auth-failure report type defined in [AFRF]) is presently supported.
ri
Interval requested between aggregate reports. The default is 86400 (one day). Indicates a request to Receivers to generate aggregate reports separated by no more than the requested number of seconds. DMARC implementations MUST be able to provide daily reports and SHOULD be able to provide hourly reports when requested. However, anything other than a daily report is understood to be accommodated on a best- effort basis.
rua
Addresses to which aggregate feedback is to be sent.
ruf
Addresses to which message-specific failure information is to be reported. If present, the Domain Owner is requesting Mail Receivers to send detailed failure reports about messages that fail the DMARC evaluation in specific ways (see the "fo" tag).
Sender Policy Framework (SPF)
Sender Policy Framework is a simple email-validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain comes from a host authorized by that domain's administrators.
sp
Requested Mail Receiver policy for all subdomains. Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. It applies only to subdomains of the domain queried and not to the domain itself. Its syntax is identical to that of the "p" tag. If absent, the policy specified by the "p" tag MUST be applied for subdomains. Note that "sp" will be ignored for DMARC records published on subdomains of Organizational Domains due to the effect of the DMARC policy discovery mechanism
v
Version. Identifies the record retrieved as a DMARC record. It MUST have the value of "DMARC1".

The DMARC specification https://tools.ietf.org/html/rfc7489

Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1

DomainKeys Identified Mail (DKIM) Signatures

{% endblock %}