Tony's Quick Guide to CSA

Client SMTP Authorization is a way of publishing in the DNS which machines are permitted to send email and who is responsible for them. CSA is not based on email addresses, so it does not say anything about who is responsible for individual messages. CSA is not based on IP addresses, so it does not say anything about who is responsible for providing the machine with connectivity. Instead, CSA is based on the machine's host name, which identifies who controls the software running on the machine.

SMTP client host names

When sending email an SMTP client starts a new session with an SMTP server by saying EHLO followed by its host name. Traditionally this host name has been purely for diagnostic purposes, and recipients are not supposed to reject messages if the client states an invalid one. This means that a large proportion of viruses and spamware lie about their host name; however it isn't possible to simply start rejecting email from SMTP clients that use invalid host names, because about 1/3 of legitimate senders are misconfigured. CSA allows a sending site to state that its SMTP clients are correctly configured and that recipients are allowed to strictly validate their host names.

CSA SRV record format

CSA uses specially-formatted SRV records in the DNS. SRV records are looked up using three parameters. The Name that is being queried is prefixed with two extra labels, which identify the Service and Protocol that is being asked about. For CSA these labels are _client._smtp, and the Name is the host name from the client's EHLO command.

The record returned by the DNS SRV query has four fields. The first three are numbers, called the Priority, Weight, and Port. CSA uses the Priority field to identify the version of CSA, which must be 1.

The Weight field is used to indicate whether or not clients using the Name are authorized to send email. If it is 1 the Name is not authorized. If it is 2 the Name is authorized. Other Weight values are not useful.

The Port field is used to make assertions about the Name and all of its subdomains. If it is 0 nothing special is asserted. If it is 1 then all legitimate email senders that use a host name which is a subdomain of the Name must be explicitly authorized with their own CSA SRV record. That is, if a client's host name doesn't have a positive CSA SRV record and one of its parent domains states that explicit authorization is required, then the client is not authorized. At the moment no other assertions are defined.

Finally, after the numerical fields is the Target. This is relevant if the Weight field is 2 (i.e. authorized). The SMTP client must use an IP address belonging to the Target in order to be able to legimately use the Name. The Name usually has appropriate address records, so the Target is usually the same as the Name.


Instant CSA how-to

Your domain name is You have an email server called and a web server called, plus some other miscellaneous computers. Your DNS currently looks like this:      MX 10 A  CNAME  A  A A

Most of your outgoing email comes from your email server, but your web server also sends a few messages. You do not have any other computers that send email. You can publish this information by adding the following CSA records to your DNS:      SRV 1 1 1 SRV 1 2 1  SRV 1 2 1

Example 1:

Cambridge University's central email relays have names like These should obviously have CSA records that state that they are authorized (Weight = 2). They have no subdomains, so the CSA records should also state that all legitimate subdomains have explicit CSA records (Port = 1) - i.e. no subdomains are legitimate. So the DNS setup for one of them will look like: SRV 1 2 1               A

Example 2:

Cambridge University's central email service (which provides a message store and webmail and so forth) is called Hermes. It has an email domain for its users called No systems legitimately use this as their host name, though it's quite common for viruses and spamware to do so. Therefore it would be useful to give it a negative CSA record (Weight = 1). There are a number of host names under, but none of them are used to send email (Port = 1); instead email goes out via the central relays. So its DNS setup will look like the following. Note that CSA ignores the target IP address in this case. SRV 1 1 1               MX  7               A

Example 3:

Cambridge University's top level domain is, and this is also used as an email domain. It should not be authorized for the same reasons as (Weight = 1). However there are many host names under which are permitted to send email, but we have not yet identified all of them and given them CSA records (Port = 0). So its DNS setup will look like the following. The lack of target IP addresses does not matter. SRV 1 1 0               MX  7

Example 4:

One of my friends has a co-located computer called Chiark. Its email domain and its host name are both the same: Its DNS setup will look like the following. Other machines are prevented from claiming to be Chiark because CSA will check that they are coming from the correct IP address. SRV 1 2 1               MX  10               A

How to check CSA


Exim versions 4.51 and greater will support CSA. You can configure to to check CSA by adding the following clause to your access control lists, near where you do DNS blacklist checks.

        require verify = csa









Usage scenarios

CSA by yourself

It's quite common for viruses and spamware to get the semantics of the EHLO command wrong, so that instead of stating their own host name they use the email domain of the recpient. Therefore if you publish CSA records in the DNS and check CSA in your MTA, you will stop a significant proportion of junk email (5% - 10%).

Deploying CSA

You can deploy CSA in stages. You can start off by adding positive CSA records for your main outgoing email servers, and negative records for any invalid EHLO host names that are commonly used by viruses and spamware, for example your email domains. Once you have audited your network to find all the machines that send email - such as web servers or application servers - you can add an explicit authorization assertion to your top level domain (Port = 1). If your network is large and has many sub-domains, you can add the assertions one at a time to each of the subdomains as they are audited.

Fixing blacklist problems

CSA can be used to correct errors in DNS blacklists. You might be blocking email using a DNSBL that is supposed to list only consumer grade IP addresses. If this DNSBL is sometimes wrong, you might want to let an SMTP client through if it passes CSA. For example, in Exim:

        require verify = csa
        deny    condition = ${if !eq{$csa_status}{ok} }
                dnslists =

Distributed whitelisting

CSA can be used as the basis for a distributed whitelist system. This system can be based on host names rather than IP addresses, so can be easier to maintain. For example, email system administrators in the UK academic community might like to exempt legitimate email from other universities from anti-spam checks:

        require verify = csa
        deny    condition = ${if !and{{ eq{$csa_status}{ok} } \
                                      { match{$sender_host_name}{[.]ac[.]uk\$} }} }
                dnslists =

Blocking outgoing email by default

An ISP might wish to restrict its users from sending email directly from their home computers, but blocking port 25 is often too harsh. Instead the ISP can use CSA to provide a default restriction, but its customers will still be able to send email directly if they take responsibility by using their own host names instead of the ISP's. Say the ISP is called and its ADSL host names are subdomains of Then the ISP can publish the following CSA record to implement the default restriction: SRV 1 1 1

This will allow recipients to block email from the more competent types of viruses and spamware that use a correct EHLO hostname.

Opting out of the block

If our example ISP has a customer that wants to send email directly, e.g. a not-for-profit organization called, then that customer can avoid being blocked by configuring its email server to use a host name in its own domain. The server thereby states that it is the responsibility of the customer, not the ISP. The customer publishes the following CSA record, which refers to the customer's ADSL address. SRV 1 2 1

Rating SMTP client behaviour

By itself CSA says nothing about whether an SMTP client is well-behaved. However it does give you a solid identification of the organization responsible for the SMTP client, in the form of a domain name. CSA relies on reputation and accreditation services to deal with irresponsible SMTP client operators. Client ratings are published using "RHSBL"s, which are like traditional DNSBLs but are based on domain names rather than IP addresses. Other new email authentication protocols, such as SPF and DomainKeys, also rely on RHSBLs.

Tony Finch <>
$Cambridge: hermes/doc/antiforgery/csa.html,v 1.9 2005/05/06 20:14:51 fanf2 Exp $