Here are some practical examples to illustrate how DMARC works with subdomains, focusing on scenarios where the subdomain either has its own DMARC policy or inherits the policy from the top-level domain.

Example 1: Top-Level Domain with DMARC, Subdomain Inherits the Policy

In this scenario, example.com has a DMARC policy set to reject, meaning that emails failing DMARC alignment and authentication will be rejected. The DMARC reports are sent to dmarc-reports@example.com. Since mail.example.com does not have its own DMARC record, it inherits the DMARC policy from example.com. Therefore, emails sent from mail.example.com are subject to the reject policy of the top-level domain.

Example 2: Top-Level Domain with DMARC, Subdomain with Its Own Policy

  • Top-Level Domain: example.com
  • Subdomain: newsletter.example.com
  • Top-Level DMARC Record: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com
  • Subdomain DMARC Record: v=DMARC1; p=reject; rua=mailto:subdomain-reports@example.com

Here, example.com has a DMARC policy set to quarantine, which means emails that fail DMARC checks may be placed in the spam folder. The DMARC reports for the top-level domain are sent to dmarc-reports@example.com. However, newsletter.example.com has a stricter DMARC policy (reject), and DMARC reports for this subdomain are sent to a different address: subdomain-reports@example.com. This setup allows for differentiated handling of emails from the main domain and the subdomain.

Example 3: Top-Level Domain without DMARC, Subdomain with DMARC

  • Top-Level Domain: example.com
  • Subdomain: services.example.com
  • Subdomain DMARC Record: v=DMARC1; p=none; rua=mailto:services-reports@example.com

In this case, example.com does not have a DMARC record, but the subdomain services.example.com has its own DMARC policy set to none. This means that emails from services.example.com that fail DMARC checks will still be delivered, but reports of these failures are sent to services-reports@example.com. This setup is often used for monitoring and gathering data before moving to a stricter policy.

Key Points

  • A DMARC record at the top-level domain level does not automatically protect subdomains unless explicitly stated in the policy.
  • Subdomains can have their own DMARC policies, independent of the top-level domain, allowing for more specific control.
  • If a subdomain does not have its own DMARC record, it will inherit the DMARC policy of its parent domain.
  • The p= tag in DMARC defines the policy (none, quarantine, reject), while rua= specifies where aggregate reports should be sent.

DMARC for Subdomains: Summary Advice When considering the need for DMARC records for subdomains, keep in mind the following key points: Evaluate Email Use of Subdomains: Assess if the subdomains are used for sending emails. Implement DMARC for those actively used for email communication. Subdomain Policy Inheritance: Subdomains without their own DMARC records inherit the policy of the parent domain. For different email practices or reporting needs, a specific DMARC record for the subdomain is advised. Enhanced Security and Control: DMARC for subdomains enhances email authentication control, helping to prevent spoofing and phishing attacks. Compliance and Reputation Management: For strict email security and compliance, or to manage the email domain's reputation, DMARC records for subdomains are prudent. Monitoring and Reporting: Setting up DMARC with a ‘none’ policy can be beneficial for monitoring purposes, allowing data collection on email sources for future policy adjustments. In summary, DMARC implementation for subdomains, while not mandatory, is highly recommended for better email security, particularly for subdomains used in email communications. The decision should be based on the specific use and security requirements of each subdomain.