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

Müşterinize teklif gönderdiniz, cevap gelmedi. Üç gün sonra aradığınızda "Hiç mail gelmedi ki" diyor; birlikte bakınca teklif spam klasöründe çıkıyor. Ya da daha kötüsü: Mail hiç ulaşmamış, sunucu sessizce reddetmiş. Kurumsal e-postaların spam'e düşmesinin en yaygın sebebi içerik değil, alan adınızın "bu maili gerçekten ben gönderdim" diyen kimlik kayıtlarının eksik ya da hatalı olmasıdır. Bu kayıtların adı SPF, DKIM ve DMARC.

Bu yazıda üç kaydın ne işe yaradığını teknik bilgi gerektirmeyen bir dille anlatıyor, kendi altyapımızda yaşadığımız gerçek bir sorunu paylaşıyor ve alan adınızı kontrol etmeniz için adım adım bir liste veriyoruz.

E-posta Sağlayıcıları Neye Bakar?

Gmail, Outlook ve diğer büyük e-posta sağlayıcıları her gün devasa miktarda sahte mail ile mücadele ediyor. Bir dolandırıcının "muhasebe@sirketiniz.com" adına mail göndermesi teknik olarak çok kolaydır; çünkü e-posta protokolü ilk tasarlandığında gönderen adresini doğrulayan bir mekanizma yoktu. Tıpkı bir zarfın arkasına istediğiniz adresi yazabilmeniz gibi.

Bu yüzden sağlayıcılar gelen her maile şu soruları sorar:

• Bu mail, alan adı sahibinin izin verdiği bir sunucudan mı geldi? (SPF)
• Mail yolda değiştirilmeden, alan adı sahibinin imzasıyla mı geldi? (DKIM)
• Bu kontroller başarısız olursa alan adı sahibi ne yapılmasını istiyor? (DMARC)

Cevaplar olumsuzsa ya da hiç cevap yoksa, mail spam klasörüne gider veya tamamen reddedilir. Son yıllarda büyük sağlayıcılar bu konuda belirgin şekilde sıkılaştı; özellikle toplu gönderim yapan alan adlarından bu kayıtların eksiksiz olmasını açıkça talep ediyorlar. Yani bir zamanlar "olsa iyi olur" olan bu kayıtlar artık fiilen zorunlu.

SPF: Kimler Benim Adıma Mail Gönderebilir?

SPF (Sender Policy Framework), alan adınızın DNS ayarlarına eklenen ve "benim adıma şu sunucular mail gönderebilir" diyen bir listedir. Alıcı sunucu, gelen mailin hangi sunucudan çıktığına bakar ve bu listeyle karşılaştırır.

Örnek bir SPF kaydı şöyle görünür (DNS'te TXT kaydı olarak):

v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all

Bu kayıt şunu söyler: "Google'ın mail sunucuları ve 203.0.113.10 adresli sunucu benim adıma gönderebilir; diğerlerinden gelenlere şüpheyle yaklaş."

SPF'te en sık yapılan hatalar:

1. Birden fazla SPF kaydı oluşturmak. Bir alan adında yalnızca bir SPF kaydı olmalıdır. Yeni bir servis eklerken ikinci bir kayıt açmak, ikisini birden geçersiz kılar. Doğrusu, mevcut kayda yeni servisi eklemektir.
2. Gönderen servisleri unutmak. Kurumsal mail servisiniz listede olabilir; peki web sitenizin iletişim formu, e-fatura sistemi, CRM'iniz ya da bülten aracınız? Sizin adınıza mail atan her servis SPF'te yer almalıdır.
3. Çok fazla "include" eklemek. SPF'in sorgu sayısı sınırlıdır; sınır aşılırsa kayıt hata verir. Çok sayıda servis kullanan şirketlerde kaydın düzenli sadeleştirilmesi gerekir.
4. Alt alan adlarını unutmak. SPF kaydı alt alan adlarını otomatik kapsamaz. Mailleriniz bildirim.sirketiniz.com gibi bir alt alan adından çıkıyorsa, o alt alan adının da kendi kaydı olmalıdır.

Son madde bize doğrudan yaşanmış bir ders olarak döndü; birazdan anlatacağız.

DKIM: Mailin Dijital İmzası

DKIM (DomainKeys Identified Mail), giden her maile görünmez bir dijital imza ekler. Gönderen sunucu bu imzayı gizli bir anahtarla oluşturur; alıcı sunucu ise DNS'inizde yayınlanan açık anahtarla imzayı doğrular. İmza tutuyorsa iki şey kanıtlanmış olur: Mail gerçekten sizin yetkilendirdiğiniz bir sistemden çıkmıştır ve yolda değiştirilmemiştir.

DKIM kurulumu genellikle şöyle işler:

1. Mail servisinizin (Google Workspace, Microsoft 365, hosting panelinizin mail sistemi, bülten aracınız vb.) yönetim ekranından DKIM anahtarı oluşturulur.
2. Servis size bir DNS kaydı verir; bu kayıt bir "seçici" (selector) adıyla birlikte alan adınızın DNS'ine eklenir.
3. DNS yayıldıktan sonra servis tarafında imzalama etkinleştirilir.

Dikkat edilmesi gereken nokta: Her gönderen servis kendi DKIM imzasını kullanır. Kurumsal maili imzalamanız, bülten aracınızın gönderdiği mailleri otomatik olarak imzalamaz. Ayrıca güncel servisler genellikle 2048 bit uzunluğunda anahtar önerir; eski ve kısa anahtarlar yenilenmelidir.

DMARC: Kurallar ve Raporlar

DMARC (Domain-based Message Authentication, Reporting and Conformance), SPF ve DKIM'in üzerine kurulan bir politika katmanıdır. İki görevi vardır:

• Alıcı sunucuya, SPF ve DKIM kontrolünden geçemeyen bir mail geldiğinde ne yapması gerektiğini söyler.
• Sizin adınıza kimlerin mail gönderdiğini gösteren düzenli raporlar gönderilmesini sağlar.

DMARC'ın üç politika seviyesi vardır:

Politika	Anlamı	Ne Zaman Kullanılır
p=none	Sadece izle, rapor gönder, mail akışına dokunma	İlk kurulum; kim adınıza gönderiyor görmek için
p=quarantine	Kontrolden geçemeyen mailleri spam'e at	Raporlar temizlendikten sonra ara adım
p=reject	Kontrolden geçemeyen mailleri tamamen reddet	Tüm meşru servisler doğrulandıktan sonra hedef

Örnek bir başlangıç kaydı (DNS'te _dmarc alt adına TXT kaydı olarak):

v=DMARC1; p=none; rua=mailto:dmarc-rapor@sirketiniz.com

Önemli bir kavram da hizalama (alignment): DMARC, SPF ya da DKIM'in yalnızca geçmesine değil, mailin "Kimden" alanındaki alan adıyla uyumlu olmasına da bakar. Bir servis kendi alan adıyla SPF'ten geçip sizin adınızla mail atıyorsa, DMARC açısından bu yeterli değildir.

Doğrudan p=reject ile başlamak risklidir: Unuttuğunuz bir servis (örneğin e-fatura sistemi) birden mail gönderemez hale gelir. Doğru yol, p=none ile başlayıp birkaç hafta raporları incelemek, eksik servisleri SPF ve DKIM'e eklemek ve ardından politikayı kademeli olarak sıkılaştırmaktır.

Kendi Deneyimimizden: Uyarı Mailleri Neden Gelmiyordu?

Bu konuyu teoriden değil, kendi altyapımızdan biliyoruz. Yönettiğimiz sunucular, disk dolması ya da şüpheli giriş denemesi gibi durumlarda otomatik uyarı maili gönderiyordu. Bir gün fark ettik ki bu uyarılar bize ulaşmıyor. Daha da kötüsü, bir güvenlik olayını incelerken sunucunun aslında bizi uyardığını, ama mailin spam'e düştüğü için kimsenin görmediğini anladık.

Sebebi incelediğimizde mesele netleşti: Uyarılar bir alt alan adı üzerinden gönderiliyordu ve bu alt alan adının SPF kaydı yoktu. Gmail bu mailleri "550-5.7.26" koduyla reddediyordu. Bu hata kodu, kısaca "gönderen alan adı kimlik doğrulamasından geçemedi" anlamına gelir. Ana alan adımızın SPF, DKIM ve DMARC kayıtları eksiksizdi; sorun, kimsenin aklına gelmeyen o alt alan adındaydı.

Çözüm basitti: Gönderen adresini, SPF ve DKIM'i doğru kurulu ana alan adına taşıdık. Uyarılar o günden beri gelen kutusuna düşüyor. Çıkardığımız iki ders:

• Sadece insanların gönderdiği mailleri değil, makinelerin gönderdiği mailleri de kontrol edin: form bildirimleri, sunucu uyarıları, sipariş onayları, şifre sıfırlama mailleri.
• Bir uyarı sistemi kurduysanız, uyarının gerçekten ulaştığını periyodik olarak test edin. Ulaşmayan uyarı, hiç olmayan uyarıdan daha tehlikelidir; çünkü güvende olduğunuzu sanırsınız.

SPF, DKIM ve DMARC Dışında Spam Sebepleri

Kimlik kayıtları eksiksiz olsa da mailler spam'e düşebilir. Diğer yaygın sebepler:

• Gönderen IP'nin itibarı: Paylaşımlı hosting'de aynı sunucudaki başka bir site spam gönderdiyse, sunucunun IP adresi kara listeye girebilir ve sizin mailleriniz de etkilenir.
• Ters DNS (PTR) kaydı: Kendi mail sunucunuzu çalıştırıyorsanız, IP adresinin geriye doğru alan adınıza çözülmesi beklenir.
• İçerik: Sadece tek bir büyük görselden oluşan mailler, kısaltılmış şüpheli linkler, aşırı büyük harf ve ünlem kullanımı filtreleri tetikleyebilir.
• Liste kalitesi: İzinsiz toplanmış ya da eski listelere yapılan gönderimler, yüksek şikâyet ve geri dönme oranı nedeniyle alan adınızın itibarını düşürür. Toplu ticari ileti gönderiyorsanız İYS ve ilgili mevzuat yükümlülüklerinizi de bir hukukçuyla netleştirmenizi öneririz.
• Web sitesi formları: Sitenizin, kendi sunucusundan sizin alan adınızla ama yetkisiz şekilde mail göndermesi çok yaygın bir sorundur. Form maillerinin doğrulanmış bir mail servisi üzerinden gönderilmesi gerekir.

Alan Adınızı Kontrol Etme Listesi

Bugün kendi alan adınız için şu adımları uygulayabilirsiniz:

1. Gmail hesabınıza kendi kurumsal adresinizden bir mail gönderin, mailin menüsünden "Orijinali göster" seçeneğini açın. SPF, DKIM ve DMARC satırlarında "PASS" görmelisiniz.
2. DNS yönetim panelinizde yalnızca bir SPF kaydı olduğunu doğrulayın.
3. Sizin adınıza mail gönderen tüm servisleri listeleyin: kurumsal mail, web formu, CRM, e-fatura, bülten, destek sistemi, sunucu uyarıları.
4. Her servisin hem SPF'te yer aldığını hem DKIM imzasının açık olduğunu kontrol edin.
5. Alt alan adlarından mail gönderiliyorsa onların kayıtlarını ayrıca kontrol edin.
6. DMARC kaydınız yoksa p=none ile başlayın, raporları birkaç hafta izleyin, sonra kademeli olarak sıkılaştırın.
7. Kritik otomatik maillerin (uyarı, şifre sıfırlama, sipariş onayı) gerçekten ulaştığını ayda bir test edin.

Sık Sorulan Sorular

SPF, DKIM ve DMARC'ın üçü de gerekli mi? Evet. SPF ve DKIM kimliği doğrular, DMARC bu doğrulamanın sonucunda ne yapılacağını belirler ve size raporlar. Biri eksik olduğunda koruma da eksik kalır ve büyük sağlayıcılar eksikliği giderek daha sert cezalandırıyor.

Bu kayıtları kurmak e-posta akışını bozar mı? Doğru planlanırsa bozmaz. Risk, unutulan bir servisin SPF'e eklenmemesi ya da DMARC'ın doğrudan reject seviyesinde başlatılmasıdır. Kademeli ilerlemek bu riski ortadan kaldırır.

Kayıtları ekledim, mailler hâlâ spam'e düşüyor. Neden? DNS değişikliklerinin yayılması zaman alabilir. Bu süreden sonra hâlâ sorun varsa IP itibarına, içerik yapısına, liste kalitesine ve mailin gerçekten hangi sunucudan çıktığına bakmak gerekir.

Google Workspace ya da Microsoft 365 kullanıyorum, yine de kurmam gerekir mi? Evet. Bu servisler kurulum için gerekli değerleri verir, ancak kayıtları alan adınızın DNS'ine eklemek sizin sorumluluğunuzdadır. DKIM ve DMARC çoğu zaman varsayılan olarak etkin gelmez.

Sonuç

Kurumsal e-postaların spam'e düşmesinin en sık sebebi, alan adınızın kimliğini kanıtlayan SPF, DKIM ve DMARC kayıtlarındaki eksiklik ve hatalardır. SPF kimin gönderebileceğini, DKIM mailin değiştirilmediğini, DMARC ise kontrolden geçemeyen mailin akıbetini belirler. Kendi deneyimimizin gösterdiği gibi, sorun çoğu zaman göz önündeki ana adreste değil, unutulan bir alt alan adında ya da bir makinenin gönderdiği uyarı mailinde saklanır.

Mail altyapınızın, DNS kayıtlarınızın ve sunucu uyarılarınızın kontrolü için IT çözümleri hizmetimizi inceleyebilirsiniz. Daha geniş bir güvenlik çerçevesi için KVKK teknik tedbirler rehberimiz de yol gösterici olacaktır. Alan adınızı birlikte kontrol etmek için bize ulaşın.