Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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: * A

So when he accesses my webapp, he would use the url: 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.

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. * MX

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

share|improve this question
Which standards violation do they state ? – Iain Jul 7 '12 at 9:25
@wyred are you suggesting that you want requests for both and to go to If so, what should happen to mail for 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
up vote 4 down vote accepted

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.

share|improve this answer
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
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 posting your answer, you agree to the privacy policy and terms of service.

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