I have been looking at AOL and YAHOO as they both cause issues with my mail server when emails get sent, this is due to the domain key.

the domainkey (DKIM) ID the mail server back to teh IP address of the server to that when spammers nick your email address, they know you didnt send it and debunk the emails not sent from the right place.

After reading lots of articals the RFC is still havent got a clue what they are onabout.One says use this and that, then other says something different, then when testing, it says there are errors in it.
TBH I havent got a clue what Im doing here, so does anyone else know how to set it up on the DNS record.

Thanks

Sounds like at some point in time your MX server IP has been "BLACKLISTED".
Search on "email blacklist" and you should find the way to be de-listed, but if you've been hacked (your mail server or user list) you'll most likely be back on.
A couple of things.
Never foward non-authoritative mail. This is to say that you will not allow mail that comes from a client that is on the internet, but not directly attached or does not have the UID/PWD necessary to authenticate to your server to pass through your server.
Having said that, if you have a global userbase that may authenticate through cafe's or any other connection, that you may end up with issues insofar as the client can read the email, but can't send any. There are several workarounds for this, some of which will cost you a bit, or you can provide a http or even https access to the mail server that will permit most if not all of the approved traffic to pass through while eliminating the spammer pass throughs that most likely got you on the black list to begin with.

Gerritt

pretty sure im not black listed, I will check again, but this DKIM stuff is not helping me get in touch with clients..

Server is secure, it doesnt forward allow forwarding, secure log in etc..

Rory,
My bad, I failed to actually read the entirety of your original post and assumed a blacklist scenerio.
DKIM utilizes a modification to the mail protocol that supports an additional field in the message header. By utilizing this field in addition to a public/private keyset such as RSA/Verisign, a "call home" can be initiated to the senders DNS name at which point the Public key is matched with the private key and a "authenticated" message can be sent back to the recievers MTA to "prove" to a degree that the message actually originated there.

While this provides for source authentication, it does not address the possibility of message modification in transit. You would have to encrypt the contents of the message using the same type of technology in order to ensure the contents are acurate.

DKIM.org is a good starting point, and make sure you are referencing the "final" and not the Historical RFC on this.

DomainKeys has to be setup in your mail server, so this may not be feasible if you don't have access to do that, or somewhat complicated even if you do.

SPF (http://en.wikipedia.org/wiki/Sender_Policy_Framework) on the other hand is much easier to setup and may help you with some mail filters. To implement, you need to add a TXT record that specifies IPs for mail servers sending email for your domain name. http://www.openspf.org/ has a wizard to generate the record.

Both solutions may help with spam filters at large ISPs, but nothing is foolproof and your email may still get eaten as a false-positive. Such is our unfortunate spam-ridden life..

Thanks Vitaliy thats just what I was after, As it was the DNS record part that I needed.

I can look up the header part of the mail system to add in on the mail server, I think that most require the look back (reverce DNS) to actaully work, I was halfway there before hand but wasnt sure on the content of the DNS record.

Oddly some guides start with the domain as _domainkey TXT bla bla.. but the wizzard shows it under the actaul domain tag ( mail.gtwcmt ) That maybe where I have gone a bit wrong??

I will pop it on and then test it..