İçeriğe geç
  • Hafta içi 08:00 – 18:00 · Destek 7/24
  1. Ana Sayfa
  2. Blog
  3. Alan Adı ve E-posta

E-posta teslimatı: SPF, DKIM ve DMARC üçlüsünü doğru kurmak

Gönderdiğiniz e-postalar spam klasörüne mi düşüyor? Üç kimlik doğrulama kaydını sırayla, doğrulayarak kurmanın yolu ve sık yapılan hatalar.

Gmail ve Outlook, 2024'ten bu yana toplu gönderim yapan alan adlarında kimlik doğrulamayı zorunlu tutuyor. SPF, DKIM ve DMARC kurulu değilse iletiniz ya spam klasörüne düşer ya doğrudan reddedilir. Üçü birbirini tamamlar; birini kurup diğerlerini atlamak yarım çözümdür.

Üç kayıt, üç ayrı soru

  • SPF — "Bu alan adı adına hangi sunucular posta gönderebilir?" Alıcı, bağlantıyı kuran IP adresini bu listeyle karşılaştırır.
  • DKIM — "İleti yolda değiştirildi mi ve gerçekten bu alan adından mı çıktı?" Gönderen sunucu iletiyi özel anahtarla imzalar; alıcı, DNS'teki genel anahtarla doğrular.
  • DMARC — "SPF ve DKIM başarısız olursa ne yapayım, sonucu kime bildireyim?" Politika ve raporlama katmanıdır.

SPF: tek satır, üç tuzak

SPF, alan adının kökünde bir TXT kaydıdır:

v=spf1 a mx include:_spf.turklokasyon.com ~all

Üç hata sık tekrarlanır:

  1. Birden fazla SPF kaydı. Alan adı başına yalnız bir TXT SPF kaydı olabilir. İkincisini eklemek doğrulamayı tamamen geçersiz kılar; yeni sunucuları mevcut satıra include: ile ekleyin.
  2. On DNS sorgusu sınırının aşılması. Her include, a ve mx ifadesi bir sorgu harcar; toplam onu geçerse kayıt "permerror" verir. Kullanmadığınız servislerin include satırlarını silin.
  3. Yanlış son ek. ~all yumuşak başarısızlık, -all sert reddir. Geçiş dönemindeyken ~all ile başlayın; raporlar temiz çıktıktan sonra -all yapın.

DKIM: anahtarı üretin, yayınlayın, doğrulayın

cPanel'de Email Deliverability ekranı DKIM anahtarını üretir ve önerilen TXT kaydını gösterir. Alan adınızın DNS'i başka bir yerde yönetiliyorsa kaydı oraya elle eklemeniz gerekir. Seçici (selector) adı önemlidir: kayıt secici._domainkey.alanadiniz.com biçiminde yayınlanır.

Kurulumdan sonra kendinize değil, dışarıdaki bir adrese test iletisi gönderin. Gmail'de iletiyi açıp "Orijinali göster" dediğinizde başlıkta üç satırı da görmelisiniz:

spf=pass · dkim=pass · dmarc=pass

Anahtar uzunluğunu 2048 bit seçin. Bazı DNS sağlayıcıları 255 karakterden uzun TXT değerini kabul etmez; bu durumda kayıt tırnaklarla parçalara bölünerek girilir.

DMARC: gözlemle başlayın, sonra sıkıştırın

_dmarc.alanadiniz.com altında bir TXT kaydı oluşturun. İlk gün şu satırla başlayın:

v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

p=none hiçbir iletiyi engellemez, yalnız rapor toplar. Bir iki hafta raporları okuyun: alan adınız adına gönderim yapan ama sizin bilmediğiniz servisler çıkabilir — fatura sistemi, haber bülteni aracı, CRM. Hepsini SPF ve DKIM'e ekledikten sonra politikayı kademeli sıkıştırın: p=quarantine, ardından p=reject. Doğrudan p=reject ile başlamak, kendi faturalarınızın müşterilere ulaşmamasıyla sonuçlanabilir.

Üç kaydı da tek oturumda doğrulayın

Panelde "kaydedildi" yazısını görmek yeterli değildir; kayıtların DNS'te yayınlandığını dışarıdan sorgulayın:

  • dig +short TXT alanadiniz.com — çıktıda v=spf1 ile başlayan tek satır olmalı. İki satır dönüyorsa doğrulama zaten bozuktur.
  • dig +short TXT secici._domainkey.alanadiniz.comv=DKIM1 ve p= ile başlayan uzun anahtar dönmeli. Boş dönüyorsa seçici adı yanlış yazılmıştır.
  • dig +short TXT _dmarc.alanadiniz.com — tek bir v=DMARC1 satırı.

Değişiklikten sonra hâlâ eski değeri görüyorsanız TTL süresi dolmamıştır. Kayıtlarla uğraşmaya başlamadan önce TTL'i 300 saniyeye düşürün; hatalı bir satırı saatler yerine dakikalar içinde geri alırsınız. Her şey oturduktan sonra 3600'e çıkarmayı unutmayın.

Hizalama (alignment) neden önemli?

DMARC yalnız SPF veya DKIM'in geçmesini istemez; geçen kimliğin From: başlığındaki alan adıyla hizalı olmasını da ister. Üçüncü taraf bir bülten servisi kendi alan adıyla imzalıyorsa SPF geçer ama hizalama başarısız olur ve DMARC düşer. Çözüm, servisin kendi alt alan adınız üzerinden gönderim yapmasını sağlamak ve DKIM anahtarını sizin alan adınıza tanımlamaktır.

Gelen DMARC raporlarını okumak

Raporlar sıkıştırılmış XML dosyaları olarak gelir; her biri bir günlük gönderimi kaynak IP adresine göre gruplar. Dört alan işinizi görür:

  • source_ip — gönderimi yapan sunucu. Tanımadığınız her adres araştırılır.
  • count — o adresten kaç ileti geçtiği. Tek haneli sayılar genelde yönlendirmedir; binli sayılar gerçek bir gönderim kaynağını gösterir.
  • policy_evaluated altındaki spf ve dkim — hizalama dahil edilerek hesaplanmış sonuç. Asıl bakılacak yer burasıdır.
  • header_from — alıcının ekranda gördüğü alan adı.

İlk hafta neredeyse her kurumda aynı üç sürpriz çıkar: muhasebe yazılımının kendi SMTP sunucusu, e-ticaret altyapısının sipariş bildirimleri ve çalışanların kişisel araçlarla yaptığı gönderimler. Politikayı sıkıştırmadan önce bu üçünü kayıtlara eklemek, kesintiyi tamamen önler.

XML'i elle okumak zorunda değilsiniz; ücretsiz bir rapor toplayıcıya rua adresini vermek çıktıyı tabloya çevirir. Kendi kutunuza da bir kopya gidecek şekilde iki adres tanımlayın, servis kapanırsa görünürlüğü toptan kaybetmeyin.

Başlıktaki hata satırı ne anlama geliyor?

Başlıkta gördüğünüzSebebiYapılacak
spf=softfailGönderen IP listede değilSunucunun çıkış IP'sini SPF kaydına ekleyin
spf=permerrorİki SPF kaydı ya da on sorgu sınırının aşılmasıKullanılmayan include satırlarını silin
dkim=fail (body hash did not verify)İleti imzalandıktan sonra değiştirildi; çoğunlukla altbilgi ekleyen liste yazılımıİçerik ekleyen aracıyı imzalayan sunucudan önceye alın
dkim=noneAnahtar yayınlanmamış ya da seçici adı yanlışSeçiciyi DNS'te sorgulayarak doğrulayın
dmarc=fail (spf ve dkim geçerken)Hizalama sorunuGönderimi From: alan adıyla imzalatın

Kimlik doğrulama tek başına yetmez

Kayıtlar doğruyken de spam klasörüne düşülebilir. Geriye kalan üç etken:

  • IP itibarı. Yeni bir gönderim IP'si "ısıtılmadan" günde binlerce ileti göndermek doğrudan bloklanma sebebidir. Hacmi birkaç hafta içinde kademeli artırın.
  • Liste hijyeni. Geri dönen (bounce) adresleri listeden çıkarın. Yüksek geri dönüş oranı, alan adının itibarını doğrudan düşürür.
  • İçerik ve abonelik. Toplu iletilerde List-Unsubscribe başlığı bulunsun; şikâyet oranını en çok bu düşürür.

Sonraki katman: aktarımın şifreli olduğunu garantiye almak

Üçlü, iletinin kimliğini doğrular; yolda şifreli gittiğini garanti etmez. Bunun için iki kayıt daha vardır. _mta-sts altında yayınlanan politika, gönderen sunuculara size yalnız geçerli sertifikayla ve TLS üzerinden bağlanmalarını şart koşar; _smtp._tls altındaki TLS-RPT kaydı ise başarısız bağlantıları günlük rapor olarak gönderir. Politikanın çalışması için posta sunucunuzun sertifikasının MX adıyla eşleşmesi gerekir — sertifika yazısındaki ad doğrulama kuralları burada da geçerlidir. Bu katman zorunlu değildir; kimlik doğrulama üçlüsü tam oturmadan başlamayın.

Kontrol listesi

  1. MX kayıtlarını doğrulayın; posta hangi sunucuya geliyor?
  2. Tek bir SPF kaydı var, on sorgu sınırının altında.
  3. DKIM anahtarı yayınlandı ve dış bir alıcıda dkim=pass görülüyor.
  4. DMARC p=none ile açıldı, raporlar bir adrese geliyor.
  5. İki hafta sonra raporlar temizse politika sıkıştırıldı.

Alan adınızın DNS kayıtlarını nasıl yöneteceğinizden emin değilseniz DNS kayıt türleri yazısına göz atın; alan adı ve DNS yönetimini tek panelden yapmak isterseniz alan adı hizmetimiz bu kayıtları arayüzden düzenlemenize izin verir.

  • #e-posta
  • #dns
  • #teslimat
Bu yazıdaki adımları uygulayacak bir altyapı mı arıyorsunuz? Satış ekibimiz mevcut kurulumunuzu dinleyip uygun paketi önersin; kurulum ve taşıma bizde.
Devamı

İlgili yazılar