E-Posta Spam Klasörüne Düşüyorsa SPF, DKIM ve DMARC'tan Hangisi Eksik?

---

Gönderdiğiniz bir e-posta karşı tarafın gelen kutusuna değil, doğrudan spam klasörüne düşüyorsa ve bu tek seferlik bir kaza değilse, sorun genelde içerikte değil, alan adınızın e-posta kimlik doğrulama kayıtlarında saklıdır. SPF, DKIM ve DMARC üçlüsünden hangisi eksik ya da yanlış yapılandırılmışsa alıcı sunucu iletinizi güvenilir bulmuyor demektir.

Bu yazı üç kaydın ayrı ayrı ne işe yaradığını ve bir spam sorununda hangisine önce bakılması gerektiğini, resmî standart belgelerine dayanarak sırayla ele alıyor.

SPF: Zarfın üzerindeki adresi kim doğruluyor?​

RFC 7208 SPF'yi, bir alan adı yöneticisinin kendi adına e-posta göndermeye yetkili sunucuları açıkça belirleyebildiği, alıcı tarafın da bu yetkiyi denetleyebildiği bir protokol olarak tanımlıyor. Denetlenen adres görünen "Kimden" başlığı değil, SMTP zarfındaki MAIL FROM adresidir; RFC bunu, hangi sunucunun "MAIL FROM" ya da HELO/EHLO alanında hangi adı kullanabileceğine dair var olan protokollerin hiçbir kısıtlama getirmediğini belirterek gerekçelendiriyor.

Pratikte bu, alan adınızın DNS'ine bir SPF TXT kaydı eklemek ve o kayıtta e-posta göndermeye yetkili sunucuları (kendi sunucunuz, kullandığınız pazarlama aracı, form eklentisi gibi) listelemek anlamına gelir. Kayıt eksikse ya da yetkili sunucu listesinde olmayan bir yerden gönderim yapılıyorsa SPF denetimi başarısız olur.

RFC'nin belirttiği bir başka nokta da şu: SPF sonucu tek başına "kabul et" ya da "reddet" emri vermiyor, alıcı sunucuya bir girdi sağlıyor. Belgeye göre bu doğrulama sayesinde yerel politika kararları, gönderen sunucunun IP adresine değil doğrudan gönderenin alan adına göre verilebiliyor; alıcı taraf bu sonuca göre iletiyi güvenle kabul etmekten tamamen reddetmeye kadar uzanan bir yelpazede karar veriyor.

DKIM: İmza gerçekten size mi ait?​

RFC 6376, DKIM'i imzalayan tarafın bir özel anahtarla iletinin belirli başlıklarını ve gövdesini imzalamasına, alıcının da bu imzayı DNS'teki `_domainkey` alt alanından aldığı genel anahtarla doğrulamasına dayanan bir mekanizma olarak tanımlıyor. Doğrulama sertifika otoritesi gerektirmez; anahtar doğrudan gönderen alan adının DNS kaydında durur.

İmza geçerliyse alıcı sunucu iletinin yolda değiştirilmediğinden ve gerçekten o alan adına ait bir sistemden çıktığından emin olur. DKIM kaydı eksikse ya da anahtar uyuşmuyorsa bu doğrulama düşer.

İmza, iletinin ham hâli değil kanonikleştirilmiş (canonicalization) bir biçimi üzerinden hesaplanıyor; bu sayede posta sunucularının yol boyunca yaptığı küçük biçimsel değişiklikler (satır sonu, boşluk gibi) imzayı bozmuyor. Buna karşılık başlık ya da gövdede gerçek bir içerik değişikliği olduğunda imza doğrulaması düşüyor; DKIM'in asıl güvencesi de tam olarak bu.

DMARC: SPF ve DKIM sonucunu kim yorumluyor?​

RFC 7489'a göre DMARC, SPF ve DKIM'in sağladığı alan düzeyindeki doğrulamayı temel alıp bunun üzerine bir politika ekliyor. Alan adı sahibi yayımladığı DMARC kaydındaki `p=` etiketiyle alıcıya ne yapması gerektiğini söylüyor: `none` değeri özel bir eylem istenmediğini, `quarantine` başarısız iletilerin şüpheli sayılmasını, `reject` ise doğrudan reddedilmesini talep ediyor.

Yani DMARC kaydı yoksa ya da `p=none` bırakılmışsa, SPF veya DKIM başarısız olan bir ileti için alıcı sunucular kendi takdirlerine göre davranır; bu da aynı iletinin bir sağlayıcıda gelen kutusuna, diğerinde spam klasörüne düşmesini açıklayabilir. DMARC.org'un genel bakış sayfası da bu mekanizmanın asıl tasarım amaçlarından birinin, alan adı taklit edilerek yapılan kimlik avı iletilerinin başarıyla teslim edilme oranını düşürmek olduğunu belirtiyor.

Üçü aynı anda mı kontrol edilmeli?​

Spam klasörüne düşme sorununda üç kaydı da tek tek DNS sorgusuyla kontrol etmek gerekir; hangisi eksikse ya da yanlış yazılmışsa asıl mesele orada gizlidir. Kayıtları eklediğiniz DNS panelinin genel yönetimiyle ilgili adımlar için alan adı ve hosting ayrı firmalardaysa DNS ayarlarının nasıl yapıldığını anlattığımız yazı başlangıç noktası olabilir; TXT kaydı eklemenin mantığı SPF/DKIM/DMARC için de aynıdır.

Bu üç kaydın kurumsal bir alan adında neden özellikle önemli olduğunu ve sık yapılan yapılandırma hatalarını kurumsal e-posta neden spam'e düşer yazımızda daha ayrıntılı ele almıştık; bu yazı ise üçünün birbirinden farkına ve hangisine önce bakılacağına odaklanıyor.

Kimlik doğrulaması hiç kurulu değilse alan adınız spoofing için de kullanılabilir hale gelir; e-postanız zaten bir sızıntıya karışmışsa ilk saatlerde izlenecek adımları e-postam veri sızıntısında çıktı yazımızda ayrıca ele alıyoruz.

Sık Sorulan Sorular​

SPF kaydı nedir, nasıl eklenir?
SPF, alan adınız adına e-posta göndermeye yetkili sunucuları listeleyen bir DNS TXT kaydıdır; DNS yönetim panelinizden TXT tipinde yeni bir kayıt olarak eklenir.

DKIM kaydı nedir?
İletinin belirli başlıklarını ve gövdesini özel anahtarla imzalayan, alıcının bu imzayı DNS'teki genel anahtarla doğruladığı bir e-posta kimlik doğrulama yöntemidir.

DMARC kaydı nedir?
SPF ve DKIM sonuçlarını yorumlayıp alıcı sunuculara başarısız iletilerle ne yapılacağını (yoksay, şüpheli say, reddet) söyleyen politika kaydıdır.

Mail SPF kaydı nasıl yapılır?
Alan adınızın DNS ayarlarına, kullandığınız tüm gönderim kaynaklarını (kendi sunucu, e-posta pazarlama aracı, form servisi) kapsayan bir TXT kaydı eklenerek yapılır; eksik kaynak eklenmezse o kaynaktan gönderilen iletiler SPF'yi geçemez.

Özetle​

SPF gönderen sunucuyu, DKIM iletinin bütünlüğünü, DMARC ise ikisinin sonucuna göre alıcının ne yapacağını belirliyor; spam klasörüne düşme sorununda üçü de ayrı ayrı sorgulanmadan hangisinin eksik olduğu anlaşılamaz. Kayıtlardan biri hiç yoksa ya da `p=none` gibi gevşek bırakılmışsa, aynı ileti bazı sağlayıcılarda sorunsuz teslim olurken bazılarında spam'e düşebiliyor.

Alan adınızın SPF, DKIM ve DMARC kayıtlarını en son ne zaman tek tek sorguladınız?

Güncelleme: 25 Ağustos 2026.

---