# E-mail teslim edilebilirliği: SPF, DKIM, DMARC ve gönderici kuralları Sayfa: https://alidemirbas.com.tr/blog/e-mail-teslim-edilebilirligi 2026-11-02 · CRM ve Lifecycle · Ali Demirbaş Mailler neden spama düşüyor? Gmail, Yahoo ve Microsoft gönderici kuralları, SPF, DKIM ve DMARC hizalaması, tek tıkla çıkış, spam oranı ve İYS. E-mail teslim edilebilirliği, gönderdiğin bir e-mailin alıcının gelen kutusuna ulaşma ihtimalidir. Yalnızca "e-mail teslim edildi mi" sorusuna değil, "spam klasörüne mi gitti, gelen kutusuna mı düştü" sorusuna da cevap verir. Türkçe kaynaklarda daha çok e-posta teslim edilebilirliği olarak geçer. Bu ihtimali üç şey belirler: gönderenin kim olduğunu SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) ve DMARC (Domain-based Message Authentication, Reporting and Conformance) ile kanıtlaması, gönderen alan adının ve IP adreslerinin itibarı ve alıcıların e-maillere verdiği tepki. Gmail, Yahoo ve Microsoft 2024'ten bu yana bu üç konuda yazılı kurallar uyguluyor. Bu rehber kuralları sağlayıcıların kendi sayfalarından aktarıyor, SPF, DKIM ve DMARC'ın nasıl birlikte çalıştığını anlatıyor ve müşteri ilişkileri yönetimi (CRM) ile lifecycle ekiplerinin gönderim akışlarını bu kurallara göre nasıl kurabileceğini gösteriyor. ## E-mail teslim edilebilirliği nedir? E-mail teslim edilebilirliği, gönderilen e-maillerin spam klasörüne değil gelen kutusuna ulaşma oranını belirleyen kimlik, itibar ve etkileşim sinyallerinin toplamıdır. Bunu teslim oranıyla karıştırmamak gerekir. Teslim oranı, alıcı sunucusunun e-maili reddetmeden kabul edip etmediğini gösterir. Sunucu e-maili kabul edip spam klasörüne koyduğunda teslim oranın yüksek görünür ama alıcı mesajı hiç görmez. Bu yüzden ESP ya da CRM panelindeki "teslim edildi" rakamı tek başına gelen kutusuna ulaştığını göstermez. E-mail sağlayıcıları gelen her e-maili üç açıdan değerlendirir. Birincisi kimlik: e-mail gerçekten From satırındaki alan adı adına mı gönderildi, yolda değiştirildi mi? İkincisi itibar: bu alan adı ve IP adresi geçmişte ne tür e-mailler gönderdi, kaç kişi spam olarak işaretledi? Üçüncüsü etkileşim: alıcılar bu göndericinin e-maillerini açıyor, yanıtlıyor mu, yoksa siliyor ya da spam bildiriyor mu? Kimlik doğrulama yalnızca kapıdan girmeni sağlar. DMARC standardının güncel sürümü olan [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.txt) de bunu açıkça yazar: DMARC'tan geçmek tek başına e-mailin gelen kutusuna teslim edilmesinin güvenli ya da istenir olduğunu garanti etmez. ### Mailler neden spama düşüyor? Mailler çoğu zaman içerik yüzünden değil, kimlik ve itibar sorunları yüzünden spama düşer. Sağlayıcıların yayımladığı kurallar ve hata kodları en sık şu nedenlere işaret eder: - **Kimlik doğrulaması eksik ya da hizasız:** SPF veya DKIM kurulmamış ya da From satırındaki alan adı, SPF veya DKIM'in doğruladığı alan adıyla eşleşmiyor. - **Spam şikayetleri:** Alıcılar e-maili spam olarak işaretliyor ve şikayet oranı sağlayıcının eşiğini aşıyor. - **Ani hacim artışı:** Geçmişi olmayan bir alan adı ya da IP adresi bir anda büyük hacimle gönderim yapıyor. - **Karışık akışlar:** Şifre sıfırlama e-mailleri ile kampanya e-mailleri aynı IP adresinden ve aynı itibarla çıkıyor. - **Bakımsız liste:** Geçersiz adreslere gönderim sürüyor, uzun süredir hiç etkileşim vermeyen alıcılar listeden çıkarılmıyor. Bu nedenlerin her biri aşağıdaki bölümlerde ayrı ayrı ele alınıyor. Önce sağlayıcıların bugün neyi zorunlu tuttuğuna bakmak gerekiyor, çünkü bir kısmı artık tavsiye değil, e-mailin reddedilme sebebi. ## Gmail, Yahoo ve Microsoft gönderici kuralları Google ve Yahoo, Ekim 2023'te duyurdukları gönderici kurallarını Şubat 2024'te uygulamaya başladı. Microsoft benzer kuralları Outlook.com için Mayıs 2025'te devreye aldı. Üç sağlayıcı da kuralları iki gruba ayırıyor: her göndericinin uyması gerekenler ve yüksek hacimle gönderenlerin ek yükümlülükleri. ### Tüm göndericiler için kurallar Google'ın [e-mail gönderici yönergeleri](https://support.google.com/a/answer/81126?hl=en), kişisel Gmail hesaplarına (@gmail.com ve @googlemail.com) e-mail gönderen herkesin SPF veya DKIM'den en az birini kurmasını, gönderen IP adresleri için geçerli ileri ve geri DNS kayıtları (PTR) tutmasını, e-maili TLS bağlantısıyla iletmesini, mesajları RFC 5322 biçimine uygun hazırlamasını ve Postmaster Tools'ta raporlanan spam oranını %0,3'ün altında tutmasını istiyor. Yahoo'nun [Sender Hub sayfası](https://senders.yahooinc.com/best-practices/) da her gönderici için SPF veya DKIM, geçerli ileri ve geri DNS kaydı, RFC 5321 ve 5322 uyumu ve %0,3'ün altında spam oranı şartı koyuyor. Yahoo'nun listesinde TLS şartı yer almıyor. ### Toplu göndericiler için kurallar Google, 24 saat içinde kişisel Gmail hesaplarına yaklaşık 5.000 ya da daha fazla e-mail gönderen herkesi toplu gönderici sayıyor. Google'ın [SSS sayfasına](https://support.google.com/a/answer/14229414?hl=en) göre aynı ana alan adından çıkan e-mailler bu sayıya birlikte girer. Yani alanadi.com'dan 2.500 ve kampanya.alanadi.com'dan 2.500 e-mail gönderen biri toplu gönderici olur. Bu eşiği bir kez geçen gönderici kalıcı olarak toplu gönderici kabul edilir. Yönergeler Google Workspace hesaplarına giden e-mailleri kapsamaz. Toplu göndericiler SPF ile DKIM'i birlikte kurmak, DMARC kaydı yayımlamak (p=none politikası yeterli), From satırındaki alan adını SPF ya da DKIM alan adıyla hizalamak, pazarlama e-maillerinde tek tıkla abonelikten çıkmayı desteklemek ve gövdede görünür bir abonelikten çıkma linki koymak zorunda. Yahoo da toplu göndericilerden SPF ve DKIM'in ikisini, en az p=none politikasıyla geçen bir DMARC kaydını, hizalamayı, tek tıkla abonelikten çıkmayı ve görünür linki istiyor. Fark şurada: Yahoo toplu gönderici için bir sayı vermiyor ve [SSS sayfasında](https://senders.yahooinc.com/faqs/) yalnızca "önemli bir hacim" ifadesini kullanıyor. Bu yüzden "Yahoo'nun eşiği de günde 5.000" demek doğru değil. Gmail ve Yahoo, DKIM anahtarının en az 1024 bit olmasını şart koşuyor ve 2048 bit öneriyor. ### Microsoft Outlook.com'un Mayıs 2025 kuralları Microsoft, Nisan 2025'teki [duyurusunda](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730) günde 5.000'den fazla e-mail gönderen alan adları için SPF ve DKIM'in geçmesini ve en az p=none politikalı, SPF ya da DKIM'den biriyle hizalı bir DMARC kaydını şart koştu. İlk planda kurallara uymayan e-mailler Junk klasörüne gidecekti. Microsoft 29 Nisan 2025'teki güncellemeyle bunu değiştirdi ve 5 Mayıs 2025'ten itibaren bu e-mailleri "550 5.7.515" koduyla reddetmeye başladı. Microsoft'un [destek sayfası](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com) bu hatanın, From adresindeki alan adının gerekli kimlik doğrulama seviyesini karşılamadığı anlamına geldiğini yazıyor. Microsoft çalışan bir abonelikten çıkma linkini ve liste temizliğini tavsiye olarak sıralıyor ama bir spam oranı eşiği yayımlamıyor. ### 2024'ten bugüne neler değişti? Kurallar bir defada sertleşmedi. Google, TLS şartını Aralık 2023'te ekledi ve kuralları 1 Şubat 2024'te başlattı. Haziran 2024'ten itibaren spam oranı %0,3'ü aşan toplu göndericiler Google'ın destek ve iyileştirme taleplerinden yararlanamıyor. Gönderimlerinde zaten abonelikten çıkma linki olanlara tek tıkla çıkma için 1 Haziran 2024'e kadar süre tanındı. Yahoo da abonelikten çıkma kuralını Haziran 2024'te uygulamaya başladı. Google, Kasım 2025'ten itibaren kurallara uymayan trafiğe karşı yaptırımı artırdığını ve bu e-maillerin geçici ve kalıcı retlerle karşılaşacağını duyurdu. Microsoft'un kuralları ise Mayıs 2025'ten beri geçerli. *Sağlayıcıların kendi yardım sayfalarına göre, Kasım 2026 itibarıyla.* | Kural | Gmail | Yahoo | Microsoft Outlook.com | | --- | --- | --- | --- | | Toplu gönderici eşiği | 24 saatte yaklaşık 5.000+ e-mail, ana alan adı bazında, kalıcı | Sayı yayımlanmıyor | Günde 5.000+ e-mail, aynı From alan adı | | Tüm göndericiler | SPF veya DKIM, PTR, TLS, RFC 5322 | SPF veya DKIM, PTR, RFC 5321 ve 5322 | Ayrı bir şart yayımlanmıyor | | Toplu göndericiler | SPF ve DKIM, DMARC en az p=none, hizalama | SPF ve DKIM, DMARC en az p=none ve geçmeli, hizalama | SPF ve DKIM geçmeli, DMARC en az p=none, hizalama | | Spam oranı | %0,1 altı önerilir, %0,3'e hiç ulaşılmamalı | %0,3 altı | Yayımlanmıyor | | Abonelikten çıkma | Tek tık (RFC 8058), görünür link, 48 saatte işlenmesi önerilir | Tek tık, görünür link, 2 günde işlenir | Çalışan link tavsiye edilir | | Uymayan e-mail | Geçici veya kalıcı ret ya da spam klasörü | Spam klasörü ya da ret | 550 5.7.515 koduyla ret | ## SPF, DKIM ve DMARC: her biri neyi kanıtlar? Üç protokol aynı soruya farklı yerlerden cevap verir: bu e-mail gerçekten bu alan adı adına mı gönderildi? Kurallardaki "hizalama" şartını anlamak için üçünün nasıl birlikte çalıştığını bilmek gerekir. ### SPF: hangi sunucular gönderebilir? SPF ([RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.txt)), alan adı sahibinin kendi adına e-mail gönderebilecek sunucuları DNS'te bir TXT kaydıyla listelemesini sağlar. Alıcı sunucu, e-mailin geldiği IP adresinin bu listede olup olmadığına bakar. SPF'nin pratikte en çok sorun çıkaran kuralı 10 DNS sorgusu sınırıdır. Kayıttaki include ve benzeri ifadeler toplamda 10 sorguyu geçerse SPF değerlendirmesi "permerror" ile sonuçlanır. Her yeni araç için kayda bir include daha eklendikçe bu sınıra yaklaşırsın. SPF, e-mailin teknik zarfındaki (Return-Path) alan adını kontrol eder, alıcının gördüğü From satırını değil. Bu yüzden ESP'nin kendi Return-Path alan adıyla gönderim yaptığı kurulumlarda SPF geçer ama hizalanmaz. ### DKIM: e-mail yolda değişti mi? DKIM ([RFC 6376](https://www.rfc-editor.org/rfc/rfc6376.txt)), gönderen tarafın e-maili kriptografik olarak imzalamasını ve alıcının bu imzayı alan adının DNS'teki açık anahtarıyla doğrulamasını sağlar. İmza hem e-mailin yolda değişmediğini hem de imzalayan alan adının e-mailin sorumluluğunu üstlendiğini gösterir. Burada önemli olan imzanın hangi alan adıyla atıldığıdır. Birçok ESP varsayılan olarak kendi alan adıyla imza atar. DKIM geçer ama imzalayan alan adı senin From alan adın olmadığı için hizalama sağlanmaz. ESP panelinde kendi alan adınla DKIM kurduğunda imza senin alan adınla atılır. ### DMARC ve hizalama DMARC, From satırındaki alan adını SPF veya DKIM'in doğruladığı alan adıyla karşılaştırır. Buna hizalama denir. Google ve Yahoo, toplu göndericiler için SPF ya da DKIM'den birinin hizalı olmasını yeterli sayıyor. Google, SSS sayfasında ileride her ikisinin de hizalı olmasının şart haline gelebileceğini de yazıyor. Hizalamanın iki modu vardır. Gevşek (relaxed) hizalamada alt alan adları ana alan adıyla eşleşmiş sayılır, sıkı (strict) hizalamada alan adlarının birebir aynı olması gerekir. RFC 9989, alan adı sahiplerinin neredeyse tamamının gevşek hizalamayı yeterli bulduğunu not ediyor. Yahoo da gevşek hizalamayı kabul ediyor. DMARC kaydının politika (p) değeri, doğrulamadan geçemeyen e-maillere ne yapılmasını istediğini söyler: none hiçbir tercih bildirmez, quarantine e-maili şüpheli sayar, reject alan adının kullanımının geçersiz olduğunu belirtir. Kayıttaki rua etiketi, alıcı sağlayıcıların sana toplu raporlar göndereceği adresi belirler. Bu etiket yoksa sağlayıcılar rapor üretmez. Yahoo bu etiketi kurulum aşamasında izleme için şiddetle öneriyor. Raporlar XML biçimindedir ve hangi IP adreslerinin senin alan adınla gönderim yaptığını, hangilerinin doğrulamadan geçemediğini gösterir. DMARC, Mayıs 2026'da standart statüsüne geçti. RFC 9989, 2015 tarihli RFC 7489'un yerini aldı ve raporlama kısmı RFC 9990 ile RFC 9991'e ayrıldı. Yeni sürüm, kademeli uygulama için kullanılan pct etiketini kaldırdı ve yerine bir test modu etiketi (t) getirdi. Bazı yardım sayfaları hâlâ pct etiketini anlatıyor, bu yüzden kaydını yazarken güncel standarda bakman iyi olur. #### DMARC politikasını p=none'dan p=reject'e taşımak Gmail ve Yahoo'nun kuralları için p=none yeterli. Ancak p=none, alan adını taklit eden e-maillerin teslim edilmesini engellemez, yalnızca raporlar. Microsoft, politikayı kademeli olarak none, quarantine ve reject sırasıyla sıkılaştırmayı öneriyor. Pratikteki sıra şöyle işler: önce p=none ve rua etiketiyle başlarsın, raporlarda senin adına gönderim yapan bütün kaynakları görürsün, meşru kaynakların hepsi hizalı geçtiğinde quarantine'e, sonra reject'e geçersin. Google'ın [DMARC kurulum sayfasına](https://support.google.com/a/answer/2466580) göre sp etiketini kullanmazsan alt alan adların ana alan adının politikasını devralır. Logonun gelen kutusunda görünmesini sağlayan BIMI (Brand Indicators for Message Identification) bu sıranın sonundaki isteğe bağlı adımdır. Google ve Yahoo, BIMI için DMARC politikasının quarantine veya reject olmasını şart koşuyor. BIMI hâlâ bir RFC değil, IETF'de bir taslak (Internet-Draft) olarak duruyor. #### Senin adına gönderen bütün araçları bulmak Hizalama sorunları çoğu zaman unutulan bir araçtan çıkar. Pazarlama e-maillerini bir ESP'den, işlemsel e-mailleri başka bir servisten, destek yanıtlarını bir yardım masası aracından, faturaları bir muhasebe yazılımından gönderiyor olabilirsin. Her biri From satırında senin alan adını kullanır ve her biri için SPF'ye eklenmesi ve DKIM'in senin alan adınla kurulması gerekir. DMARC raporları bu envanteri çıkarmanın en güvenilir yoludur, çünkü kim olduğunu bilmediğin göndericileri de gösterir. Hangi CRM ve pazarlama otomasyonu araçlarının hangi kanalları yönettiğini [CRM ve pazarlama otomasyonu araçları](https://alidemirbas.com.tr/blog/crm-pazarlama-otomasyonu-araclari) yazısında karşılaştırdım. Araç seçerken kendi alan adınla DKIM ve Return-Path kurulumunu destekleyip desteklemediğine bakmak bu yüzden önemli. ## Tek tıkla abonelikten çıkma ve spam şikayet oranı Pazarlama e-maillerinde abonelikten çıkmayı kolaylaştırmak, spam şikayetini azaltmanın en doğrudan yoludur. Çıkmak isteyen alıcı linki bulamazsa spam düğmesine basar. ### List-Unsubscribe başlıkları (RFC 8058) Tek tıkla abonelikten çıkma, e-mailin başlığına eklenen iki satırla çalışır. List-Unsubscribe başlığı bir HTTPS adresi içerir, List-Unsubscribe-Post başlığı ise "List-Unsubscribe=One-Click" değerini taşır. [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.txt), mesajın bu iki başlığı da kapsayan geçerli bir DKIM imzası taşımasını şart koşuyor. İmza yoksa alıcı sağlayıcının tek tık seçeneğini göstermemesi gerekiyor. Gmail, mailto ya da yalnızca bir URL linkiyle yapılan çıkışı tek tık şartını karşılamış saymıyor. Yahoo POST yöntemini şiddetle öneriyor ama mailto yöntemini de kabul ediyor. Her iki sağlayıcı da e-mail gövdesinde ayrıca görünür bir abonelikten çıkma linki istiyor ve bu link bir tercih sayfasına gidebilir. Bu şart pazarlama ve promosyon e-mailleri için geçerli. Google ve Yahoo, şifre sıfırlama, sipariş onayı ve rezervasyon onayı gibi işlemsel e-mailleri bu şartın dışında tutuyor. Google, bir e-mailin pazarlama mı işlemsel mi olduğuna kendisinin değil alıcıların karar verdiğini de not ediyor. Sipariş onayının içine kampanya koymak bu ayrımı bulanıklaştırır. ### %0,1 ve %0,3 ne demek? Google spam oranını, alıcının gelen kutusuna teslim edilen e-maillerin içinde spam olarak işaretlenenlerin yüzdesi olarak tanımlıyor ve her gün hesaplıyor. %0,1, gelen kutusuna ulaşan her 1.000 e-mailden 1'inin, %0,3 ise 3'ünün spam olarak işaretlenmesi demek. Google %0,1'in altında kalmayı öneriyor ve %0,1'i aşan şikayet oranlarının toplu göndericilerin gelen kutusu teslimatını şimdiden olumsuz etkilediğini yazıyor. %0,3'ü aşan gönderici, oran 7 gün üst üste %0,3'ün altında kalana kadar Google'dan destek ve iyileştirme talep edemiyor. Yahoo da oranı gelen kutusuna teslim edilen e-mailler üzerinden hesaplıyor. Bu oranı en çok zorlayan lifecycle programları, uzun süredir sessiz olan alıcılara giden [yeniden kazanım kampanyaları](https://alidemirbas.com.tr/lab/journeys/eski-musteriyi-geri-kazanma), dışarıdan içe aktarılan listeler ve kısa sürede sıklığı artan gönderimlerdir. Şikayet bütçesini düşünürken toplam gönderimin değil, bu riskli akışların oranına bakmak daha doğru sonuç verir. ## İşlemsel, lifecycle ve kampanya e-maillerini ayırmak Şifre sıfırlama e-mailin ile indirim kampanyan aynı itibarı paylaşırsa, kampanyanın aldığı şikayetler şifre sıfırlamanın gelen kutusuna ulaşmasını zorlaştırabilir. Yahoo bu yüzden e-mail türlerini IP adresine ya da DKIM alan adına göre ayırmayı öneriyor ve toplu pazarlama e-maillerini işlemsel e-maillerle aynı IP'lerden göndermemeyi söylüyor, çünkü her IP adresinin ve DKIM alan adının kendi itibarı var. Google ise mümkünse tek IP adresinden göndermeyi, birden fazla IP kullanmak zorundaysan her mesaj türü için ayrı IP kullanmayı, aynı kategorideki mesajları aynı From adresinden göndermeyi ve promosyonları satış makbuzlarının içine koymamayı öneriyor. Pratikte bu, üç akışı birbirinden ayırmak demek: işlemsel e-mailler (şifre, sipariş, fatura), [lifecycle otomasyonları](https://alidemirbas.com.tr/lab/journeys) (hoş geldin, [sepet hatırlatması](https://alidemirbas.com.tr/lab/journeys/sepet-hatirlatma), yeniden kazanım) ve toplu kampanyalar. Birçok ekip bunu her akış için ayrı bir alt alan adı ve DKIM alan adı kullanarak yapıyor. Bu Google ve Yahoo'nun yazılı bir şartı değil, Yahoo'nun "DKIM alan adına göre ayır" önerisinin bir uygulaması. Bir noktayı unutmamak gerekiyor: Gmail'in 5.000 eşiğinde alt alan adlarından giden e-mailler ana alan adının hacmine eklenir ve Postmaster Tools'taki uyumluluk paneli yalnızca ana alan adları için veri gösterir. ### Gönderim hacmini yavaş artırmak Yeni bir alan adı, alt alan adı ya da IP adresi bir itibar geçmişine sahip değildir. Google, düşük hacimle ve etkileşimli alıcılarla başlamayı, hacmi zamanla yavaş artırmayı, sabit bir hızda göndermeyi ve ani sıçramalardan kaçınmayı öneriyor. Hacmi bir anda ikiye katlamanın hız sınırlamasına ya da itibar kaybına yol açabileceğini, günlük gönderimde hacmin haftalık gönderime göre daha hızlı artırılabileceğini ve e-mailler geri dönmeye ya da ertelenmeye başlarsa hacmin düşürülmesi gerektiğini yazıyor. Yahoo da ani artışların göndericiyi ele geçirilmiş bir hesap gibi gösterebileceğini belirtiyor. Hiçbir sağlayıcı gün gün bir ısıtma takvimi yayımlamıyor. İnternette dolaşan ısıtma tabloları sağlayıcıların değil, ESP'lerin ve danışmanların önerileri. ESP değiştirdiğinde ya da yeni bir alt alan adına geçtiğinde de bu kural geçerli. ## İYS, izin ve liste hijyeni Türkiye'de ticari e-mail göndermek için alıcının onayı gerekir ve bu onaylar İleti Yönetim Sistemi'nde (İYS) tutulur. [Ticaret Bakanlığı](https://ticaret.gov.tr/ic-ticaret/ticari-elektronik-iletiler/ileti-yonetim-sistemi-iys), İYS'yi ticari elektronik ileti onaylarının alınmasına ve ret hakkının kullanılmasına imkân tanıyan elektronik sistem olarak tanımlıyor. Sistem, 6563 sayılı Kanun'da 2017'de yapılan değişikliğe ve Ticari İletişim ve Ticari Elektronik İletiler Hakkında Yönetmelik'te [4 Ocak 2020'de](https://www.resmigazete.gov.tr/eskiler/2020/01/20200104-2.htm) yapılan değişikliğe dayanıyor. Bu yazı hukuki görüş değil. Kendi durumun için yönetmeliğin güncel metnine ve hukuk ekibine bakmalısın. ### İYS izni gelen kutusunu garanti etmez Yönetmelik değişikliğine göre İYS'de onayı bulunmayan alıcılara ticari elektronik ileti gönderilemez ve İYS dışında alınan onaylar üç iş günü içinde İYS'ye kaydedilmezse geçersiz sayılır. Bu, gönderimin yasal olup olmadığının şartıdır. Gmail, Yahoo ve Microsoft ise İYS'ye bakmaz. Onlar alıcının e-maile verdiği tepkiyi, şikayet oranını ve kimlik doğrulamayı ölçer. Yıllar önce onay vermiş ama artık e-maillerini açmayan bir alıcı yasal olarak e-mail almaya uygundur. Ancak spam düğmesine bastığında şikayet oranına yine eklenir. Bu yüzden İYS izni gerekli bir şart ama tek başına gelen kutusuna ulaşmanı sağlamaz. ### Retleri tek bir bastırma listesinde toplamak Bir alıcı iki farklı yoldan abonelikten çıkabilir: e-maildeki tek tık ya da görünür link üzerinden veya doğrudan İYS üzerinden. Yönetmelik, alıcının ret hakkını İYS üzerinden de kullanabileceğini ve hizmet sağlayıcının kendisine iletilen ret bildirimlerini üç iş günü içinde İYS'ye bildirmesini öngörüyor. Google'ın 48 saat önerisi ve Yahoo'nun 2 günlük süresi de düşünüldüğünde, iki kaynaktan gelen retlerin aynı bastırma (suppression) listesine hızlı yazılması gerekiyor. Aksi halde İYS'de reddetmiş bir alıcıya e-mail gidebilir ya da e-mailden çıkmış biri İYS'de hâlâ onaylı görünebilir. Bu senkronizasyonu çoğu zaman CRM aracının hazır İYS entegrasyonu kurar. Hazır entegrasyon ihtiyacını karşılamıyorsa bazı entegrasyonları kendi veri ekiplerin de yapabilir. ### Geri dönen adresler ve pasif aboneler Var olmayan adreslere gönderim sürdükçe, sağlayıcılar bunu listenin bakımsız olduğuna dair bir işaret olarak okur. Kalıcı olarak geri dönen (hard bounce) adresler ilk dönüşte bastırma listesine alınmalı. Uzun süredir hiçbir etkileşim vermeyen aboneler için de bir sonlandırma (sunset) politikası tanımlamak gerekiyor: önce sıklığı azaltırsın, sonra bir tercih sorusu sorarsın, yanıt gelmezse pazarlama gönderimini durdurursun. [Yanıt vermeyen aboneyi sonlandırma](https://alidemirbas.com.tr/lab/journeys/yanit-vermeyen-aboneyi-sonlandirma) journey'si bu akışı adım adım gösteriyor. Hangi abonenin "pasif" sayılacağını belirlerken [RFM (Recency, Frequency, Monetary) analizi](https://alidemirbas.com.tr/blog/rfm-analizi-musteri-segmentasyonu) yazısındaki son etkileşim (recency) mantığı işine yarar. Pasif aboneyi kaybedilmiş müşteriden ayırmak için [churn ve elde tutma metrikleri](https://alidemirbas.com.tr/blog/musteri-elde-tutma-orani-churn-ltv) yazısına da bakabilirsin. Açılma oranını tek ölçüt yapmamak gerekir. Google, kendi tarafında açılma oranlarını takip etmediğini yazıyor ve açılma ölçümü e-mail istemcisine göre şaşabiliyor. Tıklama, satın alma ya da uygulama kullanımı gibi sinyalleri birlikte kullanmak daha güvenilir sonuç verir. ## Teslim edilebilirliği izlemek Spam oranını kendi panelinde göremezsin, onu sağlayıcı ölçer. Google'ın [Postmaster Tools](https://support.google.com/a/answer/14668346?hl=en) aracı, DKIM ile doğrulanmış e-maillerin spam oranını ve alan adının kurallara uyup uymadığını gösteren bir uyumluluk paneli sunuyor. Yahoo, DKIM ile imzalanan her alan adı için şikayet geri bildirim döngüsüne (CFL) kayıt olunmasını istiyor. Bu döngü, Yahoo kullanıcılarının spam olarak işaretlediği e-mailleri sana bildirir. DMARC raporları da her gün hangi kaynakların doğrulamadan geçtiğini gösterir. Bu üç veri kaynağını ESP'deki geri dönme, [şikayet ve abonelikten çıkma oranlarıyla](https://alidemirbas.com.tr/hesaplayicilar/e-posta-performansi-hesaplama) birlikte izlemek, sorunu kampanya bitmeden görmeni sağlar. Google'ın hata kodları da teşhiste yardımcı olur. Örneğin 5.7.26 kimlik doğrulama, 4.7.32 ise From hizalaması sorununa işaret eder. ## Gönderimden önce kontrol listesi Yeni bir alan adıyla, yeni bir ESP'yle ya da yeni bir kampanya akışıyla göndermeye başlamadan önce şu adımları kontrol et: 1. SPF kaydında kullandığın bütün gönderim servisleri var ve DNS sorgu sayısı 10'u geçmiyor. 2. Her servis DKIM imzasını kendi alan adınla atıyor ve anahtar en az 1024, mümkünse 2048 bit. 3. DMARC kaydı yayımlandı, rua etiketi raporları okunan bir adrese gidiyor ve raporlarda tanımadığın bir kaynak yok. 4. From alan adı, SPF ya da DKIM alan adıyla hizalı. 5. Pazarlama e-maillerinde List-Unsubscribe ve List-Unsubscribe-Post başlıkları ile gövdede görünür bir çıkış linki var. 6. E-maildeki çıkışlar ve İYS retleri aynı bastırma listesine yazılıyor ve İYS'ye üç iş günü içinde bildiriliyor. 7. İşlemsel e-mailler ile kampanyalar ayrı akışlardan gidiyor ve işlemsel e-maillerin içinde promosyon yok. 8. Yeni alan adı ya da IP için hacim kademeli artırılıyor ve Postmaster Tools'taki spam oranı %0,1'in altında. Bu listenin her maddesi sağlayıcıların kendi yayımladığı bir kurala ya da standarda dayanıyor. Kurallar değişebildiği için Gmail, Yahoo ve Microsoft'un sayfalarını yılda birkaç kez kontrol etmek ve DMARC raporlarını düzenli okumak, gelen kutusuna ulaşma oranını korumanın en kolay yolu.