I'm building an app where each customer can have their own subdomain. For this example, he setup his subdomain to be: whisky

I created a wildcard subdomain in my DNS: *.myapp.com A

So when he accesses my webapp, he would use the url: whisky.myapp.com and it would resolve to

My app also sends email (email will be handled by sendgrid) using the same subdomain my customer chooses: e.g. customer@whisky.myapp.com

But when I tried to setup a wildcard MX record to sendgrid's servers, my DNS provider does not allow me to do so, citing some standards violation.

e.g. *.myapp.com MX sendgrid.com

Is there any way I can have wildcard subdomains for both?

  • 2
    Which standards violation do they state ? – user9517 supports GoFundMonica Jul 7 '12 at 9:25
  • @wyred are you suggesting that you want requests for both whiskey.myapp.com and cognac.myapp.com to go to If so, what should happen to mail for cognac.myapp.com? Does this also go to whiskey's MX record? – Mike Pennington Jul 7 '12 at 9:29
  • @MikePennington yes, I'm using sendgrid so all mail from all subdomains should point to the same MX record – wyred Jul 7 '12 at 9:42
  • @lain Sorry, the "standards violation" part is just what I heard from a colleague. When I tried to add a wildcard subdomain MX in addition to an already existing wildcard subdomain CNAME, the system simply refuses with the error: "Cannot add data at a node with a CNAME" – wyred Jul 9 '12 at 5:31
  • How you end up implementing this? I'm in exact same situation right now, looking how to either use wildcards or dynamically create new DNS records when new client sign up. – Igor Romanov Sep 18 '12 at 14:06

RFC1912 explicitly acknowledges the existence of wildcard MX records, but warns

A wildcard MX will apply only to names in the zone which aren't listed in the DNS at all.

RFC4592 is a standard-track RFC that clarifies the existence of MX wildcards (see the example in section 2.2.1). I'm pretty sure your DNS provider is, thus, full of it.

I can imagine some DNS software having trouble with the situation, too, either because they don't support wildcard MX records at all, or because they take the "no other records" thing a bit too literally and don't allow both a wildcard MX and a wildcard A. This software is non-standards-compliant, but good luck getting that fixed.

Given how trivial it is (or should be) to automatically setup DNS records when customers sign up, I'd skip the wildcards entirely and just have your app configure DNS records for each customer.

  • Wildcard MX is a great way to say "Open to spammers". Any subdomain will appear to be a legitimate sender – BillThor Jul 7 '12 at 14:50
  • 2
    Yeah, but there's no shortage of legitimate domains to forge, and anyone who is using "is a valid sender domain" as anything other than the weakest of all possible spam scoring methods deserves whatever they get. – womble Jul 7 '12 at 15:20
  • @womple: But I still manage to drop emails using invalid domains. SPF is totally ineffective with wildcard sending domains, but is effectively used by a number of organizations. – BillThor Jul 7 '12 at 16:44
  • Thanks, it's a possible solution, to configure DNS on signup. But I think another problem may occur where some customers are not able to resolve the new domain as soon as it's created. – wyred Jul 9 '12 at 5:28
  • Why wouldn't they be able to? If your DNS infrastructure doesn't suck, the name will be available everywhere by the time the "thanks for your signup" page is finished rendering. – womble Jul 9 '12 at 6:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.