We see some typo domains in our mail queue from time to time and I have been thinking of using our internal DNS server to correct these people's mistakes.

Some examples from the current mail queue:


The above domains do not have MX records but it's easy to see what the user meant when they typed it in.

The emails in question are often signup confirmation emails so the user can't login and fix their own email address and running a cron job that fixes it in the database won't send out the confirmation email again.

Setting our internal DNS to resolve these MX lookups to the proper Hotmail, Gmail or Yahoo (or whatever) addresses would most likely result in the mails ending up in the correct inbox. A cron job could also correct their email address in the database.

The best solution would be to do the MX lookup in the signup/email verification code on the web server so we can give the user an error message while they're still on the site but I'm a sysadmin and I can't get the dev time approved for this.

Can anyone see any potential problems with redirecting typo emails using DNS ?


I thought of a problem that potentially scuttles this whole idea. Assuming we do correct the typo domains using DNS, when we connect to the target mail server we're going to (at some point) say:

RCPT TO:<fat-fingered-user@hotmal.com>

And the Hotmail server is probably going to reject it because they don't accept email for hotmal.com and they don't relay mail for me. The problem is that we haven't fixed the address. All we have done is pointed our MTA at the correct server as if we had the correct address.

I also found this mailing list archive which has a different solution to the typo domains. It doesn't solve my problem with letting the users know but it does get the mails out of my mail queue very quickly.

  • 4
    The best solution would be for your users to take five seconds and verify that they typed what they meant, otherwise it bounces. Goofing around with solutions as you propose could cause maintenance headaches later on, especially since it's non-standard and working from the assumption that you know better than the user (or what appears on the Internet later; some of those domains you thought were goofs may not be later on) – Bart Silverstrim Sep 27 '11 at 12:09
  • Good catch. If someone adds real MX records to any one of these domains then I will have to take it out of the typos set in the DNS server. These will need monitoring. I wish to could get my users to type their own email addresses consistently and correctly. – Ladadadada Sep 27 '11 at 13:02
  • This is an example of a problem that should NOT be solved with technology; it's a human problem. Attempts to work around it technologically will cause problems for you. – Bart Silverstrim Sep 27 '11 at 13:07

The biggest problem will be false positives - i.e. those typos that you correct to the wrong domain.

Using a typo that probably wouldn't happen you might get:


do you change this to




The user could have meant either.

It's far simpler just to bounce these back to the user with a "domain not recognised" message and let them make the correction.

  • Indeed, if I correct a typo domain and the user doesn't exist at the wrong domain then it bounces immediately and there's no harm done. If the user does exist then I will have sent the confirmation link to someone random, and that's bad. We will need a well defined policy about how obvious/ambiguous the typo is before a correction can be added to our DNS. – Ladadadada Sep 27 '11 at 12:59

I can't see the problem you are trying to solve. You want to send signup confirmations. But as you can't send signup confirmations to domains that do not exist, there will be no signup. That's OK. Drop the user that couldn't be confirmed and let them sign up again. That's how it goes. This is called Double-Opt-In and is a MUST for verifying Email addresses.

Normally these mails shouldn't even be in the queue:

  1. If the domain does not exist the mail should bounce immediately (time to drop the user instantly).
  2. If the domain resolves but reaches a non-existent user the mail bounces immediately (time to drop the user).
  3. If the domain resolves but the server temporarily defers the mail you can't decide if the mail will be delivered later or is an invalid address (time to wait for option 2 or 4)
  4. If the domain resolves and the user is valid, the mail will be delivered instantly (time to wait for confirmation, but the mail is out of the queue)
  • Option 3 is the closest to what I'm seeing. The domain has no MX records but does have an A record and has no mail server running on that A record IP address. Our MTA will continue trying to connect to the A record IP address for a week before giving up and bouncing. It seems so easy and tempting to fix the typo domains and get these users their emails. I'm just worried that I might break something else in our systems that relies on those domains being in control of their rightful owners. – Ladadadada Sep 27 '11 at 12:54

I agree with ChrisF about the false positives. Lately I've been working with email addresses pulled out of our ERP system and have come across many problems. Just as an example, one of our major ISPs is Optus. As I recall, based only on what is not bounced back, their email domains can be any of

  • optusnet.net
  • optusnet.com
  • optus.com.au
  • optus.net.au
  • optusnet.net.au
  • optusnet.com.au

... and possible others I don't know of.

If I see one that is invalid but looks like it should be an Optus address do I just take a wild guess at which one is correct? After all, it might be any one of those, or none none of them.


I see what you are trying to do, but I wouldn't do it on DNS-level. Why don't you just script/code it into the application?

Check against the list and ask the visitor to confirm the domainname. This is a user error, not a server problem.

  • I mentioned this in the question. I'm a sysadmin and there is no dev time approved for fixing it in the website application. I wouldn't normally do it at the DNS level either. – Ladadadada Sep 27 '11 at 12:36

We have our e-mail validation function check if the domain name for the e-mail address has a MX record. Helps prevent typos and dramatically reduces spam, too.

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.