stunt
I wrote last year about using “stunt” nameservers for customer subdomain authentication – i.e. dynamically generating all the authentication records needed in DNS for each customer as needed. For example, if you’re an ESP that has customers who can’t or won’t use their own domains and you still need to give them unique subdomains you can generate CNAME records to support white label DKIM authentication: selector ._domainkey. customerid .espcustomer.com CNAME selector .dkim.esp.com or generate white label DMARC with useful rua= reporting: _dmarc. customerid .espcustomer.com TXT “v=DMARC1 p=none rua=rua+ customerid @esp.com” Once you’ve set up these DNS records once they’ll work for all your customers, you just need to put the right domains in your DKIM signature and return path. I shared some demo code to explain the concept last year, but since then we’ve developed a robust, production-ready application to dynamically serve DNS in this way. It’s called
On Tuesday I wrote about using DNS wildcards to implement customer-specific subdomains for email authentication. As I said then, that approach isn’t perfect. You’d much prefer to have per-customer domain authentication, where each customer has their own DKIM d= and ideally their own SPF records, rather than having all customers sharing those records and relying on loose DMARC alignment to have them to work with a per-customer subdomain in the 5322 From: header. But doing that with DNS wildcards would have some odd side effects, such as TXT records appearing where they weren’t expected, in ways that could trigger bugs in rarely tested code paths at mailbox providers and potentially even open up security problems. I mentioned using a “stunt” DNS server would be one option to do that, and then quite a few people asked me what I meant by that. A stunt DNS server is one that doesn’t