SPF, DKIM ve DMARC Kayıtları: E-posta Teslim Edilebilirlik Rehberi

SPF, DKIM ve DMARC Kayıtları: E-posta Teslim Edilebilirlik Rehberi

Gönderdiğiniz e-postalar spam klasörüne düşüyorsa ya da hiç ulaşmıyorsa, sorunun kaynağı büyük olasılıkla eksik kimlik doğrulama kayıtlarıdır. SPF, DKIM ve DMARC; alan adınızdan gönderilen e-postaların gerçekten size ait olduğunu alıcı sunuculara kanıtlayan üç DNS tabanlı standarttır. Gmail ve Yahoo gibi büyük sağlayıcılar, özellikle toplu gönderim yapan alan adları için bu kayıtları fiilen zorunlu tutmaktadır. Bu rehberde üçünü de gerçek kayıt örnekleriyle adım adım yapılandıracağız.

E-postalarınız Neden Spam Klasörüne Düşer?

E-posta protokolü tasarımı gereği, gönderen adresinin (From alanı) sahteciliğe açık olmasına izin verir. Kimlik doğrulama kayıtları olmayan bir alan adından gelen iletiyi alan sunucu, gönderenin gerçekliğini teyit edemez ve iletiyi şüpheli kabul eder. Üç standart bu boşluğu birlikte kapatır:

  • SPF: Alan adınız adına hangi sunucuların e-posta göndermeye yetkili olduğunu listeler.
  • DKIM: Her iletiye kriptografik imza ekler; içeriğin yolda değiştirilmediğini ve alan adınızdan çıktığını kanıtlar.
  • DMARC: SPF/DKIM doğrulaması başarısız olursa alıcının ne yapacağını (hiçbir şey, karantina, ret) belirler ve size rapor gönderilmesini sağlar.
  • SPF Kaydı Nedir ve Nasıl Eklenir?

    SPF (Sender Policy Framework), alan adınızın DNS'ine eklenen bir TXT kaydıdır. Alıcı sunucu, iletiyi getiren sunucunun IP adresini bu listeyle karşılaştırır.

    Google Workspace kullanan bir alan adı için tipik kayıt:

    Tür: TXT
    Ad (Host): @
    Değer: v=spf1 include:_spf.google.com ~all
    

    Kendi sunucunuzdan da gönderim yapıyorsanız IP adresini ekleyebilirsiniz:

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

    Sözdiziminin parçaları şunlardır:

  • v=spf1 — kaydın SPF sürüm 1 olduğunu belirtir, her kayıt bununla başlar.
  • ip4: / ip6: — yetkili IP adresleri veya blokları.
  • include: — başka bir alan adının SPF listesini dahil eder (e-posta servisleri kendi include adreslerini dokümante eder).
  • ~all — listede olmayan kaynaklar softfail sayılır (şüpheli işaretlenir); -all ise kesin ret anlamına gelir.
  • İki kritik kural: Bir alan adında yalnızca bir SPF kaydı bulunabilir ve kayıt değerlendirilirken en fazla 10 DNS sorgusu (include zinciri dahil) yapılabilir. Birden fazla servis kullanıyorsanız hepsini tek kayıtta birleştirin.

    DKIM: Dijital İmza ile Kimlik Doğrulama

    DKIM (DomainKeys Identified Mail) çift anahtarlı şifreleme kullanır: Gönderen sunucu iletiyi özel anahtarla imzalar, alıcı sunucu DNS'te yayımladığınız genel anahtarla imzayı doğrular. Genel anahtar, selector adı verilen bir öneke sahip TXT kaydında durur:

    Tür: TXT
    Ad (Host): google._domainkey
    Değer: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...
    

    Buradaki p= değeri, e-posta sağlayıcınızın size verdiği genel anahtardır (örnekte kısaltılmıştır). Selector adı (google, default, s1 gibi) sağlayıcıya göre değişir. Anahtarı kendiniz üretmezsiniz; süreç tipik olarak şöyledir:

  • E-posta sağlayıcınızın panelinde DKIM imzalamayı etkinleştirin.
  • Sağlayıcının verdiği selector ve TXT değerini DNS'inize ekleyin.
  • Panele dönüp doğrulamayı başlatın; kayıt yayıldığında imzalama devreye girer.
  • DMARC: Politikanızı Belirleyin

    DMARC (Domain-based Message Authentication, Reporting and Conformance), _dmarc alt alanına eklenen TXT kaydıdır. Başlangıç için önerilen kayıt:

    Tür: TXT
    Ad (Host): _dmarc
    Değer: v=DMARC1; p=none; rua=mailto:dmarc-rapor@alanadi.com
    

    Etiketlerin anlamı:

  • p= — politika: none (sadece izle), quarantine (spam klasörüne at), reject (tamamen reddet).
  • rua= — toplu (aggregate) raporların gönderileceği adres. Alan adınızı kimlerin kullandığını bu raporlardan görürsünüz.
  • pct= — politikanın iletilerin yüzde kaçına uygulanacağı (varsayılan 100).
  • sp= — alt alan adları için ayrı politika tanımlamak isterseniz kullanılır.
DMARC'ın bir koşulu daha vardır: hizalama (alignment). SPF veya DKIM doğrulamasının geçmesi yetmez; doğrulanan alan adının, iletinin From başlığındaki alan adıyla eşleşmesi gerekir. Üçüncü taraf gönderim servisi kullanıyorsanız servisin "özel dönüş yolu" veya "özel DKIM alanı" ayarlarını yapılandırarak hizalamayı sağlayın.

Kayıtları Doğrulama

Kayıtları ekledikten sonra terminalden kontrol edebilirsiniz:

dig TXT alanadi.com +short
dig TXT google._domainkey.alanadi.com +short
dig TXT _dmarc.alanadi.com +short

Windows kullanıyorsanız nslookup -type=TXT alanadi.com aynı işi görür. Ayrıca kendinize bir Gmail adresine test iletisi gönderip iletinin Orijinali göster ekranında SPF: PASS, DKIM: PASS, DMARC: PASS satırlarını kontrol etmek en pratik uçtan uca testtir.

En Sık Yapılan Hatalar

  • Birden fazla SPF kaydı eklemek: Yeni bir e-posta servisi kurarken mevcut kaydı düzenlemek yerine ikinci bir v=spf1 kaydı eklemek, SPF'in tamamen geçersiz sayılmasına yol açar. Her zaman tek kayıtta birleştirin.
  • +all kullanmak: Bu ifade "herkes benim adıma gönderebilir" demektir ve SPF'i anlamsızlaştırır. Geçiş döneminde ~all, olgun kurulumda -all kullanın.
  • 10 DNS sorgusu sınırını aşmak: Çok sayıda include zinciri bu sınırı aşarsa SPF kalıcı hata (permerror) verir. Kullanmadığınız eski servislerin include satırlarını temizleyin.
  • DMARC raporlarını hiç okumamak: p=none ile yıllarca kalmak, kapıya kilit takıp kilitlememeye benzer. Raporları düzenli inceleyin ve politikayı sıkılaştırma takvimine bağlayın.
  • Alt alan adlarını unutmak: Ana alan adınız korunurken mail.alanadi.com gibi alt alanlardan yapılan gönderimler açıkta kalabilir. Gerekirse sp= etiketiyle alt alan politikası tanımlayın.
  • Kayıt değişikliklerinin yayılması TTL süresine bağlı olarak birkaç dakikadan birkaç saate kadar sürebilir. Test ederken sabırlı olun; sonucu doğrulamadan ikinci bir değişiklik yapmak hata ayıklamayı zorlaştırır.

    Aşamalı Geçiş Stratejisi

    DMARC'ı sıkılaştırmak için acele etmeyin; meşru e-postalarınızı kaybetmemek için şu sırayı izleyin:

  • SPF ve DKIM'i tüm gönderim kaynaklarınız (kurumsal e-posta, bülten servisi, web sitesi formları) için yapılandırın.
  • DMARC'ı p=none ile yayımlayın ve birkaç hafta rapor toplayın.
  • Raporlarda tüm meşru kaynakların doğrulamadan geçtiğini görünce p=quarantine değerine geçin; isterseniz pct=25 ile kademeli başlayın.
  • Sorun çıkmadığına emin olduğunuzda nihai hedef olan p=reject politikasına yükselin.
  • Bu üçlüyü doğru kurduğunuzda hem teslim edilebilirliğiniz belirgin biçimde iyileşir hem de alan adınızın sahtecilikte kullanılması büyük ölçüde engellenir. E-posta altyapınızda yapacağınız en yüksek getirili yatırımlardan biri budur.

    Sıkça Sorulan Sorular

    Bir alan adında birden fazla SPF kaydı olabilir mi?
    Hayır. Bir alan adında yalnızca tek bir SPF TXT kaydı bulunmalıdır. Birden fazla servis kullanıyorsanız hepsini aynı kayıt içinde include mekanizmalarıyla birleştirin.
    DMARC politikasına doğrudan reject ile başlayabilir miyim?
    Önerilmez. Önce p=none ile rapor toplayıp meşru gönderim kaynaklarınızın tamamının SPF ve DKIM doğrulamasından geçtiğini teyit edin; ardından quarantine ve en son reject aşamasına geçin.
    SPF ve DKIM varken DMARC gerekli mi?
    Evet. DMARC, SPF/DKIM sonuçlarının gönderen adresiyle hizalanmasını zorunlu kılar ve alıcı sunuculara doğrulama başarısız olduğunda ne yapacaklarını söyler. Ayrıca alan adınızı taklit eden gönderimler hakkında rapor almanızı sağlar.
    WxDigitals
    WxDigitals

    WebTeknoloji.net editör ekibi; web geliştirme, SEO, hosting ve yapay zeka alanlarında üretilen içeriklerin araştırma, test ve yayın süreçlerini yürütür. Tüm incelemeler gerçek kullanım deneyimine, karşılaştırmalar ise resmi dokümantasyon ve güncel fiyatlandırma sayfalarına dayanır.

    Bu içeriği faydalı bulduysanız…

    Haftalık teknoloji & SEO rehberlerimize katılın, 38 maddelik Teknik SEO Kontrol Listesi PDF'ini hediye olarak hemen indirin.

    Yorumlar (0)

    Henüz yorum yapılmamış. İlk yorumu siz yapın!

    Yorum Yazın