If you do nothing to let the world know your authorized transmitter addresses, receivers will have to accept whatever comes in under your ID. This will generally result in a large amount of spam, and a bad reputation for your ID. Most recipients will not accept mail from a sender with a bad reputation, unless that mail goes first through a gauntlet of blacklists and spam filters. The inevitable losses will make delivery of your mail less reliable. Furthermore, without an authenticated return address, you may not even know your mail was lost.
If you publish only an SPF record ending in ?all (insisting that no mail using your ID be rejected) we follow your policy. Everything is accepted, it all goes to the spam filter, and whatever is spam, counts against your reputation.
If you publish a Registry record, saying "Only these addresses can say HELO using my ID.", we will follow that policy, and your reputation should improve dramatically. Anything that we can reject, even spam coming from your own IP blocks, will not count against your ID. All of this can be done by simply publishing the required information in DNS at _auth.<SENDERS-ID>. You can even use our convenient tool to construct a record, then just cut and paste it to your own DNS service.
The important thing to understand is, we don't make policy. You decide what gets rejected as a forgery. We count the spam in what is accepted. Our recipients then decide whether mail under your ID will be whitelisted, or sent to the spam filter.
In addition to publishing your authorized addresses, you can sign up as a Registered Sender. The advantages of registration include:
1) You will have access to our alert system, whereby you
can generate an alert on your own ID. This works like a stolen credit
card notice. You are not responsible for any spam not authorized by your
updated record, even if receivers are unaware of the alert and use your old
2) You can receive immediate alerts of forgery attempts on your registered ID, and daily summaries of any spam counted against that ID. We will also keep the spam reports on our server for a few days, in case you wish to review them.
3) You can choose a more private address than "postmaster" for our communications with you.
4) You will be supporting a worthy cause. 100% of your registration fee will go to supporting Registry operations. The purpose of the fee is not to make money from senders, but to prevent millions of spammer registrations from clogging the system.
There is no one authentication method best for all situations. Each has its strengths and weaknesses. See this article for a short discussion of the different methods.
You need not chose any method to use the Registry. Just publish your authorized transmitter addresses, and we will check the address of any server that says HELO this is <your ID>. That will allow us to reject everything but the spam coming directly from your authorized servers, which should be none. Try a simple setup, pay attention to our reports of forgery and spam, then decide if you need more authentication methods.
Here is a simple, low-maintenance authentication record, one that doesn't change even if you change your MX and A records:
_auth.example.com. TXT "helo=a,mx"
"I already published my sending addresses. Stop bothering me!!" - overworked mail system admin
You can use your SPF or SenderID records as a convenient way to provide us with your Authorized HELO Addresses. If we see "helo=spf" in your _auth record, we will extract the IP4 address blocks from the SPF (or SenderID) record for your domain. There are a few problems to avoid, however.
1) SPF records sometimes do not include *all* the addresses authorized to say "HELO" under the given Identity. This will result in an immediate REJECT, and should be handled as a failure of the communications equipment, requiring an immediate fix, not involving end users. Sometimes, a really large domain will find it inconvenient to list every authorized sending address. In that case, we recommend using a different HELO name for the different divisions of the domain. "bigISP.com", for example, could have a few other IDs (bigISP-dallas.com, bigISP-boston.com, etc.), maybe one for each region or IP block, so the records will be short and easy to manage.
2) SPF records often include *more* than just the sender's own IP addresses. This is necessary, for example, when a sender wants to include other domains in an SPF record. It simply means that a sender is authorizing some other domain to say "I have MAIL FROM: <senders domain>".
3) We do not use all the "mechanisms" available in an SPF record. Currently we interpret only the IP4, MX, A, and REDIRECT terms and ignore everything else. This usually provides us with a complete list of HELO addresses. If you have INCLUDE terms in your SPF record, however, we may need some additional information. The SPF spec says these terms should be used only to include addresses outside your "administrative domain", e.g. forwarders who may change their addresses and forget to notify you. If you must use INCLUDE terms to cover your own servers, please add them also as separate helo blocks in your _auth record.
Here is what we recommend for an "all purpose" SPF record, covering both the HELO and Mail From Identities:
1) Use IP4, MX, and A terms to list your own HELO addresses.
2) Use INCLUDE terms to list the domains of other Agents who handle your outgoing mail.
3) Minimize your use of other terms.
Here is an example of a setup more complex than most senders will ever need. This sender that offers four authentication methods, and certifies that his HELO addresses are all in his SPF record, except one block which is added separately.
_auth.example.com. TXT "method=CSV,SPF,SID,DKIM helo=SPF,126.96.36.199/30"
example.com. TXT "v=spf1 mx ip4:188.8.131.52/24 ip4:184.108.40.206/27 include:mailsystem.us ?all"
Note: Using your SPF record to provide us with your HELO addresses is not the same as calling for an SPF check. If you want an SPF check, to be run exactly as called for in RFC4408, put 'method=SPF' in your _auth record.
Many domain owners don't want the expense and responsibility of operating their own transmitters. There are two solutions to this problem. They can relay their mail through a reputable Agent's server, or they can make arrangements with that Agent to operate a transmitter on their behalf. The choice depends on their needs, including reliability of delivery, and recipients' confidence in the authenticity of their messages. For most senders, reliability will be the main issue. An Agent with a good reputation will have no problem getting the mail delivered.
For some senders, however, it is important that recipients see the message as coming directly from them, and not worry if a message from redcross.org, sent by advertising.com, is really a legitimate request for donations, or a clever scam. For these senders, the Agent must identify as the original sender. This requires explicit authorization by the sender of the Agent's IP addresses. Normally, this will be just one or two IP addresses, but it could be a whole block. The sender must trust the Agent not to allow any abuse of addresses authorized under the sender's Identity. Any such abuse will count against the sender.
An alternative to using an Agent is to operate your own transmitter. For small domains with the right technical expertise, this is an option. There is still a problem in establishing a good enough reputation to have recipients accept your mail. Until you have built up a good record (long experience with lots of good mail and little reported spam) you may be treated with suspicion by rating services who don't know you. We expect there will be "accreditation services" available for such senders, and also "vouching services" offered by some large ISPs with many small-business customers.
Accreditation works by having a trusted Accreditation Service listed in your Registry record. "svc=AS:A" A recipient who trusts service "AS" will accept their A-rating of your Identity, as he would any other rating.
Vouching works by having the voucher "lend" his reputation to the new sender. Any spam sent under a vouched ID will count against both that ID and the voucher's ID. The voucher is basically saying "Treat this message as if it came from us." A company like aol.com, for example, might grant such vouchers to its business-class customers. If the authentication record for 'example.org' says "svc=VX:aol.com", the receiver will look for a "vouching" record at _vouch.example.org.aol.com. The reputation of aol.com will then be applied to example.org.
Vouching may fail if vouchers don't take their role seriously, and recipients stop trusting service VX. By counting spam against both IDs, we ensure that the voucher will be as concerned about the quality of vouched mail as if it came from their own transmitters.