E-posta Teslimat Sağlığı — Türkiye İçin Komple Rehber

1. E-posta Teslim Edilebilirlik Nedir, Neden Önemlidir?

E-posta teslim edilebilirlik (deliverability), gönderdiğiniz mesajların alıcının gelen kutusuna — spam veya çöp klasörüne değil — başarıyla ulaşması yeteneğidir. Modern internet ekosisteminde Gmail, Microsoft 365, Yahoo gibi büyük posta sağlayıcıları gelen e-postalara onlarca filtre uygular; sizin altyapınızdaki en küçük hata bile mesajlarınızın spam'e düşmesine veya tamamen reddedilmesine neden olabilir.

Teslim edilebilirlik sadece pazarlama e-postaları için değildir. Şifre sıfırlama linkleri, fatura, sipariş onayı, sistem uyarısı gibi transactional e-postalar da aynı filtrelerden geçer. Bir kullanıcı şifre sıfırlama maili alamadığında siz farkında bile olmazsınız; uçtan uca müşteri deneyiminizdeki bu görünmez kayıplar, doğru ölçülmediği sürece büyür.

İyi bir teslim edilebilirlik mimarisi üç katmandan oluşur: kimlik doğrulama (SPF/DKIM/DMARC), itibar yönetimi (IP/domain reputation, kara liste izleme) ve içerik/uygulama hijyeni (liste hijyeni, abonelik süreci, warm-up). Bu rehber üçünü de baştan sona kapsar.

Mailleriniz şu anda spam'e mi düşüyor? Acil ve adım adım bir teşhis için "Maillerim Spam'e Düşüyor" teşhis rehberimize göz atın; bu pillar sayfa ise konunun tüm teknik arka planını derinlemesine ele alır.

2. E-posta Ekosistemi Nasıl Çalışır?

Bir e-posta gönderildiğinde geçtiği yol aşağıdaki gibidir:

1. Gönderici uygulama (MUA — Mail User Agent): Outlook, Thunderbird veya bir uygulamanın SMTP istemcisi mesajı oluşturur.
2. Gönderici sunucu (MTA — Mail Transfer Agent): Postfix, Exim, Microsoft Exchange veya bir ESP altyapısı mesajı kuyruğa alır.
3. DNS sorgusu: Alıcı domain'in MX kaydı sorgulanır, alıcı MTA'nın hostname'i bulunur.
4. SMTP teslim: Gönderici MTA, alıcı MTA'nın 25 (veya 587/465) portuna bağlanır. HELO/EHLO ile tanışır, MAIL FROM ve RCPT TO ile mesajı teslim eder.
5. Alıcı filtreleme: Alıcı MTA gelen mesajda SPF, DKIM, DMARC, kara liste, içerik analizi, itibar ve diğer ~50 sinyali değerlendirir.
6. Klasör kararı: Mesaj gelen kutusu / promosyon / spam / çöp klasöründen birine yerleştirilir veya tamamen reddedilir (bounce).

Bu zincirin her halkası bir kontrol noktasıdır. Birinde başarısız olursanız, mesaj büyük olasılıkla spam'e düşer veya teslim edilmez. Modern bir mail sunucusu yöneticisinin görevi, tüm bu halkaların doğru çalışmasını sağlamaktır.

3. SPF (Sender Policy Framework)

SPF, bir alan adı (domain) adına hangi sunucuların e-posta göndermeye yetkili olduğunu DNS üzerinden ilan eden bir doğrulama mekanizmasıdır. Alıcı sunucu gelen mesajı kontrol ederken, gönderim yapılan IP adresinin domain'in SPF kaydında izinli olup olmadığına bakar.

Tipik bir SPF kaydı şöyle görünür: v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:192.0.2.10 -all. include mekanizmaları başka domain'lerin SPF kayıtlarını dahil eder, ip4 ile spesifik IP'ler eklenir, -all politikası "listede olmayanları reddet" anlamına gelir.

En yaygın SPF hataları: 10 DNS lookup limitini aşmak (her include bir lookup sayar), çift SPF kaydı yayınlamak (bir domain için yalnızca bir SPF kaydı olmalı), ~all yerine -all kullanmamak (softfail spam filtrelerini gevşetir). SPF kaydı sorgulama aracımızla mevcut kaydınızı doğrulayabilir, SPF kaydı oluşturma aracıyla sıfırdan geçerli bir kayıt üretebilirsiniz.

Önemli: ESP'lerin (SendGrid, Mailgun, Amazon SES) default Return-Path domain'i ESP'nin kendi domain'i olduğu için SPF teknik pass alsa bile DMARC alignment'tan başarısız olabilir. Bu durum bir sonraki bölümde ele alınmaktadır.

4. DKIM (DomainKeys Identified Mail)

DKIM, e-postanın gönderim sırasında değiştirilip değiştirilmediğini doğrulayan ve gönderen domain'in kimliğini kriptografik olarak garanti eden bir mekanizmadır. Gönderen MTA mesajın belirli bölümlerini (başlık + gövde) özel anahtarla imzalar; alıcı MTA ise selector._domainkey.domain DNS kaydından açık anahtarı çeker ve imzayı doğrular.

DKIM imzası DKIM-Signature header'ında yer alır ve d= (domain), s= (selector), bh= (body hash), b= (signature) gibi alanlar içerir. DKIM'in pass alması için iki şart vardır: imzanın matematiksel olarak doğru olması ve d= domain'inin DMARC için From: domain'i ile hizalanmış olması.

DKIM, SPF'e göre forwarding karşısında daha dayanıklıdır: bir kullanıcı mesajınızı başka adrese yönlendirse bile, mesajın gövdesi değişmediği sürece DKIM imzası geçerli kalır. Bu yüzden modern e-posta altyapısında DKIM alignment'a SPF'den daha çok güvenilmelidir.

DKIM anahtarlarınızı her 6-12 ayda bir döndürmeniz tavsiye edilir (key rotation). Eski selector'ı silmeden yeni selector'ı yayınlayın, paralel çalıştırın, sonra eskisini kaldırın. DKIM kaydı sorgulama aracımızla yapılandırmanızı doğrulayın.

5. DMARC: Politika ve Hizalama

DMARC (Domain-based Message Authentication, Reporting & Conformance), SPF ve DKIM sonuçlarını birleştiren ve domain sahiplerine kimlik doğrulamadan başarısız mesajlara ne yapılacağını bildirme imkanı veren bir politikadır. Aynı zamanda alıcılardan size geri bildirim (rapor) gönderir.

Tipik bir DMARC kaydı: v=DMARC1; p=reject; rua=mailto:dmarc@sirketim.com; ruf=mailto:forensic@sirketim.com; adkim=r; aspf=r;. p= politika seviyesidir: none (sadece izle), quarantine (şüpheli olarak işaretle), reject (tamamen reddet).

DMARC pass için iki şart: SPF veya DKIM'den en az birinden teknik olarak pass almak VE bu doğrulamanın From: header domain'i ile hizalanmış olması. Alignment'ın çalışması için Return-Path veya DKIM d= domain'inin From: ile aynı organizational domain olması gerekir.

DMARC raporları XML formatında günde bir kez alıcılardan gelir; içlerinde her gönderim IP'sinin SPF/DKIM/DMARC sonucu, mesaj sayısı ve disposition bilgisi yer alır. Bu raporları sistemli okumadan p=reject'e geçmek riskli olduğu için bir SaaS dashboard (DMARCian, EasyDMARC, Postmark) kullanmanız önerilir. DMARC raporları okuma rehberi bu konuyu detaylandırır.

Önerilen DMARC yayın stratejisi: p=none ile 2-4 hafta izle → eksiklikleri kapat → p=quarantine; pct=25 → kademeli pct=100 → p=reject. Toplam süreç 2-3 ay kadardır.

6. IP Kara Liste (RBL/DNSBL) İzleme

Realtime Blackhole List (RBL) veya DNSBL olarak da bilinen IP kara listeleri, spam, kötü amaçlı yazılım veya başka şüpheli aktivite kaynağı olarak tespit edilmiş IP adreslerini tutan veritabanlarıdır. Alıcı MTA'lar gelen mesajda kaynak IP'yi bu listelerde sorgular; listede ise mesajı reddedebilir, spam olarak işaretleyebilir veya itibar puanını düşürebilir.

Dünyada 300+ kara liste vardır ama büyük posta sağlayıcılarının aslında dikkate aldığı liste sayısı yaklaşık 20-25'tir. En etkili olanları: Spamhaus ZEN/SBL/XBL/PBL (en katı), Barracuda, SpamCop, CBL, UCEPROTECT L1, SORBS, MailSpike, PSBL. RBL Watch tam olarak bu listede yer alan büyük 20+ RBL'i ücretsiz tarar.

Bir IP kara listeye neden düşer? Genelde dört sebep vardır: (1) ele geçirilmiş kullanıcı hesabından spam çıkışı, (2) açık relay yapılandırması, (3) botnet/virüs bulaşmış host, (4) yetersiz onaylı pazarlama gönderimi. Kara listede bulunduğunuzu çoğu zaman müşterileriniz size mesaj alamadıklarını söyleyene kadar fark edemezsiniz; bu yüzden proaktif izleme şarttır.

RBL Watch ücretsiz IP kara liste sorgulama aracıyla IP'nizin 20+ büyük listede olup olmadığını anında sorgulayabilirsiniz. Otomatik izleme isteyenler için her aktif RBL'in detay sayfası ve RBL-spesifik delist rehberleri mevcuttur.

7. IP İtibarı: Gmail Postmaster + Microsoft SNDS

SPF/DKIM/DMARC doğrulamayı geçen mesajlar bile düşük IP/domain itibarı nedeniyle spam'e düşebilir. Gmail ve Microsoft Outlook, her gönderen IP'ye dair şikayet oranı, spam tuzaklarına gönderim, etkileşim oranı, hacim paterni gibi onlarca sinyali değerlendirir ve kendi içsel itibar puanını oluşturur.

Gmail tarafı için Gmail Postmaster Tools ücretsiz bir dashboard sunar: IP reputation, domain reputation, spam rate, authentication oranları, encryption (TLS) oranı, delivery errors. Domain'inizi DNS TXT kaydıyla doğruladıktan sonra 24-72 saat içinde veri akmaya başlar.

Microsoft Outlook ekosistemi için Microsoft Smart Network Data Services (SNDS) aynı işlevi görür ve buna ek olarak Junk Mail Reporting Program (JMRP) ile şikayet edilen mesajların kopyasını size gönderir. SNDS itibar sınıfı GREEN/YELLOW/RED olarak gösterilir; RED durumda derhal müdahale gerekir.

SNDS, Postmaster Tools ve bağımsız RBL izleme (RBL Watch) — bu üçlü, e-posta itibar sağlığınızın 360° görünümünü verir. Bir araç sorun gösterdiğinde, diğer ikisi de etkilenmeden önce müdahale fırsatınız olur.

8. rDNS / PTR ve FCrDNS

Reverse DNS (rDNS), bir IP adresinin hostname'e çözümlenmesidir. Bir mail sunucusunun PTR kaydı, IP'nin DNS'e geri (reverse) sorgulandığında dönen hostname'dir. Modern büyük posta sağlayıcıları, PTR kaydı olmayan veya jenerik dinamik IP pattern'i taşıyan PTR'leri olan IP'lerden gelen mesajları büyük olasılıkla spam'e atar.

Tipik bir doğru PTR kaydı: IP 192.0.2.10 için mail.sirketim.com. PTR kaydının Forward-Confirmed (FCrDNS) olması da gerekir: mail.sirketim.com hostname'ini DNS'te sorgulandığında geri aynı IP'ye (192.0.2.10) dönüyor olmalıdır.

rDNS doğru ayarlanmadığında: (1) Spamhaus PBL'e düşme riski artar, (2) Gmail/Outlook teslimatı düşer, (3) bazı kurumsal anti-spam sistemleri direkt reddeder. RBL Watch Reverse DNS sorgulama aracıyla IP'nizin PTR ve FCrDNS durumunu sorgulayabilirsiniz. PTR kaydını değiştirmek için ISS'inize başvurmanız gerekir (DNS bölgesi onların kontrolündedir).

9. MX Kayıtları ve Mail Routing

MX (Mail Exchanger) kayıtları, bir domain'e gelen e-postaların hangi sunuculara teslim edileceğini belirler. Bir domain için birden fazla MX kaydı olabilir; her birinin priority değeri vardır (düşük öncelik = ilk denenir).

Doğru bir MX yapılandırması şöyle görünür:

• sirketim.com IN MX 10 mail1.sirketim.com
• sirketim.com IN MX 20 mail2.sirketim.com (yedek)

Önemli noktalar: (1) MX kayıtları IP'ye değil hostname'e işaret etmelidir, (2) hostname'in A/AAAA kaydı olmalı, (3) PTR kaydının hostname ile uyumlu olması teslim oranını artırır, (4) CNAME'ye MX işaret etmek RFC ihlalidir, bazı sunucular reddeder.

RBL Watch MX kaydı sorgulama aracıyla herhangi bir domain'in MX yapılandırmasını ve her MX sunucusunun A kaydını/IP'sini görebilirsiniz.

10. Modern Standartlar: BIMI, MTA-STS, TLS-RPT

Son yıllarda e-posta güvenliği üç yeni katmanla zenginleşti. Bu standartlar zorunlu değil ama büyük posta sağlayıcıları (Gmail, Apple Mail) artık desteğiyle birlikte gelen kutusunda görünür markalama (BIMI) ve TLS güvenliği denetimi (MTA-STS) sunuyor.

BIMI (Brand Indicators for Message Identification)

BIMI, domain sahiplerinin Gmail/Apple Mail gelen kutusunda mesajlarınızın yanında logonuzun görünmesini sağlar. Üç şart vardır: (1) DMARC p=quarantine veya p=reject politikası, (2) SVG formatında BIMI uyumlu logo, (3) Verified Mark Certificate (VMC — ücretli ek katman, Gmail için zorunlu).

MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS, e-posta sunucuları arası iletişimde TLS'i zorunlu kılan modern bir politikadır. Bir domain MTA-STS yayınladığında, gönderen MTA'lar STARTTLS olmadan veya geçerli sertifika olmadan teslim yapmaz. SMTP downgrade saldırılarını engeller.

TLS-RPT (SMTP TLS Reporting)

TLS-RPT, MTA-STS politikasından sapan teslimatları size raporlayan bir mekanizmadır. Hangi gönderen MTA'lar TLS olmadan size mesaj atmaya çalıştı, hangi sertifika hataları yaşandı — bunları görürsünüz.

Bu üç standart birlikte modern bir e-posta güvenlik altyapısının "ileri seviye" katmanını oluşturur. Türkçe pazarda hâlâ az uygulanıyor — erken benimseyen domainler için rakiplerden öne çıkma fırsatıdır.

11. Liste Hijyeni ve IP Warm-up

Teknik altyapı kusursuz olsa bile, kötü liste hijyeni teslim edilebilirliğinizi yok eder. İki ana konu vardır: liste kalitesi ve IP warm-up.

Liste Hijyeni

• Double opt-in: abone olan kullanıcıya onay e-postası gönderin, tıklayanlar listeye eklensin. Satın alınmış listelerden kesinlikle kaçının.
• Bounce yönetimi: hard bounce alan adresleri derhal listeden çıkarın. Bounce oranınız %2'nin altında olmalıdır.
• Etkileşim segmentasyonu: 6+ aydır açmayan/tıklamayan aboneleri "düşük etkileşim" segmentine ayırın, ya tamamen çıkarın ya da yeniden onay alın.
• Şikayet izleme: şikayet oranı %0.1'in altında olmalı; %0.3'ü aşan kampanyalar derhal durdurulmalı.
• List-Unsubscribe + One-Click: Gmail/Yahoo 2024'ten itibaren zorunlu kıldı. List-Unsubscribe header'ı + tek-tık çıkış sağlamayan göndericiler ciddi teslimat cezası alır.

IP Warm-up

Yeni bir IP'den (veya uzun süre kullanılmamış bir IP'den) yüksek hacimde gönderim yapmak, alıcı sunucular tarafından "şüpheli yeni gönderici" olarak algılanır ve hızlı şekilde itibar düşüşüne neden olur. Çözüm: warm-up.

Tipik bir warm-up planı şöyle ilerler:

• 1. gün: 50 mesaj/saat — en etkileşimli (son 30 günde açan/tıklayan) abonelerinize
• 2-3. gün: 200-500 mesaj/saat
• 4-7. gün: 1.000-3.000 mesaj/saat
• 2. hafta: 5.000-10.000 mesaj/saat
• 3-4. hafta: hedef günlük hacme kademeli geçiş

Her gün önceki günkü hacmin 2-3 katını geçmeyin. Spam Rate Gmail Postmaster'da %0.1 üzerine çıkarsa hacmi azaltıp düşene kadar bekleyin.

12. Pratik Kontrol Listesi

Yeni bir domain/IP'den gönderime başlamadan veya teslimat sorunu yaşıyorsanız aşağıdaki listeyi sırasıyla uygulayın:

1. SPF kaydını yayınlayın: tüm gönderim kaynaklarınızı include ile dahil edin, -all ile bitirin. SPF kaydı sorgulayın.
2. DKIM imzalamayı aktifleştirin: ESP'lerin sunduğu DKIM kayıtlarını DNS'e ekleyin. DKIM kaydı sorgulayın.
3. DMARC kaydını yayınlayın: başlangıçta p=none; rua=mailto:dmarc@sirketim.com. DMARC kaydı sorgulayın.
4. PTR (rDNS) doğru mu kontrol edin: IP'nizin PTR'ı mail sunucu hostname'ine eşleşmeli. Reverse DNS sorgulayın.
5. MX yapılandırması: en az 1 (ideal 2) MX kaydı, IP'ye değil hostname'e. MX kaydı sorgulayın.
6. IP kara liste sorgulaması: IP'niz büyük RBL'lerde temiz mi? Kara liste sorgulayın.
7. Gmail Postmaster Tools + Microsoft SNDS: kayıt olun, ilk hafta verilerini izleyin.
8. Warm-up planı: yeni IP ise 4-6 haftalık kademeli artış planı yapın.
9. Liste hijyeni: bounce'ları temizleyin, eski adresleri ayıklayın, List-Unsubscribe header'ı ekleyin.
10. DMARC raporlarını izleyin: 2-4 hafta sonra p=quarantine, ardından p=reject'e kademeli geçiş.

13. Türkiye İçin Özel Durumlar

Türkiye'de mail sunucusu yöneten kuruluşların karşılaştığı bazı özel durumlar var. Bu bölüm onlara yöneliktir.

Paylaşılan Hosting ve UCEPROTECT L2/L3

Türkiye'de küçük-orta ölçekli işletmelerin çoğu paylaşılan hosting üzerinden mail gönderiyor. Bu hostingler aynı IP üzerinden birden çok müşteriye hizmet veriyor; bir tek müşterinin spam'i bütün IP havuzunu UCEPROTECT L2 (sağlayıcı bazlı kara liste) veya L3 (ASN bazlı) kara listesine sokuyor. Kendi domain'inizin SPF/DKIM/DMARC'ı kusursuz olsa bile bu durumda etkileniyorsunuz. UCEPROTECT L1 sorgulama sayfamızdan başlayıp L2, L3 sayfalarını da kontrol edin. Çözüm: kendi adresli IP (dedicated) almak veya Google Workspace / Microsoft 365 gibi kurumsal sağlayıcıya geçmek.

IHS Telekom / Yerli ISS'ler ile PTR Talebi

Reverse DNS (PTR) kaydı ekleme yetkisi DNS sağlayıcınızda değil, IP sahibi ISS'tedir. Türkiye'de IHS Telekom, Türk Telekom, Vodafone Business gibi sağlayıcılarda PTR talebi destek üzerinden açılır. Talebinizde mutlaka şunları belirtin: (1) PTR'ı hangi hostname'e (örn. mail.firmaniz.com.tr) ayarlatmak istiyorsunuz, (2) o hostname'in A kaydı sizin DNS'inizde aynı IP'ye işaret ediyor mu (FCrDNS için gerekli), (3) IPv6 PTR'sını da ayarlatmak istiyorsanız ayrıca belirtin. Reverse DNS sorgulama aracımızla PTR durumunuzu kontrol edin.

KVKK / GDPR Uyumlu Bounce ve Şikayet Yönetimi

KVKK ve GDPR uyum kapsamında onaylanmış (consent) abonelerinize mail göndermeniz şart; aboneliği bitirenleri ya da hard bounce alan adresleri en geç 30 gün içinde listenizden silmelisiniz. Gmail/Yahoo'nun List-Unsubscribe zorunluluğu da bu kapsamda. Tek-tık çıkış (One-Click Unsubscribe) header'ı eksik olan mailler 2024 sonrası ciddi teslimat cezası alıyor.

Türk Telekom Mail Bloklamaları ve Smart Host

Bazı Türk ISS'leri 25 numaralı SMTP portunu evden gönderim için bloklar. Eğer evden veya office ağından mail gönderme zorunluluğunuz varsa 587 (Submission) veya 465 (SMTPS) portu kullanın ve SMTP auth ile sağlayıcınızın smart host'undan gönderin. Bu durum SPF sorgulaması yaptığınızda da görünür — sağlayıcının SMTP IP'sini SPF'inize include: ile eklemediyseniz mailler düşer.

Türkçe Karakterler ve Subject Line

Türkçe karakterler (ş, ğ, ü, ö, ç, ı, İ) içeren konu satırları UTF-8 encoding ile MIME-encoded olarak gönderilmeli (Q-encoded veya Base64). Sunucunuz veya CMS'iniz bunu doğru yapmıyorsa konu satırı bozuk gelir ve bazı spam filtreleri bunu "spam göstergesi" olarak işaretler. WordPress kurulumlarında WP Mail SMTP eklentisi bu encoding'i otomatik yapar.

Türkiye Spesifik RBL'ler

Türkiye için özel olarak izlenen bir RBL yok ama bazı bölgesel sağlayıcılar (Mailspike, Senderscore) Türk IP havuzlarını daha sıkı değerlendiriyor. Spamhaus PBL'de listelenmiş IP havuzlarının büyük kısmı Türkiye dahil gelişmekte olan ülkelerden çıkıyor. RBL Watch IP kara liste sorgulama aracıyla Türk IP havuzlarının durumunu izleyin.

14. Sıkça Sorulan Sorular

E-posta teslim edilebilirliğim kötü, neden?

Genelde dört sebepten birinden: (1) eksik veya yanlış SPF/DKIM/DMARC, (2) IP/domain kara listede, (3) düşük itibar (Gmail/Outlook nezdinde), (4) kötü liste hijyeni (yüksek bounce/şikayet). Önce IP kara liste sorgulaması, sonra SPF sorgulaması + DKIM sorgulaması + DMARC sorgulaması yapın.

DMARC p=reject'e ne zaman geçmeliyim?

DMARC raporlarınızda meşru gönderim kaynaklarınızın %95+ pass aldığını 2-4 hafta gözlemledikten sonra. p=none → p=quarantine; pct=25 → pct=100 → p=reject kademeli geçiş 2-3 ay sürer.

Hangi RBL'ler en önemli?

Sırasıyla: Spamhaus ZEN (en katı, Gmail/Microsoft kullanır), Barracuda (kurumsal ağlar), SpamCop (veteran), CBL/XBL (botnet), UCEPROTECT L1.

SPF mi yoksa DKIM mi daha önemli?

DMARC için ikisinden biri yeterlidir ama DKIM önceliklidir çünkü forwarding (mesaj yönlendirme) altında bile çalışır, SPF ise yönlendirmeden bozulur.

IP warm-up ne kadar sürer?

Genelde 4-6 hafta. Hedef hacminize ve listenizin etkileşim kalitesine bağlıdır. Spam Rate %0.1'in üzerine çıkarsa hacmi azaltın.

Birden fazla ESP kullanıyorum, SPF'im 10 lookup'ı geçti, ne yapmalıyım?

SPF flattening (her ESP'nin IP'lerini ip4: ile direkt yazma) veya alt domain'ler için ayrı SPF kayıtları kullanın. SPF kaydı oluşturma aracımız bu konuda yardımcı olur.

Gmail/Yahoo bulk sender requirements nedir?

2024'ten itibaren günlük 5.000+ mesaj gönderenler için Gmail ve Yahoo şunları zorunlu kıldı: SPF + DKIM + DMARC, List-Unsubscribe header + tek-tık çıkış, spam rate %0.3 altı, ARC header desteği.

Hangi araçları kullanmalıyım?

Minimum üçlü: RBL Watch (bağımsız IP kara liste sorgulama) + Gmail Postmaster + Microsoft SNDS. DMARC için DMARCian veya EasyDMARC. E-posta başlık analizi aracımız tek tek mesaj teşhisi için ideal.