Kurumsal E-Posta Neden Spam'e Düşer? SPF, DKIM, DMARC

Kurumsal adresten gönderilen normal bir teklif ya da destek yanıtı spam klasörüne düştüğünde ilk şüphe genellikle konu satırı oluyor. Oysa teşhise metni değiştirerek değil, iletinin alıcı sunucuya kendini nasıl tanıttığına bakarak başlamak daha doğru.

SPF, DKIM ve DMARC üç ayrı “DNS kutusu” değildir. Birlikte; mesajı hangi sunucunun gönderdiğini, iletinin gerçekten alan adınız adına imzalanıp imzalanmadığını ve görünen gönderen adresiyle bu kimliklerin uyuşup uyuşmadığını anlatırlar. Üçü de doğru olsa bile gelen kutusu garanti değildir; itibar ve gönderim davranışı ayrı bir katmandır.

---

Önce bir test iletisinin izini okuyun​

Kendi Gmail adresinize yeni bir test gönderin. Gmail'de iletiyi açıp “Orijinali göster” bölümündeki Authentication-Results satırını bulun. Kişisel adresleri ve mesaj kimliklerini kapatarak şu üç sonucu not edin:


Google'ın resmî doğrulama kontrolü, SPF ve DKIM sonucunun ileti başlıklarından nasıl okunacağını gösteriyor. Yalnızca DNS panelinde kaydın bulunması yeterli kanıt değildir; önemli olan alıcı tarafta görülen sonuçtur.

Hata yalnız Gmail'de mi, yalnız tek bir alıcıda mı, yoksa bütün alıcılarda mı çıkıyor? Bir de geri dönüş iletisi varsa SMTP hata kodunu saklayın. Bu iki bilgi, DNS hatasıyla alıcıya özgü filtreyi birbirinden ayırır.

Üç kaydı aynı zincir gibi okuyun​

SPF: Bu sunucu alan adım adına gönderebilir mi?​

SPF, alan adınız için e-posta göndermesine izin verilen sistemleri DNS'teki TXT politikasıyla bildirir. Google Workspace, web sitesindeki form, fatura uygulaması, CRM ve bülten servisi farklı yerlerden gönderim yapıyorsa hepsi envantere girmelidir.

spf=fail görüyorsanız önce mesajı gerçekten hangi hizmetin gönderdiğini bulun. Sağlayıcının verdiği kaydı körlemesine yeni bir SPF satırı olarak eklemek yerine mevcut politikayı ve bütün göndericileri birlikte değerlendirin. Yönlendirilmiş iletilerde SPF bozulabildiği için tek başına bu sonuçla karar vermeyin; DKIM sonucuna da bakın.

DKIM: Mesaj doğru alan adıyla imzalanmış mı?​

DKIM'de gönderen hizmet iletiyi özel anahtarla imzalar, alıcı ise DNS'teki açık anahtarla imzayı denetler. DNS kaydını eklemek tek başına yetmez; gönderici panelinde imzalamanın da etkin olması gerekir.

İleti başlığındaki DKIM-Signature satırında yer alan d= imzalayan alan adını, s= ise selector adını gösterir. Sonuç none ise mesaj hiç imzalanmıyor olabilir; fail ise yanlış selector, hatalı anahtar ya da gönderimden sonra değişen ileti incelenmelidir. Özel DKIM anahtarını hiçbir zaman foruma veya DNS'e koymayın; DNS'e yalnızca sağlayıcının verdiği açık anahtar yazılır.

DMARC: Görünen gönderen ile doğrulanan kimlik uyuşuyor mu?​

DMARC, alıcının gördüğü From: alan adıyla SPF veya DKIM üzerinden doğrulanan alan adının hizalı olmasını ister. Bu nedenle SPF ya da DKIM “pass” görünürken DMARC yine “fail” olabilir. Örneğin bülten hizmeti kendi alan adıyla doğrulanıyor fakat görünen gönderen sizin alan adınızsa hizalama kurulmamış olabilir.

DMARC'ın Mayıs 2026 tarihli güncel Standards Track metni RFC 9989'dur ve eski RFC 7489 ile 9091'in yerini alır. Politika yalnızca p=none, p=quarantine veya p=reject seçmekten ibaret değildir; raporlar, hangi hizmetlerin alan adınız adına gönderim yaptığını görmenin de yoludur. Yeni RFC, alıcılar arasında tutarlı uygulanmadığı için eski pct etiketini de kaldırdı. Bu yüzden eski bir kayıttaki yüzde örneğini doğrudan kopyalamayın.

DNS kayıtlarını tahmin ederek değil, sorgulayarak kontrol edin​

Alan adını ve DKIM selector adını kendinize göre değiştirerek şu sorgular yapılabilir:


Çıktıyı sağlayıcınızın güncel kurulum belgesiyle karşılaştırın. Nameserver başka bir firmada yönetiliyorsa kaydı domaini satın aldığınız panelde değil, yetkili DNS bölgesinde değiştirmeniz gerekir. DNS, SSL ve e-posta ayarlarının aynı zincirde nasıl ele alındığını hosting ve domain rehberinde daha geniş biçimde bulabilirsiniz.

Sonuca göre nereye bakmalı?​

• SPF fail, DKIM pass, DMARC pass: DKIM hizalaması mesajı doğruluyor olabilir. SPF tarafında eksik yetki mi, yoksa yönlendirme etkisi mi bulunduğunu ayrıca inceleyin.
• SPF pass, DKIM fail veya none: Gönderici hizmette DKIM imzasını, selector'ı ve DNS anahtarını kontrol edin.
• SPF veya DKIM pass, DMARC fail: “Pass” olan kimliğin görünen From alan adıyla hizalı olup olmadığına bakın.
• Üçü de fail ya da none: Önce gerçek gönderim kaynağını çıkarın; rastgele TXT kayıtları ekleyerek tabloyu karmaşıklaştırmayın.
• Üçü de pass: IP/alan adı itibarı, kullanıcı şikâyeti, ani hacim artışı, ortak IP, içerik ve abonelik izni tarafına geçin.

Kendi posta sunucunuzu işletiyorsanız gönderen IP için geçerli ileri ve ters DNS (PTR) eşleşmesi ile TLS de kontrol edilmelidir. Bir servis sağlayıcı kullanıyorsanız bu katmanın kim tarafından yönetildiğini sorun.

Kimlik doğrulama geçse de neden spam olabilir?​

Google'ın güncel e-posta gönderen yönergeleri, kimlik doğrulamanın yanında düşük spam oranı, geçerli DNS, TLS ve standartlara uygun ileti biçimi de istiyor. Kişisel Gmail hesaplarına günde 5.000'den fazla ileti gönderenler için SPF, DKIM ve DMARC birlikte; pazarlama ve abonelik iletilerinde kolay abonelikten çıkma gibi ek koşullar geçerli.

Gönderim topluysa eski veya izinsiz adres listesi, yüksek şikâyet oranı, aniden büyüyen hacim ve ortak IP'nin kötü itibarı teknik kayıtlar doğru olsa bile teslimatı bozabilir. Bu noktada Google Postmaster Tools içindeki spam oranı, alan adı/IP itibarı, kimlik doğrulama ve teslimat hataları panolarına bakın. Kampanya tarafını düzenlemek için forumdaki e-posta pazarlama stratejileri konusu da tamamlayıcıdır.

Sorun yalnızca tek bir alıcıdaysa alıcının kişisel filtresi, daha önce “spam” işaretlemesi veya kurum içi güvenlik kuralı etkili olabilir. Herkeste aynı sorun görülüyorsa gönderen alan adı, IP ve yapılandırma tarafı daha güçlü adaydır.

DMARC politikasını bir gecede sertleştirmeyin​

SPF ve DKIM envanteri tamamlanmadan doğrudan p=reject yayımlamak; web formu, fatura sistemi veya unutulmuş bir destek uygulamasının meşru iletilerini reddettirebilir. Google'ın önerilen DMARC geçiş planındaki güvenli ortak başlangıç, önce SPF ile DKIM'i kurmak ve p=none ile raporları en az bir hafta izlemektir.

Google'ın aynı sayfası hâlâ pct ile yüzdeli geçiş örneği veriyor; güncel RFC 9989 ise tutarsız uygulama nedeniyle bu etiketi standarttan çıkardı. Bu nedenle yüzde değerine güvenerek “yalnız küçük bir bölüm etkilenir” varsayımı yapmayın. Raporlarda bütün meşru gönderim kaynakları hizalı görünmeden karantina veya ret politikasına geçmeyin; kullandığınız posta sağlayıcısının güncel desteğini ayrıca doğrulayın.

Konuya yardım isterken alan adınızı paylaşmak istemiyorsanız DNS değerlerini ve Authentication-Results satırlarını kişisel adresleri kapatarak ekleyebilirsiniz. Sizde hangi sonuç fail ya da none görünüyor: SPF, DKIM, yoksa DMARC mı?

---