SPF, DKIM ve DMARC: E-postalarınız Neden Spam'e Düşüyor

Müşterinize teklif gönderdiniz, gelmedi. Fatura yolladınız, spam klasöründe bulundu. Kendi alan adınızdan yazdığınız halde e-postalarınız güvenilmez görünüyor. Bunun sebebi çoğu zaman içeriğiniz değil, alan adınızın kimlik doğrulama kayıtlarının eksik olmasıdır.

SPF, DKIM ve DMARC, "bu e-posta gerçekten bu alan adından mı gönderildi?" sorusuna cevap veren üç DNS kaydıdır. Üçü de yoksa, alıcı sunucu sizi tanımaz ve şüpheyle yaklaşır. Bu yazıda üçünün ne işe yaradığını, nasıl kurulduğunu ve en sık yapılan hataları anlatıyoruz.

Üç kayıt, üç ayrı soru

Üçü birbirini tamamlar. Yalnızca SPF kurmak, üçte bir koruma demektir.

SPF: kim göndermeye yetkili

SPF (Sender Policy Framework), alan adınız adına hangi sunucuların e-posta gönderebileceğini listeleyen bir DNS TXT kaydıdır.

Basit bir örnek:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Bu kayıt şunu söyler: "Google Workspace ve SendGrid benim adıma gönderebilir; başkasından gelen mesajlara şüpheyle yaklaşın."

Sondaki işaret önemlidir:

• ~all (softfail): Listede olmayan sunucudan gelen mesaj kabul edilir ama işaretlenir. Geçiş döneminde kullanılır.
• -all (hardfail): Listede olmayan reddedilir. Kurulum oturduktan sonraki hedef budur.
• +all: Herkese izin verir. Asla kullanmayın, SPF'yi anlamsız kılar.

SPF'de en sık iki hata

1. Birden fazla SPF kaydı. Bir alan adında yalnızca tek bir SPF kaydı olabilir. İki ayrı v=spf1 satırı varsa standart gereği kayıt geçersiz sayılır ve doğrulama tamamen başarısız olur. Yeni bir servis eklerken yeni kayıt açmayın, mevcut kaydın içine include: ekleyin.

2. On sorgu sınırının aşılması. SPF değerlendirilirken en fazla 10 DNS sorgusu yapılabilir. Her include: en az bir sorgu harcar ve bazı sağlayıcıların include'ları kendi içinde başka include'lar barındırır. Sınır aşılırsa kayıt permerror verir ve çalışmaz.

Beş altı farklı servis (e-posta sağlayıcı, bülten aracı, CRM, fatura sistemi, form servisi) kullanıyorsanız bu sınıra çarpma ihtimaliniz yüksektir. Kullanmadığınız servisleri kayıttan çıkarmak ilk çözümdür.

DKIM: mesaj yolda değişti mi

DKIM (DomainKeys Identified Mail), giden her mesaja görünmez bir imza ekler. Alıcı sunucu, DNS'inizde yayınladığınız açık anahtarla bu imzayı doğrular. İmza tutuyorsa mesaj yolda değiştirilmemiş ve gerçekten sizin sunucunuzdan çıkmış demektir.

Kurulumu sağlayıcıya bağlıdır: e-posta sağlayıcınız size bir seçici (selector) ve bir açık anahtar verir, siz de bunu DNS'e TXT kaydı olarak eklersiniz:

selector1._domainkey.alanadiniz.com   TXT   "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

Birden fazla servisten gönderim yapıyorsanız her biri için ayrı seçici kullanılır; bunlar birbiriyle çakışmaz. SPF'nin aksine DKIM'de "tek kayıt" sınırı yoktur.

Dikkat edilecek nokta: e-posta sağlayıcınızı değiştirdiğinizde eski DKIM kayıtlarını temizleyin. Kullanılmayan anahtarlar bırakılan açık kapılardır.

DMARC: kural ve raporlama

DMARC, SPF ve DKIM başarısız olduğunda ne yapılacağını söyler. Ayrıca — çoğu kişinin atladığı asıl faydası — kim sizin adınıza mail atıyor onun raporunu size gönderir.

_dmarc.alanadiniz.com   TXT   "v=DMARC1; p=none; rua=mailto:[email protected]; pct=100"

Politika (p=) üç değer alır:

• none: Hiçbir şey yapma, sadece rapor gönder. Başlangıç noktası budur.
• quarantine: Başarısız mesajları spam klasörüne at.
• reject: Başarısız mesajları tamamen reddet.

Aşamalı geçiş şart

En sık yapılan hata, ilk günden p=reject ile başlamaktır. Kendi kullandığınız ama farkında olmadığınız bir servis (fatura sistemi, randevu yazılımı, e-ticaret bildirimleri) SPF listenizde yoksa, o servisin gönderdiği e-postalar tamamen reddedilir ve kimse fark etmez.

Doğru sıra:

1. p=none ile başlayın, raporları toplayın.
2. Raporlarda görünen tüm meşru göndericileri SPF ve DKIM'e ekleyin.
3. Birkaç hafta sonra p=quarantine yapın, pct=25 gibi kademeli oranla başlayabilirsiniz.
4. Her şey temizse p=reject'e geçin.

Bu geçiş tipik olarak 4-8 hafta sürer. Acele etmenin bedeli, giden faturaların müşteriye ulaşmamasıdır.

Mevcut durumunuzu kontrol edin

Kayıtlarınızın doğru olup olmadığını görmek için Mail Sağlık Kontrolü aracımıza alan adınızı girin: SPF, DKIM ve DMARC kayıtlarınızı okuyup eksikleri ve hataları listeler.

Ham DNS kayıtlarını görmek isterseniz DNS Sorgulama aracı TXT kayıtlarını olduğu gibi gösterir.

Kontrol listesi

• Alan adında tek SPF kaydı var
• SPF'de kullanılmayan servis yok, 10 sorgu sınırı aşılmıyor
• SPF ~all veya -all ile bitiyor (+all yok)
• Gönderim yapan her servis için DKIM seçicisi tanımlı
• Eski/kullanılmayan DKIM anahtarları temizlenmiş
• DMARC kaydı var ve rua adresi izleniyor
• DMARC politikası kademeli olarak sıkılaştırılıyor
• Alan adı sahipliği devredilirken kayıtlar gözden geçirilmiş

Sık sorulanlar

Kayıtlar ne kadar sürede geçerli olur? DNS yayılması genelde birkaç dakika ile birkaç saat arasındadır; TTL değerine bağlıdır.

Hiç e-posta göndermediğim bir alan adım var, yine de gerekli mi? Evet, hatta daha da gerekli. Gönderim yapmayan alan adları sahtecilik için idealdir. Böyle alan adlarına v=spf1 -all ve p=reject verin — kimse o alan adı adına mail atamaz.

Alt alan adları da kapsanır mı? DMARC'ta sp= parametresiyle alt alan adı politikası ayrı belirlenir. Belirtilmezse ana politika geçerli olur.

Raporları okumak

DMARC kaydına rua= adresi yazdığınızda, alıcı sunucular size günlük XML raporları göndermeye başlar. Ham hâlleri okunaksızdır ama içlerindeki bilgi değerlidir:

• Hangi IP adresleri sizin alan adınız adına mail gönderiyor
• Bu gönderimlerin kaçı SPF ve DKIM doğrulamasından geçiyor
• Geçemeyenler hangi servisten kaynaklanıyor

Raporlarda beklemediğiniz bir gönderici görürseniz iki ihtimal var: ya unuttuğunuz meşru bir servis (eski bir form aracı, muhasebe yazılımı) ya da alan adınızı taklit eden biri. İkisi de bilmeniz gereken şeyler.

Rapor adresini kurumsal e-postanıza değil, ayrı bir kutuya yönlendirmenizi öneririz; günlük hacim yüksek olabilir.

Yaygın sağlayıcılarda SPF kaydı

Kullandığınız servisin include: değerini bilmiyorsanız, sağlayıcının belgelerinde "SPF record" başlığı altında bulunur. Sık kullanılanlar:

Bunları tek bir kayıtta birleştirirsiniz:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Hosting sağlayıcınızın sunucusundan da mail gidiyorsa (iletişim formu bildirimleri gibi) onun IP adresini de eklemeniz gerekir: ip4:203.0.113.10 biçiminde.

BIMI: logonuz gelen kutusunda

DMARC'ı quarantine veya reject seviyesine getirdiyseniz bir adım daha atabilirsiniz. BIMI (Brand Indicators for Message Identification), markanızın logosunun alıcının gelen kutusunda görünmesini sağlar.

Gereksinimleri:

• DMARC politikası en az quarantine
• Logonun SVG Tiny PS formatında yayınlanması
• Bazı sağlayıcılar için doğrulanmış marka sertifikası (VMC)

Zorunlu değil ama kurumsal görünürlük açısından farkedilir bir katkı sağlar. Kimlik doğrulama zincirinizi tamamladıysanız değerlendirmeye değer.

Alan adı devri ve taşınma

E-posta sağlayıcısı değiştirirken en sık yaşanan sorun, geçiş sırasında kayıtların yarım kalmasıdır. Sırayla ilerleyin:

1. Yeni sağlayıcıyı SPF kaydına ekleyin (eskisini henüz çıkarmayın).
2. Yeni DKIM seçicisini yayınlayın.
3. Gönderimi yeni sağlayıcıya taşıyın.
4. Birkaç gün rapor izleyin.
5. Eski sağlayıcıyı SPF'den ve eski DKIM kaydını DNS'ten çıkarın.

Mevcut kutularınızı yeni sunucuya taşımanız gerekiyorsa IMAP Taşıma aracı klasör yapısını koruyarak aktarım yapar.

Kontrolü otomatikleştirin

Kayıtlar bir kere kurulduktan sonra unutulur; ama DNS değişiklikleri, sağlayıcı güncellemeleri veya bir eklentinin eklediği yeni kayıt sessizce yapıyı bozabilir. Üç ayda bir kontrol etmeyi alışkanlık hâline getirin.

Hızlı bir kontrol için Mail Sağlık Kontrolü aracına alan adınızı girmeniz yeterli; SPF, DKIM ve DMARC durumunu tek ekranda görürsünüz.

Sonuç

Bu üç kayıt, teslim edilebilirliğin temelidir. Kurulumları bir kereliktir ama yanlış yapıldığında sessizce zarar verir: e-postalarınızın ulaşmadığını genelde müşteri "size yazmıştım" dediğinde fark edersiniz.

Kurumsal e-posta altyapınızın kurulumu veya taşınması için hizmetlerimize göz atabilir, mevcut yapınızın denetimi için bize ulaşabilirsiniz.