Bir şirketin faturası, daveti, şifre sıfırlama mesajı veya kampanya e-postası alıcıya ulaşmadığında sorun çoğu zaman yalnızca içerikte aranır. Oysa gönderen alan adının DNS kimlik doğrulaması eksikse iyi hazırlanmış bir mesaj bile spam klasörüne gidebilir veya reddedilebilir. Türkçe işletmelerde bu risk, Google Workspace, Microsoft 365, yerel e-posta hizmetleri, e-ticaret platformları ve pazarlama araçlarının aynı alan adından gönderim yapmasıyla büyür. SPF, DKIM ve DMARC bu karmaşık gönderim modelini alıcı sunuculara açıklamak için birlikte kullanılır.
Üç mekanizmayı birer sihirli spam filtresi gibi görmek doğru değildir. SPF, bir alan adı adına hangi sunucuların göndermeye yetkili olduğunu açıklar. DKIM, mesajın belirli bölümlerini kriptografik imzayla ilişkilendirir. DMARC ise görünen From alan adı ile SPF veya DKIM kimliğinin hizalanmasını kontrol eder ve başarısız iletiler için alan adı sahibinin politikasını, ayrıca rapor alıcılarını belirtir. Bu ayrım, bir kaydın PASS sonucunun diğer iki mekanizmanın da doğru olduğu anlamına gelmediğini anlamak için kritiktir.
SPF: hangi kaynaklar gönderebilir?
SPF, alan adının DNS'inde TXT kaydı olarak yayınlanır. Örneğin bir şirketin Google Workspace ve işlem e-postası hizmeti kullanması, her iki gönderim kaynağının da SPF politikasında yetkilendirilmesini gerektirir. Ancak aynı alan adına birden fazla v=spf1 kaydı eklemek geçerli bir birleşim oluşturmaz; alıcılar permerror döndürebilir. Include zincirleri de DNS sorgu sayısını artırır. RFC 7208, değerlendirmeyi sınırlayan DNS lookup bütçesini tanımlar. Bu yüzden kopyala-yapıştırla büyüyen uzun bir SPF kaydı yerine, gerçekten kullanılan kaynakların envanterini çıkarıp gereksiz include satırlarını kaldırın.
- Alan adınız için yalnızca bir SPF kaydı bulunduğunu kontrol edin.
- Web sitesi barındırma hizmetini, e-posta sağlayıcısını ve işlem e-postası platformunu ayrı ayrı listeleyin.
- Kullanılmayan eski sağlayıcıları ve artık yönetilmeyen include değerlerini kaldırın.
- SPF kaydının lookup sınırına yaklaşmadığını ve sözdiziminin geçerli olduğunu doğrulayın.
- Alt alan adından gönderim yapıyorsanız ana alan adının politikasını otomatik olarak miras alacağını varsaymayın.
DKIM: mesajın alan adıyla imzalanması
DKIM'de gönderen sistem mesajı özel anahtarla imzalar, alıcı sistem ise DNS'te yayınlanan açık anahtarı kullanarak imzayı doğrular. DNS kaydı genellikle selector._domainkey.example.com biçimindedir. Selector, aynı alan adında birden fazla gönderici platformunun ayrı anahtarlar yayınlamasına izin verir. Bir sağlayıcının verdiği CNAME veya TXT değerini eksiksiz eklemek, anahtarı rotasyon sırasında güncellemek ve sağlayıcının gerçek imza alan adını bilmek gerekir. DKIM PASS görüldüğünde bile DMARC hizalaması ayrıca kontrol edilmelidir; çünkü imzalayan d= alan adı, görünen From alan adıyla beklenen organizasyon ilişkisini taşımayabilir.
DKIM kurulumu sırasında en yaygın hata, TXT değerinin tırnakları veya satır sonlarını yanlış kopyalamaktır. Bir diğer hata, DNS hizmetindeki CNAME flattening veya proxy seçeneğinin DKIM için uygun olmayan biçimde etkinleştirilmesidir. DKIM denetleyicisi ile selector sonucunu kontrol edin, ardından gerçek bir test mesajının Authentication-Results başlıklarını inceleyin. DNS kaydının varlığı yalnızca anahtarın yayımlandığını gösterir; mesajın doğru anahtarla gerçekten imzalandığını kanıtlamak için alıcı tarafındaki sonuç gerekir.
DMARC: hizalama, politika ve rapor
DMARC kaydı _dmarc.example.com adresinde TXT olarak yayınlanır. p=none, quarantine ve reject değerleri başarısız iletilere ilişkin politika niyetini ifade eder. rua ve ruf gibi rapor hedefleri, alıcıların toplu veya adli geri bildirimleri nereye göndereceğini belirtir. DMARC'ın güçlü tarafı, alan adı sahibinin kendi alan adı adına gönderilen mesajları görmesine ve SPF ya da DKIM sonuçlarını politika ile ilişkilendirmesine yardım etmesidir. Fakat DMARC, görsel olarak benzer başka bir alan adının kullanımını tek başına durdurmaz; marka taklidi için ayrıca alan adı ve tehdit izleme gerekir.
Yeni bir DMARC politikası için kademeli geçiş çoğu işletmede daha güvenlidir. Önce p=none ile rapor toplayın, meşru gönderim kaynaklarını ve hizalama hatalarını sınıflandırın. Kurumsal ekipler, müşteri bildirimleri, fatura sistemi, destek masası ve pazarlama platformu gibi her akışı ayrı test etmelidir. Beklenmeyen bir kaynak görüldüğünde bunun unutulmuş gerçek bir servis mi, yönlendirilmiş bir mesaj mı veya taklit girişimi mi olduğunu araştırın. Yeterli kapsama ulaşıldığında quarantine, daha sonra risk ve iş etkisi değerlendirilerek reject düşünülebilir.
Google gönderici kuralları neden önemli?
Google'ın kişisel Gmail hesaplarına gönderim için yayımladığı güncel kurallar, tüm gönderenler için SPF veya DKIM kimlik doğrulamasını, geçerli ileri ve ters DNS'i ve TLS kullanımını ister. Günde 5.000'den fazla ileti gönderen toplu göndericiler için SPF ve DKIM'e ek olarak DMARC, ayrıca görünen From alanıyla SPF veya DKIM alanının hizalanması gerekir. Bu kurallar yalnızca Google'a özgü bir teknik ayrıntı değildir; alıcıların alan adı sahipliğini ve gönderim davranışını değerlendirme eğilimini gösterir. Hacminiz düşük olsa bile SPF, DKIM ve DMARC'ı birlikte kurmak, alan adı itibarını savunulabilir biçimde yönetmeye yardımcı olur.
Kimlik doğrulama sonucu, teslim garantisi değil, alıcının karar verebilmesi için güven sinyalidir.
E-posta operasyonu ilkesi
Türkçe işletmeler için uygulama planı
İlk gün alan adınızdan kimlerin e-posta gönderdiğini çıkarın. Muhasebe veya ERP sistemi, müşteri ilişkileri, destek, insan kaynakları, pazarlama, web formu ve dış kaynak ajanslar genellikle unutulan kaynaklardır. Her kaynak için görünen From alanını, Return-Path alanını, DKIM d= alan adını ve gönderim amacıyla birlikte kaydedin. Sonra E-posta güvenliği kontrolü ile mevcut DNS durumunu alın ve eksikleri önem sırasına koyun. En kritik değişiklikleri düşük hacimli test alıcılarla doğrulamadan doğrudan bütün müşterilere uygulamayın.
- Gönderim kaynaklarını ve sahiplerini envantere alın.
- Tek ve sade bir SPF kaydı yayımlayın, lookup sayısını izleyin.
- Her gönderici için DKIM anahtarı ve selector rotasyonunu planlayın.
- DMARC'ı p=none ile başlatıp raporları sınıflandırın.
- Meşru kaynaklar hizalandığında politikayı kademeli sıkılaştırın.
- Düzenli DNS ve gerçek mesaj kontrolleriyle değişiklikleri yeniden doğrulayın.
Hata teşhisinde yalnızca DNS'e bakmayın
Bir ileti spam klasörüne girdiğinde SPF kaydının geçerli olması tek başına açıklama değildir. Mesaj içeriği, alıcı geri bildirimleri, IP veya alan adı itibarı, hacim değişimi, TLS, liste aboneliği ve From başlıklarının tutarlılığı da rol oynar. Aynı şekilde DMARC FAIL, her zaman gönderenin kötü niyetli olduğu anlamına gelmez; yanlış Return-Path, forwarder davranışı veya DKIM imzasının mesaj aktarımında bozulması gibi nedenler olabilir. Authentication-Results başlıklarını, DMARC raporlarını ve gönderim kaynağını birlikte inceleyin. Belirsiz bir sonuçta kullanıcıya kesin teslim sözü vermek yerine yeniden test ve gözlem süresi tanımlayın.
API ve sürekli kontrol
Birden fazla müşteri veya alan adı yöneten ekipler, kimlik doğrulama kayıtlarını elle kontrol etmek yerine E-posta kimlik doğrulama API'si ile periyodik olarak sorgulayabilir. Sonucu domain, kontrol zamanı, SPF lookup durumu, DKIM selector, DMARC policy ve bilinmeyen nedenleriyle saklayın. Değişiklik olduğunda alarm üretin, fakat tek bir geçici timeout'u alan adının bozulması olarak raporlamayın. Meşru gönderim kaynağı eklenirken kayıt değişikliğinin kimin tarafından ve hangi iş gerekçesiyle yapıldığı da denetim kaydına eklenmelidir. Bu yapı, teslim sorununu bir defalık DNS düzeltmesinden çıkarıp e-posta güvenliği programına dönüştürür.
Forwarding ve üçüncü taraf gönderimlerini test etme
E-posta yönlendirme, dağıtım listeleri ve üçüncü taraf pazarlama servisleri kimlik doğrulama sonuçlarını değiştirebilir. Bir ileti şirket içinden çıktığında SPF PASS alıp yönlendirme sonrasında SPF FAIL görebilir; DKIM imzası bozulmamışsa DMARC yine geçebilir. Bu yüzden yalnızca doğrudan gönderilen test mesajını değil, müşteriye ulaşan gerçek akışı da inceleyin. Destek bileti, fatura, parola sıfırlama ve kampanya mesajlarını ayrı kategorilerde test etmek yararlıdır. Her kategorinin From, Return-Path ve DKIM d= alanını kaydedin. Böylece bir kaynağı herkese açmadan önce hangi mesaj tipinin etkilendiği bilinir.
Raporları okurken görülen IP adresi veya gönderici alanını hemen yetkili ya da kötü niyetli diye etiketlemeyin. Eski bir servis, forwarder, mobil uygulama veya yanlış yapılandırılmış test sistemi olabilir. Gönderim sahibinden doğrulama alın, ilgili alan adının kullanım amacını kontrol edin ve yalnızca bilinçli biçimde SPF'e ekleyin. Kullanılmayan bir kaynağı korumak saldırı yüzeyini büyütebilir. Düzenli çalışan bir envanter, raporların yeni ve beklenmeyen kaynaklarını daha hızlı fark etmenizi sağlar.
- Doğrudan ve yönlendirilmiş mesajı ayrı test edin.
- Transactional, destek ve pazarlama akışlarını sınıflandırın.
- From, Return-Path, DKIM d= ve Authentication-Results başlıklarını kaydedin.
- DMARC raporundaki yeni kaynağı sahiplik ve iş amacıyla doğrulayın.
- Gereksiz SPF include değerlerini periyodik olarak temizleyin.
- Politika değişikliğini düşük riskli bir pencerede uygulayın.
E-posta güvenliği bakımında görev dağılımını yazılı hale getirin. DNS kaydını kim değiştirebilir, DKIM anahtarını hangi ekip döndürür, DMARC raporunu kim inceler ve beklenmeyen göndericiyi kim doğrular? Küçük işletmelerde bu roller tek kişide toplanabilir, ancak yedek sorumlu ve erişim bilgisi yine belirlenmelidir. Hizmet sağlayıcısı değiştiğinde kayıt güncellemesinin yanı sıra eski hesabın kapatılması ve eski anahtarın rotasyon planı kontrol edilmelidir. Böylece teknik kayıt ile hesap güvenliği birlikte yönetilir.
Kayıt değişikliğini yaptıktan sonra DNS önbelleği ve alıcı raporları için ölçülü bir gözlem penceresi bırakın. Hemen reject politikasına geçmek yerine meşru mesajların ulaştığını ve hizalama sonuçlarının istikrarlı olduğunu doğrulayın. Bir gönderim platformu yeni bir alt alan adına taşındığında ana alan adı politikasıyla ilişkisini yeniden kontrol edin. İşletme büyüdükçe yeni kaynaklar eklenebilir; her ekleme, envanter ve test sürecinden geçmelidir. Böylece e-posta güvenliği bir defalık kurulum değil, yaşayan bir kontrol olur.
E-posta teslim sorunlarında kullanıcıya kesin bir neden söylemeden önce test mesajını, Authentication-Results başlıklarını ve ilgili DMARC raporunu eşleştirin. Aynı alan adında birden fazla sağlayıcı varsa hangi akışın etkilendiğini ayırın. Bu çalışma, SPF kaydını gereksiz biçimde genişletmek veya DMARC politikasını aceleyle gevşetmek yerine gerçek hatayı düzeltmeye yardımcı olur.
Kontrol sonuçlarını e-posta sağlayıcısının önerisiyle değil, alan adınızın gerçek gönderim envanteriyle karşılaştırın. Kullanılmayan bir kaynağı eklemek güvenlik ve bakım yükünü artırır. Gerekli kaynak doğrulanamıyorsa kısa süreli izleme ve düşük riskli test planlayın; kullanıcı teslimini tehlikeye atacak acele politika değişikliği yapmayın.
SPF, DKIM ve DMARC birlikte ele alındığında alan adınızın adına kimin gönderim yapabileceği, mesajın hangi alan adıyla imzalandığı ve başarısız sonuçta alıcının ne yapması gerektiği daha net görünür. Başarılı bir kurulumun ölçütü yalnızca yeşil bir araç sonucu değildir. Gönderim envanterinin eksiksiz olması, hizalamanın gerçek mesajlarda doğrulanması, raporların okunması ve politika değişikliklerinin kontrollü yapılması gerekir. Türkiye'deki işletmeler için yerel e-posta sağlayıcıları ve küresel hizmetler bir arada kullanılabildiğinden, bu süreci dokümante etmek ve otomatik kontrollerle desteklemek uzun vadede teslim edilebilirlik ile marka güvenini korur.