A couple of weeks ago now, issues with Dreamhost not withstanding, I converted over to using Gmail for my own domain after signing up for Google Applications for your (my) Domain. While this makes essentially no difference at all to anyone else, other than avoiding confusion on which e‑mail account to respond to, it will hopefully simplify my e‑mail woes and spam volume.
There are certainly work-arounds to using Gmail with your other e‑mail addresses and those are fine, but I wanted one that was less troublesome than just forwarding addresses. I wanted to be able to send, receive, and store e‑mail with what I consider to be my permanent address. Lastly, I wanted this to integrate with my desktop mail program, in effect give me off-site access and storage of my entire e‑mail. Porting e‑mail archives is painful and this will go a long way to easing that in the future.
First is easy: just sign up for Google Apps at your domain (it’s actually Gmail, calendar, docs & spreadsheets, etc. all together). Next, in order to use the e‑mail address, you’ll have to have DNS registry access to your domain. If you personally registered your domain and host your files, or at least know the person who does this, chances are you do. Once you’ve activated your Google Apps account, you’ll have to log into your hosting management site and alter your DNS, or MX records, for mail. Google has some instructions for most major hosting services as well as generic ones. Dreamhost, where this very file is sitting right now, has some specific directions on what to change to in their Wiki. Two points:
- The priority value goes first, example:
10 ASPMX2.GOOGLEMAIL.COM. - That last period is very important, so don’t think it’s just misplaced punctuation in the instructions.
Now, you’ve got your DNS records changed, the next step is to wait. It took well over 24 hours for the DNS records to propagate after I changed mine, which is much longer than what it seemed to take for plain old http DNS changes. This may have just been a fluke, but there’s a very good chance some e‑mail to you will get bounced back to the sender as “undeliverable” over the next day or so. You can keep track of the progress by simply entering your domain name here.
The hardest step for me was setting up Mail.app. That’s just because the instructions at Google are really written for a typical Gmail account, where as some of the settings are obviously slightly different for your site. Basically, you’ll use all the same setting just with your own domain e‑mail in both the e‑mail address (well, duh!) and username fields. Also, don’t forget to check the “Use SSL” box in the Advanced settings tab. Okay, I’m not even sure why that took me more than two minutes to figure out. There are instructions for most common desktop e‑mail applications, as well.
So far, using G‑mail is great. I had to set up some rules in Mail to stick e‑mails I sent from my Gmail panel into the correct “Sent” in mail. As of yet, I don’t know if there’s any way to get Mail and Gmail to sync such that a e‑mail deleted in one is removed in the other. Chances are, that’s just asking for too much. However, having some very robust spam filtering alone has been worth it (my spam has nearly eliminated at this point). Further, I like the idea of not having to struggle to import or copy over e‑mail when switching machines when that comes up again. It’ll always be sitting there on my Gmail account’s server.
I highly recommend using this solution over two separate e‑mail accounts or the desktop-only or g‑mail-only approach. It really is the best of both worlds. The only real hurdle is having access to an e‑mail address for which you can change the DNS settings for and that’s most everyone I know now, to tell the truth. If not, then consider buying a domain name on the cheap, will ya?
Update Oct. 24th, 2007 — Google is currently in the process of rolling out IMAP for Gmail. Unlike POP accounts, IMAP does sync various changes across platforms. This means that reading or deleting an e‑mail in one place changes it in the other. I can’t see why this solution is now anything less than perfect.
MX record changes (mail) can take quite some time, so yours wasn’t really a fluke. I’ve seen DNS changes go almost instantaneously, though those were hosted with Network Solutions. Godaddy’s pretty fast, too. anyway, during MX record updates, it’s good to keep your old ones set, though with differing priorities, just something higher. 20 usually does it, and you keep both mail systems running temporarily. typically, business changes like this are made over a weekend or holiday. in 48–72 hours, you should be able to remove the old MX records as the new system should be receiving all the new mail. keeping both mail server systems up until the MX record updates propagate helps prevent bounce messages, again, more important in business environments than for personal stuff.
just a little extra info for you there
I didn’t want to say since I can’t remember for sure, but I vaguely remember a colleague telling me about priority 70 & 90 for old servers? apparently more space between makes a larger difference. not sure how much truth there is to that…
Thanks for the tip on using a different priority setting for old e‑mail servers during the transfer. That seems like a really good way to go about doing this. I was fortunate in that I didn’t seem to lose any important e‑mails (that or they got so angry they don’t speak to me anymore). However, in a business setting, I can see that being a huge problem.
I didn’t see a lot of rhyme or reason to the priority setting values or how they related to one another. Then again, I didn’t really look into it much.