E-Posta Altyapısı Audit Nasıl Yapılır? Kontrol Listesi

E-posta gönderilebilirlik sorunlarının büyük çoğunluğu yanlış yapılandırılmış DNS kayıtlarından, eksik kimlik doğrulama politikalarından veya ihmal edilmiş sunucu bileşenlerinden kaynaklanır. Sistematik bir altyapı audit süreci, bu sorunları tespit etmenin ve çözmenin en güvenilir yoludur.

Audit Neden Gereklidir?

Kurumsal e-posta altyapıları, günlük kullanımda sessiz sedasız bozulabilir: DNS yöneticisi bir kaydı yanlış günceller, yeni bir IP adresi rotasyona girer ya da bir servis sağlayıcı politika değişikliği yapar. Bu değişikliklerin her biri teslim edilebilirlik üzerinde ani ve ölçülü etkiler yaratabilir. Google Postmaster Tools ve Microsoft SNDS (Smart Network Data Services) gibi platformlar bu sorunları raporlasa da reaktif bir yaklaşım yerine proaktif periyodik audit, zararı minimize eder.

RFC 5321 (SMTP protokolü), RFC 7208 (SPF), RFC 6376 (DKIM) ve RFC 7489 (DMARC) standartları, modern e-posta ekosisteminin temelini oluşturur. Bu RFC'lerin tanımladığı mekanizmaları doğru biçimde uygulamak artık bir tercih değil, büyük posta kutusu sağlayıcılarının (Gmail, Outlook, Yahoo Mail) gönderici gereksinimi haline gelmiştir.

1. DNS Kayıtlarının Doğrulanması

Audit sürecinin ilk adımı, alan adına ait tüm e-posta ile ilgili DNS kayıtlarının sistematik olarak sorgulanmasıdır.

MX Kayıtları

MX kayıtlarının doğru öncelik değerleriyle (priority) tanımlı olduğunu ve her kaydın geçerli bir A kaydına işaret ettiğini doğrulayın. dig MX example.com +short komutu veya nslookup -type=MX example.com ile hızlı bir kontrol yapılabilir. RFC 5321'e göre MX kaydı bulunmayan bir alan adına e-posta gönderirken SMTP sunucusu A kaydına yönelir; bu durum kasıtsız e-posta kabul sorunlarına yol açar.

SPF Kaydı (RFC 7208)

SPF (Sender Policy Framework), bir alan adı adına e-posta gönderme yetkisi verilen IP adreslerini tanımlar. TXT kaydı olarak yayınlanan SPF politikası şu kriterlere göre incelenmelidir:

• Yalnızca tek bir SPF TXT kaydı bulunmalıdır; birden fazla kayıt RFC 7208 Bölüm 3.2 uyarınca "PermError" sonucu üretir.
• DNS lookup sayısı 10 ile sınırlıdır. include:, a, mx ve redirect= mekanizmaları bu sayaca dahildir. Limit aşıldığında alıcı sunucu "PermError" döner ve e-posta reddedilebilir.
• Politika sonu direktifi -all (hard fail) veya ~all (soft fail) olmalıdır; +all kullanımı güvenlik açığıdır.
• Aktif olarak kullanılmayan alan adları için v=spf1 -all yayınlanarak yetkisiz gönderimlerin önü kesilmelidir.

DKIM Kaydı (RFC 6376)

DKIM (DomainKeys Identified Mail), gönderen sunucunun e-posta başlıklarına ve gövdesine kriptografik imza eklemesini sağlar. Selector değerleri genellikle ESP tarafından belirlenir (örn. google._domainkey, s1._domainkey). Audit sırasında şunlar kontrol edilmelidir:

• Anahtar uzunluğu: RFC 6376 Bölüm 3.3 minimum 1024 bit önermekte, ancak Google ve Microsoft 2048 bit gerektirmektedir. 512 ve 768 bitlik eski anahtarlar derhal değiştirilmelidir.
• p= alanı boş bırakılmış DKIM kayıtları, anahtarın iptal edildiğini gösterir ve tüm imzaları geçersiz kılar.
• Birden fazla ESP kullanılıyorsa her biri için ayrı selector/anahtar çiftleri tanımlanmış olmalıdır.

DMARC Kaydı (RFC 7489)

DMARC, SPF ve DKIM doğrulama sonuçlarına göre posta kutularına ne yapmaları gerektiğini söyler. _dmarc.example.com TXT kaydı incelenirken şu noktalar değerlendirilmelidir:

• p=none politikası yalnızca izleme aşamasında kullanılmalıdır; raporlama verileri analiz edildikten sonra p=quarantine ardından p=reject politikasına geçilmelidir.
• rua= etiketi ile toplam raporları, ruf= etiketi ile adli raporları alacak e-posta adresleri tanımlanmış olmalıdır.
• pct= etiketi, politikanın uygulanacağı mesajların yüzdesini belirler; kademeli geçişlerde kullanışlıdır.
• Alt alan adları için ayrı politika (sp=) tanımlanmamışsa ana alan politikası geçerli olur.

2. Gönderen Sunucu Konfigürasyon Kontrolü

DNS katmanından sonra SMTP sunucusunun kendisi incelenmelidir. RFC 5321'e göre her SMTP sunucusunun EHLO/HELO komutunda sunduğu hostname, gerçek PTR (reverse DNS) kaydıyla eşleşmelidir. Bu uyumsuzluk, pek çok alıcı sunucu tarafından spam belirtisi olarak değerlendirilir.

Reverse DNS (PTR) Kaydı

Gönderen IP adresinin PTR kaydı, tercihen gönderen alan adına işaret etmelidir. dig -x [IP] +short ile sorgulanabilir. Özellikle toplu e-posta gönderimi yapılan IP'lerde PTR kaydı eksikliği, Spamhaus PBL (Policy Block List) gibi listelere girişe neden olur.

TLS ve Şifreleme Yapılandırması

STARTTLS desteği modern bir gereksinimdir. Google'ın Şeffaflık Raporu ve RFC 8461 (MTA-STS) standardına göre, e-posta iletiminde TLS kullanım oranı %90'ın üzerinde olmalıdır. Audit sırasında şunlar kontrol edilmelidir:

• TLS 1.0 ve TLS 1.1 devre dışı bırakılmış olmalıdır; yalnızca TLS 1.2 ve TLS 1.3 desteklenmelidir.
• Kullanılan sertifika geçerli, zinciri tam ve gönderen hostname ile eşleşen bir CN/SAN değerine sahip olmalıdır.
• MTA-STS politikası (_mta-sts.example.com TXT kaydı ve https://mta-sts.example.com/.well-known/mta-sts.txt dosyası) yayınlanmışsa güncel olup olmadığı kontrol edilmelidir.

3. IP İtibar ve Kara Liste Taraması

Gönderen IP adreslerinin kara listelerde (DNSBL) yer alıp almadığı düzenli olarak taranmalıdır. Aşağıdaki listeler öncelikli inceleme kapsamına alınmalıdır:

• Spamhaus ZEN: SBL, XBL ve PBL listelerini birleştirir; en yaygın kullanılan DNSBL'dir.
• Barracuda Reputation Block List (BRBL): Kurumsal e-posta güvenlik ürünlerinde sıkça referans alınır.
• SURBL ve URIBL: E-posta içeriğindeki URL'leri değerlendiren listelerdir; gönderen IP yerine içerik kalitesini ölçer.
• Microsoft SNDS: Outlook/Hotmail alıcı havuzuna gönderim yapılıyorsa zorunlu kontrol noktasıdır.

MXToolbox, MultiRBL.valli.org ve Talos Intelligence gibi araçlar çoklu liste taramasını tek sorguda gerçekleştirir. Kara listeye alınan bir IP için liste yöneticisinin kaldırma (delisting) sürecine uyulmalıdır; Spamhaus için www.spamhaus.org/removal/ adresi kullanılır.

4. E-Posta Kimlik Doğrulama Hizalaması (Alignment)

DMARC'ın etkin çalışması için SPF ve DKIM sonuçlarının "hizalanmış" (aligned) olması gerekir. RFC 7489 Bölüm 3.1'e göre hizalama iki modda çalışır:

• Relaxed (varsayılan): From: başlığındaki alan adı ile SPF/DKIM alan adının Organizational Domain'i (eTLD+1) eşleşmelidir.
• Strict: Tam alan adı eşleşmesi zorunludur; aspf=s ve adkim=s etiketleriyle etkinleştirilir.

E-posta servis sağlayıcıları (ESP) üzerinden gönderim yapılıyorsa ESP'nin DKIM imzasının From: alan adıyla hizalanması için Custom Domain DKIM (veya "Bring Your Own Domain") özelliği etkinleştirilmiş olmalıdır.

5. Gönderim Altyapısı Audit Kontrol Tablosu

6. İçerik ve Başlık Analizi

Altyapı kadar e-posta içeriği ve başlıkları da teslim edilebilirliği doğrudan etkiler. mail-tester.com ve GlockApps gibi araçlar, gönderim öncesi kapsamlı başlık ve içerik taraması sağlar. Özellikle şu başlıklar incelenmelidir:

• Message-ID: RFC 5322 Bölüm 3.6.4'e göre her mesaja özgü ve gönderen alan adını içeren bir Message-ID atanmalıdır.
• List-Unsubscribe: RFC 2369 ve RFC 8058 (One-Click Unsubscribe) uyumlu başlık, Gmail ve Yahoo'nun Şubat 2024'ten itibaren toplu göndericiler için zorunlu tuttuğu gereksinimdir.
• X-Mailer / User-Agent: Eski veya tanımlanamayan değerler bazı filtreler tarafından olumsuz puanlanır.

7. Otomasyon ve Sürekli İzleme

Periyodik audit, otomasyon araçlarıyla desteklendiğinde çok daha etkili hale gelir. Açık kaynaklı checkdmarc (Python kütüphanesi) ve dkimpy araçları CI/CD süreçlerine entegre edilerek her DNS değişikliğinde otomatik doğrulama tetiklenebilir. Ticari çözümler arasında Valimail, EasyDMARC ve dmarcian; DMARC raporlarının ayrıştırılması ve görselleştirilmesi için öne çıkan platformlardır.

Connect365 müşterileri için gönderim altyapısı izleme, platform içinde entegre olarak sunulmakta; IP itibar skorları, SPF/DKIM/DMARC geçiş oranları ve kara liste durumu gerçek zamanlı olarak raporlanmaktadır.

Sık Sorulan Sorular