How do you manage multiple domains and subdomains with DMARC?

High-level resources include dmarc.org, m3aawg.org & more. They share great visibility & more in-depth into DMARC reporting, data, forensics, analyzers, best practice documentation, and more.

p=none is what you use when you are starting on your journey to p=reject. It allows you to fine tune and make sure mail is authenticating properly. Once authentication and sending issues are addressed you can move to p=reject.

When choosing a DMARC policy, you always have to think about the phase you are in. When you don't have a DMARC record published yet, always start with policy p=none, as you don't want legitimate emails to be impacted. First, start gaining insight by adding an RUA tag to your DMARC record, which asks the receivers of emails from your domain to send you feedback. In that way, you get insight into the current authentication results (and so, the possible impact of a stricter policy on your legitimate mail senders).

It's crucial to consider the implementation of a DMARC reject policy not only for a domain but also for subdomains, so that domain subdomains are prevented from spoofing too. To achieve this, the policy has to include not only the "p=reject" value but also the "sp=reject," which obviously applies to subdomains within the domain.

DMARC is a per-domain approach. Per domain, you need to collect feedback (Aggregate reports / RUA) to see what needs to be done in terms of authentication. What are the legitimate senders that you identified based on the DMARC data for that domain? As soon as you've identified those legitimate senders, you know which senders you need to authenticate. The way of configuring SPF and DKIM differs per legitimate sender. Therefore, always check the documentation of that specific senders about how to configure SPF and DKIM correctly. Be aware of the fact that alignment is a key factor here.

SPF and DKIM are important not only for proving the legitimacy of a sender but also for successfully implementing a DMARC policy, which will keep a domain and all emails within the domain protected against cybersecurity threats. By implementing DKIM and SPF, we inform email servers that the emails originating from that specific infrastructure are authorized to do so. This allows us to prevent unsolicited email sends / scams through other infrastructures with which our emails have nothing in common.

You must manage each domain separately. If you own domains that do not send mail, be sure to tell the Internet that mail should never be expected from those domains (using SPF and DMARC records). One thing to be aware of, it may not be necessary to publish DMARC records for each subdomain depending on whether or not you need a unique DMARC policy for each subdomain. The policy applies to the domain queried and to subdomains. Subdomains can also be used as a method for having a 'reject' policy for a root domain and a 'none' policy for the subdomain (or some other combination). Otherwise, for each mail sender for any domain or subdomain, find the appropriate information to publish in the SPF record and enable DKIM when possible.

Really, by this point, you will already have published a DMARC record. It is more a matter of whether or not you can move from 'p=none' to 'p=reject'. I rarely use a quarantine policy. You are aiming for 'p=reject' and it takes getting solid alignment from your sending sources. If you are observing near 100% alignment for all of your sending sources, you are most likely ready for a 'p=reject' policy. Also consider your SPF qualifier. When everything is configured correctly a '-' (minus) is preferable and results in a fail when the sending IP is not in the SPF record.

When you have published a DMARC record on your main domain, the subdomains automatically inherit this DMARC record. Unless you have published an explicit DMARC record on your subdomain (You'll also automatically gain insight into the emails sent on behalf of the sub-domains, in this case, based on the DMARC data). With the SP= tag, you can indicate a policy for the subdomains of the relevant main domain. Before creating your first DMARC record, think carefully about its manageability. Be informed about a possible DMARC CNAME structure. This makes changing your DMARC records later more manageable!

While there are multiple ways to analyze DMARC reports, one of the most common methods is to use XML-to-human-friendly view converters. Accessing DMARC data with converters like dmarcian allows you to easily identify the email servers and IP addresses that passed/failed DKIM & SPF alignment and determine which policies were applied as a result.

In all cases, I recommend adding a RUA tag to your DMARC record. This turns on the lights and gives you insight into who or what is sending mail on behalf of your domain names. Experience shows that in 99% of cases, the truth of the internet (DMARC reports) differs from the current configurations for SPF and DKIM when turning on the reports. The reports come in XML format and are, therefore, difficult to read and in any case, very time-consuming to read them. In addition, you probably do not have a walking encyclopedia within your company that can link every IP address to a specific sender. Several good DMARC tools can read this data and give you qualified insight into your outgoing mail infrastructure!

You always start at p=none with a RUA address to gain insight into your outbound email infrastructure. As soon as you made all legitimate senders (that became visible in the reports) "DMARC compliant", you can move to a stricter policy like quarantine or reject. Especially for larger organisations, I would recommend using the PCT tag when moving to a stricter policy. The default is 100%, so it's not needed to add pct=100. Monitor the impact of your policy carefully, and as soon as everything looks good, you can move to an even stronger policy. With quarantine, you are dependent on the recipient, who could notify you that emails end up in spam. Reject often works as a kind of beep system!

For mid-sized+ organizations, it's always good to start implementation with a DMARC monitor policy (p=none). This will allow for the analysis of all servers from which the corporate emails are sent, and the tools used by different departments. Once analyzed and the DKIM/SPF implementations are made, the policy needs to be switched to the quarantine one (p=quarantine) to prevent any sends from unsolicited servers. It's good to monitor the reports for a couple of weeks before switching the policy to reject mode (p=reject), to ensure no legitimate emails will be blocked.

A key point of the process! You have to inform and educate not only the staff but also all the teams who use email as communication. That includes the Sales team, Marketing team, IT department, HR, Accounting department, etc... Don't forget the applications - the weakest point! All of these have to consider the deployment of the DMARC policy. That means all the senders on your behalf, have to be aligned and authenticated to use them. New sources of any emails on your behalf have to be DMARC Compliant. Communicate that with your partners! Send them an information letter that you implement the DMARC policy for your domains.

This is important, because if various business units are not aligned with IT, initiatives can be impacted. As an example, say your domain has a 'p=reject' policy and the marketing team introduces a new mail delivery platform. Many of these tools are very easy to utilize, requiring minimal IT interaction. Guess what happens when the first campaign is sent out? You guessed it...delivery is terrible, and the campaign was a failure. Because the configuration did what it was supposed to do! It is important to notify others that you have this configuration in place and that it must be accounted for when introducing any new sending source.

It's not clear how to manage multiple domains with this article. I came to this page because I wanted multiple domains to send the dmarc report to the same email address. That way there is only one mailbox to check. This article alludes to this but is simply explaining the high level basics of DMARC, SPF and DKIM. There is a lot more detail one can dive into to understand the various options available.

To manage multiple domains efficiently, two main solutions exist. The first is using DMARC reporting vendors like Dmarcian, which consolidate data from all domains into one central location for easy analysis. Alternatively, you can specify a single reporting email address in each domain's DMARC policy. This method directs all DMARC reports to one email, exemplified by the policy: v=DMARC1; p=quarantine; rua=mailto:[email protected], where '[email protected]' is the unified report recipient.