SPF, DKIM ve DMARC Nedir? Adım Adım Nasıl Kurulur?

SPF, DKIM ve DMARC; e-postanın gerçekten sizin adınıza gönderildiğini kanıtlayan ve alan adınızın sahtekârlıkla taklit edilmesini (spoofing/phishing) önleyen üç kimlik doğrulama katmanıdır. 2024 yılından itibaren Gmail ve Yahoo, günde 5.000'den fazla mail gönderenler için bu üçünü de zorunlu kılıyor — eksik olan gönderim throttle edilir, spam'e atılır veya reddedilir. Üçü de alan adınızın DNS kayıtlarına eklenir ve birbirini tamamlar.

SPF — Sender Policy Framework (RFC 7208)

SPF, hangi sunucuların/IP'lerin sizin alan adınız adına e-posta gönderebileceğini belirten bir TXT kaydıdır. Alıcı sunucu, maili gönderen IP'nin bu listede olup olmadığını kontrol eder.

Tür: TXT   Ad: @ (alan adının kökü)
Değer: v=spf1 ip4:198.51.100.10 include:_spf.saglayici.com ~all

Önemli kurallar

• ~all = softfail (başarısız gönderimi işaretle ama reddetme — önerilen başlangıç), -all = hardfail (katı reddetme).
• 10 DNS sorgusu limiti (RFC 7208 §4.6.4): include, a, mx, ptr, exists mekanizmaları sayılır; ip4, ip6 ve all sayılmaz. Bu limiti aşmak PermError üretir ve SPF tamamen başarısız olur. Ayrıca en fazla 2 "void" (boş dönen) sorgu izni vardır.
• Bir alan adının yalnızca bir SPF kaydı olmalıdır; ikinci bir v=spf1 kaydı geçersizliğe yol açar.

SPF'in tek başına bir zayıflığı, e-posta iletildiğinde (forward) bozulmasıdır — bu yüzden DKIM ile birlikte kullanılır.

DKIM — DomainKeys Identified Mail (RFC 6376)

DKIM, giden her e-postaya bir kriptografik imza (dijital mühür) ekler. İmzayı doğrulayan açık anahtar (public key) DNS'te yayınlanır; özel anahtar (private key) gönderen tarafında gizli kalır. Alıcı sunucu, DNS'teki açık anahtarla imzayı doğrulayarak mailin yolda değiştirilmediğini ve gerçekten sizden geldiğini teyit eder.

Tür: TXT   Ad: sendertr._domainkey
Değer: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4...(açık anahtar)

Buradaki sendertr bir selector'dür. SenderTR kullanıyorsanız seçiciniz her zaman sendertr olur; kaydı sendertr._domainkey.alanadiniz.com adıyla yayınlarsınız. Selector, aynı alan adında birden çok DKIM anahtarını ayırt etmenizi ve anahtarı periyodik olarak yenilemenizi (rotation) sağlar. İmza; genellikle From, Subject, Date gibi başlıkları ve gövdeyi kapsar.

DMARC — politikanın patronu (RFC 7489)

DMARC, SPF ve DKIM'in üstünde durur: kimlik doğrulama başarısız olduğunda ne yapılacağını söyler ve size düzenli rapor gönderir. _dmarc alt alanında yayınlanır.

Tür: TXT   Ad: _dmarc
Değer: v=DMARC1; p=none; rua=mailto:dmarc@sendertr.com; pct=100; adkim=r; aspf=r

Etiketler (tags)

• p — politika: none (yalnızca izle/raporla), quarantine (spam'e at), reject (SMTP seviyesinde reddet).
• sp — alt alan adları için ayrı politika (belirtilmezse üst politika devralınır).
• rua — toplu (aggregate) raporların gönderileceği adres; ruf — anlık hata (forensic/failure) raporu.
• pct — politikanın uygulanacağı başarısız mail yüzdesi (kademeli geçiş için).
• adkim / aspf — hizalama modu: r (gevşek/relaxed) veya s (katı/strict).

Hizalama (alignment) — DMARC'ın kalbi

DMARC'ın geçmesi için SPF veya DKIM'in doğrulanması yeterli değildir; doğrulanan alan adının, alıcının gördüğü "From" adresindeki alan adıyla eşleşmesi (hizalanması) gerekir. Gmail/Yahoo, doğrudan gönderimde bu hizalamayı arar. En az bir doğrulama (SPF ya da DKIM) hem geçerli hem hizalı olmalıdır.

Önerilen kurulum sırası

1. SPF: Tüm meşru gönderim kaynaklarınızı (kendi sunucularınız + ESP'niz) içeren tek bir SPF kaydı yayınlayın; 10 lookup limitine dikkat edin.
2. DKIM: ESP'nizin verdiği açık anahtarı selector ile yayınlayın ve imzalamayı açın.
3. DMARC (p=none): Önce yalnızca izleme modunda başlayın ve rua raporlarını toplayın.
4. Raporları analiz edin: Tüm meşru kaynaklarınızın SPF/DKIM ile geçtiğini ve hizalandığını doğrulayın.
5. Sıkılaştırın: Sorun kalmadığında p=quarantine, ardından p=reject'e geçin. İsterseniz pct ile (örn. %25 → %50 → %100) kademeli ilerleyin.

Sık karşılaşılan sorunlar

• SPF PermError (too many DNS lookups): 10 sorgu aşıldı. Fazla include'ları azaltın veya birleştirin.
• Birden çok SPF kaydı: Alan adında yalnızca bir v=spf1 olmalı; hepsini tek kayıtta birleştirin.
• DMARC geçiyor ama hizalanmıyor: SPF/DKIM geçse bile "From" alan adıyla eşleşmiyorsa DMARC başarısız sayılır — doğru alan adıyla imzalayın.
• Doğrudan p=reject: Meşru kaynaklar doğrulanmadan reject'e geçmek geçerli maillerinizi de reddeder — önce p=none ile izleyin.

SenderTR panelinde gönderim alan adınız için gerekli DKIM ve DMARC (ve isteğe bağlı SPF) kayıtlarını otomatik üretebilir, tek tıkla canlı olarak doğrulayabilir ve hizalama durumunu görebilirsiniz — böylece Gmail/Yahoo kurallarına eksiksiz uyum sağlarsınız.

Kayıtları alan adı yönetim ekranına doğru girme

Kayıt değerleri doğru olsa bile alan adı yönetim ekranındaki ad alanı yanlış doldurulursa kayıt beklediğiniz yerde yayınlanmaz. Bazı ekranlar alan adınızı kayıt adının sonuna kendiliğinden ekler. Böyle bir ekranda tam alan adını yeniden yazmak, aynı alan adının tekrarlanmasına neden olabilir. Kaydetmeden önce ekranın gösterdiği tam kayıt adını inceleyin; emin değilseniz alan adı yöneticinizin ad alanına ilişkin açıklamasına bakın.

Kayıt değerini yapıştırırken yalnızca örnekteki şablona güvenmeyin; gönderim hizmetinizin sağladığı değeri kullanın. Özellikle DKIM anahtarında eksik karakter veya araya giren boşluk, doğrulamayı engelleyebilir. Kaydı ekledikten sonra alan adı yönetim ekranında görünmesiyle yetinmeyin. Alan adınızın herkese açık kayıtlarını sorgulayarak adın ve değerin yayınlandığını kontrol edin. Değişiklik hemen görünmüyorsa önbellekte tutulan eski yanıtları dikkate alıp yeniden kontrol edin. Böylece kayıt ekleme hatasıyla yayınlanma gecikmesini birbirine karıştırmazsınız.

Gönderim hizmeti değişirken kimlik doğrulamayı koruma

Yeni bir gönderim hizmetine geçerken eski kayıtları hemen silmek yerine hangi hizmetin hâlâ e-posta gönderdiğini belirleyin. Web sitenizdeki iletişim formları, işlem bildirimleri ve bülten gönderimleri farklı kaynaklardan çıkıyor olabilir. Geçiş boyunca çalışan her kaynağın yetkilendirme durumunu ayrı ayrı kontrol edin. Kullanımdan kalktığını düşündüğünüz bir kaynağın arka planda bildirim göndermeye devam etmesi gözden kaçabilir.

Yeni hizmetin gerektirdiği yetkilendirmeyi mevcut SPF kaydı içinde düzenleyin; ayrı bir SPF kaydı oluşturarak ilerlemeyin. Yeni hizmetin DKIM anahtarı yayınlandığında, eski anahtarı kaldırmadan önce eski hizmet üzerinden gönderilmiş iletilerin durumunu değerlendirin. Eski anahtarla imzalanmış iletiler hâlâ alıcılara ulaşırken anahtarı kaldırmak doğrulamayı etkileyebilir. Geçiş sırasında farklı kaynaklardan deneme iletileri gönderip alıcı tarafındaki doğrulama sonuçlarını inceleyin. Eski hizmetin gönderimi sona erdiğinde artık gerekmeyen yetkilendirmeleri temizleyin; böylece kayıtlar yalnızca kullanılan kaynakları yansıtır.

DMARC raporlarında şüpheli kaynağı ayırt etme

DMARC raporunda bilinmeyen bir gönderim kaynağı görmek, tek başına alan adınızın kötüye kullanıldığını kanıtlamaz. Önce kaynağın bir form, bildirim sistemi veya kuruluşunuz adına gönderim yapan başka bir hizmetle ilişkili olup olmadığını araştırın. Kaynağı tanıdıktan sonra doğrulama sonucuyla gönderen adresindeki alan adının hizalanmasını birlikte değerlendirin. Doğrulama başarılı görünse bile hizalama başarısızsa sorunun hangi gönderim akışından çıktığını saptamaya çalışın.

Bir kaynak tanınmıyorsa rapordaki bilgileri kuruluşunuzun gönderim kayıtlarıyla karşılaştırın; emin olmadan DMARC politikasını değiştirmeyin. Meşru bir kaynağın hatalı yapılandırmasını düzeltmekle yetkisiz gönderimi engellemek farklı işlemlerdir. Raporların gönderildiği posta kutusuna kimlerin erişebildiğini de gözden geçirin. Raporlar gönderim kaynaklarınız hakkında bilgi sağlayabildiğinden, bu adresi kullanılmayan veya denetlenmeyen bir posta kutusu olarak bırakmayın. Yaptığınız düzeltmelerin etkisini sonraki raporlarda izleyerek aynı sorunun sürüp sürmediğini anlayın.