Sektörel·
21 Nisan 2026
Sigorta sektörü, müşterilere poliçe bilgisi, hasar bildirimi, prim hatırlatması ve fatura gibi son derece hassas belgeler iletir. Bu iletişimlerin güvenli, izlenebilir ve yasal uyumlu bir kanaldan gerçekleşmesi hem kurumsal itibar hem de yasal yükümlülük açısından zorunludur. E-posta hâlâ kurumsal iletişimin bel kemiğini oluştururken, e-posta güvenliğini sağlamak için gereken teknik ve hukuki altyapıyı kurmak sigorta şirketleri için artık bir tercih değil, bir gereklilik hâline gelmiştir.
Sigorta şirketleri, müşterilerinin Türk Ticaret Kanunu (TTK) kapsamında imzaladığı poliçe belgelerini, sağlık ve hayat sigortasına ait kişisel sağlık verilerini, banka hesap ve ödeme bilgilerini ve hasar dosyalarına ilişkin fotoğraf ile belgeleri e-posta aracılığıyla iletmektedir. Bu veriler 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) çerçevesinde "özel nitelikli kişisel veri" veya "kişisel veri" statüsünde değerlendirilmektedir. Kötü yapılandırılmış veya şifrelenmemiş bir e-posta altyapısı; veri ihlali, ortadaki adam (man-in-the-middle) saldırısı ve kimlik avı (phishing) risklerini beraberinde getirir.
Bilgi Teknolojileri ve İletişim Kurumu (BTK) istatistiklerine göre Türkiye'de kurumsal e-posta altyapısını hedef alan saldırılar her geçen yıl artmaktadır. Sigorta sektörü, finansal verilere doğrudan erişim sağlaması nedeniyle bu saldırıların öncelikli hedefleri arasında yer almaktadır.
Kurumsal e-posta güvenliğinin teknik çatısı üç temel protokol üzerine inşa edilmiştir: SPF, DKIM ve DMARC. Bu protokoller bir arada uygulandığında gönderen kimliğini doğrular ve sahte e-posta (spoofing) saldırılarını büyük ölçüde engeller.
| Protokol | RFC Referansı | İşlevi | DNS Kaydı Türü |
|---|---|---|---|
| SPF (Sender Policy Framework) | RFC 7208 | Hangi IP adreslerinin alan adınız adına e-posta gönderebileceğini tanımlar | TXT |
| DKIM (DomainKeys Identified Mail) | RFC 6376 | Gönderen sunucunun e-postayı kriptografik olarak imzalamasını sağlar | TXT (selector._domainkey) |
| DMARC (Domain-based Message Authentication) | RFC 7489 | SPF/DKIM başarısız olduğunda uygulanacak politikayı (none/quarantine/reject) belirler; raporlama sağlar | TXT (_dmarc) |
| MTA-STS (Mail Transfer Agent Strict Transport Security) | RFC 8461 | Posta sunucuları arası TLS kullanımını zorunlu kılar; aşağı sürüm (downgrade) saldırılarını engeller | HTTPS + TXT |
| BIMI (Brand Indicators for Message Identification) | BIMI Standardı | DMARC politikası "reject/quarantine" ise kurumun logosunu gelen kutusunda görünür kılar | TXT (default._bimi) |
Sigorta şirketleri için önerilen minimum yapılandırma; SPF kaydında yalnızca yetkili göndericilerin listelenmesi, DKIM için en az 2048-bit RSA anahtarı kullanılması ve DMARC politikasının kademeli olarak p=none → p=quarantine → p=reject şeklinde sıkılaştırılmasıdır.
E-posta güvenliği yalnızca gönderen kimlik doğrulamasıyla sınırlı değildir. İletim sırasında mesaj içeriğinin şifrelenmesi de kritik öneme sahiptir.
TLS (Transport Layer Security), e-posta sunucuları arasındaki bağlantıyı şifreler. RFC 8314 ile STARTTLS'in örtük TLS (implicit TLS, port 465) lehine bırakılması tavsiye edilmekte olup güncel standart TLS 1.3'tür (RFC 8446). Sigorta şirketleri, posta sunucularının TLS 1.0 ve 1.1'i devre dışı bırakacak şekilde yapılandırılmasını sağlamalıdır; zira bu sürümler artık güvensiz kabul edilmektedir.
S/MIME (Secure/Multipurpose Internet Mail Extensions) ise uçtan uca şifreleme ve dijital imza sağlar. RFC 8551 ile güncellenen bu standart, özellikle poliçe sözleşmeleri ve hasar ödemesi gibi yasal bağlayıcılığı olan belgelerin imzalanmasında kullanılabilir. S/MIME sertifikaları, Türkiye'de Kamu Sertifikasyon Merkezi (Kamu SM) veya akredite özel sertifikasyon hizmet sağlayıcılarından temin edilebilir.
Sigorta şirketlerinin e-posta iletişiminde uyması gereken başlıca yasal düzenlemeler şunlardır:
6698 Sayılı KVKK (Kişisel Verilerin Korunması Kanunu): Madde 12 uyarınca veri sorumlusu olan sigorta şirketleri, kişisel verilerin hukuka aykırı olarak işlenmesini önlemek ve yetkisiz erişimi engellemek amacıyla gerekli teknik ve idari tedbirleri almakla yükümlüdür. Sağlık sigortası kapsamındaki veriler, aynı Kanun'un Madde 6 hükmü gereği özel nitelikli kişisel veri sayılır ve açık rıza olmaksızın işlenemez. Kişisel Verileri Koruma Kurulu'nun 31/01/2018 tarihli ve 2018/10 sayılı kararı ise veri ihlali bildirimi yükümlülüğünü 72 saat olarak belirlemiştir.
6563 Sayılı Ticari İletişim ve Ticari Elektronik İletiler Hakkında Kanun (ETK): Ticari nitelik taşıyan e-postalar (kampanya, çapraz satış, yenileme hatırlatması vb.) yalnızca önceden alıcının onayı alınmış ise gönderilebilir. Kanun'un 3. maddesi kapsamında hizmet ilişkisinden kaynaklanan zorunlu iletiler (poliçe dokümanı, hasar bildirimi) ticari elektronik ileti sayılmaz; ancak bu ayrımı sağlamak için içerik ve bağlam belirleyicidir.
BTK Yönetmeliği (Ticari İletişim ve Ticari Elektronik İletiler Hakkında Yönetmelik, 04.01.2020 tarih ve 30998 sayılı Resmî Gazete): Onay kayıtlarının en az üç yıl saklanmasını, İYS (İleti Yönetim Sistemi) entegrasyonunu ve reddetme (opt-out) mekanizmasının her iletide yer almasını zorunlu kılar. Sigorta şirketleri, ticari nitelikteki tüm e-posta listelerini İYS platformuna (iys.org.tr) entegre etmek durumundadır.
Prim hatırlatması, poliçe yenileme bildirimi veya deprem/sel gibi afet sonrası hasar başvuru duyurusu gibi toplu iletiler için ayrı bir IP havuzu ve özel bir alt alan adı (örn. bildirim.sigorta-sirket.com.tr) kullanılması önerilir. Bu yapı, pazarlama e-postalarının itibar sorunlarının poliçe bildirimlerini olumsuz etkilemesini önler.
Google ve Yahoo'nun Şubat 2024'te yürürlüğe giren yeni gönderici gereksinimleri, günde 5.000'den fazla e-posta gönderen tüm kuruluşların SPF, DKIM ve DMARC p=quarantine veya p=reject politikasına sahip olmasını zorunlu kılmaktadır. Bu değişiklik, sigorta şirketleri için teknik uyum baskısını artırmıştır. Söz konusu gereksinimler Google'ın resmi Gönderici Yönergeleri sayfasında detaylı biçimde yayımlanmıştır.
Sigorta şirketleri için önerilen denetim takvimi aşağıdaki gibidir:
Mevcut altyapıyı kırmadan başlamak için önce p=none politikası uygulanır. Bu aşamada DMARC raporları toplanır ve kimlik doğrulama başarısız olan gönderici kaynakları tespit edilir. Tüm yasal göndericiler SPF ve DKIM kapsamına alındıktan sonra önce p=quarantine, ardından p=reject politikasına geçilir. Bu geçiş genellikle 3-6 ay sürer.
6098 sayılı Türk Borçlar Kanunu ve Türk Ticaret Kanunu kapsamında elektronik yollarla gönderilen poliçe belgeleri, taraflarca kabul edildiği sürece hukuken geçerlidir. Ancak sigorta şirketinin gönderimin gerçekleştiğini ispatlayabilmesi için zaman damgalı teslimat günlükleri ve mümkünse dijital imza (S/MIME veya e-imza) bulundurması önerilir.
Mevcut poliçe sahiplerine gönderilen prim son ödeme tarihi hatırlatmaları, 6563 sayılı Kanun'un 3. maddesi uyarınca ticari elektronik ileti sayılmaz; zira bu iletiler akdi yükümlülüğe (sözleşme) dayanmaktadır. Bununla birlikte, hatırlatma e-postasına yenileme veya ek ürün önerisinin eklenmesi durumunda ileti ticari nitelik kazanır ve önceden onay şartı aranır.
Özel nitelikli kişisel veri kategorisinde yer alan sağlık verileri, KVKK Madde 6 uyarınca yalnızca ilgili kişinin açık rızasıyla veya kanunda öngörülen istisnalar dahilinde işlenebilir. Bu verilerin e-postayla iletilmesi zorunlu olduğunda TLS şifreli iletim ve tercihen S/MIME ile uçtan uca şifreleme kullanılmalı; iletim günlükleri en az 3 yıl saklanmalıdır.
Evet. BTK Yönetmeliği uyarınca ticari elektronik ileti gönderen tüm kuruluşlar, göndermeden önce alıcıların İYS'deki onay durumunu sorgulamak zorundadır. Sigorta şirketlerinin ticari nitelikli e-posta listelerini (kampanya, çapraz satış vb.) İYS platformuna entegre etmesi ve her iletimden önce onay kontrolü yapması gerekir.
Üretim ortamı için -all (hard fail) tercih edilmelidir. Bu ayar, listede olmayan kaynaklardan gelen e-postaların reddedilmesini sağlar. Geçiş döneminde veya tüm göndericiler tam olarak bilinmiyorsa ~all (soft fail) geçici olarak kullanılabilir, ancak kalıcı bir yapılandırma olmamalıdır.
TLS 1.2, NIST SP 800-52 Rev. 2 ve PCI DSS 4.0 kapsamında hâlâ kabul görmektedir; ancak TLS 1.3 (RFC 8446) önemli güvenlik iyileştirmeleri ve daha hızlı el sıkışma (handshake) süreci sunmaktadır. Mümkün olan en kısa sürede TLS 1.3 desteğinin etkinleştirilmesi ve TLS 1.0/1.1'in devre dışı bırakılması önerilir.
DKIM için minimum 2048-bit RSA anahtarı kullanılması gerekmektedir; 1024-bit anahtarlar artık güvensiz kabul edilmekte ve Google başta olmak üzere büyük posta sağlayıcıları tarafından reddedilebilmektedir. Alternatif olarak Ed25519 algoritması da kullanılabilir, ancak tüm alıcı sunucular tarafından henüz tam desteklenmemektedir.
KVKK'nın 12. maddesi ve Kişisel Verileri Koruma Kurulu'nun ilgili kararı uyarınca kişisel veri ihlalinin öğrenilmesinden itibaren en geç 72 saat içinde Kurul'a bildirim yapılması zorunludur. İlgili kişilerin bilgilendirilmesi ise ihlalin niteliğine ve kapsamına göre Kurul'un yönlendirmesiyle gerçekleştirilir.
Hasar dosyası kaza fotoğrafı, tapu senedi kopyası veya tıbbi belge içeriyorsa e-posta tek başına yeterli güvenliği sağlayamaz. Bu tür belgeler için şifreli dosya aktarım platformları (SFTP veya TLS destekli müşteri portalı) tercih edilmeli; zorunlu hallerde e-postayla iletilecekse S/MIME şifreleme ve parola korumalı ek kullanılmalıdır.
Reklamsız, KVKK uyumlu; kurulum ve geçiş ücretsiz, mailleri biz taşırız.