"HELO" kimliği ya SMTP HELO ya da EHLO komutundan türetilir (bkz, [RFC2821]). Bu komutlar SMTP oturumundaki SMTP istemcisinden (gönderici konak) kaynaklanır. HELO ya da EHLO komutunda sağlanan alan adı ile ilgili gereksinimlerin gönderici taraf açısından her zaman belirgin olmadığına ve SPF istemcilerinin "HELO" kimliğinin bozuk olmasına veya bir IP adres sabiti olmasına hazırlıklı olmaları gerekir. Bu belgenin yazımı sırasında, meşru postaların çoğu hala geçersiz HELO alanları ile teslim ediliyordu.

SPF istemcilerinin sadece "MAIL FROM" kimliğini sınamakla yetinmeyip, ayrıca, <gönderici> olarak check_host() işlevini (check_host() İşlevi) uygulayarak "HELO" kimliğini de sınamaları tavsiye olunur *ÖNERİ*.

"MAIL FROM" kimliği ya SMTP MAIL komutundan türetilir (bkz, [RFC2821]). Bu komut, bir iletinin, genellikle göndericinin posta kutusundan oluşan ve teslimatla ilgili bir sorun olduğunda teslimat durum bildirimi iletisinin gönderileceği "dönüş yolu"nu sağlar.

[RFC2821] dönüş yolunun boş olmasına izin verir (RFC 2821'in Dönüş yolu boş olan iletiler bölümüne bakınız). Bu durumda belirgin bir posta kutusu yoktur ve böyle bir iletinin posta sisteminin kendisinden kaynaklanan bir bildirim iletisi olduğu varsayılır. Dönüş yolu boş olduğunda, bu belge, "MAIL FROM" kimliğinin "postmaster" yerel kısmından ve "HELO" kimliğinden (evvelce sınanmış olsun olmasın) oluşan bir posta kutusu olacağı varsayılır.

SPF istemcilerinin "MAIL FROM" kimliğini sınamaları gerekir *ZORUNLU*. SPF istemcileri "MAIL FROM" kimliğini check_host() işlevini <gönderici>yi "MAIL FROM" kimliğine uygulayarak sınarlar.

Bir SPF uyumlu alanın SPF Kayıtları bölümünde açıklandığı gibi geçerli bir SPF kaydı yayınlaması gerekir. Bu kayıt, posta aktarım aracıları tarafından "HELO" ve "MAIL FROM" kimliklerinde alan adını kullanmaya yetkili konakları belirtir.

Eğer alan sahipleri SPF kayıtlarını yayınlamayı tercih ederlerse, bu kayıtların "-all" ile bitmesi veya bunu yapan başka kayıtlara yönlendirilmesi önerilir *ÖNERİ*, böylece yetkilendirmenin tanımsal belirlemesi yapılmış olur.

Alan sahipleri SPF kayıtlarını bu alanı kullanarak asla posta gönderemeyecek konakları belirtmek için de kullanabilirler.

SPF kayıtlarını değiştirirken, tüm meşru postalar sınanıncaya kadar eski kuralın geçerli kalacağı bir geçiş sürecinin olacağı hesaba katılmalıdır.

Bir posta alıcısı aldığı her posta iletisi için bir SPF kaydı sınaması yapabilir. Bir SPF sınamasında, konağın belirtilen kimlikle posta bırakmaya yetkili bir istemci olup olmadığına bakılır. Genellikle böyle sınamalar alıcı posta aktarımcısı tarafından yapılır, fakat posta işleme zincirinin, gerekli bilginin elverişli ve güvenilir olduğu başka bir yerinde de yapılabilir. En azından "MAIL FROM" kimliği sınanmalı *ZORUNLU* ve "HELO" kimliği de bunun öncesinde ayrıca sınanmış olmalıdır *ÖNERİ*.

Alan sahibinin açık onayı olmaksızın, SPF'nin 1. sürümü kayıtlara karşın diğer kimliklerin sınanması, yanlış sonuçlar verdiği bilinen durumların varlığı nedeniyle tavsiye edilmez *ÖNERİ*. Örneğin, hemen hemen tüm posta listeleri "MAIL FROM" kimliğini yeniden yazar (bkz, Postalama Listeleri), fakat bazıları iletideki diğer kimlikleri değiştirmez. Yönlendirme Hizmetleri ve Takma Adlar bölümünde 1.2 şıkkındaki açıklama diğer bir örnektir. Diğer kimlikleri tanımlayan belgeler belirgin bir onay için gereken yöntemi tanımlamalıdır.

SPF sınamalarını gelen posta üzerinde yapılan daha geniş çaplı sınamaların bir parçası olarak kullanmak da mümkündür. Diğer sınamaların sonuçları hangi SPF sınamalarının yapılacağının belirleyicisi olabilir. Örneğin, gönderen konağın IP adresinin yerel aklistede bulunuyor olması tüm diğer sınamaların atlanmasına ve bu konaktan gelen postanın tümünün kabul edilmesine sebep olabilir.

Bir posta alıcısı bir SPF sınaması yapmaya karar verdiğinde, doğru gerçeklenmiş bir check_host() işlevini (check_host() İşlevi) doğru bağımsız değişkenlerle kullanmalıdır *ZORUNLU*. Sınama bir bütün olarak isteğe bağlı olsa da, bir sınama bir kere uygulanmaya karar verildi mi, belirtildiği gibi uygulanmalı, yani yayıncı ile alıcı arasında doğru anlamsallık korunmalıdır.

Sınamayı yaparken, posta alıcı check_host() işlevini işlevin bağımsız değişkenlerine aşağıdaki atamaları yaparak değerlendirmelidir *ZORUNLU*:

<alan> bağımsız değişkeninin iyi biçimlenmiş bir alan ismi olmayabileceğine dikkat ediniz. Örneğin, eğer dönüş yolu boşsa, EHLO/HELO alanı kendiyle ilgili sorunlarla birlikte kullanılır (bkz, HELO Kimliği). Bu durumlarda, check_host() işlevi, İlk İşlem bölümünde bir "None" sonucu döndürmek üzere tanımlanmıştır.

Bir SPF kaydı olmaması sebebiyle, geçersiz, bozuk ve mevcut olmayan alanlar SPF sınamalarının "None" döndürmelerine sebep olsalar bile, hala çoğu MTA'nın önlemi böyle alanlardan gelen epostayı reddetmektir; özellikle, geçersiz "MAIL FROM" durumunda. SPF kayıtlarında bozmadan kaçınma sırasında, eposta reddinin geçersiz alanlardan kaynaklandığı varsayılmalıdır.

Gerçeklenimler, SMTP MAIL FROM komutu ile verilen veriden <alan>ı doğru düzgün elde etmek konusunu dikkatle almalıdırlar, çünkü çoğu MTA, güvenlik sistemlerini aşmak için kötü niyetlerle kullanılmakta olan kaynak rotaları ([RFC2821]'in Kaynak Rotalar bölümüne bakınız), yüzde kotarımları [RFC1123] ve ünlemli yollar [RFC1983] gibi şeyleri hala kabul etmektedir.

Bu bölümde yetkilendirme uygulayan yazılımların, check_host() işlevinin sonuçlarını nasıl yorumlamaları gerektiği açıklanacaktır. Yetkilendirme sınaması SMTP aktarım işlemi sınasında yapılmalıdır *ÖNERİ*. Bu, hataların gönderen MTA'ya doğrudan doğruya SMTP yanıtları yoluyla dönmesini mümkün kılar.

Yetkilendirmenin SMTP aktarımı bittikten sonra sınanması şu gibi sonuçlara yol açar: (1) aldatıcı olması muhtemel başlıklardan gerekli bilginin kusursuz olarak elde edilmesi zor olabilir; (2) göndericinin yetkilendirme kuralı bu arada değişebileceğinden dolayı meşru eposta reddedilebilir.

Yetkilendirme sınaması başarısız olmuş taklit kimliklerle ilgili teslimatın kabul edilmediğine dair bildirimlerin üretilmesi genellikle istismarcılık olarak görülür ve kimlik sahibinin isteklerine açıkça aykırıdır.

550-5.7.1 SPF MAIL FROM sınaması başarısız oldu:
550-5.7.1 example.com'un açıklaması için, lütfen:
550-5.7.1 http://www.example.com/posta-politikasi.html
550 5.7.1 adresine bakınız.