SPF, DKIM ve DMARC: E-posta Sahtekarlığını Adım Adım Nasıl Durdurursunuz?

Kısaca: SPF, alan adınız adına e-posta göndermesine izin verilen sunucuları listeler, DKIM her iletiyi imzalar, DMARC ise bunlardan birinin görünen From adresindeki alan adı için geçtiğini doğrular ve başarısız olan iletilere alıcıların ne yapacağını söyler. Şubat 2024'ten beri Gmail ve Yahoo her gönderenden SPF veya DKIM, toplu gönderenlerden ise SPF, DKIM ve DMARC istiyor; Gmail ise Kasım 2025'ten itibaren denetimi sertleştirdi. Tek bir SPF kaydı yayınlayın, adınıza e-posta gönderen her serviste DKIM'i açın, DMARC'a raporlarla birlikte p=none ile başlayın ve meşru e-postalarınız geçmeye başlayınca p=quarantine veya p=reject seviyesine geçin.

E-posta, göndereni kanıtlayan hiçbir mekanizma olmadan tasarlandı. Herkes From satırına billing@yourcompany.com yazabilir ve kimlik doğrulama kayıtları yoksa alıcı sunucu bunun sahte olduğunu anlayamaz. Adınıza yapılan fatura dolandırıcılığı ve kimlik avı (phishing) böyle çalışır; gerçek e-postalarınızın Gmail'e şüpheli görünmesinin nedeni de budur.

SPF, DKIM ve DMARC bunu üç DNS kaydıyla çözer. Bu rehber, üçünün nasıl birbirini tamamladığını, büyük e-posta sağlayıcılarının ne istediğini, ücretsiz SPF ve DMARC denetleyicimizin alan adınızı nasıl okuduğunu ve hiç kayıt yokken kendi e-postalarınızı bozmadan uygulanan bir politikaya nasıl geçeceğinizi anlatır.

SPF, DKIM ve DMARC birlikte nasıl çalışır?

SPF ve DKIM'in tek başına zayıf noktası "hangi alan adı" satırıdır. RFC 7208, SPF'nin alıcının hiç görmediği MAIL FROM ve HELO kimliklerini kontrol ettiğini söyler. Bir sahtekâr, From satırında sizin alan adınızı gösterirken kendi alan adı için SPF'yi geçebilir. DMARC bu boşluğu hizalama (alignment) ile kapatır: bir ileti, yalnızca SPF veya DKIM From alan adıyla eşleşen bir alan adı için geçerse DMARC'ı geçer (esnek hizalama aynı kuruluşun alt alan adlarına izin verir).

Tek kayıtta SPF

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Her include bir sağlayıcının sunucularına yetki verir; sondaki -all geri kalan her şeyin başarısız olacağını söyler. RFC 7208 niteleyicileri tanımlar: - fail, ~ softfail ("muhtemelen yetkili değil"), ? neutral ve + pass anlamına gelir. +all tüm interneti yetkilendirir ve amacı boşa çıkarır.

Tek kayıtta DKIM

E-posta sağlayıcınız giden iletileri özel anahtarla imzalar ve size, bir selector altında yayınlamanız için açık anahtar verir; örneğin google._domainkey.example.com. Her gönderim servisi kendi selector'ünü kullanır, bu yüzden aynı anda birden fazla DKIM anahtarınız olabilir (RFC 6376).

Tek kayıtta DMARC

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

p alan adının politikasıdır, sp alt alan adları içindir; rua ise alıcılardan gelen, alan adınız adına hangi sunucuların e-posta gönderdiğini ve geçip geçmediğini listeleyen günlük toplu raporları alır.

DMARC standardı 2026'da güncellendi

Mayıs 2026'da IETF, özgün DMARC spesifikasyonu olan RFC 7489'u geçersiz kılan ve DMARC'ı Standards Track'e taşıyan RFC 9989'u yayınladı. Mevcut kayıtlar çalışmaya devam eder; sürüm etiketi hâlâ v=DMARC1. Bilmeye değer değişiklikler:

• pct kaldırıldı. RFC bunun "genellikle doğru uygulanmadığını" belirtiyor. Yerine yeni bir t etiketi ("testing") geldi: t=y, alıcılardan politikayı uygulamamalarını ister; yaklaşık olarak eski pct=0 gibidir.
• np eklendi; var olmayan alt alan adları için bir politikadır.
• rf ve ri kaldırıldı ve kuruluş alan adını bulmak için Public Suffix List yerine DNS "tree walk" yöntemi kullanılıyor.

Alıcılar yeni kurallara farklı hızlarda geçecek ve Google'ın kendi kurulum rehberi hâlâ devreye alma sırasında pct kullanmayı öneriyor. pct kullanmak hiçbir şeyi bozmaz, ancak kesin bir yüzde olarak buna güvenmeyin.

Gmail ve Yahoo ne istiyor?

İki sağlayıcı da gönderici gereksinimlerini Şubat 2024'te uygulamaya başladı.

Kaynaklar: Google'ın gönderici yönergeleri ve Yahoo'nun gönderici en iyi uygulamaları. Google, kimliği doğrulanmamış iletilerin "spam olarak işaretlenebileceği veya 5.7.26 hatasıyla reddedilebileceği" konusunda uyarıyor; SSS sayfasında ise şöyle diyor: "Kasım 2025'ten itibaren Gmail, kurallara uymayan trafiğe yönelik denetimini artırıyor"; geçici ve kalıcı reddetmeler de buna dahil. Aynı SSS, DMARC'ı hem SPF hem DKIM ile hizalamayı öneriyor ve hizalamanın ilerleyen dönemde büyük olasılıkla zorunlu hâle geleceğini söylüyor.

Günde 5.000'den çok daha az ileti gönderseniz bile bu kayıtlar faturalarınızın, parola sıfırlama e-postalarınızın ve yanıtlarınızın gelen kutusuna ulaşıp ulaşmayacağını ve bir başkasının adınıza inandırıcı e-posta gönderip gönderemeyeceğini belirler.

Searvia SPF ve DMARC denetleyicisi nasıl çalışır?

Ücretsiz SPF ve DMARC denetleyicisi, web sitesi SEO denetleyicimizin bir parçasıdır ve e-posta kimlik doğrulama kontrolünü ilk sırada gösterir. Bir alan adı girdiğinizde (baştaki www. kaldırılır):

1. Alan adının TXT kayıtlarını sorgular ve v=spf1 ile başlayanları alır. Birden fazla kayıt varsa uyarı verir, çünkü bu durumda SPF başarısız olur.
2. SPF kaydının gerektirdiği DNS sorgularını sayar (include, a, mx, ptr, exists ve redirect; her include bir seviye derinlikte izlenir) ve 10'dan fazlaysa uyarır.
3. _dmarc. artı alan adının TXT kayıtlarını sorgular ve v=DMARC1 ile başlayanı alır.
4. DMARC kaydındaki p= politikasını okur ve bir rua rapor adresi olup olmadığına bakar.
5. Her iki kaydı da tam olarak, tik veya çarpıyla gösterir; DKIM satırı "Kontrol edilmedi" olarak işaretlenir.

Genel denetimde bu kontrolün önceliği orta düzeydedir. DMARC konusunda ne kadar katı olduğuna dikkat edin: p=none, Gmail'in asgari şartını karşılar ama sahteciliği engellemediği için yine de uyarı gösterir.

Ücretsiz kontrolün kapsamadığı noktalar:

• DKIM. DKIM anahtarları her e-posta servisinin seçtiği selector'lerin altında durur ve bunları DNS'ten listelemenin bir yolu yoktur; bu yüzden rapor DKIM'i kontrol edilmedi olarak işaretler. DKIM'i e-posta sağlayıcınızın yönetim panelinden ya da gönderdiğiniz bir iletinin başlıklarından kontrol edin (dkim=pass ifadesini arayın).
• SPF'nin tüm kuralları. Yinelenen kayıtları ve 10'dan fazla sorguyu işaretler, ancak kaydın -all ya da ~all ile bitip bitmediğine bakmaz. Include'lar bir seviye derinlikte izlendiği için, derin iç içe geçmiş bir kayıt gösterilen sayıdan daha fazla sorgu gerektirebilir.
• DMARC ayrıntıları. p= değerini okur ve rua olup olmadığına bakar, ancak sp= veya hizalama ayarlarına bakmaz.

Sonucunuzu nasıl yorumlarsınız?

• Başarısız: alan adınız sahteciliğe açık ve e-postalarınız Gmail ve Yahoo gereksinimlerini karşılamıyor. Aşağıdaki 1. adımdan başlayın.
• "DMARC eksik" veya "SPF eksik": işin yarısı tamam. Eksik kaydı ekleyin.
• "DMARC none olarak ayarlı": en yaygın sonuç. (rua ayarlıysa) rapor topluyorsunuz; bu doğru ilk aşamadır. Uygulamaya (enforcement) geçişi planlayın.
• Başarılı: iyi. Ücretsiz aracın göremediği kısımları kontrol edin: her gönderen için DKIM, derin iç içe SPF include'ları ve alt alan adları için sp politikası.

Adım adım nasıl düzeltirsiniz?

1. Adım: Alan adınız adına e-posta gönderen her şeyi listeleyin

E-posta sağlayıcınız (Google Workspace, Microsoft 365), bülten aracı, CRM, yardım masası, faturalama yazılımı, e-ticaret platformu, web sitesi iletişim formu ve bildirim gönderen tüm sunucular. Burada birini atlamak, DMARC'ı uygulamaya aldığınızda işlerin ters gitmesinin başlıca nedenidir.

2. Adım: Tek bir SPF kaydı yayınlayın

1. Her sağlayıcının belgelediği include: değerini toplayın.
2. Bunları tek bir kayıtta birleştirin. RFC 7208 açıktır: birden fazla SPF kaydı varsa sonuç "permerror" olur.
3. Test ederken ~all ile bitirin, sonra -all yapın.
4. Sorguları sayın. include, a, mx, ptr, exists ve redirect her biri bir DNS sorgusuna mal olur ve sınır, iç içe include'lardaki sorgular dahil 10'dur. 10'un üstü permerror'dır. Artık kullanmadığınız servisleri kaldırın ve RFC'nin "yayınlanmamalıdır (SHOULD NOT)" dediği ptr'yi bırakın.

Bir sağlayıcı kendi zarf alan adıyla gönderiyorsa (bülten araçlarında yaygın), SPF kaydınızda hiç yer almasına gerek yoktur; DMARC'ın geçmesi için sizin alan adınızla DKIM'e ihtiyacı vardır.

3. Adım: Her gönderen için DKIM'i açın

Her serviste alan adı doğrulama veya DKIM ayarını bulun, verdiği kaydı (selector altında bir TXT ya da CNAME) yayınlayın ve imzalamayı etkinleştirin. Google, DMARC eklemeden önce SPF ve DKIM kurulumundan sonra 48 saat beklemeyi öneriyor. Ardından bir Gmail adresine test iletisi gönderin ve "Orijinali göster" seçeneğine bakın: SPF: PASS, DKIM: PASS ve DMARC: PASS görmek istersiniz.

4. Adım: DMARC'ı p=none ve raporlarla yayınlayın

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Google, p=none ile başlamayı ve her zaman rua eklemeyi öneriyor. Toplu raporlar XML dosyalarıdır; bir DMARC rapor servisi veya ayrıştırıcı bunları okunur hâle getirir. Rapor adresi başka bir alan adındaysa, o alan adının bunu bir DNS kaydıyla yetkilendirmesi gerekir.

5. Adım: Raporları okuyun ve hataları düzeltin

İki ila dört hafta boyunca SPF veya DKIM hizalamasında başarısız olan meşru servisleri arayın. Her biri için sizin alan adınızla DKIM imzalama ya da bir SPF include'u gerekir. İleti yönlendirme ve e-posta listeleri meşru nedenlerle başarısız olabilir; RFC 9989, kullanıcıları e-posta listelerine yazan alan adlarının p=reject'e geçmeden önce en az bir ay p=none'da ve benzer bir süre p=quarantine'de kalmasını öneriyor.

6. Adım: Quarantine'e, sonra reject'e geçin

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Bir seferde tek adım değiştirin ve raporları izlemeye devam edin. p=quarantine'e ulaştığınızda denetleyicimiz başarılı sonucu verir. Hedef p=reject'tir: alıcılar başarısız olan e-postaları reddeder.

7. Adım: E-posta göndermeyen alan adlarını kilitleyin

Park edilmiş ve yalnızca yönlendirme yapan alan adları, kimse izlemediği için sahtekârlar açısından caziptir. Birleşik Krallık hükümetinin rehberi şunu öneriyor:

example.net.               TXT  "v=spf1 -all"
_dmarc.example.net.        TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"
*._domainkey.example.net.  TXT  "v=DKIM1; p="
example.net.               MX   0 .

Kayıtları kendiniz kontrol edin

Denetleyici SPF ve DMARC'ı okur; üç kaydı da standart DNS araçlarıyla görebilirsiniz. macOS veya Linux'ta:

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

Windows'ta nslookup -type=TXT _dmarc.example.com aynı işi görür. DKIM için selector'e ihtiyacınız var; bunu sağlayıcınız DKIM ayarlarında gösterir ve gönderdiğiniz herhangi bir iletinin DKIM-Signature başlığında s= olarak görünür; Google Workspace için varsayılan google'dır. Bazı sağlayıcılar anahtarı kendi DNS'lerine işaret eden bir CNAME olarak yayınlar, bu sorun değildir.

En güvenilir uçtan uca test gerçek bir iletidir. Her servisten bir Gmail adresine ileti gönderin ve "Orijinali göster"i açın: SPF, DKIM ve DMARC sonucunu ve her birinin hangi alan adı için geçtiğini listeler. DKIM'in sizin alan adınız yerine sağlayıcının alan adı için geçmesi, DMARC hizalamasının hâlâ başarısız olduğu anlamına gelir; bu yüzden sonuçta kendi alan adınızı arayın.

Sık yapılan hatalar

Örnek senaryo (varsayımsal)

Aşağıdaki örnek varsayımsaldır, gerçek veri değildir. Kurgusal bir klinik olan Pinecrest Dental, hastalardan klinik adına gelmiş sahte bir ödeme talebi aldıklarını duyar. SPF ve DMARC denetleyicisi şunu gösterir:

• SPF: v=spf1 include:_spf.google.com ~all
• DMARC: eksik. Sonuç: uyarı, "DMARC eksik."

1. adım üç gönderen bulur: Google Workspace, hatırlatma e-postaları gönderen randevu sistemi ve bir e-posta bülten aracı. Randevu sistemi için bir SPF include'u gerekir; bülten aracı kendi zarf alan adını kullandığı için bunun yerine kliniğin alan adıyla DKIM alır. Klinik DMARC'ı p=none ve bir rapor adresiyle yayınlar. İki haftalık raporlar, randevu sisteminin SPF'yi, bültenin ise DKIM'i geçtiğini; ayrıca başka ülkelerdeki bilinmeyen sunuculardan gelen ve ikisini de geçemeyen birkaç yüz iletiyi gösterir: sahteciliğin kendisi. Klinik p=quarantine'e geçer, denetleyici başarılı sonucunu verir ve bir ay sonra p=reject'e geçer. Adına gönderilen sahte iletiler artık DMARC uygulayan alıcılar tarafından reddedilir.

Bu hafta bitirebileceğiniz bir kontrol listesi

1. SPF ve DMARC denetleyicisini park edilmişler dahil sahip olduğunuz her alan adında çalıştırın.
2. Alan adınız adına e-posta gönderen tüm servisleri listeleyin.
3. SPF'yi tek kayıtta birleştirin, 10 sorgunun altında tutun ve ~all veya -all ile bitirin.
4. Her serviste DKIM'i açın ve Gmail'de "Orijinali göster" ile test edin.
5. DMARC'ı p=none ve rua ile yayınlayın, raporları okuyun.
6. p=quarantine'e, ardından p=reject'e geçin.
7. Hiç e-posta göndermeyen alan adlarında v=spf1 -all ve p=reject yayınlayın.

Searvia e-posta kimlik doğrulamanızı nasıl izler?

Ücretsiz SPF ve DMARC denetleyicisi kayıtlarınızı üye olmadan saniyeler içinde okur; web sitenizin arama görünümünü, hızını ve güvenliğini de kapsayan 38 kontrollü bir denetimin parçasıdır.

Ücretsiz bir Searvia hesabı, e-postada daha da ileri giden haftalık bir güvenlik taraması ekler: eksik ya da fazla açık bir SPF kaydını (+all, ?all veya hiç all olmaması), eksik ya da hâlâ p=none olan bir DMARC politikasını ve eksik bir CAA kaydını, her bulgunun arkasındaki DNS sorgusu ve kopyalayabileceğiniz bir kayıtla birlikte işaretler. Tarama her Perşembe tekrarlanır; böylece kayıtlarınızı bozan bir DNS değişikliği bir hafta içinde ortaya çıkar. Güvenliğin web sitesi tarafı için güvenlik başlıkları rehberimize bakın.