Situation is this: you wake up in the morning and found your email hosting is down. You are not getting any emails, either they are bouncing back or going to a blackhole.

What should you do in such a situation?

Email service is much like a chain – if any part is broken, you won’t get things working (apart from lots of frustration!). Since it’s like chain, one must follow step by step to find the problem.

So at this point a good question can be – where does the chain start?

Email hosting consists of 3 parts:

1. Domain Registry record
2. DNS Hosting
3. Email Hosting

Domain Registry record:

Start by checking the domain registration. You can do that using any whois service like who.is, drwhois.com etc. Make sure your domain isn’t expired. If it is, quickly visit your domain registrar control panel and renew it. Most smtp servers keep re-trying to deliver email for around 48hours, so if your domain is expired, you should renew it quickly so that future attempts at delivery will work correctly.

DNS Hosting:

If domain registry is OK, then proceed with checking things at DNS hosting.

DNS servers play an important role in email delivery by giving your MX record to sender’s server which is like an “address” of email host. So you can try sending a DNS query to dns servers for MX records.

You can use online nslookup tools like Zoneedit’s nslookup or network tools nslookup or if you want to try to lookup from your system, use “nslookup” command in Windows DOS (as shown here) and “dig” in Linux (shown here). If server doesn’t returns MX records, then try looking up for “SOA” on that server for your domain. You will probably find no SOA records which “technically” means that server isn’t hosting dns records for your domain. In real world it can be billing issues with host or accidential removal of domain. If you don’t see any SOA records, immediately contact web host via phone. If you are using any decent web host, you can expect things to be up within a couple of minutes. Otherwise I would recommend using any free dns host like editdns or zoneedit. Just signup for a free account with them, add your domain, and then DNS records (MX and A records) followed by change in name servers of your domain.

Email Hosting:

If your DNS server is returning MX records, you can proceed to the next part of chain – email hosting. If your MX records are OK and you are still not getting emails, your of email is likely bouncing and the bounced email will include the “cause” of the bounce back. It can be email account doesn’t exist or server is not accepting email. In most such cases, you would have to contact your email host for help and it can take a day or so to sort out the issue. The best thing you can do in such time is set up a temporary redirection – based email host to prevent bounce back.

You can use free email forwarders like zonedit or editdns to get all incoming emails forwarded to your personal gmail/yahoo account.

To setup forwarding – signup for a free account with provider, add your domain and setup email forwarding for all incoming emails.Then query the dns server of that host for MX records of your domain and set those MX records at existing dns hosting (to prevent hassle of shifting dns hosting).

Summary:

Happy hosting!

Few days back I visited Official Google Apps forum (one of my favorite places ) and answered many questions. It was quite after some time i was there and found few cases/questions/problems as really interesting.

Here’s one of the questions asked there by a admin named aol985 about SPF records.

His question -

As described in http://www.google.com/support/a/bin/answer.py?hl=en&answer=33786 , I set SPF record for mashfilm.ru domain to “v=spf1 include:aspmx.googlemail.com ~all”. But aspmx.googlemail.com currently does not resolves. Is it correct?

Nice one!

He is right on fact that aspmx.googlemail.com does NOT resolve. Ok why?

anurag@root]$ dig aspmx.googlemail.com a

; <<>> DiG 9.3.4-P1.1 <<>> aspmx.googlemail.com a
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42050
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;aspmx.googlemail.com.          IN      A

;; Query time: 100 msec
;; SERVER: 66.33.216.208#53(66.33.216.208)
;; WHEN: Wed Aug  5 02:48:00 2009
;; MSG SIZE  rcvd: 38

[anurag@root]$

Thus no A record which means it won’t resolve, BUT one must remember that a zone can have many records working side by side offering their own feature, like – MX records can be there with/without A, same with txt records, and few other also.

Now observing the spf record by Google – “v=spf1 include:aspmx.googlemail.com ~all”

here include:aspmx.googlemail.com

means to include the spf record of aspmx.googlemail.com which makes sense as:

[anurag@root]$ dig aspmx.googlemail.com txt

; <<>> DiG 9.3.4-P1.1 <<>> aspmx.googlemail.com txt
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30134
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;aspmx.googlemail.com.          IN      TXT

;; ANSWER SECTION:
aspmx.googlemail.com.   7178    IN      TXT     "v=spf1 redirect=_spf.google.com"

;; Query time: 14 msec
;; SERVER: 66.33.216.208#53(66.33.216.208)
;; WHEN: Wed Aug  5 02:54:02 2009
;; MSG SIZE  rcvd: 82

[anurag@root]$

Now it means spf record for aspmx.googlemail.com is “v=spf1 redirect=_spf.google.com”

Now trying to understand _spf.google.com

underscore right in start makes it different from a sub-zone since it can’t be used as a domain but will still remain a working sub zone in terms of DNS.

So now since it can’t be used as a  sub domain i.e which can be used to be attached with web server and can supply pages via ftp, there is no meaning of A record for it here.

Checking txt string of _spf.google.com

[anurag@root]$ dig _spf.google.com txt

; <<>> DiG 9.3.4-P1.1 <<>> _spf.google.com txt
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52983
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_spf.google.com.               IN      TXT

;; ANSWER SECTION:
_spf.google.com.        300     IN      TXT     "v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ?all"

;; Query time: 29 msec
;; SERVER: 66.33.216.208#53(66.33.216.208)
;; WHEN: Wed Aug  5 02:57:26 2009
;; MSG SIZE  rcvd: 229

[anurag@root]$

And here we got it!

So much information in just one hostname!

“v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ?all” is a part of SPF record which Google makes its Google Apps users to use.

Thus using

“v=spf1 include:aspmx.googlemail.com ~all” in spf tells that “this domain allows all of the server on this ip range – ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 as authorized to send email on behalf of that domain.

So that’s how spf works in this case.