SPF, DKIM, DMARC Kontrol

SPF DKIM DMARC kontrol nedir, neden yapmalısınız?

SPF DKIM DMARC kontrol, alan adınızın e-posta kimlik kayıtlarını dışarıdan okuyup alıcı sunucuların vereceği kararı önceden görmektir. Gmail, Outlook ya da Yandex bir iletiyi teslim etmeden önce üç soru sorar ve cevabı sizin DNS kayıtlarınızda arar. Kayıtlardan biri eksik ya da hatalıysa iletiniz spam klasörüne düşer ya da hiç ulaşmaz.

• SPF: Bu sunucu bu alan adı adına gönderebilir mi?
• DKIM: İleti yolda değişmeden mi geldi, imzayı kim attı?
• DMARC: From satırındaki alan adı bu iki kontrolden biriyle eşleşiyor mu ve eşleşmiyorsa alıcı ne yapmalı?

Kurduğum her kurumsal sitede ilk hafta bu kontrolü yaparım. Çünkü iletişim formundan gelen bildirimler ve teklif e-postaları çoğu zaman tasarım hatasından değil, eksik bir DNS kaydından kaybolur. Bu yüzden web tasarım projelerimde DNS, SSL ve e-posta doğrulamasını aynı teslim listesinde tutuyorum. Kurumsal e-postayı sıfırdan kuruyorsanız alan adı uzantılı kurumsal e-posta rehberim hangi sağlayıcıyı seçeceğinizi anlatıyor.

SPF kaydındaki 10 DNS sorgusu sınırı nasıl işler?

SPF kaydı yalnız kendi satırından ibaret değildir. Her include terimi başka bir alan adının SPF kaydını çağırır, o kayıt da yeni include terimleri içerebilir. RFC 7208 bu zincirde include, a, mx, ptr, exists ve redirect terimlerinin toplamını 10 ile sınırlar. Sınırı aşan kayıt permerror verir ve SPF hiçbir iletide geçmez.

Sorun genelde sessiz büyür. Örneğin kayıtta yalnız üç include görürsünüz, ama biri kendi içinde beş sorgu daha açar. Araç bu yüzden ağacı numaralı gösterir: her satırda kaçıncı sorgu olduğu, onuncudan sonrası kırmızı yazar. Ayrıca yanıtı boş dönen sorguları (void) ayrı sayar; bunların sınırı 2'dir.

Sınıra yaklaştıysanız şu sırayla ilerlerim:

1. Artık kullanmadığınız servislerin include satırlarını silin.
2. Pazarlama servislerini kök kayda eklemeyin; çoğu kendi Return-Path alt alan adını kullanır, DKIM ile hizalanır.
3. Yoğun gönderimi e-bulten.ornek.com gibi bir alt alan adına taşıyın; alt alan adının kendi SPF kaydı olur.

Bazı araçlar include satırlarını IP adreslerine çevirmeyi (flattening) önerir. Ancak sağlayıcı IP bloklarını değiştirdiğinde kaydınız sessizce eskir, bu yüzden bu yöntemi yalnız düzenli izleme varsa kullanırım.

DKIM seçicisi ve anahtar uzunluğu neden önemli?

DKIM anahtarı alan adınızın kökünde değil, seçici._domainkey.ornek.com adında durur. Seçici adını sağlayıcı belirler: Google Workspace varsayılan olarak google, Microsoft 365 selector1 ve selector2, Yandex 360 mail, cPanel ve Plesk default kullanır. Amazon SES ve Postmark gibi servisler ise rastgele ya da tarihe bağlı seçici üretir; bu seçicileri hiçbir araç tahmin edemez. Böyle bir durumda gönderdiğiniz bir iletinin başlığındaki s= değerini seçici kutusuna yazın.

Anahtar bulunduğunda asıl bakılacak değer uzunluktur. RFC 8301 imzacıların en az 1024 bit kullanmasını zorunlu tutar ve 2048 bit önerir. Google da kişisel Gmail adreslerine gönderimde 1024 bitin altını kabul etmiyor. Araç anahtarı DNS'teki base64 değerden çözüp gerçek bit sayısını yazar; 1024 bit gördüğünüzde sağlayıcı panelinden 2048 bitlik yeni anahtar üretmenizi öneririm.

• p= boş: anahtar iptal edilmiştir; eski bir seçiciyse sorun yok.
• t=y: alan adı DKIM'i test ediyor demektir; kurulum bitince kaldırın.
• CNAME var, anahtar yok: Microsoft 365'te yedek seçici için normaldir, tek seçicinizse DKIM çalışmaz.

DMARC politikasını none'dan reject'e nasıl taşırsınız?

DMARC kaydı _dmarc.ornek.com adında durur ve alıcıya iki şey söyler: doğrulamayı geçemeyen iletiye ne yapacağını (p) ve raporları nereye göndereceğini (rua). p=none yalnız izler; sahte iletiler yine teslim edilir. Buna karşılık p=quarantine bu iletileri spam klasörüne, p=reject ise doğrudan geri çevirir.

Geçişi hiçbir zaman tek adımda yapmam. İlk olarak p=none ve rua ile başlarım, iki ila dört hafta toplu raporları okuyup adınıza gönderen tüm meşru servisleri SPF ya da DKIM ile hizalarım. Raporlarda yalnız sahte kaynaklar kaldığında p=quarantine, birkaç sessiz haftadan sonra p=reject yaparım.

Mayıs 2026'da yayımlanan RFC 9989, eski RFC 7489'un yerini aldı ve birkaç şeyi değiştirdi:

• pct etiketi kaldırıldı, yerine t=y test bayrağı geldi; Google ise kademeli geçişte pct değerini hâlâ okuyor.
• np etiketi var olmayan alt alan adları için ayrı politika tanımlıyor.
• Kamu soneki listesi yerine DNS ağaç yürüyüşü (tree walk) kullanılıyor.
• Çalışanların posta listelerine yazdığı genel amaçlı alan adlarında reject yerine quarantine öneriliyor.

Araç kaydınızı iki standarda göre de okur ve eski etiketleri ayrıca işaretler.

SPF DKIM DMARC kontrol sonucu büyük gönderici kurallarını karşılıyor mu?

Google ve Yahoo Şubat 2024'ten, Microsoft ise Outlook.com için 5 Mayıs 2025'ten beri toplu göndericilerden aynı temel şartları istiyor. Google eşiği 24 saatte kişisel Gmail adreslerine yaklaşık 5.000 ileti olarak tanımlıyor; Microsoft günde 5.000'den fazla ileti diyor, Yahoo ise sayı vermiyor. Üstelik Microsoft şartları karşılamayan iletiyi 550 5.7.515 koduyla reddediyor, Gmail de Kasım 2025'ten beri uymayan trafiğe geçici ve kalıcı ret uyguluyor.

Bu şartların bir kısmını DNS kayıtlarından görebilirsiniz, bir kısmını göremezsiniz. Araç Gönderici kuralları sekmesinde bu ayrımı açıkça yapar:

• DNS'ten görünenler: geçerli SPF, DKIM anahtarı, en az 1024 bit anahtar, en az p=none DMARC.
• Gerçek ileti isteyenler: From hizalaması, tek tıkla abonelikten çıkma, gönderimde TLS.
• Gönderim paneli isteyenler: şikâyet oranının yüzde 0,3'ün altında kalması, gönderen IP için ters DNS kaydı, çıkış taleplerinin iki gün içinde işlenmesi.

Kısacası DNS tarafı yeşil olsa bile bülteninizin başlığını bir kez de başlık analiziyle kontrol edin. Google Postmaster Tools şikâyet oranını izlemek için ücretsiz ve güvenilir bir kaynak.

E-posta başlığı analizi size ne gösterir?

DNS kayıtları doğru olsa da gerçek bir iletinin nasıl doğrulandığını yalnız başlık gösterir. Kendinize bir ileti gönderin, başlığı açıp yapıştırın; araç metni tamamen tarayıcınızda ayrıştırır ve sunucuya hiçbir şey göndermez. Paylaşım bağlantısına da başlık eklenmez.

• Authentication-Results: alıcı sunucunun verdiği spf, dkim ve dmarc sonucu.
• Hizalama tablosu: From alan adı ile zarf (Return-Path) ve imza (d=) alan adının gevşek ya da sıkı eşleşmesi.
• DKIM imzaları: seçici, algoritma, imzalı başlıklar ve tek tıkla seçiciyi kontrol etme.
• Tek tıkla çıkış: List-Unsubscribe ve List-Unsubscribe-Post başlıkları; RFC 8058 bu iki başlığın DKIM imzasının kapsamında olmasını ister.
• Aktarım adımları: Received satırlarından sunucular arası gecikme ve son adımda TLS kullanılıp kullanılmadığı.

Pazarlama servisinden gelen bir iletide DKIM geçip hizalama kalıyorsa sorun neredeyse her zaman aynıdır: servis kendi alan adıyla imzalıyordur. Servisin panelinde özel alan adı doğrulamasını açtığınızda imza sizin alan adınıza geçer ve DMARC geçer.

cPanel ve Plesk'te kayıtları nereye eklemelisiniz?

Önce kayıtların hangi panelde yönetildiğini bulun: alan adınızın ad sunucuları hangi firmayı gösteriyorsa kaydı orada eklersiniz. Ad sunucularını DNS sorgulama aracıyla, alan adının kayıt firmasını Whois sorgulama ile görebilirsiniz. Ad sunucuları Cloudflare gibi bir hizmetteyse cPanel içindeki bölge dosyası hiçbir şey değiştirmez.

• cPanel: E-posta bölümündeki Email Deliverability ekranı SPF ve DMARC için önerilen kaydı tek tıkla kurar, DKIM anahtarı üretir. Elle eklemek için Zone Editor ekranında Manage ve ardından Add Record adımlarını izleyin.
• Plesk: Websites & Domains altında alan adınızı seçip DNS Settings ekranından TXT kaydı ekleyin. DKIM için Mail Settings içindeki DKIM kutusunu işaretlemeniz yeterli; Plesk default._domainkey kaydını kendisi yayımlar.

İki kuralı unutmayın. Alan adında zaten bir v=spf1 kaydı varsa ikincisini eklemeyin, mevcut kaydı düzenleyin; iki SPF kaydı permerror verir. Ayrıca MTA-STS kullanıyorsanız mta-sts alt alan adının sertifikasını SSL sorgulama aracıyla kontrol edin; politika dosyası geçerli bir sertifika olmadan okunmaz. Kaydı değiştirdikten sonra eski kaydın TTL süresi dolana kadar bekleyip aracı yeniden çalıştırın.