Kurumsal E-postalar Neden Spama Düşer? SPF, DKIM ve DMARC

Müşterinize gönderdiğiniz teklif e-postası iki gün sonra "spam klasöründe buldum" notuyla geri dönüyorsa, sorun çoğu zaman yazdığınız metinde değil, alan adınızın DNS kayıtlarındadır. Alıcı sunucular bir e-postayı gelen kutusuna almadan önce üç soru sorar: Bu sunucu bu alan adı adına göndermeye yetkili mi (SPF)? İleti yolda değiştirilmeden mi geldi ve gerçekten bu alan adı tarafından mı imzalandı (DKIM)? Bu iki kontrol başarısız olursa alan adı sahibi ne yapılmasını istiyor (DMARC)? Bu rehberde üç kaydı doğru sırayla nasıl kuracağınızı, nasıl test edeceğinizi ve en sık yapılan hataları adım adım anlatıyoruz.

Kurumsal E-postalar Neden Spama Düşer?

Spam filtresi tek bir kurala bakmaz; gönderen itibarını, içerik sinyallerini, alıcının geçmiş davranışlarını ve kimlik doğrulama sonuçlarını birlikte değerlendirir. Kimlik doğrulama bu listenin temelidir, çünkü diğer sinyallerin anlamlı olması için önce "bu e-posta gerçekten sizden mi?" sorusunun cevaplanması gerekir.

Büyük posta sağlayıcıları bu konuda kurallarını sıkılaştırdı. Google'ın e-posta gönderen yönergelerine göre kişisel Gmail hesaplarına e-posta gönderen herkesin SPF ya da DKIM kurması, geçerli ileri ve geri DNS kayıtlarına sahip olması ve TLS kullanması gerekiyor. Günde 5.000'den fazla ileti gönderenler için ise SPF ve DKIM'in ikisi birden, en az p=none politikalı bir DMARC kaydı, gönderen adresiyle uyumlu (hizalı) alan adı ve pazarlama iletilerinde tek tıkla abonelikten çıkma şartı var. Yahoo ve Microsoft da yüksek hacimli göndericiler için benzer kurallar yayınladı.

Bu kurallar yalnızca büyük göndericileri ilgilendiriyormuş gibi görünse de, kimlik doğrulaması eksik olan küçük bir şirketin günlük yazışmaları da filtrelerin gözünde daha şüphelidir. Ayrıca DMARC olmadan, birisi sizin alan adınızı kullanarak sahte fatura ya da ödeme talebi gönderdiğinde alıcı tarafın bunu ayırt etmesi zorlaşır.

Spama düşmenin kimlik doğrulama dışındaki yaygın nedenleri de var: yeni açılmış ve henüz itibarı olmayan bir alan adı, tamamı görsel olan iletiler, kısaltılmış ya da itibarı düşük bağlantılar, satın alınmış listelere toplu gönderim. Bunları da aşağıdaki "yaygın hatalar" bölümünde ele alıyoruz.

Üç Kayıt, Üç Görev

Önemli bir ayrıntı: DMARC, SPF ve DKIM'in "geçti" demesiyle yetinmez; geçen alan adının, alıcının gördüğü "Kimden" (From) adresindeki alan adıyla uyumlu olmasını ister. Buna hizalama (alignment) denir. Bir pazarlama aracı iletiyi kendi alan adıyla imzalıyorsa DKIM teknik olarak geçer ama DMARC açısından hizalı sayılmaz.

Başlamadan Önce: Gönderen Envanteri Çıkarın

Kayıtları yazmaya başlamadan önce alan adınız adına e-posta gönderen her sistemi listeleyin. Projelerde en sık gördüğümüz sorun, bu listenin eksik kalması ve DMARC sıkılaştırıldığında bir sistemin e-postalarının sessizce kaybolması.

• Ana e-posta hizmeti: Google Workspace, Microsoft 365 ya da hosting'inizdeki posta sunucusu.
• Web sitesi: İletişim formu, sipariş bildirimi, şifre sıfırlama e-postaları. Bunlar çoğu zaman hosting sunucusundan PHP ile gönderilir ve SPF'te unutulur.
• Pazarlama ve bülten araçları: E-posta pazarlama platformları, CRM sistemleri.
• İş uygulamaları: e-Fatura bildirimleri, muhasebe programı, destek talep sistemi, randevu yazılımı.
• Cihazlar: Ofisteki tarayıcıdan "e-postaya tara" özelliği, kamera kayıt cihazı uyarıları.

Her biri için iki bilgiyi not edin: Hangi sunucudan gönderiyor (SPF için "include" değeri ya da IP adresi) ve kendi alan adınızla DKIM imzası atabiliyor mu?

Adım Adım Kurulum

1. DNS'inizin nerede yönetildiğini tespit edin. Kayıtlar, alan adının ad sunucularının (nameserver) gösterdiği yerde eklenmelidir. Alan adınız bir kayıt firmasında ama ad sunucuları Cloudflare'e yönlendirilmişse, kayıt firmasının panelinde eklediğiniz kayıt hiçbir işe yaramaz. Bu, "kaydı ekledim ama çalışmıyor" şikâyetlerinin başında gelir. DNS yönetimini taşımayı düşünüyorsanız Cloudflare rehberimize göz atın.
2. Tek bir SPF kaydı yazın. Ana alan adına (ornekfirma.com.tr) bir TXT kaydı eklenir. Yalnızca Google Workspace kullanıyorsanız v=spf1 include:_spf.google.com ~all yeterlidir. Web sitenizin sunucusu da e-posta gönderiyorsa onun IP'sini ekleyin: v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all (IP örnektir). Neden önemli: Bir alan adında birden fazla SPF kaydı olursa sonuç "permerror" olur ve SPF hiç yokmuş gibi davranılır. Yeni bir gönderen eklerken yeni kayıt açmayın, mevcut kayda ekleyin.
3. SPF'in 10 sorgu sınırını kontrol edin. RFC 7208'e göre SPF değerlendirmesi sırasında include, a, mx, exists ve redirect gibi DNS sorgusu gerektiren terimlerin toplamı 10'u geçemez; iç içe include'lar da sayılır. Beş-altı farklı hizmeti ekleyince sınır kolayca aşılır. Kullanmadığınız hizmetleri çıkarın, mümkünse sabit IP'leri ip4 ile yazın. ptr mekanizmasını hiç kullanmayın.
4. Sonu doğru seçin: ~all mı, -all mı? ~all (softfail) listede olmayan sunucuları "şüpheli", -all (fail) ise "yetkisiz" olarak işaretler. DMARC devredeyken asıl kararı DMARC politikası verir; bu nedenle geçiş döneminde ~all ile başlamak daha az risklidir. +all ise herkese izin vermek demektir; asla kullanmayın.
5. DKIM'i her gönderen için etkinleştirin. E-posta hizmetinizin yönetim panelinden DKIM anahtarı üretin; size bir seçici (selector) adı ve uzun bir açık anahtar verilir. Google Workspace'te varsayılan seçici google olduğu için kayıt adı google._domainkey.ornekfirma.com.tr olur. Google, mümkünse 2048 bit anahtar kullanılmasını öneriyor. Kaydı ekledikten sonra paneldeki "kimlik doğrulamayı başlat" adımını atlamayın; birçok kurulumda kayıt eklenir ama imzalama hiç açılmaz. Pazarlama ve CRM araçlarında da "kendi alan adınızla doğrulama" bölümünden size özel DKIM kayıtlarını (genellikle CNAME) ekleyin.
6. DMARC'ı izleme modunda yayınlayın. Google, SPF ve DKIM'i kurduktan sonra DMARC'a geçmeden önce en az 48 saat beklemeyi öneriyor. _dmarc.ornekfirma.com.tr adına şu TXT kaydını ekleyin: v=DMARC1; p=none; rua=mailto:[email protected]. p=none hiçbir iletiyi engellemez, yalnızca rapor toplar. Rapor adresi olarak kişisel posta kutunuzu değil, ayrı bir adres ya da grup kullanın; raporlar günlük ve yoğun gelir.
7. Raporları okuyun ve eksikleri kapatın. rua raporları XML biçimindedir ve hangi IP'lerin sizin adınıza gönderdiğini, SPF/DKIM sonuçlarını gösterir. Bir DMARC rapor analiz aracı ya da hizmeti bunları okunur hâle getirir. Tanımadığınız ama meşru olan bir gönderen (ör. muhasebe programı) görürseniz SPF'e ekleyin ya da DKIM'ini kurun. Tanımadığınız ve meşru olmayan kaynaklar, alan adınızın taklit edildiğini gösterir.
8. Politikayı kademeli sıkılaştırın. Birkaç hafta boyunca meşru e-postalarınızın tamamının hizalı geçtiğini gördükten sonra p=quarantine'e geçin. Google, pct etiketiyle politikayı önce iletilerin küçük bir yüzdesine uygulayıp kademeli artırmayı öneriyor (ör. pct=25, sonra 50, sonra 100). Sorun çıkmazsa son aşama p=reject'tir. Alt alan adları için ayrı politika gerekiyorsa sp etiketini kullanın.

Test Etme: Kayıtlar Gerçekten Çalışıyor mu?

DNS değişikliklerinin yayılması birkaç dakikadan birkaç saate kadar sürebilir. Sonra şu kontrolleri yapın:

• İleti başlığına bakın: Kendi adresinizden kişisel bir Gmail hesabına e-posta gönderin, iletiyi açıp "Orijinali göster" seçeneğine tıklayın. SPF, DKIM ve DMARC satırlarının üçünde de "PASS" görmelisiniz. DKIM satırında görünen alan adının sizin alan adınız olduğundan emin olun.
• DNS sorgusu yapın: Komut satırında dig TXT ornekfirma.com.tr ve dig TXT _dmarc.ornekfirma.com.tr ile kayıtların yayında olduğunu görebilirsiniz. Windows'ta aynı işi nslookup -type=TXT yapar.
• Çevrimiçi denetleyiciler: Google Admin Toolbox'taki MX denetleyicisi ve benzeri araçlar SPF sözdizimini, sorgu sayısını ve DMARC kaydını tek ekranda kontrol eder.
• Her gönderen için ayrı test: Web sitesindeki iletişim formunu, bülten aracını ve fatura bildirimini ayrı ayrı tetikleyin. Ana posta kutunuzun geçmesi, diğer sistemlerin de geçtiği anlamına gelmez.
• Toplu gönderim yapıyorsanız itibar takibi: Google Postmaster Tools, alan adınızın Gmail'deki spam oranını ve kimlik doğrulama başarısını gösterir. Google yönergelerinde spam oranının yüzde 0,3'ün altında tutulması isteniyor; önerilen hedef ise yüzde 0,1'in altı.

En Sık Yapılan Hatalar

• İki ayrı SPF kaydı: Hosting firmasının otomatik eklediği SPF kaydı dururken bir de Workspace için yenisi eklenir. İkisini tek kayıtta birleştirin.
• Doğrudan p=reject ile başlamak: Envanter çıkarılmadan sıkı politikaya geçmek, fatura ya da form e-postalarının görünmeden kaybolmasına yol açar.
• Web sitesi formunun unutulması: Site, ziyaretçinin girdiği adresi "Kimden" olarak kullanıp hosting sunucusundan gönderir. Bu hem SPF hem DMARC açısından başarısız olur. Formu, kendi alan adınızdan ve kimliği doğrulanmış SMTP üzerinden gönderecek şekilde yapılandırın; ziyaretçinin adresini "Yanıtla" (Reply-To) alanına koyun.
• Yanlış yerde kayıt eklemek: Ad sunucuları başka bir yeri gösterirken eski paneldeki DNS'i düzenlemek.
• TXT kaydında biçim hataları: Gereksiz tırnak işaretleri, kopyalarken bölünen DKIM anahtarı, kayıt adına alan adının iki kez eklenmesi (_dmarc.ornekfirma.com.tr.ornekfirma.com.tr). Panellerin çoğu kayıt adına alan adını otomatik ekler; sadece _dmarc yazmanız yeterlidir.
• Kendi posta sunucusunda PTR eksikliği: Kendi sunucunuzdan doğrudan gönderim yapıyorsanız IP'nin geri DNS (PTR) kaydı, sunucunun ana bilgisayar adını göstermeli ve o ad da aynı IP'ye çözülmelidir.
• Yalnızca DNS'e odaklanmak: Kimlik doğrulama kusursuz olsa da satın alınmış listelere gönderim, tamamı görselden oluşan iletiler ve abonelikten çıkma bağlantısı olmayan bültenler spam şikâyetlerini artırır.

Kimlik doğrulamanın doğru kurulmuş olması, alan adı taklidiyle yapılan oltalama saldırılarına karşı da önemli bir savunmadır; bu konunun geniş çerçevesini KOBİ siber güvenlik kontrol listemizde bulabilirsiniz.

Yeni Alan Adı ve Isınma Süreci

Yeni tescil edilmiş bir alan adının itibar geçmişi yoktur. Kayıtlar kusursuz olsa bile ilk haftalarda yüksek hacimli gönderim yapmak filtreleri tetikleyebilir. Yeni bir alan adına geçiyorsanız önce günlük yazışmaları başlatın, toplu gönderimleri kademeli artırın. Kurumsal e-postada yeni alan adı kararını henüz vermediyseniz alan adı seçimi yazımızda e-posta açısından dikkat edilecek noktaları anlattık. E-postanızı hosting'den bağımsız bir hizmette tutmanın avantajlarına ise hosting türleri karşılaştırmamızda değindik.

Sık Sorulan Sorular

Sadece SPF kurmak yeterli değil mi?

Günlük düşük hacimli yazışmalar için Gmail'in temel şartı SPF ya da DKIM'dir, ama yalnızca SPF iletiler yönlendirildiğinde (forward) sık sık bozulur. DKIM imzası yönlendirmeden sonra da geçerliliğini korur. DMARC ise alan adınızın taklit edilmesine karşı tek gerçek korumadır. Üçünü birlikte kurmak bugün standart kabul ediliyor.

DMARC'ı p=none'da bırakırsam ne olur?

Raporları almaya ve büyük sağlayıcıların temel şartını karşılamaya devam edersiniz, ama alan adınızı taklit eden iletiler engellenmez. p=none bir başlangıç noktasıdır; hedef, meşru gönderenlerinizi doğruladıktan sonra quarantine ya da reject'e geçmektir.

Kayıtları ekledim, e-postalar hâlâ spama düşüyor. Neden?

Önce "Orijinali göster" ile üç kontrolün de geçtiğini doğrulayın. Geçiyorsa sorun itibar ya da içerik tarafındadır: yeni alan adı, yüksek şikâyet oranı, kara listedeki bir IP ya da şüpheli bağlantılar. Alıcılardan iletinizi "spam değil" olarak işaretlemelerini istemek de itibar oluşumuna katkı sağlar.

Alt alan adından bülten göndermek mantıklı mı?

Evet, birçok kurum pazarlama e-postalarını bulten.ornekfirma.com.tr gibi bir alt alan adından gönderir. Böylece toplu gönderimin itibarı, günlük yazışmaların itibarından ayrışır. Alt alan adı için ayrı SPF ve DKIM kayıtları gerekir; DMARC'ta sp etiketi alt alan adı politikasını belirler.

DKIM anahtarını ne sıklıkla değiştirmeliyim?

Kesin bir zorunluluk yoktur, ancak anahtarların belirli aralıklarla yenilenmesi iyi bir uygulamadır. Yeni seçiciyle yeni anahtarı yayınlayıp imzalamayı ona geçirdikten sonra eski kaydı bir süre daha tutun; yolda olan iletilerin doğrulaması bozulmasın.

Nereden Başlamalı?

Bugün yapabileceğiniz en hızlı kontrol, kendinize bir Gmail adresine e-posta gönderip "Orijinali göster" ekranına bakmaktır. Üç satırdan biri bile "PASS" değilse yukarıdaki adımları sırayla uygulayın: envanter, tek SPF, her gönderen için DKIM, izleme modunda DMARC ve kademeli sıkılaştırma. Workspace hesabınızı henüz kurmadıysanız, MX kayıtları dahil temel kurulum adımları Google Workspace kurulum rehberimizde yer alıyor.

Birden fazla gönderen sistemi olan, DMARC raporlarını yorumlamakta zorlanan ya da alan adı taklidiyle karşılaşan işletmeler için IT hizmetlerimiz kapsamında e-posta kimlik doğrulamasını uçtan uca kuruyor ve raporları sizin yerinize izliyoruz. Mevcut kayıtlarınızı birlikte incelemek için bize ulaşın.

Kaynaklar

• Google – E-posta gönderen yönergeleri
• Google Workspace Yönetici Yardımı – DMARC'ı ayarlama
• IETF RFC 7208 – Sender Policy Framework (SPF)
• DMARC.org – What is DMARC?
• Yahoo Sender Hub – Sender Best Practices