Sektörel·
24 Nisan 2026
Bir yazılım şirketinde geliştirici ekibi büyüdükçe, e-posta altyapısı da karmaşıklaşır. Transaksiyonel bildirimler, CI/CD pipeline uyarıları, müşteri destek talepleri ve pazarlama kampanyaları farklı teknik gereksinimler doğurur. Yanlış yapılandırılmış bir e-posta ortamı; mesajların spam klasörüne düşmesine, yasal yükümlülüklerin ihlal edilmesine ve geliştirici üretkenliğinin azalmasına neden olur. Bu rehber, yazılım şirketlerinin e-posta altyapısını doğru kurması için gereken teknik ve yasal çerçeveyi kapsamlı biçimde ele alır.
Tek bir e-posta sunucusu veya servis sağlayıcısı üzerinden tüm e-posta türlerini göndermek, kısa vadede pratik görünse de uzun vadede ciddi sorunlar yaratır. Pazarlama kampanyalarından kaynaklanan şikayetler (spam complaint), transaksiyonel e-postaların teslim oranını (deliverability) doğrudan düşürür. Örneğin, bir kullanıcı "şifremi unuttum" e-postasını alamazsa doğrudan gelir kaybı anlamına gelir.
İnternet Mühendisliği Görev Gücü'nün (IETF) yayımladığı RFC 5321 (SMTP protokolü) ve RFC 5322 (e-posta mesaj biçimi), e-posta iletiminin teknik temellerini tanımlar. Bu standartlar gönderici kimlik doğrulamasının altyapısal önemini ortaya koyar. Buna ek olarak, Google ve Yahoo'nun Şubat 2024'te uygulamaya koyduğu gönderici gereksinimleri (Bulk Sender Guidelines), günlük 5.000'den fazla mesaj gönderen tüm kuruluşlar için SPF, DKIM ve DMARC yapılandırmasını zorunlu kılmıştır.
SPF (Sender Policy Framework) — RFC 7208'de tanımlanmıştır. Alan adınızın DNS bölgesine eklenen bir TXT kaydı olup hangi IP adreslerinin veya sunucuların o alan adı adına e-posta gönderebileceğini belirtir. Örnek bir kayıt:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 ~allBuradaki ~all (softfail) mekanizması, listede olmayan kaynaklardan gelen mesajları tamamen reddetmek yerine şüpheli olarak işaretler. Üretim ortamında daha sıkı politika için -all (hardfail) tercih edilebilir; ancak bu değişiklik öncesinde DMARC raporlarının dikkatle incelenmesi gerekir.
DKIM (DomainKeys Identified Mail) — RFC 6376'da tanımlanmıştır. E-posta başlıklarına ve gövdesine, gönderen sunucunun özel anahtarıyla imzalanmış bir dijital imza ekler. Alıcı sunucu, gönderenin DNS bölgesinde yayımlanan genel anahtar ile bu imzayı doğrular. Minimum 2048 bit RSA veya Ed25519 anahtar uzunluğu önerilir.
DMARC (Domain-based Message Authentication, Reporting and Conformance) — RFC 7489'da tanımlanmıştır. SPF ve DKIM kontrollerinin başarısız olması durumunda alıcı sunucunun ne yapacağını (none, quarantine veya reject) ve raporların nereye gönderileceğini belirler. Örnek bir DMARC kaydı:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@sirketiniz.com; ruf=mailto:dmarc-forensics@sirketiniz.com; pct=100; adkim=s; aspf=sPolitikanın none modunda başlaması, mevcut e-posta akışlarını etkilemeden raporlama yapılmasını sağlar. Birkaç haftalık rapor analizi sonrasında politika kademeli olarak quarantine ve ardından reject seviyesine yükseltilebilir.
Yazılım şirketleri için önerilen mimari, üç temel katmana dayanır. Aşağıdaki tablo her katmanın özelliklerini özetlemektedir:
| Katman | Kullanım Amacı | Gönderim Yöntemi | IP Politikası | Uyum Gereksinimi |
|---|---|---|---|---|
| Transaksiyonel | Şifre sıfırlama, sipariş onayı, bildirimler | Uygulama API'si (SMTP veya HTTP API) | Özel IP havuzu | RFC 5321, 6563 ETK Md. 3 |
| Dahili / Operasyonel | CI/CD uyarıları, izleme alarmları, ekip bildirimleri | SMTP relay veya webhook | Paylaşımlı veya özel IP | Şirket içi veri politikası |
| Pazarlama | Bültenler, kampanyalar, onboarding dizileri | E-posta pazarlama platformu | Isınmış paylaşımlı IP | 6563 ETK, 6698 KVKK, CAN-SPAM |
Bu üç katmanı birbirinden ayırmanın pratik yolu, farklı alt alan adları (subdomain) kullanmaktır. Örneğin notifications.sirketiniz.com transaksiyonel gönderimler için, mail.sirketiniz.com pazarlama için ayrılabilir. Her alt alan adının bağımsız SPF, DKIM ve DMARC kayıtları olmalıdır.
Modern yazılım şirketlerinde e-posta, yalnızca kullanıcılara gönderilen bir araç değil; aynı zamanda geliştirme süreçlerinin ayrılmaz bir parçasıdır. Derleme hataları, başarısız testler, güvenlik açığı taramaları ve deploy sonuçları tipik olarak e-posta veya webhook üzerinden bildirilir.
Bu tür dahili bildirimlerin yönetimi için iki temel yaklaşım vardır:
Geliştirici testleri sırasında gerçek kullanıcı adreslerine e-posta gönderilmemesi kritik önem taşır. Bu amaçla MailHog, Mailtrap veya benzer yerel e-posta yakalama araçları kullanılmalıdır. Bu araçlar, SMTP protokolü aracılığıyla gelen tüm mesajları gerçekten iletmek yerine yerel bir arayüzde gösterir.
Türkiye'deki yazılım şirketleri için e-posta altyapısı yalnızca teknik bir mesele değildir; aynı zamanda yasal bir zorunluluktur.
6698 Sayılı Kişisel Verilerin Korunması Kanunu (KVKK), e-posta adresleri gibi kişisel verilerin işlenmesini düzenler. Madde 4 uyarınca kişisel veriler yalnızca belirli, açık ve meşru amaçlarla işlenebilir. Pazarlama amaçlı e-posta göndermek için ilgili kişinin açık rızası (Madde 5) veya kanunda sayılan diğer hukuki sebeplerden biri gereklidir. Ayrıca Madde 12 kapsamında veri güvenliğinin sağlanması; e-posta listelerinin şifreli ortamlarda saklanması, yetkisiz erişime karşı korunması ve saklama sürelerinin belirlenmesi anlamına gelir.
6563 Sayılı Elektronik Ticaretin Düzenlenmesi Hakkında Kanun (ETK) ve bu kanuna dayalı olarak çıkarılan Ticari İletişim ve Ticari Elektronik İletiler Hakkında Yönetmelik (son değişiklik: Resmî Gazete 04.01.2020, Sayı 30998), ticari amaçlı elektronik ileti gönderimini doğrudan düzenler. Temel yükümlülükler şunlardır:
Bilgi Teknolojileri ve İletişim Kurumu (BTK), ETK kapsamındaki şikayetleri inceler ve ihlaller için idari para cezası uygulayabilir. 2024 yılı itibarıyla güncel ceza tutarları için BTK'nın resmi duyurularının takip edilmesi önerilir.
Teknik altyapı ne kadar iyi kurulursa kurulsun, e-posta listesinin kalitesi gönderici itibarını (sender reputation) doğrudan etkiler. Liste hijyeni için uygulanması gereken temel pratikler şunlardır:
Yazılım geliştirme sürecinde e-posta işlevlerinin test edilmesi, gerçek kullanıcı adresleri kullanılmadan güvenli biçimde yapılmalıdır. Bunun için iki yaklaşım yaygın olarak kullanılır:
Yerel SMTP sunucusu (MailHog): Docker üzerinde kolayca çalıştırılabilir ve geliştirici ortamındaki tüm çıkan e-postaları yakalar. Uygulama kodu değiştirilmeden SMTP yapılandırması yerel sunucuya yönlendirilir.
Sandbox servisleri (Mailtrap.io): Bulut tabanlı test ortamları sunar; farklı e-posta istemcilerinde render testi, spam skoru analizi ve HTML doğrulama gibi ek özellikler içerir. Ekip üyeleri aynı gelen kutusunu paylaşabilir.
Staging ortamında ise gerçek e-posta gönderimi yapılıyorsa, domain bazlı filtreleme ile yalnızca şirket alan adından kayıtlı test hesaplarına teslim yapılması sağlanmalıdır. @test.sirketiniz.com gibi özel bir alt alan adı bu amaç için ayrılabilir.
Teknik olarak her biri bağımsız çalışabilir; ancak Google ve Yahoo'nun Şubat 2024'te yürürlüğe giren Bulk Sender Guidelines kuralları, günlük 5.000'den fazla mesaj gönderen alanlar için üçünü de zorunlu kılmaktadır. Daha az hacimde gönderim yapılsa bile DMARC olmadan SPF ve DKIM'in sağladığı koruma eksik kalır; alan adı sahteciliğine (spoofing) karşı tam koruma ancak üçünün birlikte kullanılmasıyla elde edilir.
Teknik olarak mümkündür ancak önerilmez. Pazarlama kampanyalarından gelen spam şikayetleri, aynı alan adından gönderilen transaksiyonel e-postaların teslim oranını olumsuz etkiler. En iyi uygulama, her amaç için ayrı alt alan adı ve ayrı IP havuzu kullanmaktır.
6698 sayılı KVKK'nın 8. maddesi uyarınca kişisel verilerin üçüncü taraflara aktarılması, ilgili kişinin açık rızasını veya Madde 5'te sayılan diğer hukuki sebeplerin varlığını gerektirir. E-posta listesinin üçüncü bir pazarlama şirketiyle paylaşılması, büyük olasılıkla açık rıza gerektiren bir veri aktarımı kapsamına girer. Ayrıca bu aktarımın KVKK aydınlatma metninde önceden belirtilmesi gerekir.
Evet. ETK'nın 8. maddesi ve ilgili yönetmelik, ticari elektronik iletilerin her birinde alıcının kolayca abonelikten çıkabileceği bir mekanizmanın bulunmasını zorunlu kılmaktadır. Bu bağlantı işlevsel olmalı ve alıcının talebinin en geç 3 iş günü içinde yerine getirilmesi gerekmektedir.
Çoğu modern CI/CD aracı (GitHub Actions, GitLab CI, Jenkins) yerleşik bildirim mekanizmalarına sahiptir. E-posta tercih ediliyorsa, dahili bildirimlerin ayrı bir alt alan adı ve SMTP relay üzerinden gönderilmesi önerilir. Alternatif olarak Slack veya Teams gibi anlık mesajlaşma araçlarına webhook entegrasyonu, geliştirici üretkenliği açısından daha verimli olabilir.
Google Postmaster Tools (postmaster.google.com), Gmail'e gönderilen e-postaların teslim oranı, spam oranı ve alan adı itibarı hakkında ücretsiz raporlar sunar. Microsoft'un SNDS (Smart Network Data Services) aracı da Outlook/Hotmail'e yapılan gönderimler için benzer veriler sağlar. Bu araçlara ek olarak MX Toolbox üzerinden kara liste taraması düzenli olarak yapılmalıdır.
Zorunluluk standartlara göre değişir; ancak RFC 8314, posta istemcileri ile sunucular arasındaki iletişimde TLS kullanımını açıkça önermektedir. Sunucular arası iletimde ise STARTTLS geniş çapta desteklenmektedir. Google ve diğer büyük sağlayıcılar, TLS desteklemeyen sunuculardan gelen bağlantıları giderek daha fazla kısıtlamaktadır. Minimum TLS 1.2, tercihan TLS 1.3 kullanılmalıdır.
DMARC raporları XML formatında gelir ve doğrudan okunması güçtür. dmarcian, Postmark'ın DMARC Digests aracı veya açık kaynaklı parsers aracılığıyla bu raporlar görselleştirilebilir. Raporlarda dikkat edilmesi gereken başlıca metrikler: SPF ve DKIM başarı oranları, yetkisiz kaynaklardan yapılan gönderimler ve disposition (ne yapıldığı) değerleridir.
Türk mevzuatında genel bir e-posta arşivleme zorunluluğu bulunmamakla birlikte, bazı sektörel düzenlemeler (bankacılık, sermaye piyasaları gibi) farklı yükümlülükler getirebilir. 6563 sayılı ETK kapsamında ticari elektronik ileti için alınan onayların 3 yıl saklanması zorunludur. Bunun yanı sıra KVKK'nın 12. maddesi uyarınca işlenen kişisel veri niteliğindeki içerikler için uygun teknik ve idari tedbirlerin alınması gerekmektedir.
Birkaç katmanlı önlem alınması önerilir: uygulama seviyesinde ortam değişkeni (APP_ENV=development) kontrolü; e-posta gönderim servisi için staging kimlik bilgilerinin üretim kimlik bilgilerinden ayrı tutulması; ve MailHog gibi yerel SMTP yakalama araçlarının kullanılması. CI/CD pipeline'larında e-posta gönderen servisler için sandbox modunun zorunlu kılınması da ek bir güvence sağlar.
Reklamsız, KVKK uyumlu; kurulum ve geçiş ücretsiz, mailleri biz taşırız.