E-posta Şifreleme Nedir? TLS, MTA-STS, S/MIME ve PGP

E-posta şifreleme, iletilerin yetkisiz kişilerce okunmasını veya değiştirilmesini önleyen yöntemlerin genel adıdır ve iki katmanda ele alınır. Aktarım şifrelemesi (TLS) iletiyi sunucular arasında yolda korurken, uçtan uca şifreleme (S/MIME veya PGP) içeriği yalnızca alıcının açabileceği biçimde kilitler. Çoğu kurum için temel ihtiyaç zorunlu ve doğrulanmış aktarım şifrelemesidir; uçtan uca şifreleme ise belirli yazışmalar için tamamlayıcı bir katmandır.

Aktarım şifrelemesi: TLS ve STARTTLS nasıl çalışır?

SMTP protokolü ilk tasarlandığında şifreleme içermiyordu. Bugün sunucular arasındaki bağlantı, STARTTLS komutuyla (RFC 3207) şifreli bir oturuma yükseltilir: bağlantı düz metin olarak başlar, alıcı sunucu STARTTLS desteğini bildirir ve TLS el sıkışmasından sonra ileti şifreli kanal üzerinden aktarılır.

Kullanıcının e-posta istemcisinden sunucuya gönderimde iki yöntem bulunur:

587 numaralı port: Bağlantı düz başlar ve STARTTLS ile şifrelenir.
465 numaralı port: Bağlantı en baştan TLS ile kurulur (örtük TLS). RFC 8314, gönderim ve posta kutusu erişimi için bu yöntemi önerir.

Sunucudan sunucuya teslim ise 25 numaralı portta STARTTLS ile yapılır. Aktarım şifrelemesinin önemli bir özelliği, her bağlantıda ayrı ayrı kurulmasıdır: ileti her sunucuda şifresi çözülmüş halde işlenir ve bir sonraki bağlantıda yeniden şifrelenir. Bu nedenle TLS, iletinin yolda dinlenmesini engeller ama aradaki sunucuların içeriği görmesini engellemez.

Fırsatçı TLS ile zorunlu TLS arasındaki fark nedir?

Sunucular arası iletişim varsayılan olarak fırsatçı (opportunistic) TLS ile çalışır: karşı taraf destekliyorsa şifreleme kullanılır, desteklemiyorsa ileti düz metin olarak gönderilir. Bu modda sertifika da genellikle doğrulanmaz. Ağ yolundaki bir saldırgan, STARTTLS desteğini bildiren yanıtı silerek (STARTTLS stripping) bağlantıyı şifresiz kalmaya zorlayabilir veya sahte bir sertifika sunabilir.

Zorunlu TLS ise belirli alan adları için şifrelemeyi ve gerekirse sertifika doğrulamasını şart koşar; şartlar sağlanmazsa ileti gönderilmez, kuyrukta bekler veya geri döner. Bankalar, iş ortakları ve hassas yazışmalar için sık tercih edilir.

Yöntem	Nasıl çalışır	Güçlü yanı	Zayıf yanı
Fırsatçı TLS	Destek varsa şifreler, yoksa düz gönderir	Kurulum gerektirmez, yaygındır	Şifreleme kaldırma ve sahte sertifika saldırılarına açıktır
Zorunlu TLS	Belirli alan adları için TLS ve sertifika doğrulaması şart koşulur	Bilinen iş ortaklarıyla güçlü koruma	Her alan adı için ayrı yapılandırma gerekir
MTA-STS	Alıcı alan adı, HTTPS üzerinden yayımladığı politikayla TLS kullanımını zorunlu kılar	DNSSEC gerektirmez	İlk politika alınana kadar koruma sağlamaz
DANE	Sertifika bilgisi DNSSEC ile imzalı TLSA kayıtlarında yayımlanır	Sertifika doğrulaması DNS üzerinden güvenceye alınır	Alan adında ve gönderen tarafta DNSSEC desteği gerekir

MTA-STS ve TLS raporlaması nasıl kurulur?

MTA-STS (RFC 8461), alan adınıza posta gönderen sunuculara "bu alan adına yalnızca geçerli sertifikalı TLS bağlantısıyla teslim yap" demenizi sağlar. Kurulum üç parçadan oluşur:

_mta-sts alt alanında politika sürümünü bildiren bir TXT kaydı
mta-sts alt alan adında HTTPS ile sunulan /.well-known/mta-sts.txt politika dosyası
Başarısız teslim girişimlerini raporlamak için isteğe bağlı TLS-RPT (RFC 8460) kaydı

_mta-sts.ornek.com.tr.    TXT  "v=STSv1; id=20261011"
_smtp._tls.ornek.com.tr.  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

Politika dosyasının içeriği de kısadır:

version: STSv1
mode: testing
mx: mx1.ornek.com.tr
mx: mx2.ornek.com.tr
max_age: 86400

Politikayı önce testing modunda yayımlayıp raporları izleyin, sorun görmediğinizde enforce moduna geçin. Dosyadaki MX adları, sunucu sertifikalarındaki adlarla eşleşmelidir. Ayrıntılı kurulum için MTA-STS nedir yazımıza bakabilirsiniz.

DANE ne sağlar?

DANE (RFC 7672), alıcı posta sunucusunun sertifika veya açık anahtar bilgisini DNS'te TLSA kaydı olarak yayımlar ve bu kayıtların DNSSEC ile imzalanmasını şart koşar. Gönderen sunucu, bağlandığı sunucunun sertifikasını bu kayıtla karşılaştırarak sahte sertifikaları reddeder. Güçlü bir yöntemdir, ancak alan adınızın ve DNS sağlayıcınızın DNSSEC desteği ile sertifika yenilemelerinde TLSA kayıtlarının dikkatle güncellenmesini gerektirir.

Uçtan uca şifreleme: S/MIME ve PGP

Uçtan uca şifreleme, içeriği gönderenin cihazında şifreler ve yalnızca alıcının özel anahtarıyla açılabilir hale getirir. Aradaki sunucular, posta sağlayıcınız dahil, içeriği okuyamaz. İki yaygın standart vardır:

S/MIME (RFC 8551): Sertifika otoritelerinin verdiği X.509 sertifikalarını kullanır. Kurumsal e-posta istemcilerinin çoğunda yerleşik desteği vardır; dijital imzayla gönderenin kimliğini ve iletinin bütünlüğünü de kanıtlar.
OpenPGP (RFC 9580): Anahtar çiftlerini kullanıcılar kendileri üretir ve dağıtır; güven, merkezi bir otorite yerine anahtarların doğrulanmasına dayanır. Teknik ekiplerde ve açık kaynak topluluklarında yaygındır.

Kriter	TLS (aktarım)	S/MIME	OpenPGP
Neyi korur	Sunucular arası bağlantıyı	İleti içeriğini ve ekleri	İleti içeriğini ve ekleri
Kurulum	Sunucu tarafında, kullanıcıya görünmez	Her kullanıcıya sertifika gerekir	Her kullanıcı anahtar çifti üretir
Anahtar yönetimi	Sunucu sertifikaları	Sertifika otoritesi veya kurumsal PKI	Kullanıcı tarafında, dağıtık
Alıcı tarafında gereksinim	Karşı sunucunun desteği yeterli	Alıcının sertifikası bilinmeli	Alıcının açık anahtarı bilinmeli
İçerik taraması	Ağ geçidi içeriği tarayabilir	Anahtar olmadan taranamaz	Anahtar olmadan taranamaz
Tipik kullanım	Tüm kurumsal trafik	Kurumsal ve düzenlemeye tabi yazışmalar	Teknik ekipler, bireysel kullanıcılar

Uçtan uca şifrelemenin en büyük zorluğu anahtar yönetimidir. Çalışan ayrıldığında veya anahtar kaybolduğunda şifreli yazışmalara erişim sorunu çıkabilir; bu yüzden kurumsal kullanımda anahtar yedekleme ve kurtarma politikası baştan tasarlanmalıdır.

Sertifikalarda nelere dikkat edilmeli?

MX sunucularının sertifikaları, MX kaydındaki ana bilgisayar adlarıyla eşleşmelidir; MTA-STS bu eşleşmeyi doğrular.
Ara sertifikalar dahil tam zincir sunulmalıdır.
Yenileme otomatikleştirilmeli ve bitiş tarihleri izlenmelidir; süresi dolan bir sertifika, zorunlu TLS kullanan iş ortaklarından gelen postayı durdurabilir.
TLS 1.0 ve 1.1 kapatılmalı, en az TLS 1.2 kullanılmalıdır; eski sürümler RFC 8996 ile kullanımdan kaldırılmıştır.

E-posta güvenlik ağ geçidi neyi yapabilir, neyi yapamaz?

Bir mail gateway aktarım şifrelemesinde önemli rol oynar, ancak sınırlarını bilmek gerekir. Ağ geçidi kendi üzerinden geçen bağlantılarda TLS kullanabilir, geçerli bir sertifika sunabilir, şifreleme kullanımını kayıt altına alabilir ve arşivlenen iletileri depolamada şifreli tutabilir.

Buna karşılık S/MIME veya PGP ile şifrelenmiş içeriği anahtar olmadan tarayamaz; bu tür iletilerin ve parolalı arşivlerin içeriği filtrelerce incelenemez. İletinin kendisinden sonraki sunucular arasında şifreli kalmasını garanti edemez, posta kutusunda duran iletinin şifrelenmesi de posta sağlayıcısının sorumluluğundadır. Örneğin MXZilla, arşivlenen e-postaları depolamada şifreli tutar; şifreli ZIP arşivlerinde bile içerideki dosya adlarını okuyarak yasaklı uzantıları engelleyebilir.

Kişisel veri içeren yazışmalarda şifreleme, KVKK'nın veri güvenliğine ilişkin teknik tedbirlerinin bir parçası olarak değerlendirilebilir; arşiv tarafı için KVKK e-posta arşivleme yazımıza bakabilirsiniz (bu bilgi hukuki danışmanlık değildir, değerlendirme için bir hukukçuya danışın).

Alan adınızın SPF, DKIM, DMARC ve MX yapılandırmasını ücretsiz güvenlik kontrolü ile görebilir, şifreli arşiv içeren seçenekleri paketler bölümünde inceleyebilirsiniz.

Sık sorulan sorular

TLS kullanıyorsam e-postalarım uçtan uca şifreli mi?

Hayır. TLS iletiyi yalnızca iki sunucu arasındaki bağlantı süresince korur; ileti her sunucuda şifresi çözülmüş olarak işlenir ve posta kutusunda da bu şekilde durabilir. İçeriğin yalnızca alıcı tarafından okunabilmesi için S/MIME veya PGP gibi uçtan uca şifreleme gerekir.

STARTTLS ile 465 numaralı port arasındaki fark nedir?

STARTTLS, düz metin olarak başlayan bir bağlantıyı sonradan şifreli hale getirir ve genellikle 25 ile 587 numaralı portlarda kullanılır. 465 numaralı portta ise bağlantı en baştan TLS ile kurulur. Doğru yapılandırıldığında iki yöntem benzer güvenlik sağlar; RFC 8314 ise gönderimde zamanla örtük TLS'e geçilmesini önerir.

MTA-STS mi DANE mi kullanmalıyım?

Alan adınızda DNSSEC yoksa MTA-STS daha kolay uygulanabilir bir başlangıçtır. DNSSEC kullanıyorsanız DANE güçlü bir ek koruma sağlar ve iki yöntem birlikte de yayımlanabilir. Her iki durumda da TLS-RPT raporlarını açmak sorunları erken görmenizi sağlar.

S/MIME sertifikası nereden alınır?

S/MIME sertifikaları ticari sertifika otoritelerinden alınabilir veya büyük kurumlar kendi iç sertifika altyapılarıyla üretebilir. Sertifika kullanıcının e-posta adresine bağlıdır ve e-posta istemcisine yüklenir. Karşı tarafın size şifreli posta gönderebilmesi için önce imzalı bir ileti göndererek sertifikanızı paylaşmanız gerekir.

Şifreli e-postalar spam filtresinden nasıl geçer?

Uçtan uca şifrelenmiş içerik anahtar olmadan taranamaz; filtre yalnızca gönderen, başlıklar ve itibar gibi bilgilere bakabilir. Bu nedenle bazı kurumlar dış kaynaklı şifreli iletileri veya parolalı arşivleri karantinaya alır ya da ek kontrol uygular. Zararlı ek politikaları için zararlı e-posta eki engelleme yazımıza göz atabilirsiniz.