10. Other Topics

This section discusses various topics related to DMARC deployment and operation.

10.1. Issues Specific to SPF

SPF presents some issues when used with DMARC that Domain Owners and Mail Receivers should be aware of:

SPF-only Authentication: If a Domain Owner publishes only an SPF policy and not a DKIM policy, all email forwarding (where the RFC5321.MailFrom domain changes) will cause Identifier Alignment failures.
Mailing Lists: Many mailing lists use the original author's domain in the RFC5322.From field but change the RFC5321.MailFrom domain to their own. This breaks SPF Identifier Alignment.
Forwarders: Simple forwarding (where a user forwards mail to another address) does not change the RFC5321.MailFrom domain but can cause SPF failures because the forwarding server's IP address is not listed in the original domain's SPF record.

DMARC implementers should be aware of the following DNS-related considerations:

Query Volume: Mail Receivers will query DNS for DMARC records for every message that undergoes DMARC evaluation. High-volume receivers should implement appropriate caching strategies.
Caching: DNS records for DMARC policies should be cached according to their TTL (Time To Live) values. Domain Owners should set appropriate TTL values:
- Short TTLs (e.g., 300 seconds) during policy rollout or changes
- Longer TTLs (e.g., 86400 seconds) for stable policies
Negative Caching: Absence of a DMARC record should also be cached according to the SOA record's negative cache TTL.

When a DMARC policy indicates that a message should be rejected, Mail Receivers should consider the following:

SMTP vs. Post-SMTP Rejection:
- SMTP rejection (during the SMTP transaction) is preferred because it provides immediate feedback to the sending MTA and doesn't require generating a bounce message.
- Post-SMTP rejection (after accepting the message) should be avoided as it can lead to backscatter.
Rejection Codes: When rejecting during SMTP, use appropriate 5xx SMTP reply codes. A suitable message might be:
```
550 5.7.1 Message rejected per DMARC policy for example.com
```
User Notification: Consider whether to notify legitimate users if their messages are rejected due to DMARC failures.

Several considerations apply to Identifier Alignment:

Subdomain Alignment: In relaxed mode, subdomains are considered aligned. Domain Owners should be aware that this means mail from any subdomain will be considered aligned if SPF or DKIM passes for the Organizational Domain.
Third-Party Senders: When using third-party email services, Domain Owners must ensure:
- The third party can send DKIM-signed messages with the Domain Owner's domain in the "d=" tag, OR
- The third party's sending IP addresses are included in the Domain Owner's SPF record, and the RFC5321.MailFrom domain can be set to align
Multiple Sending Sources: Domain Owners with multiple sending sources (internal mail servers, email marketing services, CRM systems, etc.) must ensure all sources can produce aligned messages.

DMARC deployment can cause interoperability issues with certain email practices:

Mailing Lists:
- Problem: Lists often modify messages (adding footers, subject tags, etc.) which breaks DKIM signatures
- Solutions:
  - Lists can re-sign messages with their own DKIM signature
  - Lists can rewrite the RFC5322.From address (but this changes the apparent sender)
  - Domain Owners can use a more relaxed policy for domains used on mailing lists
Forwarding:
- Problem: Forwarding breaks SPF (forwarding server's IP not authorized)
- Solutions:
  - Rely on DKIM (which survives forwarding if content unchanged)
  - Forwarders can implement SRS (Sender Rewriting Scheme)
Indirect Email Flows: Any email flow where messages are modified or relayed through intermediaries may have DMARC issues. See [DMARC-INDIRECT] for detailed discussion.
Notification Messages: Automated notification systems should be configured to use aligned identifiers or may need to use a "p=none" policy domain.