EN
← Bloga dönRehberler

Mailler Spam'e Düşüyor: DNS Kontrol Listesi

Mailler spam'e düşüyor mu? Önce başlıkları okuyun, sonra SPF, DKIM, DMARC hizalaması, reverse DNS, MX ve TLS ayarlarını dig komutlarıyla adım adım kontrol edin.

Yayınlanma: · 6 dk okuma

Meşru e-postalar spam klasörüne düşüyorsa neden iki şeyden biridir: kimlik doğrulama (alıcı, postanın gerçekten sizin alan adınızdan geldiğini doğrulayamıyor) ya da itibar (doğrulayabiliyor ve gördüğünden hoşlanmıyor). DNS birincisini çözer. İkincisini çözmez; ama birincisi düzelmeden yaptığınız başka hiçbir şey hesaba katılmaz.

Bu kontrol listesi, DNS tarafını sorunları en hızlı bulduran sırayla tarıyor. Arkasındaki kavramlar MX, SPF, DKIM ve DMARC yazısında; burada işin pratiğindeyiz.

0. adım — Spam'e düşen bir iletinin başlıklarını okuyun

Tahmin yürütmeyin. Sorunun yaşandığı sağlayıcıda kendi kontrolünüzdeki bir posta kutusuna ileti gönderin, açın ve "orijinali göster" / "kaynağı görüntüle" seçeneğini kullanın. Alıcının eklediği Authentication-Results başlığını bulun:

Authentication-Results: mx.receiver.example;
   spf=pass smtp.mailfrom=bounces.mailer.example;
   dkim=pass header.d=mailer.example header.s=s1;
   dmarc=fail (p=NONE) header.from=example.com

Bu tek başlık, ihtiyacınız olanın çoğunu söyler:

Alan Yanıtladığı soru
spf= ve smtp.mailfrom= Gönderen IP, zarf alan adının SPF kaydıyla eşleşti mi; o alan adı hangisiydi?
dkim= ve header.d= Geçerli bir imza var mıydı, hangi alan adı için?
dmarc= ve header.from= SPF ya da DKIM, alıcının gördüğü alan adı için geçti mi?

Örnekte her şey "pass" ama DMARC yine de başarısız: SPF ve DKIM, example.com için değil, gönderim hizmetinin kendi alan adları için geçmiş. En sık karşılaşılan bulgu budur; 4. adım bununla ilgilenir.

Alıcının eklediği en üstteki Received: satırındaki gönderen IP'yi de not edin; 5. adımda gerekecek.

1. adım — Alan adınız adına posta gönderen her şeyi listeleyin

Doğrulama en çok kimsenin hatırlamadığı bir gönderende başarısız olur: posta kutusu sağlayıcısı, bülten aracı, CRM, e-fatura ya da ön muhasebe sistemi, destek yazılımı, sitedeki iletişim formu, ofisteki tarayıcı, izleme uyarıları. Hepsini yazın. Her biri SPF ya da DKIM ile, tercihen ikisiyle birden kapsanmalıdır.

2. adım — SPF kaydı

$ dig +short example.com TXT | grep spf1
"v=spf1 include:_spf.mailprovider.example include:spf.mailer.example -all"

Kontrol edin:

  • v=spf1 ile başlayan tam olarak bir kayıt var. İki kayıt kalıcı hatadır (permerror); sonuç, hiç kaydınız yokmuş gibidir.
  • 1. adımdaki her gönderen bir include:, ip4: ya da ip6: ile kapsanıyor.
  • Toplamda en fazla 10 DNS sorgusu var. include, a, mx, exists ve redirect ayrı ayrı sayılır, include'lar iç içe de sayılır. Sınırı aşmak da permerror üretir. "SPF flattening" çözümlerine uzanmadan önce artık kullanmadığınız hizmetleri çıkarın.
  • Kayıt ~all ya da -all ile bitiyor. +all tüm interneti yetkilendirir; ?all hiçbir şey söylemez.
  • ptr mekanizması yok. Yavaştır, güvenilmezdir ve SPF standardının kendisi kullanılmamasını önerir.
  • Posta gönderen alt alan adlarının (bulten.example.com) kendi SPF kaydı var. SPF miras alınmaz.

SPF'in neyi denetlediğini unutmayın: From başlığını değil, zarf göndericisini (Return-Path). Bir hizmet kendi geri dönüş (bounce) alan adını kullanıyorsa SPF onların alan adı için geçer; özel return-path tanımlamadıkça DMARC sonucunuza katkısı olmaz.

3. adım — DKIM kaydı

Gerçek bir iletinin DKIM-Signature başlığından seçiciyi (s=) ve alan adını (d=) alın, ardından anahtarı sorgulayın:

$ dig +short s1._domainkey.example.com TXT
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
  • Kayıt var ve bir p= değeri içeriyor. Boş p=, anahtarın iptal edildiği anlamına gelir.
  • Uzun anahtarlar, panelin araya kattığı boşluk ya da satır sonu olmadan birkaç tırnaklı dizgiye bölünmüş.
  • Sağlayıcı izin veriyorsa anahtar 2048 bit; alıcıların kabul ettiği alt sınır 1024'tür.
  • Sağlayıcı TXT yerine CNAME kaydı istediyse bunlar yerinde ve DNS sağlayıcınız tarafından "düzleştirilmemiş" ya da proxy'lenmemiş.
  • d= sizin alan adınız, sağlayıcınınki değil. Çoğu hizmet, "alan adınızı doğrulayın" kurulumunu tamamlayana kadar kendi alan adıyla imzalar. DKIM'in DMARC için sayılmasını sağlayan şey budur.
  • Her gönderim hizmetinin kendi seçicisi var.

Bir alan adının DKIM seçicilerini dışarıdan listelemenin yolu yoktur. Onları ileti başlıklarında ya da sağlayıcının ayarlarında bulursunuz.

4. adım — DMARC ve hizalama

$ dig +short _dmarc.example.com TXT
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
  • _dmarc.example.com adında, v=DMARC1 ile başlayan ve geçerli bir p= içeren tek bir kayıt var.
  • rua= adresini birisi ya da bir araç gerçekten okuyor. Adres başka bir alan adındaysa o alan adının bir yetkilendirme kaydı yayınlaması gerekir.
  • Her gönderen için SPF ya da DKIM'den en az biri From alan adıyla eşleşen bir alan adıyla geçiyor (varsayılan gevşek kipte aynı kurumsal alan adı yeterlidir).

Şubat 2024'ten beri Gmail ve Yahoo, kullanıcılarına günde yaklaşık 5.000 ve üzeri ileti gönderenlerden SPF, DKIM ve hizalamayla birlikte bir DMARC kaydı (en az p=none), ayrıca pazarlama iletilerinde tek tıkla abonelikten çıkma ve düşük şikâyet oranı istiyor. Diğer büyük sağlayıcılar da benzer kurallar duyurdu. Küçük gönderenler için asgari şart SPF ya da DKIM'dir, ama pratikte onlar da aynı ölçütlerle değerlendirilir.

p=none size rapor kazandırır ve asgari şartı karşılar. Alan adını sahteciliğe karşı korumaz. Raporlar tüm meşru kaynakların hizalandığını gösterdiğinde quarantine, ardından reject politikasına geçin.

5. adım — Gönderen sunucu: reverse DNS ve HELO

Yalnızca posta sunucusunu kendiniz işletiyorsanız geçerlidir. 0. adımdaki IP ile:

$ dig +short -x 192.0.2.25
mail.example.com.
$ dig +short mail.example.com
192.0.2.25
  • PTR kaydı var ve sağlayıcının genel varsayılanı değil.
  • Ad, aynı IP'ye geri çözümleniyor.
  • Sunucu EHLO selamlamasında aynı adı kullanıyor.
  • Sunucunun IPv6 adresi varsa aynısı o adres için de geçerli ya da giden posta IPv4 ile sınırlandırılmış.

Ayrıntılar: reverse DNS (PTR) kaydı nedir.

6. adım — MX ve alan adının kendisi

  • Alan adının, posta kabul eden sunucu adlarına (IP'ye ya da CNAME'e değil) bakan çalışır MX kayıtları var. Alıcılar, geri dönen iletileri ve yanıtları alamayan gönderenlere güvenmez.
  • postmaster@ ve abuse@ adresleri bir insana ulaşıyor.
  • Hiç posta göndermeyen alan adları bunu açıkça söylüyor: v=spf1 -all, null MX (0 .) ve v=DMARC1; p=reject. Park edilmiş alan adları sahteciliğin gözdesidir.

7. adım — TLS

  • Giden posta STARTTLS kullanıyor. Gmail şifrelenmemiş iletileri kırmızı kilit simgesiyle işaretler; toplu gönderici kuralları da TLS ister.
  • Kendi MX sunucunuz, süresi dolmamış bir sertifikayla STARTTLS sunuyor:
$ openssl s_client -connect mail.example.com:25 -starttls smtp </dev/null 2>/dev/null \
    | openssl x509 -noout -enddate

8. adım — Kara listeler ve itibar

  • Gönderen IP'yi ve alan adını büyük kara liste işletmecilerinin kendi sorgulama sayfalarında arayın. Tanınmayan bir listede yer almak nadiren önem taşır; yaygın kullanılan birinde yer almak taşır. Çıkarılma talebinden önce nedeni giderin: ele geçirilmiş hesap, korumasız form, satın alınmış liste.
  • Alan adını büyük posta sağlayıcılarının sunduğu postmaster araçlarına kaydedin. Bu araçlar, o sağlayıcıların alan adınızı nasıl gördüğünü gösterir: şikâyet oranı, doğrulama sonuçları, itibar.

DNS kusursuz ama mailler yine spam'e düşüyorsa

O zaman sorun itibar ya da içeriktir ve hiçbir DNS kaydı yardımcı olmaz:

  • ısındırma yapmadan ilk günden yüksek hacim gönderen yeni alan adı ya da yeni IP
  • postayı hiç istememiş ve şikâyet eden alıcılar
  • ölü adreslerle dolu eski listeler
  • bağlantı kısaltıcılar, itibarı zayıf alan adlarına verilen bağlantılar, yalnızca görselden oluşan iletiler
  • bağlantılardaki ve imzadaki alan adından farklı bir From alan adı
  • paylaşımlı IP'lerde diğer müşterilerin davranışı

DNS, sizin kendiniz olarak değerlendirilmenizi sağlar. Bundan sonrası ne gönderdiğinize bağlıdır.

Sık yapılan hatalar

  • Yeni hizmet için mevcut SPF kaydını genişletmek yerine ikinci bir SPF kaydı eklemek.
  • spf=pass ve dkim=pass görüp orada durmak; hangi alan adının geçtiğine bakmamak.
  • Raporları okumadan p=reject politikasına atlayıp unutulmuş bir sistemin gönderdiği faturaları kaybetmek.
  • Yalnızca aynı sağlayıcıdaki kendi posta kutunuzdan kendi posta kutunuza test etmek.
  • Değişikliklerin anında görünmesini beklemek; SPF ve DMARC kayıtları TTL süresince önbellekte kalır.

OrbitProbe ile kontrol edin

OrbitProbe MX sorgulama aracı bir alan adının MX sunucularını ve önceliklerini, olası posta sağlayıcısını, SPF ve DMARC kayıtlarını, yaygın yapılandırma hatalarına dair bulgularla birlikte gösterir. DKIM seçicilerini listeleyemez, çünkü bunu dışarıdan kimse yapamaz; onları 3. adımda anlatıldığı gibi ileti başlığından kontrol edin. Aracı From adresinizdeki alan adı için, ardından posta gönderen her alt alan adı için ayrıca çalıştırın.