6XC

E-posta DNS Denetimi (SPF, DKIM, DMARC)

Alan adının e-posta DNS'ini tek raporda denetleyin: MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT ve BIMI — geçti/uyarı/hata rozetleriyle.

1.170 görüntülenme

Data: Google Public DNS (DoH) — sorgular tarayıcınızdan yapılır.

E-posta Kimlik Doğrulaması Nasıl Çalışır?

Üç DNS kaydı birlikte çalışarak, birinin alan adınız adına sahte e-posta göndermesini engeller. SPF (Sender Policy Framework), alan adı adına e-posta göndermeye yetkili sunucuların listesini DNS'te yayınlar — alıcı sunucu, bağlanan IP'yi bu listeyle karşılaştırır. DKIM (DomainKeys Identified Mail), giden her mesaja kriptografik bir imza ekler; alıcı sunucu genel anahtarınızı DNS'ten çekip imzayı doğrular ve mesajın yolda değiştirilip değiştirilmediğini anlar — bu, SPF'nin tek başına yapamadığı bir şeydir. DMARC (Domain-based Message Authentication, Reporting and Conformance) ikisini birbirine bağlar: SPF veya DKIM başarısız olduğunda alıcı sunucunun ne yapacağını belirler — hiçbir şey yapma, spam'e gönder ya da doğrudan reddet — ve toplu raporlar ister, böylece alan adınız adına kimlerin mail gönderdiğini, taklitçiler dahil, görebilirsiniz.

Somut örnek: bu üç kayıttan hiçbiri yokken bir saldırgan [email protected] görünümlü bir e-posta gönderebilir ve çoğu mail sunucusu bunu hiçbir uyarı göstermeden doğrudan alıcının gelen kutusuna teslim eder. Yukarıdaki denetim aracına alan adınızı yazın; MX, SPF, DKIM (yaygın selector'ları otomatik deneyerek) ve DMARC kayıtlarını DNS-over-HTTPS ile sorgular, ardından tam olarak neyin eksik olduğunu işaretler: eksik SPF kaydı, hâlâ p=none'da takılı kalmış (yalnızca izleme, sıfır gerçek koruma) bir DMARC politikası, birbiriyle çelişen iki SPF kaydı (doğrulamayı tamamen bozan bir standart ihlali) veya SPF dizesinin sonunda eksik bir all mekanizması.

Bilinmesi Gerekenler

Marka itibarını ya da e-posta teslim edilebilirliğini (deliverability) önemseyen herkes için bu üç kaydı doğru kurmak tercihe bağlı değildir — SPF, DKIM ya da DMARC'ında boşluk olan bir alan adı hem sahtecilik için daha kolay bir hedeftir hem de kendi meşru mailinin spam'e düşme riski daha yüksektir, çünkü Gmail, Yahoo ve Outlook gibi büyük sağlayıcılar göndereni güvenilir saymadan önce giderek daha fazla tam kimlik doğrulama talep eder. Sıralı yapıldığında bu kurulum güvenlidir: önce SPF'yi yayınlayın, mail sağlayıcınız üzerinden DKIM imzalamayı ekleyin, sonra p=none'dan başlayan bir DMARC ekleyin — böylece gerçek maili riske atmadan toplu raporları izleyebilirsiniz; pazarlama araçları, CRM ya da destek sistemleri gibi her meşru gönderim kaynağı doğrulanıp hizalandıktan sonra karantina ya da reddetmeye geçin.

  • Bir alan adının yalnızca tek bir SPF TXT kaydı olabilir — birden fazla hizmet kullanıyorsanız (Google Workspace, bir pazarlama platformu, bir CRM), ayrı kayıtlar yayınlamak yerine hepsinin include mekanizmalarını tek bir dizede birleştirin.
  • DKIM selector'ları sağlayıcıya özeldir: Google Workspace genelde "google" altında yayınlar, Microsoft 365 "selector1" ya da "selector2" kullanır — otomatik kontrol bir şey bulamazsa, sağlayıcınızın tam selector adını bulup manuel girin.
  • Bu araç yalnızca DNS yapılandırmasını denetler; kara liste durumunu ya da mesaj içeriğini taramaz — bunlar, doğru yapılandırılmış bir DNS temeli üzerine kurulan ayrı e-posta teslim edilebilirliği katmanlarıdır.

Sıkça Sorulan Sorular

SPF tam olarak neyi kontrol eder, neyi yakalayamaz?

SPF, bir mesajı teslim etmek için bağlanan sunucunun alan adının yetkili gönderici listesinde olup olmadığını doğrular. Mesajın yolda değiştirilip değiştirilmediğini algılayamaz ve e-posta yönlendirmesinde genelde iyi çalışmaz — DKIM ve DMARC'ın yanında var olmasının nedeni tam olarak budur; SPF tek başına yeterli değildir.

Denetleyici hangi DKIM selector'larını otomatik deniyor?

Yaygın olanlar: default, google, selector1, selector2, k1, s1, mail, dkim. Sağlayıcılar bilinen selector'larla yayınlar — Google Workspace genelde "google" kullanır, Microsoft 365 selector1 ya da selector2 kullanır. Özel bir selector'ınız varsa doğrudan selector alanına yazın.

DMARC politikam p=none gösteriyor — bu bir sorun mu?

p=none yalnızca izler ve raporlar; sahte mailin gelen kutusuna ulaşmasını engellemez. Raporları toplayıp tüm meşru gönderenleri doğrularken atılacak doğru ilk adımdır, ama nihai hedef p=quarantine, ideal olarak p=reject olmalıdır.

İki SPF kaydı olması neden her şeyi bozar?

Standart, alan adı başına tam olarak bir SPF TXT kaydına izin verir. Doğrulayıcılar birden fazla kaydı kalıcı hata sayar ve kontrolü tamamen başarısız kılabilir, bu da aslında meşru olan mailin spam'e düşmesine yol açabilir. Her include kaynağını tek bir v=spf1 dizesinde birleştirin.

Bu araç alan adımın kara listede olup olmadığını ya da spam içeriğini tarıyor mu?

Hayır — yalnızca DNS kayıtlarını denetler: MX, SPF, DKIM, DMARC ve modern eklentiler MTA-STS, TLS-RPT, BIMI. Kara liste durumu ve içerik bazlı spam puanlaması ayrı sistemlerdir; doğru DNS kimlik doğrulaması, bu sistemlerin güven inşa ettiği temeldir.

Yorumlar

Henüz yorum yok — ilk yorumu siz yazın!

Benzer Araçlar

Meta Etiket Oluşturucu (Title & Description) Başlık ve açıklamanızı canlı Google önizlemesi ve uzunluk rehberiyle yazın — temiz HTML meta etiketlerini kopyalayın. Oluştur Open Graph & Twitter Card Oluşturucu Canlı paylaşım kartı önizlemesiyle og: ve twitter: meta etiketleri üretin — linkinizin sosyal medyada nasıl görüneceğini siz belirleyin. Oluştur Google Arama Sonucu Önizleme (SERP) Başlık, URL ve meta açıklamanızın Google arama sonuçlarında nasıl görüneceğini yayınlamadan önce görün — canlı karakter/piksel kesilme uyarılarıyla. Çalıştır URL Slug Oluşturucu Herhangi bir başlığı temiz URL slug'ına çevirin — Türkçe karakterler dönüştürülür, noktalama temizlenir, çok satırlı toplu işlem desteklenir. Oluştur