12. Security Considerations

This section discusses security considerations specific to DMARC.

12.1. Authentication Methods

DMARC is built on top of SPF and DKIM. The security of DMARC is therefore dependent on the security of these underlying mechanisms. Implementers should be familiar with the security considerations of both SPF [SPF] and DKIM [DKIM].

Key points:

1. SPF Security: SPF can be bypassed if an attacker can send mail through a server authorized in the SPF record.

2. DKIM Security: DKIM signatures can be forged if the signing key is compromised. Key management is critical.

3. Combined Security: DMARC's requirement for Identifier Alignment provides stronger authentication than either SPF or DKIM alone.

12.2. Attacks on Reporting URIs

An attacker could attempt to cause mail receivers to send large volumes of reports to a victim's address by:

1. Publishing a DMARC record for a domain under the attacker's control with the victim's address in the "rua" or "ruf" tags.

2. Sending large volumes of unauthenticated mail claiming to be from that domain.

The verification mechanism described in Section 7.1 prevents this attack by requiring that external report destinations explicitly authorize the reporting relationship.

Additionally, Mail Receivers should:

• Implement rate limiting on report generation
• Monitor for unusual reporting patterns
• Respect unsubscribe requests from report recipients

12.3. DNS Security

DMARC relies heavily on DNS for policy distribution. DNS security considerations include:

1. DNS Spoofing: An attacker who can spoof DNS responses could:

   • Provide a false DMARC policy
   • Redirect reports to an attacker-controlled address
   • Cause denial of service by removing policy records

2. DNSSEC: Use of DNSSEC can mitigate DNS spoofing risks. Implementers should consider deploying DNSSEC for domains publishing DMARC policies.

3. Cache Poisoning: DNS cache poisoning could cause incorrect DMARC policies to be cached and applied.

12.4. Display Name Attacks

DMARC does not protect against attacks on the display name portion of the RFC5322.From field. An attacker can use a display name that appears trustworthy while using a different domain in the address:

From: "Trusted Bank" <[email protected]>

Users may see only "Trusted Bank" and not notice the actual sending domain. This limitation is explicitly noted as out of scope in Section 2.2.

User education and MUA improvements (such as prominently displaying the actual email address) are needed to address this threat.

12.5. External Reporting Addresses

When DMARC reports are sent to external addresses (addresses at domains other than the one being reported on), several security considerations apply:

1. Data Exposure: Reports contain information about the domain's email infrastructure and traffic patterns. This information could be valuable to attackers.

2. Third-Party Trust: Domain Owners must trust third-party report recipients to:

   • Handle report data securely
   • Not misuse the information
   • Comply with applicable privacy regulations

3. Verification: The verification mechanism in Section 7.1 ensures that external destinations are authorized, but Domain Owners should still carefully consider what information they're sharing.

12.6. Secure Protocols

While DMARC itself does not mandate the use of specific secure protocols, implementers should consider:

1. DNSSEC: As mentioned in Section 12.3, DNSSEC can protect against DNS spoofing attacks.

2. TLS for Reports: When sending reports via email, use of STARTTLS or other encryption mechanisms protects report content in transit.

3. HTTPS for Report URIs: If future extensions allow HTTPS URIs for report delivery, TLS should be used to protect report data.

4. Secure Key Storage: DKIM private keys must be stored securely to prevent compromise.

---