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:
- 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. - On DNS sorgusu sınırının aşılması. Her
include,avemxifadesi bir sorgu harcar; toplam onu geçerse kayıt "permerror" verir. Kullanmadığınız servislerin include satırlarını silin. - Yanlış son ek.
~allyumuşak başarısızlık,-allsert reddir. Geçiş dönemindeyken~allile başlayın; raporlar temiz çıktıktan sonra-allyapı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ıdav=spf1ile başlayan tek satır olmalı. İki satır dönüyorsa doğrulama zaten bozuktur.dig +short TXT secici._domainkey.alanadiniz.com—v=DKIM1vep=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 birv=DMARC1satı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_evaluatedaltındakispfvedkim— 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üz | Sebebi | Yapılacak |
|---|---|---|
spf=softfail | Gönderen IP listede değil | Sunucunun çı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=none | Anahtar yayınlanmamış ya da seçici adı yanlış | Seçiciyi DNS'te sorgulayarak doğrulayın |
dmarc=fail (spf ve dkim geçerken) | Hizalama sorunu | Gö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-Unsubscribebaş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
- MX kayıtlarını doğrulayın; posta hangi sunucuya geliyor?
- Tek bir SPF kaydı var, on sorgu sınırının altında.
- DKIM anahtarı yayınlandı ve dış bir alıcıda
dkim=passgörülüyor. - DMARC
p=noneile açıldı, raporlar bir adrese geliyor. - İ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