İçeriğe geç
Yeni yazı çıkınca e-posta · 4.812 abone 115 rehber · 78 ipucu · 33 komut RSS GitHub LinkedIn İletişim
Ara Ctrl K Bültene katıl
Bültene katıl 4.812 abone · yeni yazı çıkınca e-posta
Güvenlik & Entra ID · genel

Gönderdiğimiz e-postalar spama düşüyor

Sorun içerikte değil, kimlik doğrulamada. SPF, DKIM ve DMARC kayıtlarının hangisi eksikse alıcı sunucu ona göre karar veriyor.

8 Ağustos 2026 · yaklaşık 6 dakika
Bu belirtileri yaşıyorsanız doğru yerdesiniz
  • Müşterilere gönderdiğimiz postalar gereksize düşüyor
  • Bazı alıcılara ulaşıyor bazılarına ulaşmıyor
  • Adımıza sahte e-posta gönderilmiş
  • Yeni pazarlama aracından gönderilenler engelleniyor
30 saniyelik çözüm
Resolve-DnsName _dmarc.ornek.com -Type TXT | Select-Object -Expand Strings
Hazır araç

eposta-tanilama.ps1

Alan adının MX, SPF (sorgu sayısı dahil), DKIM seçicileri, DMARC politikası, MTA-STS ve TLS-RPT kayıtlarını DNS üzerinden denetler; eksik ve hatalı olanları sıralar. Yalnızca sorgu yapar.

İndir

Alıcı sunucu, gelen mesaja üç soru sorar: gönderen sunucu yetkili mi (SPF), mesaj yolda değişmiş mi (DKIM), ikisi tutmazsa ne yapmalıyım (DMARC). Üçünden biri eksikse cevap “gereksiz kutusuna at” olur.

İçeriği değiştirmek, konu satırından ünlem işaretini çıkarmak bu kararı değiştirmez.

1. Önce üç kaydı okuyun

.\eposta-tanilama.ps1 -Alan ornek.com

Betik hepsini tek seferde sorar. Elle bakmak isterseniz:

Resolve-DnsName ornek.com -Type TXT | Where-Object Strings -match 'v=spf1'
Resolve-DnsName _dmarc.ornek.com -Type TXT | Select-Object -Expand Strings
Resolve-DnsName selector1._domainkey.ornek.com -Type CNAME

2. En sık çıkan dört hata

Birden çok SPF kaydı. Yeni bir pazarlama aracı eklerken ikinci bir v=spf1 kaydı açmak, RFC’ye göre hatadır: alıcı sunucu ikisini de yok sayabilir. Doğrusu tek kayıtta include: eklemektir.

10 DNS sorgusu sınırının aşılması. Her include, a, mx bir sorgu üretir ve include’ların içindekiler de sayılır. Sınır aşıldığında SPF permerror verir — yani hiç yokmuş gibi davranılır. Beş sağlayıcı eklendikten sonra çoğu kurum farkında olmadan bu durumdadır.

DKIM’in hiç kurulmamış olması. SPF, mesaj yönlendirildiğinde kırılır; DKIM kırılmaz. Yalnızca SPF’e dayanan bir yapılandırma, posta listeleri ve yönlendirmelerde başarısız olur.

DMARC’ın p=none’da unutulması. Rapor toplar, hiçbir şeyi engellemez. Kurumların çoğu yıllarca burada kalır ve korunduğunu sanır.

3. Yeni bir gönderen eklerken

Pazarlama aracı, fatura sistemi, CRM — her biri sizin adınıza gönderir. Eklemeden önce:

  1. Aracın include: kaydını SPF’e ekleyin (yeni bir kayıt açmayın)
  2. Aracın verdiği DKIM kayıtlarını yayınlayın
  3. İlk hafta DMARC raporlarını okuyun: aracın gerçekten hizalı gönderip göndermediği orada görünür

Kayıtları üretmek için SPF, DKIM ve DMARC üreteci aracını kullanabilirsiniz.

Doğrulama

Değişiklik sonrası kendinize değil, dış bir adrese gönderin ve mesaj kaynağındaki Authentication-Results başlığına bakın:

spf=pass ... dkim=pass ... dmarc=pass

Üçü de pass değilse iş bitmemiştir. DNS değişikliklerinin yayılması için TTL kadar beklemeyi unutmayın — aynı gün içinde alınan sonuç yanıltıcı olabilir.

Kalıcı çözüm

DMARC raporlarını toplayan bir adres tanımlayın ve okuyun. Kimin sizin adınıza gönderdiğini başka hiçbir kaynak bu kadar net söylemez; hem spam sorununu hem de sahtecilik girişimlerini aynı yerden görürsünüz.

Bu çözüm işinize yaramadıysa ya da eksik bir adım varsa yazın — güncelliyorum.