Does DMARC need an update to handled branded TLDs? I say yes
Some background
As I've said before, one of the things I like about DMARC is how I don't have to specify a policy for every single domain that I own. To recap what I said in my other post, here's the DMARC record of microsoft.com (I've removed the reporting addresses):
microsoft.com | "v=DMARC1; p=reject; pct=100"
There's no subdomain policy, which means that the following domain which has no DMARC record:
foo.microsoft.com | No DMARC record
... inherits the organizational domain policy, which in this case is p=reject. This is great because I can't possibly set up DNS records for every possible combination of *.microsoft.com but I don't have to because they all inherit from the organizational domain by default. I set it and forget it on the organizational domain, and I'm done unless I specifically publish a policy for a subdomain.
The tricky part of DMARC is where branded domains come in (which from this point forward I will sometimes refer to as .brand). If you're not aware, a branded domain is something that a company (or any organization willing to pay for it) can specify that customizes their own Top Level Domain. That is, outside of traditional TLDs like .com, .net, .io, you can specify .microsoft. For example, https://home.microsoft is a real domain, it redirects to https://www.microsoft.com. The URL https://surface.microsoft redirects to https://www.microsoft.com/en-ca/surface. Branded TLDs are neat because you can put your entire brand into the URL, and it looks reasonably authoritative.
Indeed, I think if we were to start the Internet all over again, we'd put a greater emphasis on branded domains.
So what's the problem?
The problem with .brand comes with DMARC.
How do you specify a DMARC policy that covers your entire .brand? That is, how would I publish a policy that covers all @surface.microsoft, @home.microsoft, @xbox.microsoft, and so forth? Obviously, I can set something up for each of those domains but I can't possibly specify a permutation for all of them.
DMARC says that if a domain doesn't have a DMARC record, look up the DMARC record of its organizational domain. The algorithm for this is to look up the Public Suffix List and then go to the string just in front of it. For example, if looking up home.live.microsoft.com's organizational domain, you would say "Find a TLD in that domain -> which is .com. Next, prepend the next substring, which is microsoft. That means the organizational domain for home.live.microsoft.com is microsoft.com."
And, in order for links to resolve someplace such that Internet browsers can make use of a .brand URL, Microsoft had to register .microsoft and publish it in the public suffix list.
For a .brand, the organizational domain for foo.microsoft (which doesn't exist) is... foo.microsoft. That's because the TLD is microsoft, and prepending foo gives us foo.microsft. There's no way I can publish a DMARC entry for everything. You might say "Well, just publish a DMARC record for... er... the microsoft TLD." Well, do we publish DMARC records for com (as in, *.com)? No, we don't.
And that means DMARC needs an update for branded TLDs.
Some options for fixing this
I've thought about this for about 15 minutes, and propose one of the following options:
1. Use home.brand as the default organizational domain
Any new TLD registered after a certain date (has to be something in the past) can be reasonably implied to be a branded TLD. And if the domain with a branded TLD doesn't have a DMARC record, the organizational domain should fallback to home.brand. For example, if the DMARC record for foo.microsoft does not exist, and since .microsoft was registered in December 2014, then check the DMARC record for home.microsoft and use that instead.
The advantage of this is that home.brand is a "natural" place to look a .brand's DMARC policy. If 127.0.0.1 is home, then home.brand can really be home.
OR
2. Assume any non-existent *.brand defaults back to brand.com
Once again, you need to assume that any .brand domain is something created after a certain date so you can know whether or not it is a branded domain (to differentiate it from .com, .net, etc.). If foo.microsoft has no DMARC policy, then check microsoft.com's DMARC policy and use that.
Similarly, bar.foo.microsoft would have no DMARC. Next, check foo.microsoft which has no DMARC. Then, check microsoft.com which does have a DMARC record. This method adds another DNS check, but helps logically connect the .brand to the .com TLD.
The advantage of this is that it ties the most well-known TLD - .com - with the .brand. The drawback is that the .brand may not actually be related to the .com.
OR
3. Assume any .brand is DMARC reject
Let's be honest. If we were doing email over again, we probably wouldn't make it as insecure as it is. We'd start with a strong policy from the ground up. So, if something is a .brand domain then assume it is DMARC p=reject (the .bank TLD is like this). If someone wants to specify something else not as strongly protected, then they have to set it up explicitly. For example, if foo.microsoft has no DMARC policy, then assume it is
p=reject
If foo.microsoft should not behave that way, then the domain administrator would have to explicitly publish a DMARC record for foo.microsoft.
Once again, we need an algorithm to figure out what's .brand and what isn't (e.g., using a date), but this simplifies the management of the .brand domain when it comes to email.
Some email folks don't like default policies that aren't explicit. I'm not one of them.
OR
4. Actually publish a DMARC policy for .brand
I said above that we don't publish DMARC policies for TLDs. But, maybe we should.
On the other hand, how would you do a DNS query for com? That seems a little weird, and it would require modifying the DMARC algorithm to check the TLD's DMARC record after checking the organizational domain. The advantage in this case is that it doesn't require figuring out whether or not a TLD is a .brand, as any .brand could choose to publish or not publish a DMARC policy. The disadvantage is that it requires an upgrade to all existing DMARC implementations.
OR
5. Don't bother with any of this DMARC business and just reject email from domains that don't resolve
Getting email from foo.microsoft which has no DMARC record? Not a problem. If it's spoofed, it's probably coming from something that's completely spoofed. It will probably have no A-record, and no MX-record. Since those are always spam, reject them unconditionally.
Except that they aren't always spam. Microsoft may have a lot of domains in the .brand that we want to use for marketing purposes and set up A-records for. Those will resolve; we just might forget to publish DMARC records but we would still want that email rejected. To which you might respond "Well, that's your problem if you can't manage your DNS."
To which I reply "If you work in a big organization, DNS updates are hard to do. This process as not as simple as you think it is." Relying upon the domain owner to keep their DNS records up-to-date is not going to work. As a large receiver, I don't want to take a dependency someone else. I work on a team that is responsible for keeping spam and phish out of the inbox, and if someone is spoofing your .brand but you haven't locked it down with DMARC, I'm not going to say "Oh, well, I'd like to reject it but since it resolves in DNS, I can't take action on it." I have to say "What was the domain owner's intent?" Options 1-4 above try to guess a domain owner's intent irrespective of whether or not they have good management processes. Option 5 does not.
There you have it. That's what I see on the horizon for an update to DMARC. We don't see a lot of .brand in email yet, but I do see it sometimes when it comes to links. It's only a matter of time before email catches on, and DMARC had better be prepared.
You can see I lean heavily towards figuring out what's a .brand and what isn't, and propose using the date registered in the public suffix list as a potential cutoff. That may not work, but if anyone else has a better suggestion I am open to it.