Soğuk E-postanızı Sessizce Batıran SPF, DKIM, DMARC Hataları

Bir domain'de SPF, DKIM, DMARC kayıtları 'var' olması, doğru çalıştığı anlamına gelmez. B2B outreach ekipleri genelde bu kayıtları bir kez kurup unutur; oysa yeni bir gönderim aracı eklendiğinde veya CRM entegrasyonu değiştiğinde kayıtlar sessizce bozulur ve kampanyanın yanıt oranı düşene kadar kimse fark etmez.

Yapılandırma hatası neden fark edilmeden kampanyayı batırır

SPF, DKIM, DMARC hataları çoğu zaman gönderim anında bir uyarı vermez. E-posta gider, alıcı sunucu onu sessizce spam klasörüne atar veya hiç teslim etmez, gönderen tarafta ise 'gönderildi' durumu görünür. Bu yüzden bir outreach kampanyasının yanıt oranı beklenenden düşükse ilk bakılması gereken yer içerik değil, DNS kayıtlarıdır.

Sorun genelde tek seferlik bir kurulum hatasından değil, zaman içindeki birikimden çıkar: yeni bir CRM entegre edilir, satış ekibi yeni bir gönderim aracı kullanmaya başlar, fatura sistemi e-posta göndermeye başlar — her biri SPF kaydına bir include eklenmesini gerektirir. Kayıt her düzenlendiğinde kimse eskiyi temizlemez, limit sessizce dolar.

B2B outreach'te bu durumun maliyeti toplu tüketici pazarlamasından daha yüksektir, çünkü hedef listesi zaten dardır. Yüz kişilik özenle seçilmiş bir ICP segmentine gönderim yapan bir ekip için, gönderimin yarısının spam klasörüne düşmesi, o segmentin tamamen 'yakılması' anlamına gelebilir — aynı alıcılara kısa sürede tekrar yazmak, itibarı daha da bozar.

Bu yüzden DNS kayıtlarının denetimi, kampanya öncesi bir kerelik kontrol değil, altyapıya her yeni araç eklendiğinde tekrarlanan bir rutin olmalıdır. Bir sonraki bölümlerde SPF, DKIM ve DMARC tarafında en sık görülen hataları ayrı ayrı ele alıyoruz.

SPF kaydında en sık görülen hatalar

SPF'in bilinen teknik sınırı şudur: bir domainin SPF kaydında en fazla 10 DNS lookup (include, redirect, a, mx gibi mekanizmaların toplamı) yapılabilir. Bu limit aşıldığında SPF kontrolü permerror ile sonuçlanır ve alıcı sunucu genelde bunu başarısızlık olarak değerlendirir — yani kayıt 'var' ama işlevsiz hale gelir. Birden fazla gönderim aracı (CRM, ESP, fatura sistemi, destek yazılımı) art arda eklendikçe bu limit kolayca dolar.

İkinci sık hata, aynı domainde birden fazla v=spf1 TXT kaydının bulunmasıdır. Bir ekip yeni bir araç eklerken eski kaydı düzenlemek yerine ikinci bir TXT kaydı oluşturur; DNS standardına göre bir domainde yalnızca tek bir SPF kaydı olabilir, iki ayrı kayıt bulunduğunda sonuç belirsizleşir ve doğrulama genelde başarısız sayılır. Bu hata özellikle birden fazla kişinin veya ajansın aynı DNS paneline erişimi olduğu durumlarda ortaya çıkar — biri değişiklik yaparken diğerinin daha önce eklediği kaydı görmez.

Üçüncü hata ise `~all` (soft fail) yerine yanlışlıkla `-all` (hard fail) kullanmak veya tam tersi — hangisinin kullanılacağı gönderim altyapısının olgunluğuna göre değişir, ama seçim bilinçli yapılmalı. Dördüncü hata, ana domain için SPF kaydı düzgün kurulurken bir alt domainin (ör. mail.sirket.com veya crm.sirket.com üzerinden gönderim yapan bir araç) SPF kaydının hiç oluşturulmamış olmasıdır; alt domainler ana domainin SPF kaydını otomatik miras almaz.

• Tek domainde birden fazla v=spf1 TXT kaydı
• Include zincirinin 10 DNS lookup limitini aşması
• Artık kullanılmayan eski aracın include'unun temizlenmemesi
• Alt domain (ör. mail.sirket.com) için ayrı SPF kaydı unutulması
• ~all ve -all arasında bilinçsiz seçim

DKIM yapılandırmasında dikkat edilmesi gerekenler

DKIM, e-postaya domain sahibinin özel anahtarıyla kriptografik bir imza ekler; bu imza e-posta başlığında görünür, açık anahtar ise selector._domainkey.domain.com biçiminde bir DNS TXT kaydında yayınlanır. En sık hata, gönderim aracının ürettiği DKIM anahtarının doğru selector adıyla DNS'e eklenmemesidir — araç imzalamaya devam eder ama alıcı sunucu karşılık gelen açık anahtarı DNS'te bulamaz, doğrulama başarısız olur.

İkinci yaygın hata, birden fazla gönderim aracı kullanırken hepsinin aynı selector'ı paylaşmasını beklemektir — her araç genelde kendi selector'ıyla gelir (örneğin google._domainkey veya mandrill._domainkey gibi), bu yüzden her yeni araç eklendiğinde ayrı bir DKIM DNS kaydı gerekir. Bu adımı atlayan ekipler, yeni aracın SPF include'unu ekler ama DKIM tarafını unutur — sonuç, SPF geçer ama DKIM başarısız olur ve DMARC hizalaması genel olarak zayıflar.

Üçüncü hata, eski bir aracı bıraktıktan sonra onun DKIM kaydını DNS'te silmemektir; bu doğrudan bir hataya yol açmaz ama gereksiz kayıt yükü bırakır ve denetimi zorlaştırır — bir yıl sonra DNS panelini açan biri, hangi selector'ın hâlâ aktif hangisinin ölü olduğunu ayırt edemez. Dördüncü hata, DKIM anahtarını çok uzun süre değiştirmemektir; anahtar rotasyonu güvenlik açısından önerilir ama rotasyon sırasında eski ve yeni anahtarın bir süre paralel yayında kalması gerekir, aksi halde geçiş anında imzalanan e-postalar doğrulanamaz.

DMARC kaydını kurarken yapılan hatalar

DMARC, SPF ve DKIM sonuçlarını From başlığındaki domain ile 'alignment' (uyum) üzerinden birleştirir ve bu kontroller başarısız olursa alıcı sunucuya ne yapacağını söyler: p=none (sadece izle), p=quarantine (spam'e koy) veya p=reject (reddet). En sık hata, kaydı hiç kurmamak değil, kurup rua= (aggregate rapor) adresini boş bırakarak hiç izlememektir — bu durumda SPF/DKIM'de bir sorun çıksa bile kimse fark etmez.

İkinci hata, SPF ve DKIM henüz tüm gönderim kaynaklarında (CRM, fatura sistemi, destek yazılımı dahil) hizalanmamışken doğrudan p=reject ile başlamaktır. Bu durumda meşru ama henüz hizalanmamış bir kaynaktan giden e-postalar da reddedilir. Doğru sıra genelde p=none ile başlayıp raporları birkaç hafta izlemek, hangi kaynağın hizalı hangisinin hizalı olmadığını görmek, sonra kademeli olarak p=quarantine ve p=reject'e geçmektir.

Üçüncü hata, DMARC kaydında alignment modunu (strict veya relaxed) hiç düşünmemektir — relaxed mod, alt domainlerin ana domainle hizalanmasına izin verirken strict mod tam eşleşme ister; hangi modun kullanılacağı, kaç farklı alt domainden gönderim yapıldığına göre değişir ve bu seçim genelde varsayılan bırakılıp hiç gözden geçirilmez.

Bu hataları nasıl tespit edip düzeltirsiniz

Denetim sırası önemli. Önce SPF kaydını bir DNS lookup aracıyla açıp include zincirini elle sayın — 10'a yaklaşıyorsa gereksiz veya eski include'ları temizleyin, gerekirse birden fazla aracı tek bir include altında (bazı sağlayıcılar bunun için 'SPF flattening' benzeri çözümler sunar) toplayın. Sonra her aktif gönderim aracının DKIM selector'ının DNS'te doğru yayınlandığını tek tek doğrulayın; bu genelde her araç panelinde 'DNS ayarları' veya 'domain doğrulama' bölümünde listelenir.

Son olarak DMARC kaydını kontrol edin: rua= adresi dolu mu, politika mevcut gönderim olgunluğuna uygun mu. Bir CRM veya adresli outreach platformu üzerinden gönderim yapıyorsanız, platformun kendi gönderim domain'i veya alt domain'i için de aynı üçlü kontrolü (SPF, DKIM, DMARC hizalaması) ayrıca yapmak gerekir — ana domain'in kaydı düzgün olsa bile alt domain'de aynı hata tekrarlanabilir.

B2B outreach ajanslarında veya birden fazla marka/domain yöneten ekiplerde bu denetim daha da kritikleşir, çünkü aynı hata birden fazla müşteri domain'inde aynı anda tekrarlanabilir. Bu durumda denetimi tek bir domain için değil, kullanılan tüm gönderim domainleri için standart bir checklist halinde tekrarlamak, sorunu tek tek keşfetmek yerine sistematik önlemeyi sağlar.

• SPF include zincirini say, 10 lookup limitine yaklaşıyorsa temizle
• Domainde tek bir v=spf1 TXT kaydı olduğunu doğrula
• Her aktif gönderim aracının DKIM selector kaydını DNS'te tek tek kontrol et
• DMARC rua= adresinin dolu ve gerçekten izlendiğini doğrula
• Alt domain kullanıyorsan aynı üçlü kontrolü orada da tekrarla
• Artık kullanılmayan araçların SPF include'unu ve DKIM kaydını temizle

Sık sorulan sorular