What is the DMARC ‘sp’ Tag for Subdomains?
Domain owners with multiple subdomains expose their businesses to phishing and spoofing attacks, which underscores the importance of protecting them with DMARC. Generally, domain administrators only deploy SPF, DKIM, and DMARC for the main domains, leaving unsecured subdomains to be the ideal entry points for threat actors. That’s why all your subdomains should have a quarantine or reject policy, with the percentage parameter ideally set to 100.
The DMARC ‘sp’ tag is short for subdomain policy that allows domain owners to specify how DMARC should manage illegitimate emails sent from their subdomains. Let’s discuss this in detail.
What is the ‘sp’ Tag in DMARC?
If a DMARC record is not published for a single domain, the DMARC policy specified for an organizational domain will be enforced on all subdomains by default. On the other hand, domain owners can use the ‘sp’ tag to define exclusive rules for all subdomains by setting a subdomain policy. In short, the ‘sp’ tag can override the default behavior and state distinct policies for subdomains.
The ‘sp’ tag is exactly the same as the ‘p’ tag, except it’s meant to specify a policy for the subdomain, whereas the ‘p’ tag defines a DMARC policy for a domain.
How Does the ‘sp’ Tag Work?
Subdomains typically follow the DMARC policy set for the parent domain unless a specific policy is defined for the subdomain. The ‘sp’ attribute allows for overriding this default behavior. Even if a subdomain’s DMARC record sets a policy to ‘none,’ it will still take precedence over the parent domain’s policy.
Let’s take an example where a domain named mybusiness.com has its DMARC policy set to p=reject, but finance.mybusiness.com is at p=none. In this scenario, threat actors can impersonate your brand despite the domain being set to the reject policy. They can send spoofed emails from subdomains, and recipients won’t be suspicious because how would they know that you don’t really use your subdomain for sending emails?
This proves that DMARC is only effective to applied domains and subdomains.
To simplify management, it’s advisable to avoid specifying the ‘sp’ attribute for the organizational domain itself. This ensures that subdomains inherit a default policy, guarding against spoofing. Remember, the behavior of subdomains ultimately follows the overarching policy set at the organizational level.
Why Use the ‘sp’ Tag?
Granular Control Over Email Authentication
The ‘sp’ tag allows you to tailor DMARC policies as per each subdomain’s requirements, risk profiles, and operational needs. Not all email systems within an organization may be equally secure. Granular control enables administrators to apply stricter authentication measures to high-risk subdomains or systems while maintaining more relaxed policies for lower-risk areas.
Moreover, it gets more flexible to adapt to authentication policies based on evolving threat risks, compliance requirements, risk tolerance, etc.
Better Security
By protecting your subdomains, you minimize the attack surface and bolster email security to stay abreast of phishing, spoofing, impersonating, and other email-based threats attempted by exploiting subdomains.
Compliance Alignment
Using the ‘sp’ tag ensures that subdomains adhere to organizational email security policies and industry best practices. This alignment with DMARC standards can help enhance regulatory compliance efforts and demonstrate a commitment to robust email security practices.
Minimized False Positives
The ‘sp’ tag allows selective enforcement for subdomains based on their risk tolerance, threat exposure, operational needs, etc., which ensures that legitimate emails from subdomains are not erroneously blocked or flagged as spam, reducing the likelihood of false positives.
Moreover, by analyzing authentication data and feedback reports, administrators can identify and address issues that may lead to false positives, such as misconfigured SPF records or inconsistent alignment. This proactive approach helps maintain a balance between security and legitimate email delivery, further minimizing false positives.
Enabling DMARC sp
To enable the DMARC subdomain policy for subdomains, you need to generate DMARC records for each subdomain you want to apply the policy to. This involves creating a TXT record in the DNS settings for each subdomain with the appropriate DMARC policy, including the ‘sp’ tag.
Specify the handling policy (none, quarantine, or reject) for emails that don’t pass the DMARC check. Before fully deploying DMARC SP for subdomains, thoroughly test the configuration to ensure that it behaves as expected and doesn’t inadvertently disrupt email delivery.
Regularly Monitor DMARC Reports
DMARC RUA (aggregate) and DMARC RUF Reports (forensic) give domain owners detailed insights into the authentication status of emails sent from your domain and on your business’s behalf. This allows you to detect unauthorized and fraudulent activities, including phishing and spoofed emails sent by impersonating your brand and its official representatives.
Moreover, you can also catch misconfigurations and misalignments by coming across false positives and false negatives through DMARC reports. Analyzing DMARC reports for domains and subdomains enables you to fine-tune and optimize your DMARC policy based on real-world email authentication data. You can adjust policy settings such as the enforcement level (none, quarantine, or reject) to strike the right balance between security and email deliverability.
Although it’s entirely optional to choose to receive aggregate and forensic reports, doing so optimizes DMARC benefits.
Aim to Move Towards the Strictest Policy
Aim to move towards the strictest DMARC policy for domains and subdomains for protection against email-based menaces. Implementing a “p=reject” policy provides an additional layer of defense, particularly for subdomains, where security risks might be overlooked. While this may demand careful planning and monitoring, the long-term benefits of enhanced security and brand protection outweigh the potential challenges.