DNS and your email

You're not getting any email if the world can't find your server, and it us also getting increasingly difficult to send email without having certain DNS settings right.

To set up email you need two entries in particular. Your “MX” record and your “mail.” record. If you're using our simple DNS product, those are taken care of for you, unfortunately if you're going to be sending a lot of emails, that product is probably no longer sufficient. More about that later.

To set up the mx record is not difficult at all. In our advanced DNS product (which is real similar to most such interfaces you will work with) you enter an “@” symbol under “host” on the line for the MX record, and under “address” enter “mail. .“ Don't forget the period after the domain name, it is important, otherwise your domain name will be appended once again to the entry, this time with the period at the end – which isn't correct and won't work. Once you have the record entered, go ahead and 'save' it. When the field populates in the table, add the number “10” in the small box to the left of the address and save it again.

That's it. You now have an mx record which tells the world to send mail to your domain to “mail.. So now you need to make an 'A' record for mail..

All that's necessary is to enter “mail” under the “host” heading in the table, select “A” for record type and then enter your mail server's IP. If everything is on one server, that's fine (and easy), just put your server IP in the “address” space and save it. If you're running mail services on a separate server, that's find too, simply enter that server's IP in the address space.

You are now all set up to receive email, assuming you have email server software running.

Most of the headaches with email are in the process of sending the emails. Remember, at one time over 90% of ALL the traffic on the internet was spam email. Things have been done to defend against spam.

One of the things that increasing numbers of mail servers do is check what is called reverse DNS. When a server sends an email, in the internet header the server adds its own IP address. Most email client programs don't show the full internet headers by default (some of them can't show them at all), so you may never have seen them – but they are there. The receiving mail server does a “reverse lookup” on that IP address and expects the domain name it finds that way to match the domain name in the “from” address in the header.

If it doesn't all is not lost, which is good since many people are in shared hosting environments and the rDNS can't match the rDNS of the server as each IP address can have only ONE domain assigned as the reverse match.

If all this is confusing, a couple of examples might help.

If you open the command line interface on your computer (on a Windows machine, click on Start>Run type in 'cmd in the box and hit “Enter”), type in at the prompt: nslookup google.com .

You will get something smilar to:

nslookup google.com

Non-authoritative answer:
Name: google.com
Address: 64.233.167.99
Name: google.com
Address: 64.233.187.99
Name: google.com
Address: 72.14.207.99

Now, if you enter the first IP address thus: nslookup 64.233.167.99 you'll get:

nslookup 64.233.167.99

Non-authoritative answer:

99.167.233.64.in-addr.arpa name = py-in-f99.google.com.

That name is the rDNS value assigned to that IP address. For a mail server it must either match the domain in the email address or be mail., although only the most paranoid mail servers insist on the latter (but they are out there).

So if you are on your own dedicated server with your own domain and email, you simply go to our “Edit Server” page in your admin.cari.net account and enter your domain name as the rDNS and you'll be fine.

It's a bit more complicated on a shared server where multiple domains are sharing IP's.

Even if each domain is on an “exclusive” IP address on the server, which works fine for SSL certificates for secure transactions – but everyone on the server is sharing the same email server program, and while it LISTENS on all the active IP addresses on the server it only SENDS on the primary IP of the server. So it is that IP that gets stamped on all the emails sent from the server.

To get around this problem we use a technique called Sender Policy Framework, or SPF for short. A fancy name for a short text record that is added to the DNS records for a domain which tells the world which servers are allowed to send email for that domain.

To set up an SPF record for a domain at cari.net you will need our advanced DNS product. In that interface under “host” goes the “@” symbol, you select “TXT” for the 'type', and then in quotations you enter the SPF record.

There is excellent help on the web for composing an SPF record for your domain. First, make sure you know the IP and/or the domain name of the sending server(s), then go to:

SPF: A Sender Policy Framework to Prevent Email Forgery

and use their wizard. Cut and paste their result into the TXT field in the DNS setup (with the quotation marks). And you are set. If you want to double check the record, you can use SPF Query Tool .

And there you are. With a proper rDNS and/or SPF record you should have no problems with sending email (so long as you don't get yourself on a blacklist, but that's a different problem.)