Sorun Giderme·
11 Haziran 2026
DNS'e SPF kaydı eklediniz, MX'iniz doğru çalışıyor; ama e-postalarınız yine de alıcının çöp kutusuna iniyor. Bu durum, pek çok sistem yöneticisinin ve e-posta pazarlamacısının karşılaştığı en yaygın teslim edilebilirlik sorunlarından biridir. SPF, e-posta kimlik doğrulamasının yalnızca bir katmanıdır; tek başına yeterli olmadığı durumlar oldukça fazladır.
SPF (Sender Policy Framework), RFC 7208 ile standardize edilmiş bir DNS tabanlı kimlik doğrulama mekanizmasıdır. Bir alıcı sunucu, gelen bağlantıda MAIL FROM alanındaki domain'in DNS kaydını sorgular ve bağlanan IP adresinin o domain adına posta göndermesine izin verilip verilmediğini kontrol eder. Doğrulama yalnızca RFC 5321'de tanımlanan "zarf göndereni" (envelope sender) üzerinden yapılır; kullanıcının e-posta istemcisinde gördüğü From: başlığını (RFC 5322) doğrudan kapsamaz.
Bu ayrım kritik önem taşır. Bir e-postayı bir üçüncü taraf gönderim platformu (ESP) üzerinden gönderdiğinizde, zarf göndereni çoğunlukla platformun kendi domain'ini içerir; sizin domain'inizin SPF kaydı bu durumda devreye girmez ya da yanlış yorumlanır. Alıcı sunucu SPF kontrolünü geçerli kabul etse bile, son kullanıcının gördüğü From: başlığı farklı bir domain'e işaret edebilir; bu durum, DMARC uyumu açısından "hizalama hatası" (alignment failure) olarak nitelendirilir.
SPF kaydı mevcut olduğu hâlde e-postalarınız spam klasörüne düşüyorsa aşağıdaki nedenlerin bir ya da birkaçı söz konusu olabilir:
DKIM (DomainKeys Identified Mail), RFC 6376 ile tanımlanmış bir kriptografik imzalama mekanizmasıdır. E-posta içeriğini ve belirli başlıkları imzalar; böylece iletim sırasında içerik değiştirildiğinde veya iletildiğinde (forward) doğrulama başarısız olmaz mı diye kontrol edilebilir. DKIM olmaksızın bir e-postanın ileri iletilmesi — örneğin bir mailing list üzerinden geçmesi — SPF doğrulamasını otomatik olarak kırar, çünkü iletim IP'si artık orijinal gönderenin SPF kaydında tanımlı değildir. Google ve Microsoft, 2024 yılı itibarıyla günlük 5.000'den fazla e-posta gönderen domain'ler için DKIM'i zorunlu hâle getirmiştir.
DMARC (Domain-based Message Authentication, Reporting and Conformance), RFC 7489 ile standart hâline gelmiştir. SPF ve DKIM sonuçlarını bir araya getirerek alan adı sahibine, başarısız doğrulama durumunda e-postanın ne yapılacağını belirleme imkânı sunar (none, quarantine, reject). DMARC politikası olmayan domain'lerde alıcı sunucular, SPF veya DKIM hatalarını kendi iç algoritmalarıyla değerlendirir; bu da tutarsız ve genellikle olumsuz sonuçlara yol açar.
RFC 7208, Bölüm 4.6.4'e göre bir SPF kaydının değerlendirilmesi sırasında yapılabilecek maksimum DNS sorgusu sayısı 10 ile sınırlıdır. include:, a, mx ve redirect= mekanizmaları bu limiti tüketir. Sorgu sayısı 10'u aştığında alıcı sunucu PermError döndürür; bu durum pratikte SPF başarısızlığı ile eşdeğer kabul edilir ve e-posta spam olarak işaretlenebilir. Birden fazla ESP kullanan büyük kuruluşlarda bu sorun son derece yaygındır.
Kimlik doğrulama katmanları tamamen doğru yapılandırılmış olsa bile, gönderen IP'nin veya domain'in itibarı (reputation) zayıfsa e-postalar spam'e düşebilir. Google Postmaster Tools ve Microsoft SNDS (Smart Network Data Services), göndericinin IP ve domain itibarını izlemek için kullanabileceğiniz ücretsiz araçlardır. Yüksek şikayet oranları, düşük açılma oranları ve spam tuzaklarına (spam trap) düşen e-postalar zamanla itibarı aşındırır.
Gmail, alıcıların şikayet oranını gerçek zamanlı olarak izler. Google Postmaster Tools verilerine göre şikayet oranının %0,10'u aşması teslim edilebilirliği olumsuz etkilerken, %0,30'un üzeri ciddi kısıtlamalara yol açar. Bu eşikler sektör standardı olarak RFC bazlı belgelerden değil, doğrudan sağlayıcı politikalarından kaynaklanır.
Yeni bir IP adresinden veya domain'den yüksek hacimde e-posta gönderilmesi, alıcı sunucularda güven sorununa neden olur. Özellikle büyük ESP'ler üzerinden toplu gönderim yapıyorsanız, IP ısınma (IP warm-up) süreci atlanamazın. Microsoft'un posta sunucuları bu konuda özellikle katı bir politika izlemektedir.
| Özellik | SPF | DKIM | DMARC |
|---|---|---|---|
| Tanımlayan Standart | RFC 7208 | RFC 6376 | RFC 7489 |
| Doğrulanan Alan | Zarf göndereni (envelope sender) IP | E-posta içeriği ve başlıklar | SPF + DKIM hizalaması |
| İletim (Forward) Direnci | Zayıf — IP değişince başarısız olur | Güçlü — imza içeriğe bağlıdır | DKIM varsa güçlü |
| Politika Tanımlama | Hayır | Hayır | Evet (none / quarantine / reject) |
| Raporlama | Hayır | Hayır | Evet (RUA / RUF raporları) |
| DNS Kaydı Türü | TXT | TXT (selector._domainkey) | TXT (_dmarc) |
| Zorunlu mu? (Gmail 2024) | Evet | Evet (>5K/gün) | Evet (>5K/gün) |
E-postanızın neden spam'e düştüğünü anlamak için aşağıdaki araçlardan yararlanabilirsiniz:
E-posta başlıklarını doğrudan incelemek de son derece aydınlatıcıdır. Gmail'de "Orijinali göster" seçeneğiyle erişeceğiniz başlıklarda Authentication-Results satırları, SPF, DKIM ve DMARC doğrulama sonuçlarını açıkça içerir. spf=pass, dkim=fail, dmarc=fail gibi değerler sorunun tam olarak hangi katmanda olduğunu ortaya koyar.
Mevcut SPF kaydınızda çok fazla include: mekanizması kullanıyorsanız DNS sorgu limitine takılma riskiniz yüksektir. Çözüm için şu adımları izleyin:
include: mekanizmalarının gerçekten kullanılıp kullanılmadığını doğrulayın; kullanılmayan ESP'lerin kayıtlarını kaldırın.include: zincirleri yerine doğrudan IP bloklarını (ip4:, ip6:) kullanın. Bazı DNS sağlayıcıları veya üçüncü taraf araçlar bunu otomatikleştirir.~all (softfail) yerine geçiş aşamasından sonra -all (hardfail) kullanmayı değerlendirin; ancak DMARC politikanız devredeyse bu ayrım pratikte daha az belirleyicidir.DMARC uyumu için SPF veya DKIM'in geçmesi yetmez; aynı zamanda doğrulama yapılan domain'in, e-postadaki From: başlığında yer alan domain ile "hizalı" (aligned) olması gerekir. SPF hizalaması varsayılan olarak "relaxed" moddadır; bu, organizasyonel domain eşleşmesini kabul eder. Ancak bir ESP'nin kendi alt domain'i üzerinden gönderim yapması hizalamayı bozabilir. Bu durumda DKIM hizalaması, SPF'nin aksine iletim sonrasında da korunduğundan, tercih edilmesi gereken doğrulama yöntemidir.
SPF geçmesi tek başına yeterli değildir. DKIM imzası eksik ya da hatalıysa veya DMARC hizalaması sağlanamıyorsa, alıcı sunucu e-postayı şüpheli olarak değerlendirebilir. Ayrıca gönderen IP veya domain itibarının düşük olması, içeriğin spam filtrelerini tetiklemesi ya da şikayet oranının yüksek seyretmesi de bu duruma yol açar.
RFC 7208 uyarınca maksimum 10 DNS sorgusu hakkınız var. Kullanılmayan ESP kayıtlarını (include:) kaldırın ve mümkün olan her yerde include: yerine doğrudan ip4: veya ip6: bloklarını kullanın. SPF Flattening araçları bu süreci otomatikleştirebilir; ancak IP blokları değiştiğinde kaydı güncellemeniz gerektiğini unutmayın.
Doğrudan p=reject uygulamak, meşru gönderim kaynaklarınızdan bazılarını engelleme riskini beraberinde getirir. Önerilen yaklaşım şudur: önce p=none ile başlayarak DMARC raporlarını toplayın, tüm meşru gönderim kaynaklarını belirleyin, ardından p=quarantine'a geçin ve son olarak p=reject'e yükseltin. Bu süreç genellikle 4-8 hafta alır.
Evet, eğer o ESP sizin domain'iniz adına e-posta gönderiyorsa SPF kaydınıza ilgili ESP'nin include: mekanizmasını eklemeniz gerekir. Ancak bazı ESP'ler özel subdomain (custom return-path) yapılandırması sunarak kendi SPF altyapısını kullanır; bu durumda sizin SPF kaydınızda değişiklik gerekmeyebilir.
DKIM seçicisi, DNS'teki imzalama anahtarını konumlandırmak için kullanılan bir alt etikettir; selector._domainkey.domain.com formatında tanımlanır. Farklı gönderim platformları (CRM, destek sistemi, e-posta servisi) için ayrı seçiciler kullanmak, bir anahtarın riske girmesi durumunda diğerlerini etkilememesi açısından iyi bir uygulamadır. Ayrıca DKIM anahtarlarının periyodik olarak döndürülmesi (key rotation) önerilir.
Liste hijyenine önem verin: aktif olmayan aboneleri düzenli aralıklarla listenizden çıkarın, çift onay (double opt-in) yöntemini kullanın ve abonelikten çıkma bağlantısını e-postalarınızda belirgin hâlde tutun. Gmail ve Yahoo, 2024 itibarıyla tek tıkla abonelik iptali (List-Unsubscribe: One-Click, RFC 8058) özelliğini zorunlu tutmaktadır.
IP ısınma süresi, hedef hacminize göre değişir. Genel kural olarak ilk hafta günlük birkaç yüz e-postayla başlanır; her hafta hacim iki katına çıkarılır. Büyük hacimler için bu süreç 4-8 hafta alabilir. Isınma sürecinde açılma ve şikayet oranlarını yakından takip etmek kritik önem taşır.
~all (softfail), SPF başarısızlığında e-postanın yine de teslim edilmesine olanak tanır; -all (hardfail) ise kesin red anlamına gelir. DMARC politikanız etkinse bu ayrımın pratikte önemi azalır; çünkü DMARC kendi işlem kurallarını belirler. Geçiş döneminde ~all tercih edebilir, altyapınıza güven tazeldikten sonra -all'a geçebilirsiniz.
Kimlik doğrulama katmanları yalnızca gönderenin kim olduğunu kanıtlar; içeriğin kalitesini veya göndericinin itibarını değerlendirmez. İçerik spam filtrelerini tetikleyebilir (aşırı büyük görseller, spam sözcükleri, kırık bağlantılar), domain veya IP itibarı düşük olabilir ya da alıcılar önceki e-postalarınızı şikayet olarak işaretlemiş olabilir. Tüm doğrulamalar geçse bile itibar ve içerik faktörleri nihai teslim edilebilirliği belirler.
Connect365, DKIM imzalamasını ve SPF yapılandırmasını otomatik olarak yönetir; DMARC raporlarını yorumlanabilir biçimde sunar. Gönderim altyapısı ısınmış ve itibarı yüksek IP'ler üzerinden çalışır. Kampanya bazında açılma oranı, şikayet oranı ve teslim edilebilirlik metrikleri gerçek zamanlı olarak izlenir; böylece spam'e düşme eğilimi tespit edildiğinde hızla müdahale edilebilir.
Reklamsız, KVKK uyumlu; kurulum ve geçiş ücretsiz, mailleri biz taşırız.
Kurulum + migrasyon ücretsiz. KVKK uyumlu, Türkiye'de barındırma. 7/24 Türkçe destek.
Kampanya 30 Haziran'a kadar geçerlidir.