Defaults.Exposed › Düzeltmeler › SPF (Sender Policy Framework)

SPF (Sender Policy Framework) nasıl düzeltilir

SPF, alan adı ayarlarınızda yer alan ve hangi e-posta hizmetlerinin işletmeniz adına posta göndermeye yetkili olduğunu listeleyen bir kayıttır. Bu kayıt olmadan dünyanın herhangi bir yerindeki biri sizden geliyormuş gibi görünen e-posta gönderebilir; üstelik kendi gerçek postalarınız müşterilerin spam klasörüne düşme riskiyle karşı karşıya kalır.

İşletmeniz için sonuç: Herhangi biri işletmenizi taklit ederek müşterilerinize, personelinize ve tedarikçilerinize e-posta gönderebilir; fatura, ödeme bilgisi değişikliği isteği ve benzeri mesajlar bunların başında gelir. Aynı zamanda gerçek teklifleriniz ve faturalarınızın spam'e düşme olasılığı artar; anlaşmalar sessiz sedasız askıya alınır.

Bu size ne mal olabilir

• Bir dolandırıcı, müşterinize 'sizden geliyormuş gibi' görünen ve kendi banka bilgilerini içeren bir fatura gönderir; müşteri ödemeyi yapar. Durumu haftalarca sonra, müşteri neden teslimat yapılmadığını sorunca öğrenirsiniz — ve hem itibarınız hem de olası yasal sorumluluğunuz tehlikededir.
• Teklifleriniz, faturalarınız ve yanıtlarınız müşterilerin spam klasörüne düşer; büyük servis sağlayıcılar bunların gerçekten sizden geldiğini doğrulayamadığından. Anlaşmalar soğur ve neden olduğunu asla öğrenemezsiniz.
• Bir dolandırıcı, işletme sahibinizi veya finans sorumlusunu taklit ederek personele acil ödeme ya da hediye çeki isteyen bir e-posta gönderir. Mesaj gerçekten alan adınızdan geliyormuş gibi göründüğünden biri ödeme yapar.
• Daha büyük bir potansiyel müşterinin BT veya güvenlik ekibi alan adınızı inceler, gönderici koruması olmadığını görür ve sizi risk unsuru olarak işaretler — ya anlaşmayı kaybedersiniz ya da düzeltme yapana kadar haftalar geçer.
• SPF kaydı var diye kendinizi korunmuş sandınız; oysa kayıt 'soft fail' olarak ayarlı, onu zorunlu kılan hiçbir şey yok ya da sessizce bozulmuş — sahte postalar hâlâ geçiyor.

Neden önemlidir. Bir e-postadaki 'gönderen' adresini taklit etmek son derece kolaydır ve saldırgana hiçbir maliyeti yoktur. SPF, alan adınızı taklit etmeyi zorlaştırmanın ve gerçek postalarınızın spam'e düşmesini engellemenin en ucuz ve en hızlı yoludur. Google ve Yahoo, kimliği doğrulanmamış alan adlarından gelen postaları artık aktif biçimde spam'e atıyor ya da reddediyor; bu nedenle SPF artık isteğe bağlı değil, e-postanın hiç iletilmesi için temel bir gerekliliktir.

Kısa özet

Şu anda, SPF’yi doğru şekilde kurulmamışsa dünyanın herhangi bir yerindeki biri işletmenizden geliyormuş gibi görünen e-posta gönderebilir. Müşterilerinize sahte faturalar, personelinize sahte ödeme talepleri ve tedarikçilerinize adeta sizden geliyormuş gibi mesajlar iletebilirler; alan adınızda aksini söyleyen hiçbir şey olmadığından bu iletiler gerçek görünür.

SPF (Sender Policy Framework) bu sorunu çözer. Alan adı ayarlarınızda sizin adınıza posta göndermeye yetkili olan posta hizmetlerini listeleyen tek bir metin satırıdır. Alıcı posta sağlayıcıları — Gmail, Outlook ve diğerleri — bir mesajın gerçek olup olmadığına karar vermeden önce bu listeyi kontrol eder. Liste yoksa ya da zayıfsa ellerinde hiçbir dayanak kalmaz.

Bu sayfa doğru olması gereken iki şeyi kapsar: SPF kaydının var olup olmadığı ve gerçekten işini yapacak kadar katı olup olmadığı.

Bunun size maliyeti ne olabilir?

Bunlar, eksik veya zayıf bir SPF kaydının para ve güven kaybına yol açmasının günlük, gerçek dünya biçimleridir. Gerçek bir işletmeyi asla adlandırmayız — bunlar veriler genelinde gördüğümüz örüntülerdir.

• Fatura yeniden yönlendirmesi. Bir suçlu, müşterilerinizden birine tam olarak sizden geliyormuş gibi görünen, kendi banka hesabını içeren gerçekçi bir fatura ekiyle e-posta gönderir. Müşteri ödemeyi yapar. İlk haberiniz, müşterinin siparişinin nerede olduğunu soran bir mesajla olur. Artık öfkeli bir müşteri, bir suçlunun eline geçmiş bir ödeme ve kimin zararı üstleneceğine dair zor bir konuşma var.
• CEO/finans dolandırıcılığı. Biri muhasebeciye “sizden” bir mesaj gönderir: “Küçük bir iyilik — bu ödemeyi gün bitmeden gönderir misin?” Mesaj gerçekten alan adınızdan geliyormuş gibi göründüğünden kimsenin şüphesi uyanmaz. Para binadan çıkar.
• Sessiz teslim edilebilirlik vergisi. Gmail ve Yahoo sizden gerçekten gönderildiğini doğrulayamadığından teklifleriniz ve faturalarınız müşterilerin spam klasörüne düşmeye başlar. Geri dönüş almaz, hata görmezsiniz — anlaşmalar sadece sessiz kalır. İş kaybediyorsunuzdur ama bunu bile fark edemezsiniz.
• Kaybedilen sözleşme. Daha büyük bir müşterinin tedarik veya güvenlik ekibi, başlarken alan adınız üzerinde temel bir kontrol yapar. Gönderici kimlik doğrulaması olmadığını görür ve sizi risk olarak işaretler. En iyi ihtimalle son dakika baskısıyla düzeltmeye çalışırsınız; en kötü ihtimalle kontrolü geçen rakibe giderler.
• Marka zehirleme dalgası. Alan adınız kamuya yönelik bir kimlik avı kampanyasında kullanılır. Zarar gören kişiler artık adınızı taşıyan her e-postaya güvenmez — gerçek teklifleriniz ve yenilemeleriniz dahi görmezden gelinir ya da şikâyet edilir.

Tüm bu senaryolardaki ortak nokta: saldırgan hiçbir şey harcamaz, işletmeniz maliyeti ve suçu üstlenir.

Teknik olarak nedir?

Bir e-posta ulaştığında, alıcı posta sunucusu tek bir şeyi öğrenmek ister: bu, iddia ettiği kişiden mi geliyor? SPF bu sorunun bir bölümünü yanıtlar.

Alan adınızın DNS ayarlarına — bir “TXT kaydı” olarak — adınıza posta göndermeye yetkili posta hizmetlerini belgeleyen kısa bir metin satırı yayımlarsınız. Örneğin:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Sade bir dille şunu söyler: “Bizden gelen gerçek postalar Google’ın ve SendGrid’in sunucularından gelir — başka bir yerden geldiğini iddia eden her şeyi reddedin.”

Notunuz için önem taşıyan iki bölüm:

1. Kayıt mevcut mu? Bu en kritik noktadır (herhangi bir tek e-posta kontrolünün en yüksek ağırlığını taşır). Kayıt yoksa alıcıların karşılaştıracağı bir liste yoktur, kimlik taklidi tamamen açıktır. Dikkat edilmesi gereken önemli bir başarısızlık durumu daha vardır: alan adınızda iki veya daha fazla SPF kaydı varsa kurallar hepsinin geçersiz olduğunu söyler — böylece görünürde kayıt olmasına rağmen etkin SPF’niz kalmaz.

2. Politika yeterince katı mı? Bir kayıt var olabilir ama yine de etkisiz olabilir. Bitiş — “all” mekanizması — alıcılara verilen talimattır:

   • -all (hard fail) — listede olmayanları reddet. En güçlü ayar. Tam puan.
   • ~all (soft fail) + reject politikalı DMARC — modern önerilen kurulum. Hard fail ile eşdeğer koruma, iletilen postanın geri dönme riski olmadan. Tam puan.
   • ~all + quarantine politikalı DMARC — kabul edilebilir, biraz daha zayıf; tam koruma için DMARC’ı reject’e taşıyın.
   • ~all tek başına (DMARC zorunluluğu yok) — zayıf. “Muhtemelen sahte, yine de ilet” demektir. Sahte postalar hâlâ geçer. Birçok işletmenin korunduğunu sanarak düştüğü tuzak budur.
   • ?all (nötr) — hiçbir koruma sağlamaz.
   • +all — aktif olarak tehlikelidir: dünyaya herkesin sizin adınıza posta gönderebileceğini söyler. Asla kullanmayın.

Bir görünmez başarısızlık daha vardır: SPF değerlendirilirken yalnızca 10 DNS aramasına izin verilir. Çok fazla include: girişi eklerseniz kayıt bu sınırı aşar; o noktada alıcılar tüm kaydı bozuk sayar — ve yine korumasz kalırsınız. Bu, çok sayıda pazarlama ve SaaS aracı kullanan işletmeler için yaygın, sessiz bir sorundur.

“İyi” neye benzer: tam olarak bir SPF kaydı, adınıza meşru şekilde posta gönderen her hizmeti listeler, -all ile biter (ya da p=reject DMARC’la birlikte ~all) ve 10 arama sınırının oldukça altında kalır.

Nasıl düzeltilir (ücretsiz, ~10 dakika)

Bu bölümü alan adınızı veya web sitenizi yöneten kişiye iletin — ve düzeltmenin ücretsiz olduğunu belirtin. Bu, satın alınan bir ürün değil, bir DNS ayarında yapılan değişikliktir. Yalnızca zamanla doğru kalmasını izlemek için ücret alıyoruz, değişikliği yapmak için değil.

1. Adım — Adınıza posta gönderen her hizmeti listeleyin. İnsanların yanlış yaptığı yer burasıdır. Hepsini yazın: posta kutusu sağlayıcınız (Google Workspace, Microsoft 365 vb.) ile her türlü haber bülteni aracı, CRM, yardım masası, e-ticaret platformu, faturalama/muhasebe uygulaması ve rezervasyon sistemi. Adınızla posta gönderen bir hizmeti unutursanız, politikayı sıkılaştırdığınızda SPF’niz o hizmetin postalarını engeller.

2. Adım — Kök alan adınıza bir TXT kaydı yayımlayın. Tüm göndericileriniz için “include” satırlarını tek bir kayıtta birleştirin. Yaygın platformlar için:

• Google Workspace: include:_spf.google.com
• Microsoft 365: include:spf.protection.outlook.com
• SendGrid: include:sendgrid.net
• Mailchimp: include:servers.mcsv.net
• Zoho: include:zoho.eu (veya bölgeye uygun alan adı)

Birleşik bir kayıt şöyle görünür:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all

Sağlayıcıya göre nereye ekleneceği:

• Cloudflare: DNS → Kayıtlar → Kayıt ekle → Tür TXT, Ad @, İçerik = yukarıdaki değer.
• Microsoft 365 / Google admin: Kurulum sihirbazında kullanılacak tam include dizesini yayımlarlar; DNS barındırıcınızın TXT kaydına kopyalayın.
• GoDaddy / çoğu barındırıcı: DNS yönetimi → Ekle → TXT, Ana Bilgisayar/Ad @, Değer = kayıt.

3. Adım — Güvenli başlayın, ardından zorunlu kılın. Gönderici listenizin eksiksiz olduğunu doğrularken, meşru hiçbir şeyin yanlışlıkla engellenmemesi için ~all (soft fail) ile yayımlayın. Tüm gerçek postalarınızın hâlâ aktığını doğruladıktan sonra -all (hard fail) sıkılaştırın — ya da daha iyisi, ~all ile kalın ve p=reject DMARC politikası ekleyin; bu modern önerilen ikilidir.

4. Adım — Tam olarak BİR kayıt olduğundan emin olun. Eski bir SPF kaydı zaten varsa ikinci bir kayıt eklemek yerine onu düzenleyin. İki v=spf1 kaydı birbirini iptal eder ve sizi korumasız bırakır.

5. Adım — Arama sayısını izleyin. Çok fazla göndericiniz varsa 10 arama sınırını aşabilirsiniz. Bu durumda birleştirin — bazı sağlayıcılar “SPF düzleştirme” sunar veya artık kullanmadığınız göndericileri kaldırın.

6. Adım — Alan adınızı yeniden kontrol edin ve kaydın mevcut ve politikanın katı olduğunu doğrulayın.

Yaygın hatalar

• İki SPF kaydı. En yaygın sessiz başarısızlık. Mevcut kaydı düzenlemek yerine yeni bir kayıt eklemek ikisini de geçersiz kılar. Tam olarak bir tane olmalıdır.
• ~all ile durup bittiğini sanmak. Arkasında DMARC olmadan soft fail, zayıf bir orta yoldur — yapılandırılmış görünür ama sizi neredeyse korumaz. Ya -all’a geçin ya da p=reject DMARC ile ~all ikilisini kullanın.
• Bir göndericinin unutulması. Faturalama uygulamanızı, CRM’inizi veya haber bülteni aracınızı listelemeden -all sıkılaştırması, kendi meşru postalarınızı engellemeye başlar. Önce her şeyi listeleyin.
• 10 arama sınırını aşmak. Her include: daha fazla aramayla zincirleme bağlanabilir. Çok fazlası kaydı bozuk sayılan hale getirir. Sade tutun.
• +all kullanmak. Bu, tüm internete sizin adınıza posta göndermesi için açıkça yetki verir. Kayıt olmamasından daha kötüdür. Asla yayımlamayın.

Bunun içinde yeri

SPF temeldir ancak üç katmandan biridir. DKIM, bir mesajın kurcalanmadığını kanıtlayan kriptografik bir imza ekler; DMARC ise SPF ve DKIM’i bir araya getiren ve alıcılara başarısız olan postalarla ne yapacaklarını söyleyen talimattır — müşterilerin gördüğü görünür ‘gönderen’ adının taklidini de engellemek dahil. Önce SPF’yi doğru yapın (en hızlı kazanım ve en yüksek ağırlığı taşır), ardından kapıyı tamamen kapatmak için DKIM ve DMARC ekleyin. Üç düzeltmenin tümü ücretsizdir.

Sunucunuzda kurun

Popüler sağlayıcılar için adım adım:

• GoDaddy üzerinde SPF kurun
• Namecheap üzerinde SPF kurun
• Cloudflare üzerinde SPF kurun
• Google Workspace üzerinde SPF kurun
• Microsoft 365 üzerinde SPF kurun
• Squarespace üzerinde SPF kurun
• Wix üzerinde SPF kurun
• AWS Route 53 üzerinde SPF kurun
• Hostinger üzerinde SPF kurun
• Porkbun üzerinde SPF kurun
• IONOS üzerinde SPF kurun
• Bluehost üzerinde SPF kurun

SSS