Gönderici adresinin sınanması anlamında, sadece göndericinin varlığının değil, ayrıca kimliğinin de kanıtlanmasını sağlayacak çeşitli kullanıcı doğrulama şemaları geliştirilmiştir. İnternet alanının sahibi kendi alanındaki göndericilerden teslimata yetkili olanları belirleyen bazı kurallar belirtir.
Bu şemaların ilklerinden iki örnek:
Bu iki şema altında, kullanıcı@alanadı.dom adresli tüm postalar alanadı.dom'un DNS kayıtlarında bulunan konaklardan gelmek zorundadır.
Bu iki şema gelişmiş, hatta benzer çalışmalara çatallanmıştır.
SPF (“Sender Policy Framework” veya “Sender Permitted From” kısaltması), gönderici yetkilendirme için en iyi bilinen şemalardan biridir. Yukarıdaki şemalardan hareketle ortaya çıkmıştır ama kuralları belirtmek bakımından biraz daha esnek bir yapıdadır.
SPF bilgisi bir alan adının üst düzey DNS kayıtları arasında bir TXT kaydı olarak görünür. Bu kayıt bu alanın kullanıcısının ağzından basitçe şunu der: "Ben postamı sadece bu makinelerden gönderiyorum. Eğer başka bir makine benim postamı oradan gönderdiğini iddia ediyorsa, o bir yalancıdır." Bu kayıtta şunlar belirtilmiş olabilir:
Bu TXT kaydının geliştirilmesi hala sürmektedir, yine de temel özellikler yukarıda bahsedildiği gibidir. Bir v=spf1 dizgesi ile başlar ve şu belirteçlerden bazıları ya da hepsi kullanılabilir:
Bu belirteçlerin herbirinin önüne bir yetkili kaynak olduğunu belirtmek için bir artı işareti (bu öntanımlıdır), yetkisiz olduğunu belirtmek için bir eksi işareti, yetki bakımından nötr olduğunu belirtmek için soru işareti veya yetkisiz olarak değerlendirilebilineceğini belirtmek üzere bir yaklaşık işareti (~) konabilir.
Her belirteç bir ikinokta üstüste işaretinden sonra bir alan adı belirtmek üzere kullanılabilir. Örneğin, bir Comcast müşterisiyseniz, sizin DNS kayıtlarınız arasında “v=spf1 -ptr:client.comcast.net ptr:comcast.net -all” şeklinde bir TXT kaydı olabilir. Bu kayıt, bu alandan posta gönderen makinenin IP adresi çözümlendiğinde elde edilen isim
Her alan adı için bir SPF kaydı bulunmalıdır. Bazı büyük siteler artık bu kaydın bulunmadığı alanlardan posta kabul etmemektedir.
Gönderici yetkilendirme şemaları genelde kabul görmemiş olmasına rağmen SPF evrensel olarak büyük oranda kabul görmüştür. SPF'ye karşı çıkanlar, alan adı sahiplerinin posta gönderen müşterileri/kullanıcıları üzerinde bir tekel kurmak için bunu kullanabileceklerini ileri sürmektedirle[27].
Diğer bir idda, SPF'nin geleneksel eposta yönlendirmesini bozduğu şeklindedir; yönlendiren konak, zarf göndericisinin alan adındaki SPF kaydında yetkisiz olabilir. Bu sorun, Göndericiyi Yeniden Yazma Şeması (SRS - Sender Rewriting Scheme) ile kısmen halledilebilir. SRS'de postanın yönlendiricisi Zarf Göndericisi adresinin biçimini değiştirir:


kullanıcı=kaynak.alanadı@yönlendirici.alanadı
Kurallarının gönderici alan adının DNS bilgileri arasında bir TXT kaydı olarak görünmesi bakımından SPF'ye benzer. Ancak, basit anahtar sözcükler yerine, XML olarak kodlanmış oldukça geniş kapsamlı MS CIDE bilgilerinden oluşur. Bu XML şeması Microsoft tarafından bir lisans altında yayınlanmıştır.
SPF, bir postanın sadece Zarf Göndericisi adresine bakarak çalışırken, MS CIDE iletinin RFC 2822 başlıklarını değerlendiren bir araç olarak karşımıza çıkar. Böyle bir sınamanın SMTP aktarımında yapılabileceği en erken nokta, ileti verisi alındıktan sonra ve son 250 yanıtını göndermeden öncedir.
Dobra dobra ölü doğmuş denebilir. Patentiyle ve karmaşıklığıyla bir engelli olarak doğmuş da denebilir.
http://www.openspf.org/'da SPF'ye ek olarak MS Çağrı kimliğini de (MS CIDE) sınayacak araçlar bulabilirsiniz.
Basit Çağrıcı Yetkilendirme Yapısının (SCAF - Simple Caller Authorization Framework) bir parçası. Bu şema, zaten özgün RMX'in tasarımcısı olan Hadmut Danisch tarafından geliştirilmiştir.
RMX++, HTTP sunucular üzerinden özdevimli yetkilendirmeyi mümkün kılar. Alanadı sahibi DNS üzerinden bir sunucu belirtir ve posta alıcısı konak bu sunucuya bağlanarak göndericinin geçerliliğini saptamak için oradan bir yetkilendirme kaydı elde etmeye çalışır.
Bu şema alanadı sahibine gönderici adreslerini yetkilendirmede kullanılacak kuralları daha ayrıntılı belirleme imkanı verir (SPF kayıtlarıyla, ağının yapısını kamuya açık alanlarda ilan etmeksizin). Hadmut'tan bir örnek: Hergün iş saatleri dışında belli bir adresten beş iletiden fazlasına izin vermeyen bir yetkilendirme sunucusu bu sınır aşıldığında bir uyarı verecektir.
Keza, SCAF epostalarla sınırlı değildir, ayrıca IP üzerinden sesli iletişim (VoIP) gibi hizmetler için çağrıcı yetkilendirmesi için kullanılabilir.
Rick Stewart <rick.stewart (at) theinternetco.net> RMX++'nın makine ve ağ kaynaklarına etkisine dikkat çekerek RMX++'in perde arkasında kalan bir olasılıktan sözetmiştir: HTTP sunucularının yanıtları DNS sunucularının ki gibi geniş çapta önbelleklenmediğinden bir HTTP isteği yapmak bir DNS isteğinden kat kat pahalıya malolacaktır.
Rick devam ediyor, RMX++'nın özdevimli doğası bir başarısızlığın nedenlerinin bulunmasını da zorlaştıracaktır. Eğer günlük beş iletilik bir sınır varsa, bu sınır, tek bir iletinin beş kere sınanması ile dolacaktır. Yani şema, bir iletinin defalarca sınanmasına imkan vermiyor.
RMX, RMX++, ve SCAF hakkında daha fazla bilgi edinmek için
http://www.danisch.de/work/security/antispam.html adresine bakınız.