Postfix + Dovecot ile Kurumsal E-posta: SPF, DKIM, DMARC, MTA-STS

Kurumsal e-posta teslim edilebilirliği (deliverability) artık sadece “doğru SMTP portları açıldı mı?” sorusuna indirgenmiyor. Alıcı tarafların spam/kimlik doğrulama kontrolleri; SPF, DKIM, DMARC ve giderek daha fazla MTA-STS gibi sinyallere dayanıyor. Postfix + Dovecot ile kendi altyapınızı kurduğunuzda, bu kayıtları doğru şemayla ve doğru zamanlama ile yapılandırmak; kimlik sahteciliği riskini azaltır, yanlış pozitif spam durumlarını düşürür ve teslimat istikrarı sağlar. Bu rehberde sunucu tarafını kurulum düzleminde ele alıp DNS kayıtlarını, doğrulama adımlarını ve tipik hataları net şekilde göreceksiniz.

Mimari: Postfix (SMTP) + Dovecot (IMAP/POP) ve DNS doğrulama mantığı

Önce kimin ne yaptığını netleştirelim: - Postfix: Gönderim (SMTP) tarafı. “Bu sunucu domain adına e-posta yolluyor mu?” sorusu SPF ve DKIM ile cevaplanır. - Dovecot: Alınan mesajların kullanıcı erişimi (IMAP/POP) tarafı. Kimlik doğrulama sinyalleri doğrudan Dovecot’tan değil, gönderim doğrulama zincirinden ilgilidir. - DNS kayıtları: Alıcı MTA (mail transfer agent) sistemleri, gönderinizin “otantik” olup olmadığını SPF/ DKIM/ DMARC ile kontrol eder; ek olarak MTA-STS ile STARTTLS zorlaması yapar.

Tasarım kararı: Tek bir gönderim kimliği mi, birden fazla yol mu?

Kurumsal ortamlarda SMTP trafiği tek bir makineden çıkabilir ya da birden fazla sunucu (ör. NAT arkasında farklı hostlar) üzerinden çıkabilir. SPF/DKIM kayıtlarını buna göre tasarlarsınız. - Tekil çıkış: SPF kayıtları kısa ve net olur. - Çoklu çıkış: SPF include/top-level yaklaşımıyla yönetilir; DKIM için yayınlanan anahtar seti genellikle aynı kalır, ama imza yapan parametreleri tutarlı tutmanız gerekir.

SPF, DKIM, DMARC ve MTA-STS: Ne işe yarar, nerede kullanılır?

Aşağıdaki tablo “neyi kontrol ediyoruz?” sorusunu hızlı yanıtlar.

Alignment (uyum) kritik noktadır

DMARC’de asıl mesele SPF ya da DKIM “geçti mi?” değil; “geçen sonucun From domainiyle uyumlu olup olmadığıdır”. - SPF alignment: Return-Path (envelope-from) domaini ile From: domaini uyumlu olmalı. - DKIM alignment: DKIM d= alanı (imza domaini) ile From: domaini uyumlu olmalı.

Bu yüzden DMARC ayarlarken pencereleri yanlış kurarsanız (ör. DKIM d= farklı, From farklı), politika sertleşse bile başarısızlık artar.

Adım adım yapılandırma: Postfix + DKIM imzası ve SPF/DMARC uyumu

Aşağıdaki bölümde Postfix seviyesinde DKIM imzasının mantığını ve DNS tarafında SPF/DMARC’in “uyumlu” tasarımını ele alıyoruz. DNS tarafı için hedef, alıcının raporlarında açık ve tutarlı sinyaller görmenizdir.

1) SPF kaydı: gönderim IP(leri)ni doğru kapsamla

SPF kaydının mantığı şudur: “Bu domain adına e-posta gönderebilecek kaynaklar nereler?”

Kurumsal senaryoda yaygın yaklaşım: - Sunucunuzun sabit bir IPv4/IPv6 adresi varsa: doğrudan include etmeyi tercih edin. - Bir üçüncü taraf (ör. e-posta pazarlama platformu) da aynı domainle gönderiyorsa: ilgili sağlayıcının SPF include ifadesini ekleyin.

Örnek SPF (alan adınız example.com olsun; varsayımsal örnek): - Sunucu IPv4: 203.0.113.10 - Sunucu IPv6: 2001:db8::10

SPF TXT kaydı: - v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.example-thirdparty.com -all

Burada: - -all “bu listedekiler dışında fail” anlamına gelir. Kurumsal kullanıma geçmeden önce 7-14 gün “~all” (softfail) ile izleme yapılması sık kullanılan yöntemdir.

SPF için yaygın hatalar

• PTR (reverse DNS) ile uyumsuzluk: SPF geçse bile bazı sistemler ek kontrol yapabilir.
• Çok agresif -all: Yeni gönderim hattı eklediğinizde hemen fail oluşur.
• “Başka alt domainlerden” gelen trafik için gereksiz geniş include: teslimat istikrarını bozar.

2) DKIM: Postfix’in imza attığı alanı DMARC alignment ile eşleştirin

DKIM tarafında hedef: DMARC’nin istediği alignment koşulunu sağlamaktır. - DKIM imzasında d= alanı (domain) genellikle DMARC’nin görmek istediği From domainiyle aynı olmalıdır. - Postfix DKIM entegrasyonunda (genelde milter üzerinden) selector ve anahtar yönetimi belirleyicidir.

DKIM DNS kaydı örneği (selector mail): - DKIM TXT: mail._domainkey.example.com üzerinde v=DKIM1; k=rsa; p=... içeriği.

DKIM’de “selector” sürekliliği

• Selector değiştirmek, yeni anahtar yayınlamak ve eski anahtarların dolaşımını düşünmek demektir.
• İmza doğrulama başarısını artırmak için bir selector ile ilerleyip, anahtar rotasyonu için kontrollü geçiş yapın.

3) DMARC: önce p=none, sonra kademeli sertleştirin

DMARC TXT kaydı şu formatı izler: - v=DMARC1; p=...; rua=...; ruf=...; fo=1; adkim=...; aspf=...; pct=...

Kademeli yaklaşım (önerilen): 1) İlk faz: p=none ile rapor topla 2) Kimlik doğrulama sonuçları beklendiği gibi ise: p=quarantine 3) En sonunda: p=reject

Örnek DMARC (rapor alma aktif): - v=DMARC1; p=none; rua=mailto:[email protected]; fo=1; aspf=s; adkim=s; pct=100

Buradaki noktalar: - aspf= s (strict): SPF alignment için katı uyum. - adkim= s: DKIM alignment için katı uyum.

Strict alignment başlangıçta riskli görünebilir; ancak Postfix + DKIM ayarlarını doğru kurduğunuzda doğru strateji olur. Yine de gerçek trafik gözlemiyle hareket edin.

DMARC raporlarını nasıl değerlendirirsiniz?

Raporlar iki açıdan kritiktir: - disposition alanları (none/quarantine/reject gibi) - SPF/DKIM doğrulama ve alignment sonuçları

En çok sorun çıkaran tipik durum: DKIM pass ama d= domain From ile hizalı değil.

4) MTA-STS: STARTTLS davranışını DNS politikasıyla sabitleyin

MTA-STS (RFC 8461), alıcı MTA’ların gönderenin TLS politikasına uyum sağlaması için kullanılır. PRatik sonuç: gönderen tarafınız STARTTLS’yi sağlıklı sunmuyorsa, uyumsuzluk gecikme veya reddedilme doğurabilir.

MTA-STS genelde şu mantıkla çalışır: - DNS TXT kaydı: _mta-sts.example.com (tam alan adı, uygulamaya göre değişebilir; net bilgi için sağlayıcınızın dokümantasyonuna bakın) - “max-age” ile politika süresini belirlersiniz - “mode” ile enforce yaklaşımı (ör. testing/enforce)

MTA-STS’yi yayına almak için temel şartlar: 1) Postfix’in SMTP submission ve/veya SMTP 25 üzerinde STARTTLS sağlaması 2) Sertifika zincirinin doğru (intermediate dahil) servis edilmesi 3) Güvenli TLS sürümleri/şifre takımlarının modern olması

MTA-STS için güvenli devreye alma sırası

• Önce TLS servisinizin dışarıdan doğruluğunu test edin.
• Sonra MTA-STS’i “testing” benzeri modla devreye alın (mode desteği varsa).
• Ardından max-age’i kademeli artırın.

Doğrulama: Kurduktan sonra “hangi testte ne görmeliyim?”

E-posta doğrulama zincirinde amaç, alıcının gözünden tutarlı sinyaller almak. Bunun için hem DNS hem de SMTP davranışını test etmelisiniz.

1) SPF testleri: geçiyor mu ve hangi mekanizma?

Beklenen: - Alıcı raporlarında spf=pass görmelisiniz. - SPF fail olduğunda “why” kısmında IP’yi listeleyen kısım (veya include’ların kaynakları) yakalanabilir.

2) DKIM testleri: pass mi, selector doğru mu?

Beklenen: - Alıcı taraf dkim=pass göstermeli. - “selector” uyumsuzluğu varsa DKIM pass olmaz.

3) DMARC testleri: dmarc=pass ve alignment

Beklenen: - dmarc=pass veya en azından dmarc=none fazında doğru raporlar. - alignment fail varsa, adkim/aspf strict policy ile sorun daha görünür olur.

4) MTA-STS testleri: STARTTLS başarısı

Beklenen: - STARTTLS müzakere edilebilmeli. - Sertifika doğrulama hataları olmamalı (chain, hostname, expiry).

Karşılaştırmalı kontrol listesi: “Hazırım mı?” değerlendirmesi

Aşağıdaki kontrol listesi, dört kayıt türünün de birlikte çalıştığını doğrular.

• SPF
• [ ] SPF kaydı gönderdiğiniz tüm çıkış IP’lerini kapsıyor
• [ ] include kullandığınız tarafların SPF’i sürüm değiştirince takip ediliyor
• [ ] Kurumsal kullanıcıdan raporlar “softfail” yerine giderek “pass”a dönüyor
• DKIM
• [ ] İmza atan domain (d=) DMARC’de From domainiyle hizalı
• [ ] Selector DNS’te yayında ve Postfix imza parametresiyle aynı
• [ ] Anahtar rotasyonu planı var (en azından “ne zaman ve nasıl”)
• DMARC
• [ ] İlk aşamada p=none ile rapor toplandı
• [ ] SPF/DKIM alignment nedenleri çözüldü
• [ ] Son aşamada p=quarantine ve ardından p=reject kademeli yapıldı
• MTA-STS
• [ ] STARTTLS her ilgili portta tutarlı şekilde çalışıyor
• [ ] Sertifika zinciri doğru servis ediliyor
• [ ] max-age kademeli artırılıyor (ani enforce riski azaltılıyor)

Tipik senaryolar ve net çözümler

Senaryo A: SPF pass, DMARC fail

Neden: - DKIM alignment fail veya DKIM hiç çalışmıyor ve DMARC strict alignment arıyor.

Çözüm: - DKIM imzasının DNS’teki public key ile eşleştiğini doğrulayın. - DKIM d= alanını From domainiyle aynı hale getirin.

Senaryo B: DKIM pass, SPF fail ve DMARC fail

Neden: - SPF “-all” ile dışarıda kalmış bir çıkış IP’yi kapsıyor.

Çözüm: - Postfix’in gerçekten kullandığı outbound IP’yi bulun (NAT varsa bu kritik). - SPF’i bu IP/alt ağ ile güncelleyin.

Senaryo C: DMARC pass ama teslimat hâlâ düzensiz

Neden: - IP itibar, yeni domain ısınma, HTML/şablon metin içeriği veya gönderim yoğunluğu etkili olabilir.

Çözüm: - 2-4 hafta planlı “düşük hacimle” kademeli artırın. - DMARC raporlarıyla birlikte greylisting/softbounce sinyallerini de izleyin.

Senaryo D: MTA-STS devreye alınca teslimatlar düşüyor

Neden: - STARTTLS bazı istemci/cihazlarda başarısız oluyor (firewall, sertifika chain, farklı hostname).

Çözüm: - Sertifika chain ve TLS ayarlarını tüm ilgili portlar için kontrol edin. - DNS MTA-STS politikasını geri alıp TLS’i düzeltin; sonra tekrar kademeli ilerleyin.

Sonuç: En doğru aksiyon sırası

Kendi Postfix + Dovecot kurulumunuzda SPF, DKIM, DMARC ve MTA-STS’i aynı anda “tam sert” şekilde açmak yerine, doğrulama zincirini sırayla sağlamlaştırın. İlk adım SPF/DKIM’i doğru alignment ile çalışır hale getirmek; ardından DMARC’i p=none ile raporlayıp sorunları kapatmak; en son aşamada MTA-STS’i STARTTLS tutarlılığı garanti edildikten sonra kademeli devreye almak en düşük riskli yoldur. Bugün kurulumunuz tamamlandıysa, önce DNS doğrulamalarını yapın, sonra alıcı raporlarından alignment sonuçlarını toplayın; bir sonraki aşamaya (DMARC sertleştirme, MTA-STS enforce) yalnızca “beklenen metrikler” geldikten sonra geçin.