webtrajans
tr

SPF, DKIM ve DMARC nedir? E-postalarınız neden spama düşüyor?

Kurumsal e-postaların gelen kutusu yerine spam klasörüne gitmesinin en yaygın nedeni eksik ya da hatalı kimlik doğrulama kayıtlarıdır. Üç DNS kaydıyla bunu düzeltebilirsiniz.

Güncellendi: 5 dk okuma

E-posta protokolü (SMTP) 1980’lerde tasarlandığında, göndericinin gerçekten iddia ettiği kişi olup olmadığını kontrol eden bir mekanizma yoktu. Herkes From: satırına istediği adresi yazabiliyordu. SPF, DKIM ve DMARC bu açığı kapatmak için sonradan eklenen üç katmandır ve üçü de alan adınızın DNS kayıtlarında tanımlanır.

E-postalar neden spama düşer?

Alıcı sunucu (Gmail, Outlook, Yandex…) her gelen iletide kabaca şu soruları sorar:

  1. Bu iletiyi gönderen sunucu, alan adı sahibinin izin verdiği bir sunucu mu? (SPF)
  2. İleti yolda değiştirilmiş mi, gerçekten bu alan adı tarafından imzalanmış mı? (DKIM)
  3. Alan adı sahibi, bu kontroller başarısız olursa ne yapılmasını istiyor? (DMARC)

Bu soruların yanıtı “bilinmiyor” ya da “hayır” ise ileti spama düşer veya hiç teslim edilmez. Özellikle web sitenizin iletişim formu, e-ticaret sipariş bildirimleri ya da bülten gönderimleri gibi üçüncü taraf servislerden giden postalar, bu kayıtlar eksikse ilk etkilenenlerdir.

SPF: Kim adına gönderebilir?

SPF (Sender Policy Framework), alan adınız adına e-posta göndermesine izin verilen sunucuların listesidir. Alan adının kök kaydına eklenen bir TXT kaydıdır:

v=spf1 include:_spf.google.com include:spf.brevo.com ~all
  • v=spf1 kaydın SPF olduğunu belirtir.
  • include: başka bir servisin SPF listesini dahil eder (Google Workspace, Microsoft 365, Brevo, Mailchimp…).
  • ip4: / ip6: belirli bir IP adresine izin verir.
  • Sondaki ~all “listede olmayanlar şüphelidir” (softfail), -all “kesinlikle reddet” (fail) demektir.

Sık yapılan hatalar:

Hata Sonuç Çözüm
İki ayrı v=spf1 kaydı SPF tamamen geçersiz Tek kayıtta birleştirin
10’dan fazla DNS sorgusu (include zinciri) permerror Kullanılmayan servisleri çıkarın
+all kullanmak Herkes sizin adınıza gönderebilir ~all veya -all kullanın
Form eklentisinin sunucusunu eklememek Site bildirimleri spama düşer Hosting’in SPF’ini include edin

DKIM: İleti değiştirilmedi mi?

DKIM (DomainKeys Identified Mail), giden her iletiye sunucunuzun gizli anahtarıyla dijital imza ekler. Alıcı, imzayı doğrulamak için açık anahtarı DNS’te arar. Açık anahtar, bir seçici (selector) adıyla yayınlanır:

google._domainkey.ornek.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

DKIM anahtarını siz üretmezsiniz; e-posta sağlayıcınızın panelinden (Google Workspace → Uygulamalar → Gmail → E-postanın kimliğini doğrulama; Microsoft 365 → Defender → DKIM) alıp DNS’e eklersiniz. Her gönderici servis kendi seçicisini kullanır; birden fazla DKIM kaydı olması normaldir.

DMARC: Başarısız olursa ne olsun?

DMARC, SPF ve DKIM’i birbirine bağlayan politikadır. İki şey yapar: alıcıya başarısız iletilerle ne yapacağını söyler ve size rapor gönderilmesini sağlar. _dmarc alt alan adına eklenen bir TXT kaydıdır:

_dmarc.ornek.com  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"
Politika Anlamı Ne zaman?
p=none Sadece izle, raporla İlk kurulum, 2–4 hafta
p=quarantine Başarısızları spama at Raporlar temiz görünüyorsa
p=reject Başarısızları reddet Tüm kaynaklar doğrulandıktan sonra

DMARC’ın geçmesi için SPF veya DKIM’den en az birinin hem geçmesi hem de From: adresindeki alan adıyla hizalı (aligned) olması gerekir.

Hizalama (alignment) neden önemli?

Bir bülten servisi iletinizi kendi sunucusundan gönderdiğinde SPF kontrolü çoğu zaman servisin kendi alan adı için yapılır (ör. bounce.servis.com). SPF geçer ama alan adı sizin From: adresinizle eşleşmediği için DMARC açısından hizalı sayılmaz. Bu yüzden her gönderici serviste kendi alan adınızla DKIM imzalamayı etkinleştirmek, DMARC’ı geçmenin en güvenilir yoludur.

DMARC kaydına eklenebilecek diğer yararlı etiketler:

Etiket Örnek Anlamı
rua rua=mailto:[email protected] Günlük toplu (aggregate) raporların gönderileceği adres
pct pct=25 Politikanın iletilerin yalnızca bir kısmına uygulanması (kademeli geçiş)
sp sp=reject Alt alan adları için ayrı politika
adkim / aspf adkim=s Sıkı (s) veya esnek (r, varsayılan) hizalama

Toplu raporlar XML dosyası olarak gelir ve elle okunması zordur. Ücretsiz katmanı olan DMARC rapor analiz servisleri bu dosyaları okunabilir tablolara çevirir; hangi IP’lerin sizin adınıza gönderdiğini böylece görürsünüz.

Google, Yahoo ve Microsoft gönderici kuralları

Şubat 2024’ten itibaren Gmail ve Yahoo, Mayıs 2025’ten itibaren de Microsoft (Outlook.com, Hotmail) kişisel posta kutularına gönderilen iletiler için kuralları sıkılaştırdı:

Gereksinim Tüm göndericiler Toplu göndericiler (günde 5.000+ ileti)
SPF veya DKIM Zorunlu SPF ve DKIM birlikte zorunlu
DMARC kaydı Önerilir Zorunlu (en az p=none)
From: alan adı hizalaması — SPF veya DKIM ile hizalı olmalı
Geçerli ters DNS (PTR) ve TLS Zorunlu Zorunlu
Tek tıkla abonelikten çıkma — Pazarlama e-postalarında zorunlu, talepler 2 gün içinde işlenmeli
Spam şikâyet oranı %0,3’ün altında %0,1 altı hedeflenmeli, %0,3 asla aşılmamalı

Kurallara uymayan iletiler önce spama düşüyordu; artık giderek daha sık kalıcı ret hatasıyla (ör. Gmail 5.7.x, Outlook 550 5.7.515) geri dönüyor. Günde 5.000 ileti göndermeseniz bile üç kaydın tamamını kurmak, teslim edilebilirlik için en güvenli yoldur.

Sorun giderme: SPF/DKIM/DMARC başarısız olursa

Bir iletinin neden spama düştüğünü görmek için Gmail’de iletiyi açıp ⋮ → Orijinali göster seçeneğini kullanın. Üstte SPF, DKIM ve DMARC sonuçları PASS / FAIL olarak listelenir.

  • SPF: SOFTFAIL / FAIL → Gönderen sunucunun IP’si SPF kaydınızda yok. Hangi servisin gönderdiğini bulup include değerini ekleyin.
  • SPF: PERMERROR → İki SPF kaydı var veya 10 DNS sorgusu sınırı aşılmış.
  • DKIM: FAIL → DNS’teki açık anahtar yanlış kopyalanmış (tırnak, boşluk, satır bölünmesi) ya da servis farklı bir seçici kullanıyor.
  • DMARC: FAIL → SPF ve DKIM geçse bile hiçbiri From: alan adıyla hizalı değil.

DNS kayıtlarının genel yapısı ve TTL konusunda daha fazla bilgi için DNS kayıtları rehberimize bakın.

Adım adım kurulum

  1. Mevcut durumu kontrol edin. SPF ve DMARC kontrol aracına alan adınızı girin; hangi kayıtların eksik olduğunu görün.
  2. Gönderen tüm servisleri listeleyin. Kurumsal posta (Google/Microsoft/Yandex), hosting’in sunucusu (form bildirimleri), bülten aracı, e-ticaret altyapısı, CRM.
  3. Tek bir SPF kaydı oluşturun ve bu servislerin include değerlerini ekleyin.
  4. Her servis için DKIM’i etkinleştirin ve verdikleri kaydı DNS’e girin.
  5. DMARC’ı p=none ile yayınlayın, raporları birkaç hafta izleyin.
  6. Politikayı sıkılaştırın: önce quarantine, sonra reject.
  7. Kayıtları doğrulayın: DNS sorgulama aracıyla TXT kayıtlarının yayıldığını kontrol edin.

Kontrol listesi

  • Alan adında tek bir v=spf1 kaydı var ve 10 DNS sorgusu sınırının altında.
  • Kullandığınız her gönderici servis için DKIM etkin.
  • _dmarc kaydı var ve en az p=none ile rapor adresi tanımlı.
  • Web sitenizin iletişim formu, alan adınızın kendi SMTP hesabı üzerinden gönderiyor (PHP mail() yerine).
  • Alan adının süresi ve DNS sağlayıcısı belli; WHOIS sorgusuyla kontrol edilebilir.

Sık sorulan sorular

SPF kaydı olmadan e-posta gönderilebilir mi?

Gönderilebilir, ancak Gmail ve Outlook gibi sağlayıcılar kimliği doğrulanmamış iletileri giderek daha sık spama atar ya da reddeder. 2024'ten beri Google ve Yahoo, toplu gönderenlerden SPF, DKIM ve DMARC'ın üçünü de istiyor.

Bir alan adında birden fazla SPF kaydı olabilir mi?

Hayır. Aynı alan adında iki ayrı v=spf1 kaydı olursa SPF 'permerror' verir ve hiç kayıt yokmuş gibi davranılır. Tüm gönderici servisleri tek kayıtta include: ile birleştirin.

DMARC politikasını hemen p=reject yapmalı mıyım?

Hayır. Önce p=none ile birkaç hafta rapor toplayın, meşru tüm gönderici kaynaklarınızın SPF/DKIM'den geçtiğini görün; sonra p=quarantine, en son p=reject'e geçin.

Değişiklikler ne kadar sürede etkinleşir?

DNS kayıtları genellikle birkaç dakika ile birkaç saat içinde yayılır; TTL değeri yüksekse 24 saate kadar sürebilir.

İlgili rehberler