E-postalarınız spam klasörüne düşüyorsa nedenini sırayla bulun: kara liste, ters DNS, SPF, DKIM, DMARC, TLS, gönderen itibarı, ileti biçimi ve başlık okuma. Her adımda hangi aracı çalıştıracağınız ve neyi düzelteceğiniz yazıyor.
Gmail, Yahoo ve Outlook.com kimlik doğrulamayı (SPF, DKIM, toplu gönderimde DMARC) ve geçerli ters DNS'i yazılı şart olarak istiyor; uymayan ileti spam'e düşer ya da reddedilir. Sırayla bakın: gönderen IP kara listede mi, ters DNS ileri doğrulanıyor mu, SPF, DKIM ve DMARC geçiyor mu, görünen From alan adıyla hizalı mı; ilk beşini kara liste, ters DNS ve e-posta güvenliği araçlarıyla birkaç dakikada denetlersiniz. Hepsi temizse gerçek bir iletinin başlığındaki Authentication-Results satırını okuyun (9. adım).
Tablo, üç sağlayıcının kendi sayfalarından alındı (erişim 26.10.2026). "Toplu" (bulk), günlük eşiği aşan göndericidir; "herkes" hepsidir. "–": ilgili sayfada böyle bir şart yazmıyor. Outlook sütunu Microsoft'un tüketici hizmetleridir (Outlook.com, Hotmail, Live, MSN).
| Şart | Gmail | Yahoo | Outlook |
|---|---|---|---|
| Toplu gönderici eşiği (günde) | ≈ 5.000 | sayı yok | 5.000 |
| Herkes: kimlik doğrulama | SPF ya da DKIM | SPF ya da DKIM | önerilir |
| Toplu: kimlik doğrulama | SPF ve DKIM | SPF ve DKIM | SPF ve DKIM |
| Toplu: DMARC | en az p=none | en az p=none | en az p=none |
| Hizalama (From ile) | SPF ya da DKIM | SPF ya da DKIM | SPF ve/veya DKIM |
| Ters ve ileri DNS | herkes | herkes | geçerli ters DNS |
| TLS | herkes | – | – |
| Spam oranı | < %0,10 | < %0,3 | – |
| Tek tıkla abonelik iptali | toplu | toplu | – |
| DKIM anahtarı | ≥ 1024 bit | ≥ 1024 bit | – |
5322.From alan adını taşıyan 5.000'den fazla ileti. Uymayan iletiler Önemsiz klasörüne düşebilir ya da 550 5.7.515 ile reddedilebilir. Tek tıkla iptal istemiyor, ama iptal yolunun belgelenmiş ve bulması kolay olmasını şart koşuyor.Kara liste (DNSBL), IP adreslerinin spam kaydını DNS ile yayımlayan listelerdir. Önce iletiyi gerçekten gönderen IP'yi bulun; bu web sitenizin IP'si olmayabilir. Alıcının eklediği Received satırındaki köşeli parantezli adres (9. adımdaki örnek) ya da red iletisinde geçen IP sizin çıkış IP'nizdir.
Kara liste aracı o IP'yi 24 listede tarar; her liste için "listede", "temiz", "sonuç yok" ya da "atlandı" (liste IPv6 desteklemiyor) yazar. "Sonuç yok" temiz sayılmaz: o liste yanıt vermemiştir. Terminalde curl ipsorgu.net/8.8.8.8 çıktısında Blacklist 0 / 24 listede satırı çıkar.
Elle sorgulamak için RFC 5782'nin iki kuralı yeter: liste adı, IP'nin sekizlilerini ters yazıp liste alan adını eklemekle oluşur; her IPv4 listesi test için 127.0.0.2 kaydını tutar. Hangi çözümleyiciye sorduğunuz sonucu değiştirir. Bu yazıdaki komut çıktıları 26.10.2026 tarihlidir ve zamanla değişebilir. Spamhaus'un test adresini üç yoldan sorduk:
$ ip=127.0.0.2
$ rev=$(echo $ip | awk -F. '{print $4"."$3"."$2"."$1}')
$ dig +short $rev.zen.spamhaus.org # yerel çözümleyici
127.255.255.254
$ dig +short @8.8.8.8 $rev.zen.spamhaus.org # Google Public DNS: çıktı boş
$ dig +short @a.gns.spamhaus.org $rev.zen.spamhaus.org # listenin kendi sunucusu
127.0.0.2
127.0.0.10
127.0.0.4
Yerel çözümleyici 127.255.255.254 döndürdü; Spamhaus bu kodu "açık çözümleyiciden gelen sorgu" diye tanımlıyor, "listede" demek değil. 8.8.8.8 boş döndü, yani yanlışlıkla "temiz" göründü; Spamhaus açık çözümleyicilerin çoğunlukla "listede değil" yanıtı aldığını da belirtiyor. Doğru yanıtı yalnızca listenin kendi sunucusu verdi: 127.0.0.2 SBL, 127.0.0.10 PBL, 127.0.0.4 XBL kaydıdır. Aracımız bu yüzden her listeyi yetkili sunucusuna sorar ve 127.255.255.x kodlarını "listede" saymaz. Sunucu adını dig +short NS zen.spamhaus.org verir.
Sorun varsa: nedeni bulun; çıkış adımları için kara listeden çıkma yazısına bakın. PBL kaydı spam kanıtı değildir: Spamhaus'a göre PBL, doğrudan e-posta göndermemesi gereken IP alanını (çoğu kez internet servis sağlayıcıların abone aralıklarını) listeler. PBL'deki bir adresten doğrudan göndermeyin, kimlik doğrulamalı bir SMTP sunucusu kullanın. Spamhaus önce sunucu kayıtlarına bakmanızı da söylüyor: red iletisi yoksa listede olmanın teslimatı etkilediği kanıtlanmış olmaz.
Gmail, gönderen sunucunun genel IP'sinde bir ada çözülen PTR kaydı ister; aynı ad A (IPv4) ya da AAAA (IPv6) kaydıyla yine aynı IP'ye dönmelidir. Buna ileri doğrulanmış ters DNS (forward-confirmed reverse DNS, FCrDNS) denir. Yahoo ayrıca adın anlamlı olmasını, alan adınızı yansıtmasını ve dinamik adres gibi görünmemesini öneriyor; Outlook.com geçerli ters DNS bekliyor. Toplu göndericilere Gmail, PTR eksikse geçici (4.7.23) ya da kalıcı (5.7.25) hata verir. IPv6 ile gönderiyorsanız PTR'yi IPv6 adresi için de isteyin.
Ters DNS aracı PTR adını ve ileri doğrulamayı gösterir; aynı "İleri doğrulama" satırı IP raporunun Sağlayıcı kartında da vardır. E-posta güvenliği raporu da MX sunucularının PTR kaydını denetler, ama bunlar gelen posta sunucularıdır; giden IP'niz farklı olabilir. Komutla (26.10.2026):
$ ip=8.8.8.8 $ ptr=$(dig +short -x $ip | head -1); echo $ptr dns.google. $ dig +short A $ptr | grep -x $ip && echo "FCrDNS tamam" 8.8.8.8 FCrDNS tamam
Sorun varsa: PTR yoksa ilk komut boş döner; ad başka bir IP'ye dönüyorsa ikinci komut eşleşme vermez. Kayıt alan adınızın bölgesinde değil, IP'nin ters bölgesinde (in-addr.arpa) durur; bu bölgeyi IP bloğunun sahibi yönetir. Paylaşımlı hostingte sahibi hosting firmasıdır, kaydı ondan isteyin. Ayrıntı: ters DNS (PTR) yazısı.
SPF, alan adınız adına hangi sunucuların ileti gönderebileceğini bir TXT kaydıyla (kayıt türleri) bildirir. Yetkilendirdiği şey From başlığı değil, zarf göndericisi (MAIL FROM, Return-Path) ve HELO adıdır (RFC 7208). Üç şey aranır: tek bir v=spf1 kaydı (ikincisi permerror verir), en çok 10 DNS araması (include, a, mx, ptr, exists, redirect sayılır; ip4, ip6, all sayılmaz) ve gönderen tüm hizmetlerin kayıtta olması.
E-posta güvenliği raporu kaydı okur, include zincirini izler ve "N / 10 DNS araması" yazar. Kayıt yoksa, birden fazlaysa, 10 aramayı aşıyorsa ya da +all varsa hata; ?all, eksik all ya da ptr için uyarı verir. Terminal çıktısının e-posta bölümü (google.com, 26.10.2026; durum işaretleri çıkarıldı):
$ curl ipsorgu.net/dns/google.com E-posta güvenliği SPF Geçerli v=spf1 include:_spf.google.com ~all · 1/10 DNS araması DKIM Bulunamadı ! 12 yaygın selector denendi DMARC Geçerli p=reject · rua tanımlı MTA-STS Geçerli id=20210803T010101 · mode: enforce BIMI Yok - Kayıt yok (isteğe bağlı; gelen kutusunda logo gösterir)
Elle: dig +short TXT ornek.com | grep spf1. Toplu göndericilerden Gmail SPF ve DKIM'in ikisini birden ister; SPF geçmezse 4.7.27 ya da 5.7.27 verir. Hiç kimlik doğrulaması yoksa 5.7.26 görebilirsiniz.
Sorun varsa: birden fazla v=spf1 kaydını tek satırda birleştirin; 10 aramayı aşıyorsa kullanılmayan include'ları silin. Ayrıntı: SPF yazısı.
DKIM, iletiyi sunucunuzdaki özel anahtarla imzalar; alıcı genel anahtarı seçici._domainkey.alanadi TXT kaydından alıp doğrular. Gmail ve Yahoo en az 1024 bit RSA anahtarı şart koşuyor, 2048 bit öneriyor. RFC 8301 de imzalayanın 1024 bitten kısa anahtar kullanamayacağını, 2048 bitin önerildiğini söylüyor.
Seçici adı bilinmeden DKIM bulunamaz. Aracımız yaygın 12 seçiciyi dener (default, google, selector1, selector2, k1, k2, mail, dkim, s1, s2, smtp, mx) ve bulduğu anahtarın uzunluğunu yazar: 1024 bitten kısası hata, 2048 bitten kısası uyarıdır. "Bulunamadı", DKIM yok demek değildir; yukarıdaki google.com çıktısı bunu gösteriyor. Gerçek seçici, bir iletinin DKIM-Signature başlığındaki s= değeridir (Google da bu yolu anlatıyor). Kaydı sorup uzunluğu ölçmek için Yahoo'nun herkese açık iki seçicisiyle (26.10.2026):
$ for s in s1024 s2048; do
dig +short TXT $s._domainkey.yahoo.com | tr -d '" ' \
| sed 's/.*p=//; s/;.*//' | base64 -d \
| openssl pkey -pubin -inform DER -noout -text | head -1
done
Public-Key: (1024 bit)
Public-Key: (2048 bit)
2048 bitlik anahtar TXT kaydında tırnaklı birden çok parçaya bölünür, alıcı bunları birleştirir; komut tırnakları ve boşlukları bu yüzden siliyor. Eski OpenSSL satırın başına RSA ekler.
Sorun varsa: anahtarı sağlayıcınızın panelinden 2048 bit üretip kaydı ekleyin; paneliniz 2048'i desteklemiyorsa Google 1024'ü öneriyor. Toplu göndericilere Gmail, DKIM geçmezse 4.7.30 ya da 5.7.30 verir.
DMARC, SPF ya da DKIM'in geçmesini ve geçen alan adının görünen From alan adıyla hizalı (aligned) olmasını ister (RFC 9989; Mayıs 2026'da RFC 7489'un yerine geçti). Gevşek hizalamada iki alan adının aynı kuruluş alan adını (organizational domain) taşıması yeter, sıkı hizalamada aynı olmaları gerekir. SPF için karşılaştırılan alan adı MAIL FROM alan adıdır, HELO değil. Bu yüzden SPF ve DKIM ayrı ayrı "pass" iken DMARC "fail" olabilir: hizmet sağlayıcı iletiyi kendi alan adıyla imzalıyor, kendi bounce adresini kullanıyorsa.
Üç sağlayıcı da toplu göndericilerden en az p=none ister. Gmail, DMARC kaydı ya da politikası yoksa 4.7.31, hizalama yoksa 4.7.32 ile iletiyi yavaşlatır. Raporumuz kaydın varlığını, politikayı ve rua adresini denetler; p=none'ı "Zayıf" diye işaretler, bu bir uyarıdır ve üç sağlayıcının asgari şartını karşılar. Hizalamayı raporumuz göremez, çünkü o bir iletinin başlığında görünür.
Sorun varsa: kayıt yoksa en az şunu ekleyin (rua raporların gideceği kutudur):
_dmarc.ornek.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
Politikayı kademeli sıkılaştırmak için DMARC yazısına bakın.
Gmail tüm göndericilerden TLS ile bağlanmasını ister; toplu göndericilere TLS yoksa geçici (4.7.29) ya da kalıcı (5.7.29) hata verir. Denetimi alıcı tarafta yaparsınız: Gmail'e bir ileti gönderin, "Orijinali göster"de by mx.google.com içeren Received satırına bakın. with ESMTPS görmelisiniz; ESMTPS, STARTTLS'in başarıyla kurulduğunu söyler (RFC 3848). Gmail'de alıcı ayrıntılarındaki kırmızı açık kilit de şifresiz bağlantıyı gösterir. Postmaster Tools'un Encryption panosu TLS ile giden iletilerin yüzdesini verir.
Gelen e-posta sunucunuzun TLS desteğini şöyle sınarsınız. Gmail'in sunucusunda ilgili satırlar (26.10.2026; -brief eski sürümlerde ve macOS'in varsayılan openssl'inde yok):
$ openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25 -brief Protocol version: TLSv1.3 Ciphersuite: TLS_AES_256_GCM_SHA384 Peer certificate: CN=mx.google.com Verification: OK
MTA-STS ise gelen e-postanızın şifreli teslimini zorunlu kılar; spam'e düşmenizle doğrudan ilgili değil, isteğe bağlıdır. Rapor _mta-sts TXT kaydını ve https://mta-sts.alanadi/.well-known/mta-sts.txt politikasını denetler; mode değeri enforce, testing ya da none olabilir (RFC 8461). Gmail'in kaydı v=STSv1; id=20190429T010101; biçimindedir (26.10.2026).
Sorun varsa: giden TLS'i posta sunucusunun ayarı belirler. Kendi sunucunuzda dışa giden bağlantıda STARTTLS'i açın; paylaşımlı hostingte hosting firmasından isteyin.
Alıcılar yalnızca kayıtlarınıza değil, geçmişinize de bakar. Google'a göre paylaşımlı IP'de herhangi bir göndericinin davranışı o IP'yi kullanan herkesin itibarını etkiler; paylaşımlı IP'nin kara listede olmadığından emin olun (1. adım). Hıza da bakın. Google hacmi yavaş artırmanızı, düzenli bir hızla göndermenizi ve ani sıçramalardan kaçınmanızı öneriyor. Microsoft, şikâyet oranı düşük kalırsa yeni bir IP'nin birkaç hafta ya da daha kısa sürede itibar kazandığını belirtiyor. Yahoo, pazarlama iletilerini işlem iletilerinden ayrı IP ya da DKIM alan adıyla göndermenizi istiyor.
Google Postmaster Tools'a alan adınızı DNS kaydıyla doğrulayarak ekleyin. Spam oranı panosu, gelen kutusuna ulaşan iletilerden kullanıcıların spam diye işaretlediklerinin yüzdesini gösterir; %0,10'un altında kalın. Üç uyarı: pano yalnızca DKIM ile doğrulanmış iletileri sayar; Gmail'in kendiliğinden spam'e attığı iletiler orana girmez, yani düşük oran spam'e düşmediğinizi kanıtlamaz; günlük hacim azsa pano boş kalabilir. Compliance status panosu şartları tek tek "Compliant", "Needs work" ya da "No data found" olarak gösterir; değişiklikler 7 güne kadar geç yansır. Microsoft'un ücretsiz SNDS ve JMRP hizmetleri IP'nizin Outlook.com'daki görünümünü ve şikâyetleri gösterir.
Sorun varsa: yalnızca isteyen alıcılara gönderin, abonelik iptalini kolaylaştırın, hacmi azaltıp yavaş artırın.
RFC 5322 yalnızca Date ve From başlıklarını zorunlu tutar, ikisi de tam bir kez bulunur; Message-ID için "olmalı" (SHOULD) der. Gmail daha katıdır: geçerli bir Message-ID ister, From, To, Subject, Date gibi tekil başlıkların bir kez geçmesini, From'da tek adres bulunmasını ve HTML'in standartlara uymasını bekler; içeriği gizleyen HTML/CSS'ten ve gerçek yanıt olmayan "Re:" konularından kaçınmanızı ister. Biçim bozuksa Gmail hata verir ya da iletiyi spam'e yollar.
Bir örnek iletişim formudur: From'u ziyaretçinin adresiyle doldurmayın. İletiyi sizin sunucunuz gönderdiği için hizalama tutmaz (5. adım). Google, Gmail adresini From'da taklit etmenin teslimatı etkileyebileceğini, Microsoft ise From ya da Reply-To adresinin gerçek gönderen alan adını yansıtmasını istiyor. From kendi alan adınızda olsun, ziyaretçiyi Reply-To'ya yazın.
Toplu gönderiyorsanız pazarlama ve abonelik iletilerinde tek tıkla abonelik iptali (one-click unsubscribe) için iki başlık gerekir (Google'ın örneği):
List-Unsubscribe: <https://ornek.com/abonelik-iptal/Ab12Cd34> List-Unsubscribe-Post: List-Unsubscribe=One-Click
RFC 8058: List-Unsubscribe bir HTTPS adresi içermeli, ileti bu iki başlığı kapsayan geçerli bir DKIM imzası taşımalı, POST isteği yönlendirme döndürmemeli. Gmail yalnızca bu başlıkları sayar: gövdedeki bağlantı ya da mailto: tek tıkla iptal sayılmaz. Yahoo mailto: yöntemini kabul edilebilir, POST yöntemini ise şiddetle önerilir diye yazıyor. Şifre sıfırlama gibi işlem iletileri kapsam dışıdır. Gmail iptalin 48 saat içinde işlenmesini öneriyor, Yahoo 2 gün içinde işlenmesini istiyor.
Gmail: iletiyi açın, Yanıtla'nın yanındaki üç nokta menüsünden "Orijinali göster"i seçin, "Panoya kopyala" ile başlıkları alın. Google Yönetici Araç Kutusu'nun İleti Üstbilgisi aracı bunları çözümler. Outlook.com ve yeni Outlook: More actions (diğer eylemler) > View > View message details. Klasik Outlook: iletiyi çift tıklayıp açın, Dosya > Özellikler, "Internet üst bilgileri" kutusu. Aşağıdaki örnek anonimleştirilmiş ve kısaltılmıştır; Gmail'in parantez içi açıklama metinleri belgelenmemiştir ve değişebilir, okunacak olan pass ve fail sonuçlarıdır.
Received: from mail.ornek.com (mail.ornek.com. [203.0.113.25])
by mx.google.com with ESMTPS id ...
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 26 Oct 2026 10:15:02 -0700 (PDT)
Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=default;
spf=pass (google.com: domain of [email protected] designates
203.0.113.25 as permitted sender) [email protected];
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ornek.com
Received: köşeli parantezdeki adres gönderen IP'dir (1. ve 2. adımda sorgulayın); ESMTPS ve TLS1_3 TLS kullanıldığını gösterir (6. adım).smtp.mailfrom SPF'nin, header.i (Outlook.com'da header.d) DKIM'in, header.from DMARC'ın esas aldığı alan adıdır. dmarc=pass için header.from ile ilk ikisinden biri hizalı olmalı.mx.google.com); gönderen sahte bir satır ekleyebilir (RFC 8601, bölüm 7.1).spf=pass (sender IP is 203.0.113.25) smtp.mailfrom=ornek.com; dkim=pass (signature was verified) header.d=ornek.com; dmarc=pass action=none header.from=ornek.com.Hizalama hatasının tipik görünümü: spf=pass ve dkim=pass, ama smtp.mailfrom ile DKIM alan adı hizmet sağlayıcınınki (hizmet.example), header.from=ornek.com ve dmarc=fail. İkisi geçti, hizalı değil. Sağlayıcının panelinde alan adınızı doğrulayıp iletiyi kendi alan adınızla imzalatın; Microsoft da aynı kontrolü öneriyor.
Kendi sitemizde yaşadık: gönderim IP'miz Microsoft tarafında engellenmişti. Microsoft alıcılarına (Outlook.com, Hotmail.com, Live.com, MSN.com) giden iletiler 5.7.1 koduyla reddediliyordu ve sunucunun teslimat kayıtlarında görünüyordu. Giriş e-postaları için ayrı bir gönderim hizmetine geçerek çözdük.
Belirti. Bu adreslere giden iletiler şu biçimde geri döner (Microsoft Q&A'da kullanıcılar aynı metni aktarıyor; IP belgeleme adresiyle değiştirildi):
550 5.7.1 Unfortunately, messages from [203.0.113.25] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors.
Neden. İleti, engelin köşeli parantezdeki IP'ye ve bulunduğu ağa uygulandığını söylüyor. Microsoft'un filtreleri IP, alan adı, kimlik doğrulama, liste doğruluğu, şikâyet oranı ve içeriğe bakar; şikâyet oranı başlıca etkenlerden. Paylaşımlı hostingte IP'yi başkalarıyla paylaşırsınız (7. adım). S3150 kodunun anlamını Microsoft'un yayımlanmış belgelerinde bulamadık. Bu liste taradığımız 24 herkese açık listeden biri de değil: kara liste raporunuz temiz çıkıp yine de engelli olabilirsiniz.
Ne yapılır.
sender.office.com Outlook.com için değil, Microsoft 365 (kurumsal) alıcıları içindir: 5.7.606-649 koduyla dönen iletilerde orada, 5.7.511 için [email protected] adresine başvurulur (Microsoft belgesi).Reddedilen iletiyi aynı IP'den tekrar tekrar göndermeyin: Microsoft, 5xx kalıcı hatadan sonra aynı iletinin yeniden denenmemesini şart koşuyor.
DKIM-Signature başlığından alın (4. adım).v=spf1 kaydı permerror verir; kayıtları birleştirin.From'u ziyaretçinin adresiyle doldurmak (8. adım).Yazıdaki teknik bilgiler yukarıdaki kaynaklardan alınmış, komutlar ve örnekler çalıştırılarak denetlenmiştir. Bir hata görürseniz bize yazın; düzeltmeyi tarihiyle birlikte ekleriz.