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 (I've removed the reporting addresses): | "v=DMARC1; p=reject; pct=100"

There's no subdomain policy, which means that the following domain which has no DMARC record: | 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 * 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, is a real domain, it redirects to The URL redirects to 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,,, 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'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 is"

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 (which doesn't exist) is... 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 does not exist, and since .microsoft was registered in December 2014, then check the DMARC record for and use that instead.

The advantage of this is that home.brand is a "natural" place to look a .brand's DMARC policy. If is home, then home.brand can really be home.


2. Assume any non-existent *.brand defaults back to

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 has no DMARC policy, then check's DMARC policy and use that.

Similarly, would have no DMARC. Next, check which has no DMARC. Then, check 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.


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 has no DMARC policy, then assume it is


If should not behave that way, then the domain administrator would have to explicitly publish a DMARC record for

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.


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.


5. Don't bother with any of this DMARC business and just reject email from domains that don't resolve

Getting email from 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.

Comments (5)
  1. ifightspam says:

    Hello Terry, what you have proposed is a needed upgraded to DMARC, which way should the community go with is the question? From the options you have proposed, I would personally go with 3 or 5. 3 due to the fact domain admins don’t need to publish DNS records because it might be a long complex change management/request process and therefore it is assumed all domains are p=reject, would mail receivers assume this? Would it need to be a DNS entry? Currently, receivers expect a record in DNS. To 5, having DNS record types which require work which probably spammers will not do is a great way to distinguish between legitimate senders and illegitimate ones however as time has shown, spammers are evolving and maybe they will take the time out to make themselves look legitimate, this still isn’t the case but who knows.

    All the best!

  2. I’m not sure I’ve understood the problem: why does Microsoft not publish a DMARC policy for .microsoft? Presumably the fees that Microsoft pays the registry operator (Network Solutions by the look of it) would be sufficient to motivate publication of a text record upon request. The required record would be something like IN TXT “v=DMARC1; p=reject; pct=100; rua=mailto:…; ruf=mailto:…; fo=1”
    just as for

    .com is not a brand TLD, it’s a public suffix, so the question doesn’t seem to arise in that case.

    There may be a need to update the public suffix database to cope with this, but it doesn’t require a DMARC change. The organisational domain for is simply .microsoft.

    The idea that new TLDs after some arbitrary date are all brand TLDs is simply false. Although ICANN processed a batch of them, new gTLDs can be applied for at any time.

    > As a large receiver, I don’t want to take a dependency someone else.

    No doubt, but the _entire_ premise of DMARC is that you might find it useful to receive recommendations from domain registrants about the use of their domains. You’re making the argument for not using DMARC at all.

    1. tzink says:


      > .com is not a brand TLD, it’s a public suffix, so the question
      > doesn’t seem to arise in that case.

      From, we see com is a public suffix:

      // com :

      And we see microsoft is a public suffix using the exact same notation:

      // microsoft : 2014-12-18 Microsoft Corporation

      So why wouldn’t my question apply? looks like an organizational domain in and of itself.

      > The organisational domain for is simply .microsoft.

      Not according to the DMARC algorithm which says to acquire a public suffix list, and then do the match attempting to match the greatest number of suffixes (which would be .microsoft) and then prepend n+1 labels.

      1. Ah, I hadn’t thought to check the public suffix list. This is simply erroneous data in that list: members of the public can _not_ register sub-domains of .microsoft. The domain registrant (Microsoft!) should simply advise to correct this. (Quite apart from the DMARC consequences, this erroneous listing also means that browser cookies can’t be shared between and which, presumably, is not Microsoft’s intention.)

        DMARC outsources knowledge about specific domains – like .brands – to The solution to incorrect data in the latter is to fix the latter, not start pushing domain-specific workarounds into DMARC.

        (Side note: your blog isn’t generating email notifications to commenters when their comments receive replies.)

        1. tzink says:

          I still don’t get it, what’s erroneous? Microsoft Corp listed the .microsoft TLD on the public suffix list.

          I’m not saying anyone can register the domain *.microsoft, but I am saying that any phisher/spammer can spoof *.microsoft in the From: address, and DMARC doesn’t have a good way to address that because the organizational domain will always roll up to *.microsoft, the same way an organizational domain would roll up to *.com. But whereas *.com can publish a DMARC policy because the organization is the *, in a .brand the organization is not the * but instead is the .microsoft. The analogous would be the com for the .com TLD.

Comments are closed.

Skip to main content