That will only work if you know exactly how your entire mail stack will handle resolution and you re-implement it exactly on your frontend. Consider this case:

Resolving not-mailinator.whatever.com returns:

    not-mailinator.whatever.com. 86400 IN MX 10 a.bad-mailserver.com
    not-mailinator.whatever.com. 86400 IN MX 10 b.bad-mailserver.com
    not-mailinator.whatever.com. 86400 IN MX 10 c.bad-mailserver.com
    not-mailinator.whatever.com. 86400 IN MX 10 d.bad-mailserver.com
    not-mailinator.whatever.com. 86400 IN MX 10 e.bad-mailserver.com
    not-mailinator.whatever.com. 86400 IN MX 10 f.bad-mailserver.com
    not-mailinator.whatever.com. 86400 IN MX 10 g.bad-mailserver.com
    not-mailinator.whatever.com. 86400 IN MX 10 h.bad-mailserver.com
    not-mailinator.whatever.com. 86400 IN MX 10 mailinator.com

If you choose one at random, your frontend has a 90% chance of choosing a mail server that isn't mailinator. But when your MTA tries to send the message, it will notice that bad-mailserver.com is offline and try the other MXes, eventually hitting mailinator and delivering the message you tried to block.

You could put a limit on the number of MX records a domain can have, but Gmail has 5 and so you'd only reduce the chance of success to 80%.

Then you have to consider the mechanics of DNS. How many layers of CNAME indirection will you follow? Will you cache results? (If so, how will you trust that the responses are valid?) How long will you wait for DNS responses?

A poor implementation of DNS lookups will use unbounded time, unbounded bandwidth, and unbounded file descriptors. This isn't a hack you are going to code up in an afternoon, and one mistake means your website is going to randomly go down.

And so you have to ask: why? Why do you care if someone uses mailinator? Spammers are just going to set up their own domain or use someone's malware'd Windows box. And someone that wants to ignore your email is just going to have a procmail rule auto-submit your messages to Spamcop anyway.

So you gain nothing, spend a lot of time programming, and it won't solve any problems. In conclusion: worst idea ever.