DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol designed to protect domains from spoofing and phishing. It builds on SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) by providing a framework for domain owners to specify how receiving mail servers should handle emails that fail SPF or DKIM checks, and to receive reports on email authentication results. Moving a domain to a `p=reject` policy is the ultimate goal for DMARC, ensuring that unauthenticated emails are blocked, but achieving this without disrupting legitimate mail flow requires meticulous planning and execution, especially for Managed Service Providers (MSPs) managing multiple client environments.
Why is DMARC p=reject essential for your clients?
A DMARC policy of `p=reject` instructs receiving mail servers to outright refuse emails that fail DMARC authentication. This is the strongest possible enforcement level and offers the highest protection against email impersonation, phishing, and Business Email Compromise (BEC). While `p=none` provides monitoring and `p=quarantine` sends suspicious emails to junk folders, `p=reject` actively prevents malicious emails from reaching inboxes. For MSPs, guiding clients to this level of protection significantly enhances their cybersecurity posture and reduces their risk exposure.
The MSP Checklist: Moving to DMARC p=reject
Transitioning a domain to `p=reject` is a phased process. Rushing it can lead to legitimate emails being blocked, causing business disruption. Follow this structured approach for each client domain.
- Inventory All Sending Sources: Identify every service that sends email on behalf of the client's domain. This includes Microsoft 365, Google Workspace, CRM systems (e.g., Salesforce, HubSpot), marketing automation platforms (e.g., Mailchimp, Marketo), invoicing systems, ticketing systems, internal applications, and any third-party vendors sending transactional or marketing emails. Do not forget printers/scanners that email, or legacy on-premise systems.
- Configure SPF Records for All Sources: Ensure SPF records are correctly configured for all identified sending sources. Each source must be authorized to send email for the domain. Be mindful of the 10-lookup limit for SPF. Consolidate where possible and use `include` statements carefully. Test thoroughly.
- Configure DKIM Records for All Sources: Implement DKIM signing for every sending source. Most major email services provide clear instructions for setting up DKIM. For third-party services, ensure they support custom DKIM keys for your client's domain. Verify that DKIM records are published correctly in DNS.
- Set Initial DMARC Policy to p=none: Publish a DMARC record with `p=none` and valid `rua` (aggregate report) and `ruf` (forensic report, if desired) tags. This allows you to gather data on email authentication without impacting mail flow. Use a DMARC reporting service to easily analyze these reports.
- Analyze DMARC Aggregate Reports: For several weeks (4-8 weeks, depending on email volume and complexity), meticulously review aggregate reports. These reports show which emails are passing or failing SPF and DKIM, and their alignment with the DMARC policy. Identify any legitimate sending sources that are failing authentication.
- Address Authentication Failures: For any legitimate sources failing authentication, revisit SPF and DKIM configurations. This might involve updating DNS records, reconfiguring sending services, or contacting third-party vendors for support. Repeat report analysis until all legitimate traffic shows DMARC pass with alignment.
- Introduce DMARC pct Tag: Once you're confident that all legitimate emails are authenticating correctly, gradually increase the DMARC enforcement. Start by changing your DMARC record to `p=quarantine; pct=10`. This quarantines only 10% of failing emails. Monitor reports closely.
- Increase pct and Move to p=quarantine: Over time, increase the `pct` value (e.g., 25%, 50%, 75%, 100%) while continuously monitoring reports. Once `pct=100` is stable, change the policy to `p=quarantine`. This will send all failing emails to recipients' junk folders. This phase allows for a softer landing and further validation.
- Handle Forwarding and Mailing Lists: Understand that email forwarding and mailing lists can break SPF and sometimes DKIM. If your clients use these heavily, consider implementing a `sp=quarantine` or `sp=none` for subdomains if the main domain is at `p=reject`, or instruct clients on proper DMARC-compliant forwarding solutions (e.g., ARC – Authenticated Received Chain).
- Set Subdomain Policy (sp): Decide on a subdomain policy (`sp`). If not specified, `sp` inherits the `p` value. Often, `sp=quarantine` is a safer initial choice than `sp=reject` for subdomains, especially if there are many unknown or rarely used subdomains that might send email. This can be adjusted later.
- Communicate with Client Stakeholders: Keep client leadership and key IT personnel informed throughout the process. Explain the benefits, the phased approach, and potential temporary disruptions. Ensure they understand what to look for and how to report issues.
- Implement DMARC p=reject: Once you've confirmed that virtually all legitimate emails are passing DMARC with `p=quarantine` and `pct=100` for an extended period (typically several weeks), change the policy to `p=reject`. Continue to monitor DMARC reports vigilantly for any unexpected issues.
Common Breakages and How to Avoid Them
- Unidentified Sending Sources: The most common cause of legitimate email being blocked. Thorough inventory is crucial. Use DMARC reports to identify sources you missed.
- SPF 10-Lookup Limit Exceeded: Adding too many `include` mechanisms in SPF can cause it to fail. Use a tool to check your SPF record's lookup count. Consolidate where possible or explore subdomains for specific services.
- Incorrect DKIM Configuration: DKIM selectors, public keys, or DNS entries can be misconfigured. Double-check all settings and use online tools to validate DKIM records.
- Lack of DMARC Alignment: SPF and DKIM must not only pass but also align with the DMARC policy. This means the 'header from' domain must match the domain in the SPF or DKIM signature. Many third-party senders require specific configurations to achieve alignment.
- Email Forwarding: When an email is forwarded, the 'sending' IP changes, often breaking SPF. DKIM can also be broken if the message body is altered. If forwarding is critical, consider implementing ARC or educating clients about DMARC-compliant forwarding options.
- Mailing Lists: Similar to forwarding, mailing lists often modify emails, breaking authentication. For internal mailing lists, ensure they are configured to re-sign emails or are exempt from DMARC checks if possible. For external lists, advise senders to use dedicated domains for list sends.
- Neglecting Subdomains: Many organizations have subdomains (e.g., `marketing.yourcompany.com`, `support.yourcompany.com`) that send email. Ensure these are covered by your DMARC policy, either explicitly or via the `sp` tag.
- Insufficient Monitoring: Moving to `p=reject` without ongoing DMARC report analysis is a recipe for disaster. Continuous monitoring helps catch issues quickly.
What about SPF, DKIM, and DMARC for internal mail?
While SPF, DKIM and DMARC are primarily designed for external email validation, their proper configuration is still vital for internal mail flow. Most modern email systems will apply DMARC checks even for internal messages, especially if they route through external gateways or cloud services. Ensuring all internal sending systems (e.g., applications, network devices, on-premise servers) are correctly included in SPF and sign with DKIM prevents internal spoofing and ensures consistent authentication. This also helps when an internal email is forwarded externally.
How Lion Group helps
Lion Group provides managed DMARC services tailored for MSPs, simplifying the complex process of DMARC deployment and enforcement. Our platform offers intuitive DMARC report analysis, guided configuration steps, and expert support to help you achieve `p=reject` for your clients without disruption. We streamline the inventory of sending sources, ensure proper SPF, DKIM and DMARC alignment, and provide continuous monitoring, allowing you to secure your clients' domains effectively and efficiently.