Altyapı 7 dk okuma Buğra Han Öksüz

Self-hosted Mail: SaaS yerine kendi altyapımız neden?

Hanbisan kurumsal mail altyapısını SaaS yerine kendi tarafımızda kurduk. Karar gerekçesi, seçim kriterleri, kurulum mimarisi ve mail-tester 10/10 ile Gmail Inbox delivery sonuçları — yapan birinin notları.

Karar: Bağımlılığı sıfırlamak

Transactional email için pazardaki SaaS çözümleri (Resend, Postmark, SendGrid, Amazon SES) gerçekten kolay. 5 dakikada API key alıyor, fiyat tarifesi makul, deliverability ortalama üstü. Sorun ortaya çıktığında ortaya çıkıyor: bir SaaS gönderici reputation düşüşü senin yaptığın bir hata değilken bile seni etkiliyor; pricing tier sınırına çarpınca tedarikçi switch'i 2 hafta sürüyor; bazı sağlayıcılar tek bir politika ihlalinde hesap kapatıyor.

Hanbisan için belirleyici şart şuydu: iletisim@hanbisan.com'dan gönderilen bir mail, gönderim altyapısını kim sağlıyor olursa olsun, alıcının Inbox'ına düşmeli ve bu davranış 5 yıl sonra da aynı kalmalı. SaaS'ta bu garanti yok — sağlayıcının IP havuzu, politikası, hatta varlığı değişebilir.

Maliyet karşılaştırması

  • Resend Pro: $20/ay, 50K mail/ay üst sınır
  • Postmark Outbound: $15/ay, 10K mail/ay
  • SES + DIY DKIM/SPF/DMARC: $0,10/1000 mail (orta-ölçek için aylık $5)
  • Self-host: $0/ay marjinal (mevcut kapasitenin unutulmuş köşesi)

Maliyet ana motivasyon değildi — kontrol idi. Ama sıfır marjinal mail başına maliyet, gelecek müşteri onboarding'lerinde (welcome mail, password reset, invoice) hiç düşünmeden kullanmak demek.

Hangi mail engine?

Self-hosted mail dünyasında üç gerçek seçenek var:

  • Klasik stack: 25 yıllık kanıtlanmış kombinasyon, ama 4 ayrı servisi yapılandırmak ve sürdürmek devasa bir devops yükü.
  • All-in-one paket çözüm: Tek dağıtım, hızlı kurulum, ama "siyah kutu" — debug etmek zor.
  • Modern, tek-binary mail engine: SMTP + IMAP + JMAP ve DKIM/SPF/DMARC tek yerde, konfig deklaratif, web admin var. Olgunluk daha kısa ama tek operasyonel yüzeyi kontrol etmek değer.

Hanbisan için kararımız modern tek-binary tarafında oldu. Üç gerçek sebep:

  1. Tek binary, tek dependency. Container olarak deploy ettik — kurulumdan 30 dakika sonra çalışıyordu.
  2. JMAP desteği yerleşik. Bugün IMAP'le yetiniyoruz ama gelecekte modern client entegrasyonu için kapı açık.
  3. Performans. Aynı altyapıda paralel olarak web, realtime servisler, yönetim katmanı, mail — hepsi rahatça koşuyor.

Mimari: tek altyapı, çok servis

┌────────────────────────────────────────────────────────────────┐
│  Reverse proxy + container orchestration                       │
├────────────────────────────────────────────────────────────────┤
│  Web sunucu        → kurumsal site + admin paneli              │
│  Realtime canvas   → BetterCAD multi-user                      │
│  Mail sunucu       → SMTPS + IMAPS + JMAP                      │
│  Yönetim katmanı   → orchestration dashboard                   │
└────────────────────────────────────────────────────────────────┘

Tüm servisler kendi altyapımızda container olarak çalışıyor. Mail için DNS proxy kapalı, yalnızca DNS only — mail için PTR/HELO uyumu gerekli.

DKIM: çift imza, çift güvence

Mail authentication için minimum şart SPF + DKIM + DMARC üçlüsü. Tek RSA imzası yerine RSA + Ed25519 çift imza ekledik.

  • RSA-2048: tüm receiver'lar destekler, geniş uyum.
  • Ed25519: 2017'den beri RFC 8463 ile DKIM standartı, modern. Kuantum sonrası geçişte avantajlı, key rotation kolay.

Çift imza demek, alıcı sunucu hangi algoritmayı destekliyorsa onu doğrulayacak. İmzalardan biri başarısız olsa bile diğeri kurtarır.

DNS records (örnek pattern)

# SPF — sadece mail alt-domain'inden gönderim
example.com.    TXT  "v=spf1 a:mail.example.com -all"

# DKIM — RSA
selector1._domainkey.example.com.   TXT  "v=DKIM1; k=rsa; p=…"

# DKIM — Ed25519
selector2._domainkey.example.com.   TXT  "v=DKIM1; k=ed25519; p=…"

# DMARC — başlangıçta p=none, raporları topla
_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

# MTA-STS — TLS zorunlu
_mta-sts.example.com. TXT  "v=STSv1; id=20260509"
mta-sts.example.com.  CNAME example.com.
Pratik not DMARC'ı ilk gün p=quarantine veya p=reject yapmayın. 1 hafta p=none ile gerçek trafiği gözlemleyin — yanlış yapılandırılmış legacy bir mail relay'iniz varsa raporlarda görürsünüz, mailler dropping olmadan düzeltirsiniz.

İlk gönderim: mail-tester 10/10

Mail-tester.com transactional mail'inizin gönderim kalitesini ölçen bir araç. Mail'i test adresine yolluyorsunuz, dakikalar içinde tüm authentication checks (SPF, DKIM, DMARC, blacklist, content score) skoru veriyor.

İlk testte 10/10. SPF pass, DKIM pass (RSA + Ed25519 ikisi de), DMARC aligned, IP temiz, content spam kelime yok. Hanbisan brand HTML template'i renderable.

10/10
mail-tester
2/2
DKIM imza
100%
SPF aligned
0
DNSBL hit

Gmail Inbox: warm-up gerçeği

mail-tester 10/10 alındı, ama ilk Gmail testi spam klasörüne düştü. Bu bekleniyor: yeni domain reputation + Gmail'in agresif yeni-gönderici filtreleri.

Çözüm üç adımda:

  1. Gmail filter: from:@example.com için "asla spam'a düşme" kuralı. Sadece ilgili Gmail hesapları için geçerli, ama asıl alıcı kişisel Gmail'lerse yeterli.
  2. Postmaster Tools: Google Postmaster Tools'a domain'i kaydedip TXT record ile doğrulayın. Reputation, IP, authentication, encryption metriklerini izlersiniz.
  3. Düşük volüm warm-up: İlk hafta günlük 5-10 mail. İkinci hafta 15-25. Üçüncü haftadan sonra natural volume.

Uygulama entegrasyonu

Web tarafından gönderilen transactional mail'ler SMTPS üzerinden yola çıkıyor. Branded HTML template (Hanbisan brand pack typography ve renkleri) production'da render ediliyor; teslimat sonrası Postmaster Tools üzerinden authentication + spam rate metriklerini gözlemliyoruz.

Container-içi bağlantılarda strict TLS verify bypass edilebilir (kendi self-signed cert chain'iniz varsa). Production'da TLS her durumda etkin, sadece sertifika doğrulama esnetilmiş. Dış dünyaya gönderilen mailler için bu geçerli değil — full strict TLS.

Sonuçlar — 1 hafta sonra

  • 3/3 e2e test mail Gmail Inbox'a doğrudan düştü (filter aktif sonrası)
  • 0 bounce, 0 reject, 0 deferral
  • Postmaster Tools'ta IP reputation: Medium (yeni domain için ideal)
  • Domain reputation: High
  • Authentication pass rate: 100%

Karşılaşmadığımız sorunlar (henüz)

  • IP blacklisting: Henüz olmadı. Yeni VPS aldıysanız mxtoolbox.com/blacklists.aspx'ten önce kontrol edin.
  • PTR/Reverse DNS: VPS sağlayıcının paneli üzerinden self-service set edebildik — destek bileti açmaya gerek olmadı (her sağlayıcı izin vermez, mail çalışacaksa bu kontrol listesi).
  • Outlook/Hotmail Junk: Test henüz yapılmadı. Microsoft'un yeni-gönderici politikası Gmail'den agresif. Ayrı warm-up döngüsü gerekebilir.

Tavsiye: ne zaman self-host, ne zaman SaaS?

  • SaaS doğru seçim: ay başına 50K+ mail; mail uzmanlığı sıfır; hızlı go-to-market; SOC2/ISO27001 vendor compliance gerekli.
  • Self-host doğru seçim: orta-düşük volüm (50K altı/ay); kontrol kritik; uzun vadeli bağımsızlık önceliği; mevcut kapasite var; en az 1 kişi DKIM/SPF/DMARC bilgisine sahip.

Hanbisan ikinci kategoride.

Yardımcı kaynaklar mail-tester.com · Google Postmaster Tools · RFC 8463 (Ed25519 DKIM) · RFC 8461 (MTA-STS)

Hanbisan Mühendislik Notları · 9 Mayıs 2026 (rev. 10 Mayıs) ← Tüm yazılar

İletişim