İYS (İleti Yönetim Sistemi) için DNS ve E-posta Kayıt Ayarları

İYS (İleti Yönetim Sistemi), Türkiye'de ticari elektronik ileti gönderimi yapan her işletmenin kayıt altına almak zorunda olduğu yasal bir platformdur. Sisteme kaydolmak tek başına yeterli değildir; gönderdiğiniz e-postaların gerçekten alıcıya ulaşması için gönderici domain'inizin DNS kayıtlarının da doğru yapılandırılmış olması şarttır. İYS uyumu hukuki bir zorunluluk, DNS yapılandırması ise teknik bir zorunluluktur; ikisi birlikte çalışmadığında iletileriniz spam klasörüne düşer ya da tümden reddedilir.

Bu iki katman arasındaki ilişki çoğu zaman göz ardı edilir. İşletmeler İYS'ye kaydolur, izin veritabanını günceller, ardından e-posta kampanyasına geçer. Alıcı sunucu ise mesajı almadan önce gönderici domain hakkında birkaç DNS sorgusu yapar. Bu sorgular olumsuz sonuç verirse mesaj imzalanmamış ve kaynağı doğrulanamamış bir ileti olarak değerlendirilir; içeriğin yasal uyumluluğu bu aşamada hiç sorgulanmaz.

Domain'inizi İYS kaydı için kullandığınız adres ile e-posta gönderimi için kullandığınız adres örtüşüyorsa SPF ve DMARC kayıtları doğrudan alıcıya ulaşılabilirliği belirler. Aşağıda, İYS uyumlu toplu e-posta gönderimi için hangi DNS kayıtlarını nasıl yapılandırmanız gerektiği adım adım ele alınmaktadır.

İYS Uyumluluğu Neden DNS Yapılandırmasını Etkiler?

İYS, yalnızca izin yönetimini düzenler. Alıcının onayını almak sizin sorumluluğunuzdadır; alıcı sunucunun o e-postayı teslim edip etmeyeceğine ise DNS kayıtları karar verir. Bu iki sistem farklı katmanlarda çalışır ve biri diğerinin yerine geçmez.

Bir alıcı size ticari ileti izni vermiş olabilir. Ne var ki alıcının e-posta sağlayıcısı, gönderici domain'inizin SPF kaydını kontrol ettiğinde yetkisiz bir IP adresiyle karşılaşırsa mesaj spam klasörüne düşer. Hukuki açıdan uyumlu bir ileti, teknik açıdan teslim edilemez hale gelir. E-postaların spam klasörüne düşmesi çoğunlukla bu tür DNS kaynaklı sorunlardan kaynaklanır; içerik değil, altyapı kayıtları suçludur.

İYS kaydı ve DNS yapılandırması özellikle üç durumda birbirini doğrudan etkiler: İYS platformuna kayıt sırasında domain doğrulaması yapılıyorsa, gönderilen iletiler kurumsal domain'den çıkıyorsa ya da üçüncü taraf bir e-posta servis sağlayıcısı (ESP) kullanılıyorsa. Bu durumların tamamında SPF, DKIM ve DMARC kayıtlarının eksiksiz tanımlanmış olması şarttır. Eksik bir kayıt, diğer iki kaydı işlevsiz kılmaz ama teslim başarısını düşürür.

Gönderici Domain Seçimi: Ana Domain mi, Alt Domain mu?

Toplu İYS iletileri için ana domain'i (örneğin sirket.com) kullanmak, ana domain'in e-posta itibarını kampanya performansına doğrudan bağlamak anlamına gelir. Toplu gönderimlerde şikayet oranı yükseldiğinde ya da açılma oranları düştüğünde bu itibar zarar görür ve işletmenin tüm kurumsal e-postaları etkilenebilir.

Alt domain kullanmak, mesela bulten.sirket.com veya iys.sirket.com, gönderim itibarını izole eder. Ana domain'in DNS kayıtları bozulmaz; kampanya kaynaklı sorunlar yalnızca alt domain'i etkiler. Bu yöntemin ek maliyeti, her alt domain için ayrı SPF, DKIM ve DMARC kaydı tanımlanmasıdır.

Alt domain tercih edildiğinde MX kaydı da eklenmelidir. Bazı spam filtreleri, aktif bir gelen kutusu olmayan domain'lerden gelen iletileri otomatik olarak şüpheli işaretler. MX kaydı olarak ana domain'in posta sunucusuna yönlendirme yapılabilir; aktif bir gelen kutusu çalıştırmak şart değildir, kaydın varlığı yeterlidir.

Hangisi seçilmeli? Gönderim hacmi düşükse ve alıcı listesi küçük, tanıdık bir kitleden oluşuyorsa ana domain yönetimi daha basit tutar. Hacim yüksekse, ESP üzerinden toplu ileti gönderiliyorsa ve şikayet riskini izole etmek istiyorsanız alt domain daha güvenli seçimdir. Kampanya frekansı ayda birden fazlaysa bu ayrımı yapmak isabetlidir.

SPF Kaydı: Yetkili Gönderici IP'lerini Tanımlama

SPF (Sender Policy Framework), bir domain adına e-posta gönderme yetkisi verilen IP adreslerini listeleyen TXT kaydıdır. Alıcı sunucu, mesajın geldiği IP'yi bu listeyle karşılaştırır. Listede yoksa sonuç fail veya softfail olur; DMARC politikasına göre mesaj reddedilebilir ya da spam klasörüne taşınabilir.

Bir ESP kullanıyorsanız, o ESP'nin SPF bloğunu include mekanizmasıyla kaydınıza eklemeniz şarttır. Her servis sağlayıcısının include değeri farklıdır; bu değer genellikle ESP'nin yardım belgelerinde yer alır. Örnek bir SPF kaydı şöyle görünür:

v=spf1 include:esp-spf.ornek.com ip4:203.0.113.5 ~all

Burada include değeri ESP'nin sunucu bloğunu referans alır, ip4 doğrudan gönderim yapan ek sunucuyu tanımlar. Bir domain'de yalnızca tek bir SPF kaydı olabilir. İki ayrı TXT kaydı v=spf1 ile başlıyorsa alıcı sunucu ikisini de geçersiz sayar ve doğrulama başarısız olur. Birden fazla servis sağlayıcısı eklemek için tüm include değerleri tek kayıtta birleştirilmelidir.

Kaydın sonundaki ~all (softfail) başlangıç aşaması için uygundur; DMARC politikası kararlı hale geldikten sonra -all (hardfail) olarak güncellenebilir. SPF lookup limiti önemli bir kısıttır: include, a, mx gibi DNS sorgusu gerektiren mekanizmalar toplamda 10'u geçemez. Bu sınırı aşan kayıtlar permerror döndürür. Kullanılmayan eski include değerlerini kayıttan çıkarın; her biri limit harcadığı gibi teşhis sürecini de zorlaştırır.

Birden fazla servis için SPF kaydını genişletmek gerektiğinde lookup sınırını aşmadan tüm gönderici bloklarını tek kayıtta birleştirmek, özellikle birden fazla ESP kullanan kurumsal yapılarda planlı bir kayıt mimarisi gerektirir.

DKIM Kaydı: Mesaj Bütünlüğü İçin Dijital İmza

DKIM (DomainKeys Identified Mail), gönderilen her mesajın başlığına kriptografik bir imza ekler. Alıcı sunucu bu imzayı, domain'in DNS bölgesinde yayımlanan açık anahtarla doğrular. İmza tutarlıysa mesajın yolculuk sırasında değiştirilmediği ve gerçekten o domain adına gönderildiği teyit edilir.

DKIM için eklenmesi gereken kayıt bir TXT kaydıdır. Kaydın adı şu biçimde olur: selector._domainkey.sirket.com. Buradaki selector, ESP'nin veya mail sunucunuzun belirlediği bir tanımlayıcıdır. Aynı domain'de birden fazla selector kullanılabilir; bu, farklı servisler için farklı imzalar oluşturmanıza ve her birini bağımsız yönetmenize olanak tanır.

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

Bu public key değeri ESP'nin kontrol panelinden ya da mail sunucusu kurulumu sırasında üretilir; sizin oluşturmanız gerekmez. Farklı platformlarda selector alıp DNS'e eklemek benzer adımları izler; temel fark yalnızca selector adı ve key uzunluğudur.

CNAME tabanlı DKIM kurulumu bazı ESP'lerin tercih ettiği yöntemdir. ESP kendi sistemindeki DKIM anahtarlarını yönetir; sizden yalnızca bir CNAME kaydı eklemenizi ister. Bu CNAME, ESP'nin yönettiği TXT kaydına işaret eder. Avantajı açıktır: anahtar rotasyonu otomatik gerçekleşir, siz her güncellemede DNS kaydını değiştirmek zorunda kalmazsınız. Dezavantajı ise DNS bağımlılığını ESP'ye devretmiş olmanızdır; ESP altyapısında yaşanan sorun DKIM doğrulamasını doğrudan etkiler.

DKIM kaydı yayımlandıktan sonra doğrulama 24-48 saat içinde tamamlanır. TTL değerini ilk kurulumda 3600 saniye olarak ayarlamak, sorun çıkması durumunda hızlı güncelleme yapmanızı kolaylaştırır. Anahtar boyutu için 2048 bit tercih edilmelidir; 1024 bit artık yeterince güvenli kabul edilmemektedir.

DMARC Kaydı: Politika, Hizalama ve Raporlama

DMARC (Domain-based Message Authentication, Reporting and Conformance), SPF ve DKIM doğrulamalarını bir politika çerçevesinde birleştirir. Alıcı sunucuya, doğrulama başarısız olan mesajlarla ne yapması gerektiğini söyler: hiçbir şey yapma (none), karantinaya al (quarantine) veya reddet (reject).

İlk aşamada p=none politikasıyla başlamak zorunludur. Hiçbir iletiyi engellemeden gönderim verisi toplanır ve raporlama altyapısı test edilir. Aggregate raporları okuyarak politikayı kademeli sıkılaştırmak, başarısız iletilerin kaynağını anlamadan reject'e geçmek yerine izlenmesi gereken standart yoldur.

Temel bir DMARC TXT kaydı şu şekilde görünür:

v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

Burada rua parametresi, aggregate raporların gönderileceği adresi belirtir. fo=1 ise SPF veya DKIM başarısız olduğunda rapor üretilmesini sağlar. Bu adres geçerli bir posta kutusu olmalıdır; yoksa raporlar ulaşmaz ve hata saptanamaz. Raporlar XML biçiminde gelir; bir DMARC rapor okuma aracı kullanmak ham veriyi anlamlandırmayı kolaylaştırır.

DMARC'da hizalama (alignment) kavramı kritik önemdedir. SPF hizalaması, MAIL FROM adresiyle From başlığının domain'inin örtüşmesini gerektirir. DKIM hizalaması ise imzalayan domain'in From başlığıyla eşleşmesini bekler. ESP kullanıldığında bu hizalama genellikle özel domain yapılandırmasıyla sağlanır; varsayılan kurulumda ESP kendi domain'i adına imzalama yapar ve DKIM hizalaması sağlanamaz. Dolayısıyla ESP kontrolünüzdeki bir selector ile imzalama yapmalı ya da CNAME delegasyonu kurmalısınız.

ESP ile Çalışırken Hizalamayı Doğru Kurmak

Toplu İYS iletileri genellikle bir ESP (e-posta servis sağlayıcısı) aracılığıyla gönderilir. ESP, kendi IP altyapısını kullanır ve mesajları sizin domain'iniz adına iletir. Bu mimaride SPF hizalaması varsayılan olarak kırılır, çünkü mesajın geldiği IP ESP'ye aittir ama From adresi sizin domain'inizi gösterir.

İki yol mevcuttur. Birincisi, ESP'nin sunucularını kapsayan bir SPF include değeri eklemek ve ESP'nin sizin selector'ınızla DKIM imzalaması yapmasını sağlamaktır. İkincisi, ESP'nin önerdiği CNAME tabanlı yöntemi izlemektir. Her iki durumda da From başlığındaki domain ile imzalayan domain örtüşmeli; örtüşmezse DMARC hizalaması sağlanamaz ve quarantine ya da reject politikasına geçildiğinde iletiler teslim edilmez.

Peki ne zaman bu yapılandırma gereksizdir? Yalnızca dahili araçlarla küçük bir listeye test amaçlı ileti gönderiliyorsa ve DMARC politikası p=none seviyesinde kalacaksa tam hizalama zorunlu değildir. Ancak yasal zorunluluk olan İYS iletilerini toplu olarak göndermek için bu minimum yapıyı atlamak uzun vadede itibar sorununa yol açar.

Google Workspace gibi kurumsal e-posta platformlarında bu hizalama kurulum rehberlerinde açıkça belirtilir; ESP ise çoğunlukla kullanıcıya özel bir domain kurulum kılavuzu sunar. Takip etmeniz gereken her adım bu kılavuzda yer alır.

Kurulum Sonrası Doğrulama Sırası

Kayıtlar eklendikten sonra TTL süresinin dolmasını bekleyin. Standart TTL değeri 3600 saniyedir; bazı sağlayıcılar 86400 saniye (24 saat) kullanır. Acil güncelleme beklentiniz varsa kaydı eklemeden önce TTL'yi 300-600 saniyeye düşürün, değişiklik sonrasında eski değere geri döndürün.

Kayıt yayılımı tamamlandıktan sonra doğrulama sırasını şöyle kurabilirsiniz:

1. SPF kaydını dig TXT sirket.com veya nslookup -type=TXT sirket.com ile sorgulayın. Tek bir v=spf1 kaydı döndürmeli.
2. DKIM kaydını dig TXT selector._domainkey.sirket.com ile sorgulayın. p= değeri dolu dönüyorsa kayıt yayılmış.
3. DMARC kaydını dig TXT _dmarc.sirket.com ile sorgulayın. v=DMARC1 ile başlayan değer görünüyorsa kayıt aktif.
4. Gerçek bir test mesajı gönderin ve başlıklarını inceleyin. Authentication-Results satırı SPF pass, DKIM pass ve DMARC pass göstermeli.

Test mesajının başlıklarında dmarc=pass görünüyorsa üç kayıt da doğru hizalanmış demektir. Sadece SPF ve DKIM pass gösterip DMARC fail dönüyorsa hizalama sorunu vardır; From adresi ile imzalayan domain veya MAIL FROM domain'ini karşılaştırın.

Dikkat: DMARC raporları rua adresine XML olarak gelir. Raporlar birkaç saat ile 24 saat arasında gecikmeyle ulaşır. Raporlama adresi dışarıdan bir domain'de ise (örneğin üçüncü taraf bir raporlama servisi kullanıyorsanız) o domain'in _dmarc alt kaydında izin beyanı olmalıdır; yoksa büyük çoğunluk alıcısı raporları o adrese iletmez.

Kayıt Yönetimi: Değişiklik, Rotasyon ve İzleme

DNS kayıtları bir kez kurulup unutulan yapılar değildir. ESP değiştirdiğinizde eski include değerini SPF kaydından çıkarın; aksi halde lookup limiti zamanla dolabilir. Yeni ESP eklendiğinde ise hem SPF hem de DKIM selector kurulumunu sıfırdan yapmanız şarttır.

DKIM anahtar rotasyonu önerilen güvenlik pratiğidir. Mevcut selector aktifken yeni bir selector oluşturun, DNS'e yayımlayın ve ESP'yi yeni selector'a geçirin. Eski selector'ı hemen silmeyin; yolda olan mesajlar eski imzayı içerebilir. Birkaç gün geçtikten sonra eski kaydı kaldırmak güvenlidir.

Domain portföyünüzü düzenli izlerken DNS kayıt değişikliklerini de takip altında tutmanız önerilir. Özellikle birden fazla domain üzerinden İYS iletisi gönderiliyorsa her domain için ayrı kayıt seti yönetilmesi gerekir; tek bir DNS panelinde bunları etiketli ve gruplu tutmak bakımı kolaylaştırır.

DMARC politikasını none'dan quarantine'e taşıma zamanı geldiğinde raporlardaki başarı oranına bakın. İzinli kaynaklardan gelen mesajların tamamına yakını pass alıyorsa geçiş güvenlidir. Yüzde değil, oransal tutarlılık önemlidir; tek bir kötü günün verisiyle karar vermek yerine bir iki haftalık tablo üzerinden değerlendirme yapın.

İYS uyumluluğu için doğru izinleri toplamak ve güncel tutmak kadar, bu iletilerin alıcıya sorunsuz ulaşmasını sağlamak da sizin sorumluluğunuzdadır. SPF yetkisiz bir IP'ye işaret ettiğinde, DKIM imzası hizalanamadığında ya da DMARC politikası belirsiz kaldığında izin almış olmanın teknik karşılığı sıfıra düşer. Yasal ve teknik katmanları birlikte yönetmek, İYS iletilerinin gerçekten işe yaramasının temel koşuludur.

DNS kayıtları doğru yapılandırılmış bir göndericinin iletileri filtrelere takılmadan geçer; yanlış ya da eksik yapılandırılmış bir göndericinin iletileri ise izin durumundan bağımsız olarak teslim edilemez. Teknik altyapıya yapılan bu yatırım, İYS uyum maliyetinin görünmeyen ama zorunlu bir parçasıdır.