As of June 2015, common requirements are:
DKIM Enabling DKIM in Exim
is now a very important tool to reduce the chance of your emails being flagged as spam. It's highly recommended to enable DKIM for your domains.
SPF record with -all instead of ~all (see below)
3) DMARC records
to help remote servers decide what to do with failed DKIM/SPF messages.
The usual things, a) like reverse IP lookup on sending IP, b) forward lookup on that rDNS value preferably pointing to same IP, c) MX record on hostname.
In early 2008, new changes were added to these email providers in the strict rules used to accept email from these providers. The exact details are secret, but what we do know is that SPF records are now a more important factor in these rules.
You can use google to inquire about other people with these issues (you're not alone). A few more descriptive results:
Lets start off with a quick overview of what an SPF record is. An SPF record is simply a TXT type dns record which is used to store information about what IPs are allowed to send email for a specific domain. A receiving mailserver can do a lookup on this TXT record get get this data, and use the information to decide if an IP sending email from a specific domain really is allowed to be sending email for that domain.
There are a few options you can use with SPF records to govern the severity of encforcement on these rules.
Details on these rules can be found here: http://www.openspf.org/SPF_Record_Syntax
By default (as of May 12, 2008), DirectAdmin uses the ~all value for it's SPF records.
This means that all receiving mailservers should be neutral about who is allowed to be sending mail for a domain.
For example, mail would be allowed to come from your DA box, and allowed to come from your clients ISP mailserver (since many ISPs block all smtp traffic out execpt from their own servers). This is why we use a default of ?all, so that it's more allowing of mail from different locations, since many users simply don't have the ability to send through their DA server. (Note: using port 587 instead of 25 to the DA box
is the current workaround for that, which is recommended for this fix).
Now these big email providers don't like this email sending neutrality. They want to know for sure that a sender is correct, so they assume that any domain sending email with a neutral SPF record must be spam, thus your emails end up in their spam folders.
The solution is to setup your SPF record to use the -all option insetad of the ~all option so that email can *only* be sent from your server. This means that you *must* get all of your clients to send their smtp through your server, or they will be tagged as spam for spoofing. If they're blocked on port 25 to your server, tell them to send on port 587 to your server (same thing, just not block by the ISP)
To setup a value of -all, you can either change your DNS zone manually from:
Admin Level -> DNS Administration -> domain.com
or User Level -> DNS Management
"v=spf1 a mx ip4:220.127.116.11 ~all"
"v=spf1 a mx ip4:18.104.22.168 -all"
of course, where 22.214.171.124
should be replaced by your server IP.
If you'd rather do this to all of your domain, you can use perl
perl -pi -e 's/~all/-all/' *.db
change /var/named to the appropriate directory for your db files for your OS (/etc/bind, /etc/namdb)
If you want this to be your default for new domains, type:
cp ../dns_txt.conf .
perl -pi -e 's/~all/-all/' dns_txt.conf
which will change the default TXT template to use the -all value.
Restart named after making the changes. Allow at least 4 hours for the new records to propogate (possibly more if they ignore the TTL values)
There are other basic things on top of the SPF records, like making sure your hostname resolves, and that your server IP has a reverse IP lookup (see How to setup the Mail System
More information about this will be added as it becomes known.