E-posta teslim edilebilirliği kontrol listesi (2026)

Alıcı sunucular nasıl karar verir?

Hiçbir tekil ayar tek başına gelen kutusuna ulaşmayı garanti etmez; teslim edilebilirlik, birbirinin üzerine binen birkaç kontrolün toplu sonucudur. Alıcı sunucular önce iletinin gerçekten sizin adınıza gönderilip gönderilmediğini, yani kimliğinin doğrulanıp doğrulanmadığını kontrol eder; ardından gönderimi yapan altyapının meşru görünüp görünmediğine bakar; en sonunda da alıcıların sizden bu tür postaları gerçekten isteyip istemediğini değerlendirir. İlk katmanda kalan bir ileti, içeriği ne kadar kusursuz olursa olsun genellikle ya doğrudan reddedilir ya da spam klasörüne düşer. Kontrol listesinin sırası bu yüzden önemlidir: alttaki katmanlar düzelmeden üsttekilerde yapılan iyileştirmelerin ölçülebilir bir etkisi olmaz.

Büyük posta sağlayıcıları ilk iki katmanı artık açıkça yazılı kurallara bağlamış durumdadır. Google ve Yahoo, Şubat 2024'ten bu yana istisnasız her göndericinin kimlik doğrulama kullanmasını ve geçerli DNS kayıtlarına sahip olmasını şart koşar; günde kabaca 5.000 iletiden fazlasını gönderen toplu göndericiler için de ek kurallar tanımlar. Microsoft 2025 yılında Outlook.com için benzer gereksinimleri duyurdu. Pratikte bu, yıllardır yalnızca iyi uygulama olarak önerilen maddelerin artık kabul edilmenin şartına dönüştüğü anlamına gelir.

1. Kimlik doğrulama

Google'ın gönderen kuralları tüm göndericilerden SPF ya da DKIM kurmasını, toplu göndericilerden ise her ikisini birden ve en azından p=none politikası taşıyan bir DMARC kaydını ister. Toplu postada From alan adının ayrıca SPF veya DKIM alan adlarından en az biriyle hizalı olması gerekir. Bunları yalnızca alt sınır olarak görün ve her gönderim akışında DKIM hizalamasını hedefleyin, çünkü DKIM imzası yönlendirmelerden sağ çıkan tek kimlik doğrulama yöntemidir. SPF hizalaması ise ileti bir posta listesi ya da otomatik bir yönlendirme üzerinden geçtiğinde çoğu zaman bozulur.

Kayıtlar yerine oturduktan sonra DMARC geçiş planını baştan sona uygulayın. Zorlamaya alınmış bir politika, alan adınızın itibarını sahteciliğe karşı korur; aksi halde sizin adınızla gönderilen sahte iletilerin bir bölümü alıcı tarafında yine sizin hanenize yazılır. Politikayı haftalar içinde kademeli sıkılaştırmak ve bu sırada raporları izlemek, meşru gönderim kaynaklarını yanlışlıkla engellemenizi önler.

2. Gönderim altyapısı

İleri ve ters DNS

Posta gönderen her IP adresinin bir PTR kaydı olmalı ve bu kayıttaki sunucu adı çözümlendiğinde yine aynı IP adresine dönmelidir. İleri doğrulamalı ters DNS adı verilen bu karşılıklı eşleşme, Google'ın istisnasız tüm göndericiler için aradığı gereksinimlerden biridir. Barındırılan posta hizmetleri bunu kendi sunucuları için hallederler; kendi posta sunucunuzu işletiyorsanız PTR kaydını IP bloğunun sahibinden talep etmeniz gerekir. Ters DNS kaydı çoğu zaman alan adınızın DNS sağlayıcısında değil, IP adresini size tahsis eden ağ operatöründe tanımlanır.

10.2.0.192.in-addr.arpa. IN PTR mail.example.com.
mail.example.com.         IN A   192.0.2.10

Her iki yönü de kontrol edin: IP adresi için Ters DNS aracını, sunucu adı için DNS Sorgulama aracını kullanın. 192-0-2-10.dynamic.example.net gibi otomatik üretilmiş genel bir PTR kaydı pek çok filtreye ev tipi bir bağlantı izlenimi verir ve tek başına puan kaybettirir. Bunun yerine posta sunucunuzun gerçek adını, örneğin mail.example.com, kullanın.

TLS

Alıcı sunucular postanın TLS üzerinden gelmesini bekler ve Google bunu açıkça bir gereksinim olarak listeler. Güncel posta yazılımları, karşı sunucu desteklediğini bildirdiğinde STARTTLS'i kendiliğinden kullanır; bu yüzden çoğu kurulumda ek bir ayar yapmanız gerekmez. Size gelen postada ise MTA-STS ve TLS raporlaması, TLS'i zorunlu kılmanızı ve başarısız teslim denemelerini görmenizi sağlar; kurulumun ayrıntıları MTA-STS rehberinde anlatılıyor.

Kara listeler

Yaygın kullanılan bir DNS kara listesinde yer almak, o listeyi kullanan her alıcı sunucuda reddedilmeye yol açabilir. Gönderim yaptığınız IP adreslerini hem olaylardan hemen sonra hem de düzenli aralıklarla Kara Liste Kontrolü ile tarayın. Listelendiyseniz, her listenin kendi sürecini anlatan listeden çıkarma rehberi izlenecek adımları sırasıyla açıklar. Listelenme nedenini bulmadan çıkma talebinde bulunmak çoğu zaman kısa süre sonra yeniden listelenmeyle sonuçlanır.

İleti biçimi

İletiler RFC 5322'ye uymalıdır: tek bir From başlığı, geçerli bir Date ve Message-ID alanı ve başka bir alan adının kimliğine bürünen hiçbir başlık bulunmamalıdır. Büyük bir posta sağlayıcısının alan adından geliyormuş gibi görünen ama başka bir yerden gönderilen postalar, o sağlayıcıların kendi DMARC politikaları gereği reddedilir. Bu yüzden form bildirimlerinde ve otomatik iletilerde ziyaretçinin adresini From alanına koymak yerine kendi alan adınızı kullanın ve ziyaretçinin adresini Reply-To başlığında taşıyın.

3. Toplu ve pazarlama postası kuralları

Tek tıkla abonelikten çıkma

Toplu göndericilerin pazarlama ve abonelik iletileri, RFC 8058'de tarif edilen tek tıkla abonelikten çıkma özelliğini desteklemek zorundadır. İleti, HTTPS adresi içeren bir List-Unsubscribe başlığı ile bir List-Unsubscribe-Post başlığı taşır; kullanıcı abonelikten çıkma bağlantısına tıkladığında posta sağlayıcısı o adrese bir POST isteği gönderir. Google, abonelikten çıkma taleplerinin iki gün içinde uygulanmasını ister. Bu özellik alıcının şikayet düğmesine basmak yerine sessizce ayrılmasını kolaylaştırdığı için şikayet oranını da doğrudan düşürür.

List-Unsubscribe: <https://example.com/unsubscribe?id=3f9a1c>, <mailto:unsubscribe@example.com?subject=3f9a1c>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Her iki başlık da DKIM imzasının kapsamında olmalı ve adres, POST isteği için bir giriş ekranı veya onay sayfası olmadan çalışmalıdır. Kullanıcıdan ayrıca onay isteyen bir sayfa bu testte başarısız sayılır, çünkü posta sağlayıcısı kullanıcıyı o sayfaya hiç göndermez. Makbuz ve parola sıfırlama gibi işlemsel iletilerin tek tıkla abonelikten çıkma özelliğine ihtiyacı yoktur.

Şikayet oranı

Google, toplu göndericilerden Postmaster Tools ekranında raporlanan spam şikayet oranını %0,1'in altında tutmalarını ve hiçbir zaman %0,3'e ulaşmamalarını ister. Şikayetler doğrudan alıcıların “Spam bildir” düğmesine basmasından doğar; dolayısıyla çözüm neredeyse her zaman postanın kime gittiğiyle ve listeden ayrılmanın ne kadar kolay olduğuyla ilgilidir. Yalnızca içeriği değiştirmek yüksek bir şikayet oranını düşürmez; asıl düzeltilmesi gereken şey listenin kendisi ve izin akışıdır.

• Yalnızca postayı isteyen kişilere gönderin; onaylı kayıt (confirmed opt-in) hem yazım hatalarını hem de sahte kayıtları listeden temizler.
• Kalıcı olarak geri dönen adresleri gecikmeden çıkarın ve uzun süredir hiç etkileşime girmeyen alıcılara göndermeyi durdurun.
• Gönderen adını ve konu satırını tanınabilir tutun ki alıcılar sizi tanımadıkları bir gönderici sanıp spam olarak işaretlemesin.
• Abonelikten çıkma bağlantısını yalnızca başlıklarda değil, iletinin gövdesinde de kolayca görülebilecek bir yerde bulundurun.
• Pazarlama postasını işlemsel postadan farklı alt alan adlarıyla ayırın ki birine gelen şikayetler diğerinin itibarını etkilemesin.

İçerik ve bağlantılar

Kimlik doğrulama, iletinin gerçekten sizden geldiğine güvenilip güvenilmeyeceğine karar verir; içerik ise iletinin alıcıların isteyeceği bir şeye benzeyip benzemediğine karar verir. Filtreler yalnızca gönderen alan adınıza değil, ileti içindeki bağlantıların alan adlarına da bakar. İtibarı kötü bir alan adına giden tek bir bağlantı ya da spam göndericilerinin yoğun kullandığı halka açık bir adres kısaltma servisi, başka her açıdan temiz bir iletiyi spam klasörüne çekebilir. Bu nedenle bağlantı alan adlarını da gönderen altyapınızın bir parçası sayın ve kime ait olduğu belirsiz üçüncü taraf alan adları üzerinden yönlendirme yapmayın.

• Bağlantıları kendi alan adınıza ya da onun bir alt alan adına verin; tıklama takibi için kullanılan alan adını da markalı hale getirin (örneğin links.example.com).
• HTML'in yanında bir düz metin bölümü de gönderin; neredeyse hiç metin içermeyen, tek bir görselden oluşan iletiler filtrelere spam gibi görünür.
• Alıcıların tanıdığı bir From adı ve adresi kullanın ve Reply-To adresine gelen yanıtların gerçekten okunduğundan emin olun.
• HTML'i sade tutun: gizli metin, devasa ekler ve posta istemcilerinin zaten temizlediği betikler iletide bulunmasın.
• Her bağlantının ve görsel adresinin HTTPS kullandığını ve birbiriyle ilgisiz birkaç alan adı üzerinden yönlendirilmediğini kontrol edin.

Yönlendirme Kontrolü aracı, bir takip bağlantısının arkasındaki zincirin tamamını, her bir adımı ve ulaşılan son adresi gösterir. Sitenize varmadan önce üç ayrı alan adından geçen bir bağlantıyı sadeleştirmeye değer, çünkü her ek adım hem gecikme hem de filtrelerin şüpheyle karşıladığı bir sıçrama anlamına gelir.

Katılmaya değer sağlayıcı programları

Birkaç büyük posta sağlayıcısı, postanızı kendi tarafından nasıl gördüğünü paylaşan ücretsiz programlar sunar. Bu programlar alan adının ya da IP aralığının sizin denetiminizde olduğunu kanıtlamanızı ister ve bir kısmı yalnızca belirli bir hacmin üzerindeki göndericiler için veri raporlar. Buna rağmen o sağlayıcıdaki itibarınıza dair edinebileceğiniz tek doğrudan görünüm bunlardır; geri kalan her şey dolaylı çıkarım ve tahminden ibarettir.

Geri bildirim döngüleri, gönderim platformunuz şikayet eden alıcıları otomatik olarak listeden çıkardığında gerçekten yararlı hale gelir. Bir şikayet, birinin postanızı istemediğine dair elde edebileceğiniz en net sinyaldir; aynı kişiye göndermeyi sürdürmek şikayet oranınızı daha da yukarı çeker. Bu yüzden geri bildirim verisini yalnızca okunacak bir rapor gibi görmeyin, doğrudan abonelikten çıkarma akışınıza bağlayın.

4. Hacim ve ısınma

Alıcı sunucular yeni IP adreslerine ve yeni gönderim alan adlarına temkinli yaklaşır, çünkü geçmiş davranışa dair ellerinde hiçbir veri yoktur. Günde birkaç iletiden büyük kampanyalara aniden sıçramak, liste tertemiz olsa bile ele geçirilmiş bir hesabın ya da bir spam göndericisinin davranışına benzer. Hacmi günlere, gerekiyorsa haftalara yayarak artırın ve işe postalarınızı en çok açan, en etkileşimli alıcılardan başlayın. Bu alıcıların ürettiği olumlu sinyaller, sonraki daha geniş gönderimler için bir temel oluşturur.

Bir e-posta servis sağlayıcısındaki paylaşımlı IP havuzları hazır bir itibarla gelir; çoğu göndericinin kendi başına bir ısınma süreci yürütmemesinin nedeni de budur. Adanmış IP adresleri ancak hacminiz düzenliyse ve o IP'ye kendi itibarını kazandıracak kadar yüksekse anlamlıdır; düşük hacimde adanmış bir IP çoğu zaman fayda değil zarar getirir. Her iki durumda da alan adı itibarı sizin From alan adınızı, DKIM alan adınızı ve içeriğinizi takip etmeye devam eder, yani IP değiştirmek geçmişi silmez.

İşlemsel posta kendi şeridini hak eder

Parola sıfırlama, makbuz ve güvenlik uyarıları kullanıcıların en çok ihtiyaç duyduğu iletilerdir ve pazarlama kaynaklı sorunlardan en çok zarar gören de yine onlardır. Bültenler ile makbuzlar aynı From alan adını, aynı DKIM anahtarını ve aynı IP havuzunu paylaşıyorsa, bir kampanyaya gelen şikayet dalgası makbuzların bağlı olduğu itibarı da aşağı çeker. İkisini birbirinden ayırmak, birçok kurum için yapılabilecek en etkili tek yapısal değişikliktir. Ayrım aynı zamanda sorun gidermeyi kolaylaştırır, çünkü her akışın kendi raporları ve kendi itibar geçmişi olur.

Her alt alan adı kendi SPF kaydını ve kendi DKIM seçicisini alır, kurumsal DMARC politikasını ise olduğu gibi devralır. İzleme de basit kalır, çünkü toplu raporlarda her satırın hangi From alan adına ait olduğu açıkça görünür. İşlemsel iletileri tanıtım içeriğinden uzak tutun; ikisini yeniden karıştırmak, ayırarak uzaklaştırdığınız şikayet riskini geri getirir.

5. İzleme

Teslim edilebilirlik sorunlarının çoğu, tam bir kesintiye dönüşmeden önce kendini belli eder: yükselen bir erteleme oranı, DMARC raporlarında beliren yeni bir başarısız kaynak ya da postmaster panelinde düşmeye başlayan bir itibar puanı. Bu sayılara haftada bir bakmak, sorunları düzeltmesi hâlâ kolayken yakalamanızı sağlar. Ölçümleri kalıcı bir yerde biriktirin; tek bir haftanın rakamı değil, haftalar boyunca izlenen eğilim anlamlıdır.

DMARC toplu raporları ayrı bir dikkati hak eder, çünkü tek bir sağlayıcıyı değil rapor gönderen tüm alıcı sunucuları kapsar. İmzalamayı bırakan bir servis ya da pazarlama ekibinin haber vermeden kullanmaya başladığı yeni bir araç, önce orada görünür. Raporları okumak için ayrı bir araç kullanıyorsanız, yeni kaynaklar için uyarı kurmak haftalık taramadan daha hızlı sonuç verir.

Postalar spam klasörüne düşmeye başlarsa

1. Yeni gelen bir iletiyi E-posta Başlığı Analizi ile kontrol edin: SPF, DKIM ve DMARC sizin alan adınızla geçmiş olmalı.
2. Bozulmuş bir SPF kaydını, eksik bir DMARC kaydını ya da DNS hatalarını yakalamak için Alan Adı Sağlığı taraması çalıştırın.
3. Gönderim yaptığınız IP adreslerini ve alan adınızı Kara Liste Kontrolü aracıyla sorgulayın.
4. Sorunun görüldüğü sağlayıcının postmaster panelinde şikayet ve itibar verilerine bakın.
5. Son dönemde neyin değiştiğini gözden geçirin: yeni bir liste içe aktarımı, yeni bir gönderim aracı, bir DNS taşıması ya da hacimde ani bir artış.
6. Tam hacimle göndermeye dönmeden önce nedeni giderin; ardından eski hacme kademeli olarak çıkın.

Kontrol listesi

• SPF: tek bir kayıt, en fazla 10 DNS sorgusu, sonunda açıkça -all ya da ~all.
• DKIM: her gönderim akışı kendi alan adınızla imzalanmış, 2048 bit anahtarlar ve yazılı bir anahtar değiştirme planı.
• DMARC: tek bir kayıt, haftalık okunan rua raporları ve reject yönünde ilerleyen bir politika.
• Gönderim yapan IP adresleri için, çözümlendiğinde aynı IP'ye dönen PTR kayıtları.
• Giden teslimatta TLS; gelen posta için MTA-STS ve TLS-RPT.
• Yaygın kullanılan kara listelerin hiçbirinde kayıt bulunmaması.
• Pazarlama postasında RFC 8058 tek tıkla abonelikten çıkma ve taleplerin iki gün içinde uygulanması.
• Gmail'de %0,1'in altında bir şikayet oranı, onaylı kayıt ve geri dönen adreslerin temizlenmesi.
• Pazarlama, işlemsel ve kişisel postanın alt alan adlarıyla birbirinden ayrılması.
• DMARC raporlarına ve postmaster panellerine haftada bir göz atılması.

SSS

Kaynaklar

• Google: E-posta gönderen kuralları
• Yahoo Sender Hub: En iyi uygulamalar
• RFC 8058: Signaling One-Click Functionality for List Email Headers
• RFC 5322: Internet Message Format
• RFC 7489: DMARC
• Google Postmaster Tools