E-posta şifreleme, bir mesajın içeriğini yetkisiz kişilerin okuyamayacağı hâle getiren yöntemlerin genel adıdır. Şirketler için üç katmanı vardır: sunucular arasında taşıma sırasında şifreleme (TLS), sunucuda saklarken şifreleme ve yalnızca alıcının açabildiği uçtan uca şifreleme (S/MIME, OpenPGP). Doğru kurgu, her katmanı hangi veri için kullanacağınızı belirlemektir.
E-posta şifreleme nedir, şirketler neden yanlış anlıyor?
Çoğu yöneticinin kafasındaki soru "Mailimiz şifreli mi?" sorusudur; cevap da genellikle "Evet, sağlayıcımız TLS kullanıyor" olur. Bu cevap doğru ama eksiktir. TLS, mesajı iki sunucu arasındaki yolda korur; mesaj karşı sunucuya ulaştığında, alıcının kutusunda ve iki taraftaki yedeklerde açık metin olarak durabilir.
Günlük işte bunun karşılığı somuttur. İnsan kaynakları bir adayın sağlık raporunu, muhasebe bir müşterinin kimlik fotokopisini, hukuk ekibi bir sözleşme taslağını ek olarak gönderir. Karşı tarafın sunucusu şifreli bağlantıyı desteklemiyorsa mesaj sessizce şifresiz gidebilir ve kimse bunu fark etmez.
İkinci yanılgı, şifrelemeyi tek başına bir güvenlik önlemi sanmaktır. Saldırgan bir çalışanın parolasını ele geçirdiyse, şifreleme mesajları ona açılmış hâlde sunar. Bu yüzden şifreleme, kurumsal parola güvenliği ve çok faktörlü kimlik doğrulama ile birlikte düşünülmelidir.
Şifrelemeyi ertelemenin maliyeti
Şifreleme eksikliği çoğu zaman bir ihlal yaşandığında görünür hâle gelir. Uluslararası veriler, kurumların önemli bir kısmının bu konuda hazırlıksız olduğunu gösteriyor:
IBM'in 2026 araştırmasında ihlal yaşayan kurumların yalnızca %37'si hassas verileri hem saklamada hem aktarımda şifrelediğini söyledi. (IBM 2026 Cost of a Data Breach basın bülteni)
İhlalin bedeli de küçük değil. IBM Cost of a Data Breach Report 2026 verisine göre bir veri ihlalinin küresel ortalama maliyeti, önceki yıla göre %12 artışla rekor seviye olan 4,99 milyon dolara ulaştı. Bu rakam farklı ülke ve sektörlerden kurumların küresel ortalamasıdır; bir KOBİ'nin toplam bedeli daha küçük olsa da hukuk, müşteri kaybı ve itibar kalemleri aynı mantıkla işler.
Türkiye'de ise mevzuat konuyu açıkça ele alıyor. Kişisel Verileri Koruma Kurulu'nun 31.01.2018 tarihli ve 2018/10 sayılı kararı, özel nitelikli kişisel verilerin e-posta ile aktarılması gerekiyorsa bunun "şifreli olarak kurumsal e-posta adresiyle veya Kayıtlı Elektronik Posta (KEP) hesabı kullanılarak" yapılmasını istiyor. Bir ihlal olduğunda ise veri sorumlusunun durumu öğrendiği andan itibaren en geç 72 saat içinde Kurul'a bildirim yapması gerekir; süreci KVKK veri ihlali 72 saat yazısında anlattık.
E-posta şifreleme türleri: hangisi neyi korur?
Aşağıdaki tablo, kurumsal e-postada kullanılan yöntemleri korudukları alan ve gerektirdikleri çaba açısından karşılaştırır:
| Yöntem | Neyi korur? | Alıcıdan ne ister? | Tipik kullanım |
|---|---|---|---|
| STARTTLS (fırsatçı TLS) | Sunucular arası yolu | Hiçbir şey; destek yoksa şifresiz gidebilir | Tüm günlük yazışma |
| MTA-STS / DANE | TLS'in zorunlu tutulmasını | Alıcı alan adında uygun kayıt | Alan adınıza gelen maili korumak |
| Sunucuda saklama şifrelemesi | Diskteki kutu ve arşivi | Hiçbir şey | Sağlayıcı ve yedek tarafı |
| S/MIME | İçeriği uçtan uca | Sertifika ve karşılıklı anahtar değişimi | Hukuk, finans, sağlık yazışmaları |
| OpenPGP | İçeriği uçtan uca | Anahtar yönetimi | Teknik ekipler, sınırlı muhatap |
| Parolalı ek / güvenli bağlantı | Yalnızca eki | Parolanın ayrı kanaldan iletilmesi | Tek seferlik hassas belge |
Tablodan çıkan sonuç şu: TLS herkes için zorunlu taban, uçtan uca şifreleme ise seçilmiş yazışmalar için bir üst katmandır. Her maili S/MIME ile göndermeye çalışan kurumlar çoğu zaman anahtar ve sertifika yönetiminin yükü altında zorlanır. Taşıma katmanının kimlik doğrulama kayıtlarıyla birlikte nasıl çalıştığını SPF, DKIM ve DMARC rehberinde ayrıca ele aldık.
Kurumsal e-posta şifreleme için 7 adımlık çerçeve
- Veriyi sınıflandırın. Hangi yazışmalar özel nitelikli kişisel veri, ticari sır ya da finansal bilgi içeriyor? Sağlık raporu, bordro, sözleşme ve teklif dosyaları genellikle ilk listeye girer. Aynı sınıflandırma, hangi verinin yapay zeka araçlarına girilemeyeceğini de belirler; bkz. ChatGPT ve şirket verisi güvenliği.
- Taşıma katmanını ölçün. Alan adınız için MTA-STS (RFC 8461) politikası ve TLS raporlaması (TLS-RPT, RFC 8460) yayınlayın. Raporlar, alan adınıza mail gönderen sunucuların hangilerinin şifreli bağlantı kurmakta sorun yaşadığını gösterir. Giden taraf için de sağlayıcınızdan, karşı sunucuya TLS kurulamadığında mesajın nasıl gönderildiğini öğrenin.
- Saklama şifrelemesini sorun. Sağlayıcınıza posta kutularının, arşivin ve yedeklerin diskte şifreli tutulup tutulmadığını ve anahtarların kimde olduğunu yazılı olarak sorun.
- Uçtan uca şifrelemeyi dar bir grupla başlatın. S/MIME'ı önce hukuk, İK ve finans gibi hassas yazışma yapan ekiplerde deneyin; sertifika yenileme ve çalışan ayrılığı süreçlerini baştan yazın. Hasta verisiyle çalışan sağlık kuruluşlarında tıbbi rapor gönderen birimler doğal pilot grubudur.
- Ekleri mailde dolaştırmayın. Hassas belgeyi ek yerine yetki kontrollü bir dosya alanında tutup yalnızca ilgili kişiye erişim verin. Bu yaklaşımı dosya paylaşım yetkilendirme yazısında ayrıntılandırdık.
- Kimliği güçlendirin. Şifreli bir kutu, ele geçirilmiş parolayla açılır. Çok faktörlü doğrulama, oturum takibi ve ayrılan çalışanın erişiminin hemen kapatılması şifrelemenin ön şartıdır.
- Arşivi ve saklama süresini birlikte planlayın. Şifreli mesajların yıllar sonra da okunabilmesi için anahtarların saklanması gerekir; bu konu e-posta arşivleme ve KVKK politikanızın parçası olmalıdır.
Uçtan uca şifrelemenin pratik sınırları
S/MIME ile şifrelenmiş bir mesajı sunucu okuyamaz; bu, istenen korumadır ama bazı bedelleri vardır. Spam ve zararlı yazılım filtresi içeriği tarayamaz, arşivde arama zorlaşır ve alıcının sertifikası yoksa mesaj şifreli olarak gönderilemez. Bu yüzden uçtan uca şifrelemeyi, muhatapları belli ve sayıca az olan yazışmalarla sınırlı tutmak daha gerçekçidir.
Parolalı ek gönderirken sık yapılan hata
Parolalı ZIP ya da PDF göndermek yaygın bir yöntemdir, ancak parolanın aynı mail zincirinde ikinci bir mesajla iletilmesi korumayı ortadan kaldırır. Parolayı telefon ya da SMS gibi ayrı bir kanaldan verin ve her gönderimde farklı parola kullanın. Resmî ve delil niteliği gereken gönderimler için ise KEP (kayıtlı elektronik posta) daha uygun bir kanaldır.
Digital Bridge'de e-posta şifrelemeyi nasıl ele alıyoruz?
Şifrelemeyi bir yazılım ayarı olarak değil, veri akışının bir parçası olarak ele alıyoruz. Çalışma sırası genellikle şöyledir:
- Keşif ve ihtiyaç analizi. Siber güvenlik danışmanlığı kapsamında alan adınızın MX, SPF, DKIM, DMARC ve MTA-STS durumunu, sağlayıcınızın saklama şifrelemesini ve hassas eklerin hangi ekiplerden çıktığını inceliyoruz.
- Mevzuat eşlemesi. KVKK uyum danışmanlığı ile hangi yazışmanın özel nitelikli veri içerdiğini ve hangi kanaldan gönderilmesi gerektiğini belirliyor, bunu KVKK uyum sürecinizin teknik tedbirler bölümüne işliyoruz.
- Pilot. Uçtan uca şifrelemeyi ya da yetki kontrollü dosya paylaşımını tek bir ekiple, örneğin İK ile, birkaç hafta deniyor ve çalışanların gerçekten kullanıp kullanmadığını ölçüyoruz.
- Altyapı ve entegrasyon. E-posta ya da dosya altyapınızı değiştirecekseniz geçişi bulut geçiş ve altyapı danışmanlığı kapsamında planlıyor, yapılacak işleri kurum içi ekibinizle paylaşıyoruz.
Smart360 bu çerçevede ne sağlar?
Ürün ailemiz Smart360, şifreleme çerçevesindeki kimlik ve erişim adımlarını tek panelde ve tek kimlikte toplar. SmartMail'de posta kutusu parolalarını sistem üretir ve AES-256-GCM ile şifreli saklar; bu parolalar çalışanlara dağıtılmaz, çalışanlar tek kimlikle (SmartID) giriş yapar. Oturumlar cihaz bilgisiyle listelenir ve uzaktan kapatılabilir; parola değiştiğinde tüm oturumlar kapanır. Ayrılan çalışanın erişimi ise tek işlemle bütün ürünlerde kapanır.
Her kurumun verisi her ürün için ayrı veritabanında tutulur; belgeler ve mail arşivi S3 uyumlu nesne depolamada saklanır. Hassas bir eki mail zincirinde dolaştırmak yerine SmartMail'e gelen eki tek tıkla SmartFiles alanına kaydedebilir, orada sekiz ayrı yetkiyle yalnızca ilgili kişiye açabilirsiniz. SmartFiles'ın indirme ve önizleme bağlantıları dakikalar içinde geçersizleşir; kopyalanıp başka yere iletilen bir bağlantı sonradan işe yaramaz.
Gelen tarafta SmartMail, her maili kendi SPF, DKIM, DMARC ve PTR doğrulamasıyla birlikte 12 sinyalle değerlendirir ve gerekçesi yazılı bir rapor üretir. Şifreleme mesajın yolda okunmasını engeller; bu değerlendirme ise şifreli ama sahte bir mesajın güvenilir sanılma riskini azaltır.
Sonraki adım
Başlamak için tek bir soru yeterli: Kurumunuzdan son bir ayda hangi hassas belgeler ek olarak çıktı ve hangi kanaldan? Bu listeyi hazırlayıp iletişim sayfamızdan bize ulaşın; alan adınızın taşıma şifrelemesi durumunu birlikte inceleyelim ve size uygun katmanları belirleyelim. Diğer rehberler için Kurumsal E-posta ve Belge rehberlerine, altyapı seçimi için kurumsal e-posta nasıl seçilir yazısına göz atabilirsiniz.