7

For organization we setup a _domainkey.domain.com as a separate zone instead of creating all our DKIM records on our root domain zone domain.com.

As a result the nameservers for _domainkey.domain.com and domain.com are different.

Is this acceptable?

Numerous ESP's are validating our DKIM setup correctly. One major ESP is not validating and they are saying it's because the nameservers for _domainkey.domain.com and domain.com must be the same in order for mail providers to pass the DKIM authentication. Yet when we send a test to Gmail it does pass DKIM.

Is this company wrong? Or can you host the two on different nameservers?

jadent
  • 175
  • 3
  • 1
    Consider the number of businesses who farm out their email solution to a mailwashing company. Would be easiest to delegate the whole domain, but _domainkeys.domain.dom --> NS of mailwashing.co.dom would be the next best thing. – Criggie Aug 27 '16 at 01:07

2 Answers2

10

RFC 4871 addresses some concerns for subdomains that are not admistratively related to their parent, I.e. the operator of .com taking control of the example.com DKIM records and that with normal DNS delegations there is no guarantee where the cut of administrative control is (i.e. with vanity TLD domains such as .walmart compared to walmart.co.uk there is two levels of difference where administrative control starts and that can even become deeper).
The RFC considers that an acceptable risk for the same reason that it is acceptable for normal domain delegation.

Therefore as far as I can tell subdomain delegation for a _domainkey. subdomain is not outright forbidden and such DNS delegation ought to be followed but §8.13 also says:

Note that a verifier MAY ignore signatures that come from an unlikely domain ...

HBruijn
  • 72,524
  • 21
  • 127
  • 192
  • I would assume that "Note that a verifier MAY ignore signatures that come from an unlikely *domain*" refers to the `d` parameter in the header...? – Håkan Lindqvist Aug 26 '16 at 23:05
  • @HåkanLindqvist: It also means that, for example, the Gmail team is fully within their rights to reject [validly signed email that purports to originate from a Google address but actually didn't](https://www.wired.com/2012/10/dkim-vulnerability-widespread/). – Kevin Aug 27 '16 at 03:12
  • 2
    The major ESP deliverability team has now also agreed that you can host _domainkey on a different zone and that their verification routine has a bug in it – jadent Aug 31 '16 at 14:55
4

There is nothing in the RFC that would indicate that all records must have the same nameservers. However, in section 8.4 it is recommended that strict validation of glue records be applied. It is possible your server is not supplying the glue records.

It is common to setup sub-domains as separate zones. These can be served by the same server or delegated to different nameservers. example.com. is a sub-domain of the com. domain.

Having _domainkey as a separate zone makes updating the sub-domain simpler as only that zone needs to be reloaded. When rotating keys, only a few entries need to reloaded. It also prevents accidental changes to other records in the domain.

I haven't tested, but it may make sharing the zone among multiple domain simpler. I'll be testing this soon for my _domainkey and _dmarc sub-domains.

BillThor
  • 27,354
  • 3
  • 35
  • 69