SPF, DKIM ve DMARC Kayıtlarını Sıfırdan Kurma: Maillerin Spama Düşmesini Engelleyen 3 DNS Kaydı

Kısa cevap: Maillerinizin spam klasörüne düşmesinin en yaygın sebebi eksik veya hatalı mail kimlik doğrulama kayıtlarıdır. Alan adınızın DNS bölgesine üç kayıt eklemeniz gerekir: gönderime yetkili sunucuları listeleyen SPF, her maile dijital imza ekleyen DKIM ve bu ikisi başarısız olduğunda alıcı sunucuya ne yapacağını söyleyen DMARC. Üçü eksiksiz kurulduğunda teslim oranı, hiçbir kod değişikliği yapmadan gözle görülür şekilde düzelir.

• SPF, DKIM ve DMARC birbirinin alternatifi değildir; üçü birlikte çalışır.
• Bir alan adında yalnızca tek bir SPF kaydı olabilir. İkinci kayıt eklemek doğrulamayı komple bozar.
• SPF kaydında 10 DNS sorgusu sınırı vardır; her include satırı bu bütçeden harcar.
• DKIM anahtarını panel üretir, siz sadece TXT kaydını DNS tarafına kopyalarsınız.
• DMARC yolculuğuna her zaman p=none ile başlanır, rapor okunur, sonra sıkılaştırılır.
• Kurulumdan sonra mutlaka test edin: yayılma birkaç dakika ile 24 saat arasında sürer.

SPF, DKIM ve DMARC nedir? Aralarındaki fark ne?

Üç kaydın tamamı, alıcı mail sunucusunun şu soruyu cevaplamasına yardım eder: bu mail gerçekten bu alan adı adına gönderilmiş mi? Her biri bu soruyu farklı bir açıdan yanıtlar.

Benzetme ile anlatmak gerekirse: SPF, kapıdaki güvenliğe verilen misafir listesidir. DKIM, misafirin üzerindeki kimlik kartıdır. DMARC ise güvenliğe verilen talimattır, yani listede olmayan ve kimliği bulunmayan kişiye ne yapılacağını söyler.

SPF kaydı nasıl kurulur?

SPF kaydı, alan adınızın kök seviyesine eklenen tek bir TXT kaydıdır. En basit hali, mailleri hosting sunucunuz üzerinden gönderiyorsanız şöyle görünür:

Tip: TXT
İsim: @
Değer: v=spf1 a mx ip4:185.10.20.30 ~all

Mailleri Google Workspace üzerinden gönderiyorsanız kayıt şu şekli alır:

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

Hem hosting sunucusunu hem de bir bülten servisini kullanıyorsanız her ikisini aynı kayıtta birleştirmelisiniz:

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

SPF kaydında en sık yapılan üç hata

1. İki ayrı SPF kaydı eklemek. Yeni bir servis eklerken ikinci bir TXT kaydı oluşturmak, SPF sonucunu permerror durumuna düşürür ve doğrulama tamamen çöker. Doğrusu, mevcut kaydın içine yeni bir include satırı eklemektir.
2. 10 DNS sorgusu sınırını aşmak. Her include, a ve mx ifadesi bu bütçeden harcar. Dört beş servisi üst üste eklediğinizde sınır dolar ve kayıt görünüşte doğru olsa bile başarısız olur.
3. Sonu yanlış bitirmek. ~all yumuşak başarısızlık demektir ve mail teslim edilir ama işaretlenir. -all katı başarısızlıktır ve reddedilir. Kurulumun ilk gününde -all yazmak, unuttuğunuz bir gönderici yüzünden fatura veya sipariş maillerinizin sessizce kaybolmasına yol açar. Emin olana kadar ~all ile ilerleyin.

DKIM kaydı nasıl oluşturulur?

DKIM için anahtar çiftini elle üretmenize gerek yok; mail sunucunuz bu işi yapar. Sizin göreviniz üretilen açık anahtarı DNS tarafına taşımak.

• cPanel: Email Deliverability bölümüne girin, alan adının yanındaki Manage bağlantısına tıklayın. Panel eksik kayıtları listeler ve Install the Suggested Record düğmesi ile DNS zaten aynı sunucudaysa kaydı otomatik ekler.
• Plesk: Mail Settings bölümünde DKIM imzalamayı aktif edin. Plesk, default seçicisi ile bir anahtar üretir ve DNS bölgesine kaydı kendisi yazar. DNS başka bir sağlayıcıda ise kaydı DNS Settings ekranından kopyalayıp oraya taşımanız gerekir.
• Google Workspace: Apps bölümünden Gmail ayarlarına, ardından Authenticate email adımına gidin. 2048 bit anahtar üretin, verilen TXT kaydını ekleyin ve DNS yayıldıktan sonra panelde Start Authentication düğmesine basın. Bu son adım sık atlanır ve imzalama sessizce kapalı kalır.

Eklenecek kayıt kabaca şu yapıdadır:

Tip: TXT
İsim: default._domainkey
Değer: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

Buradaki default kısmı seçicidir, yani selector. Aynı alan adında farklı servisler için farklı seçiciler kullanılabilir; Google google._domainkey, bülten servisleri ise kendi seçicilerini ister. Bu yüzden DKIM, SPF gibi tek kayıt sınırına takılmaz.

DMARC kaydı nasıl yazılır?

DMARC, SPF ve DKIM sonuçlarını bir politikaya bağlar. İlk gün için doğru kayıt izleme modundadır:

Tip: TXT
İsim: _dmarc
Değer: v=DMARC1; p=none; rua=mailto:dmarc@alanadiniz.com; adkim=r; aspf=r; pct=100

Politika kademeleri şöyle ilerler:

rua adresine gelen XML raporları çıplak gözle okunmaz. Ücretsiz bir DMARC rapor servisine yönlendirmek ya da raporları ayrıştırıp tabloya yazan küçük bir betik kullanmak en pratik yol. Ben kendi alan adlarımda bu raporları basit bir PHP betiği ile ayrıştırıp SQLite tablosuna yazıyorum; hangi IP adresinin adınıza mail göndermeye çalıştığını görmek şaşırtıcı derecede öğretici oluyor.

Kurulumu nasıl test ederim?

Kayıtları ekledikten sonra en az on beş dakika bekleyin, sonra sırayla şunları yapın:

1. Komut satırından sorgulayın. Kayıtların dışarıdan görünüp görünmediğini doğrulamanın en hızlı yolu:

   dig TXT alanadiniz.com +short
   dig TXT default._domainkey.alanadiniz.com +short
   dig TXT _dmarc.alanadiniz.com +short

2. Kendinize test maili gönderin. Gmail hesabına bir mail atın, maili açın, üç noktadan Orijinali göster seçeneğini kullanın. SPF, DKIM ve DMARC satırlarının üçünde de PASS yazmalı.
3. Puan alın. Mail tester tipi servislere test maili gönderip 10 üzerinden puan ve eksik kalan kayıtların listesini alabilirsiniz.
4. Ters DNS kaydını kontrol edin. Kendi sunucunuzdan gönderim yapıyorsanız PTR kaydının mail sunucusu adıyla eşleşmesi gerekir. Bu kayıt sizde değil, IP sahibi sağlayıcıdadır ve talep edilmesi gerekir.

Saha notu: Kayıtlar doğru ama mailler hâlâ spamda

Çalıştığım fabrikada sipariş ve irsaliye maillerinin bir kısmı müşteri tarafında spam klasörüne düşüyordu. SPF, DKIM ve DMARC kayıtlarının üçü de doğruydu. Sorun başka yerdeydi: muhasebe programı, mailleri kendi bulunduğu ofis internet bağlantısı üzerinden doğrudan gönderiyordu, yani alan adının mail sunucusunu hiç kullanmıyordu. SPF kaydında böyle bir IP tanımlı olmadığı için doğrulama haklı olarak başarısız oluyordu.

Çözüm, kaydı genişletmek değil programı SMTP kimlik doğrulaması ile alan adının mail sunucusuna bağlamak oldu. Buradan çıkan kural şu: SPF kaydına ofis IP adresi eklemek yerine, gönderimi mail sunucusundan geçirin. Dinamik IP adresleri değişir, kayıt eskir ve sorun aylar sonra hiç beklenmediği bir günde geri döner. Aynı mantık, sitenizdeki iletişim formu için de geçerlidir: PHP mail fonksiyonu ile doğrudan göndermek yerine SMTP üzerinden göndermek, kimlik doğrulamayı ilk günden doğru tarafa oturtur.

Sık Sorulan Sorular

SPF, DKIM ve DMARC kayıtları zorunlu mu?

Teknik olarak zorunlu değil, pratikte zorunlu hale geldi. Büyük mail sağlayıcıları toplu gönderim yapan alan adlarından bu kayıtları bekliyor; eksik olduğunda mailler ya spam klasörüne düşüyor ya da hiç teslim edilmiyor.

Aynı alan adında iki SPF kaydı olabilir mi?

Olamaz. Standart tek kayda izin verir ve ikinci kayıt bulunduğunda doğrulama hata verir. Yeni bir gönderici eklemek istediğinizde mevcut kaydın içine include satırı eklemelisiniz.

Kayıtlar ne kadar sürede aktif olur?

DNS yayılması genellikle beş dakika ile bir saat arasında tamamlanır, TTL değerine bağlı olarak nadiren 24 saati bulur. Kayıt eklemeden önce TTL değerini düşürmek yayılmayı hızlandırır.

DMARC politikasını doğrudan reject yapabilir miyim?

Yapabilirsiniz ama tavsiye edilmez. Fatura, sipariş onayı veya form maili gönderen ve farkında olmadığınız bir sistem varsa, o mailler sessizce kaybolur. Önce p=none ile rapor toplayıp tüm meşru göndericileri tespit etmek doğru sıradır.

Alan adımdan mail göndermiyorum, kayıt eklemem gerekir mi?

Evet, hatta daha da gerekli. Gönderim yapmayan bir alan adı, adınıza sahte mail atmak isteyenler için açık kapıdır. Boş bir alan adı için katı bir SPF ve DMARC kaydı yayınlamak koruma sağlar:

v=spf1 -all
v=DMARC1; p=reject;

Alt alan adları ana kayıttan miras alır mı?

DMARC için ana alan adının politikası alt alan adlarını da kapsar, sp parametresi ile ayrıca özelleştirilebilir. SPF için ise durum farklıdır: alt alan adının kendi SPF kaydı olması gerekir, ana kayıt otomatik geçerli olmaz.