SPF, DKIM ve DMARC Kurulumu: Soğuk E-posta İçin Adım Adım Rehber

Soğuk e-postayı kendi alan adınızdan gönderiyorsanız, alıcı sunucuların iletinin gerçekten size ait olduğuna inanıp inanmayacağına üç DNS kaydı karar verir: SPF, DKIM ve DMARC. Bunlar olmadan, iyi yazılmış bir ilk e-posta bile kimse okumadan filtrelenebilir.

Bu rehber, you@yourcompany.com gibi bir adresten, genellikle Google Workspace üzerinden ilk temas e-postaları gönderen kurucular ve satış ekipleri içindir. Biz (Outreach), her kaydı kurmanız gereken sırayla anlatıyor, kayıt biçimlerini Google'ın yardım sayfalarında ve RFC'lerde yayımlandığı haliyle gösteriyor ve bir kaydın iyi görünürken sessizce başarısız olmasına yol açan hataları belirtiyoruz.

DNS uzmanı olmanız gerekmez. Alan adınızın DNS ayarlarına (alan adı kayıt kuruluşunuzda veya DNS sağlayıcınızda) ve DKIM için Google Workspace yönetici erişimine ihtiyacınız vardır.

SPF, DKIM ve DMARC birer cümleyle nedir?

SPF, alan adınız adına posta göndermesine izin verilen sunucuları listeler; DKIM, bir iletinin sahte olmadığını ya da değiştirilmediğini kanıtlayan kriptografik bir imza ekler; DMARC ise bir ileti bu kontrollerden geçemediğinde alıcıların ne yapması gerektiğini söyler. Üçü de alan adınızın DNS'inde TXT kaydı olarak yayımlanır.

Birlikte çalışırlar. SPF ve DKIM'in her biri dar bir şeyi kanıtlar; DMARC ise bu kanıtları insanların From satırında gerçekten gördüğü adrese bağlar.

Bu kayıtlar soğuk e-posta için gerçekten zorunlu mu?

Evet — Gmail ve Yahoo'ya gönderen her gönderici için en azından SPF veya DKIM zorunludur, toplu e-posta gönderenlerin ise üçüne de ihtiyacı vardır. Bu bir en iyi uygulama önerisi değildir; her iki sağlayıcının yayımladığı gönderici kurallarında yer alır.

Google'ın e-posta gönderici yönergeleri tüm göndericilerin “Gönderici alan adlarınız için SPF veya DKIM e-posta kimlik doğrulamasını ayarlayın.” kuralına uymasını ister. “Gmail hesaplarına günde 5.000'den fazla ileti” gönderenler ayrıca “SPF ve DKIM'i ayarlamalı” ve “gönderici alan adınız için DMARC e-posta kimlik doğrulamasını” da kurmalıdır; From alan adı da SPF veya DKIM alan adıyla hizalı olmalıdır. Bu kurallar 1 Şubat 2024'te yürürlüğe girdi.

Yahoo'nun Sender Hub en iyi uygulamaları da aynı kuralı koyar: her gönderici “En azından SPF veya DKIM uygulayın,” toplu e-posta gönderenler ise “Hem SPF hem DKIM uygulayın” ve “En az p=none olan geçerli bir DMARC politikası yayımlayın.”

Küçük bir soğuk e-posta programı günde 5.000 iletiye hiç ulaşmayabilir. Yine de üçünü de kurun: hiçbir maliyeti yoktur, bir öğleden sonranızı alır ve sınırın nerede olduğunu hiçbir zaman öğrenmek zorunda kalmamanızı sağlar.

SPF nasıl kurulur?

Kök alan adınıza v=spf1 ile başlayan, sizin adınıza posta gönderen her hizmeti listeleyen ve ~all ile biten bir TXT kaydı ekleyin. Yalnızca Google Workspace üzerinden gönderen bir alan adı için Google'ın SPF kurulum sayfası şu kaydı verir:

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

Adımlar:

1. Alan adı sağlayıcınızın DNS ayarlarında oturum açın.
2. Bir TXT kaydı oluşturun. Google, kaydı bir alt alan adına değil kök alan adına ekliyorsanız ana bilgisayar (host) veya ad alanına @ girmenizi söyler.
3. Kaydı değer olarak yapıştırın ve kaydedin.
4. Bekleyin. Google şunu not eder: “SPF kimlik doğrulamasının çalışmaya başlaması 48 saate kadar sürebilir.”

Alan adınızdan başka hizmetler de posta gönderiyorsa — bir bülten aracı, bir CRM, bir işlem e-postası hizmeti — her birinin aynı kayıt içinde kendi include: terimine ihtiyacı vardır. Google'ın sayfası şu birleşik örnekleri verir:

v=spf1 include:_spf.google.com include:amazonses.com ~all
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all

Her gönderim hizmetinin kendi belgelerinde verdiği include değerini kullanın; tahmin yürütmeyin.

SPF kaydı ~all ile mi yoksa -all ile mi bitmeli?

Google'ın kurulum rehberi ~all kullanır ve adınıza gönderen her hizmeti henüz keşfetmeye devam ederken güvenli varsayılan budur. İki bitiş, SPF standardı olan RFC 7208 belgesinde farklı anlamlara gelir:

• ~all (softfail), “Yayımlayan ADMD'nin, ana bilgisayarın büyük olasılıkla yetkili olmadığına dair zayıf bir ifadesidir.”
• -all (fail), “İstemcinin verilen kimlikte alan adını kullanma yetkisinin olmadığına dair açık bir ifadedir.”

-all ile, dahil etmeyi unuttuğunuz bir gönderim hizmeti kesin başarısızlık alır. DMARC devreye girdikten ve raporları her meşru kaynağın geçtiğini gösterdikten sonra SPF bitişinin önemi azalır, çünkü alıcıların izlediği talimat DMARC'ın politikası olur.

Çok fazla include olduğunda SPF neden bozulur?

Çünkü bir SPF kontrolü en fazla 10 DNS sorgusu tetikleyebilir; bunun ötesinde sonucun tamamı hataya dönüşür. RFC 7208, bölüm 4.6.4, uygulamaların “SPF değerlendirmesi sırasında bu terimlerin toplam sayısını mutlaka 10 ile sınırlaması gerektiğini” ve “Bu sınır aşılırsa uygulamanın mutlaka 'permerror' döndürmesi gerektiğini” söyler.

Sayılan terimler include, a, mx, ptr, exists ve redirect değiştiricisidir. Önemli olan nokta, sayımın değerlendirmenin tamamını kapsamasıdır — yani kendi içinde başka include'lar barındıran bir include: 10 hakkınızdan birkaçını harcar. Google'ın kendi sayfası bunu “Bir SPF kaydı en fazla 10 include: etiketi içerebilir” diye ifade eder; iç içe sorgular da sayıldığı için RFC daha katı bir okumadır.

Yıllar içinde birkaç satış ve pazarlama aracı eklediyseniz, yeni include'lar eklemeden önce artık kullanmadıklarınızı kaldırın.

Bir alan adında iki SPF kaydı olursa ne olur?

SPF hatayla başarısız olur — iki kayıt, birleştirilecek iki liste olarak değil, bozuk bir yapılandırma olarak değerlendirilir. RFC 7208, bir alan adı için birden fazla v=spf1 kaydı bulunduğunda kontrolün “'permerror' sonucunu ürettiğini” söyler.

Bunun sık görülen nedeni şudur: biri yeni bir araç için mevcut kaydı düzenlemek yerine ikinci bir TXT kaydı ekler. Çözüm, yukarıdaki örneklerde olduğu gibi bunları birden fazla include: terimi içeren tek bir kayıtta birleştirmektir.

Google Workspace'te DKIM nasıl açılır?

Google Yönetici Konsolu'nda bir anahtar oluşturun, onu google._domainkey adresinde TXT kaydı olarak yayımlayın, ardından “Kimlik doğrulamasını başlat” seçeneğine tıklayın. Google'ın DKIM kurulum sayfası yolu şöyle gösterir:

1. Google Yönetici Konsolu'nda Uygulamalar > Google Workspace > Gmail > E-posta kimlik doğrulaması yoluna gidin. (Gmail ayarları yönetici ayrıcalığına sahip olmanız gerekir.)
2. Alan adını seçin ve yeni bir kayıt oluşturun.
3. Anahtar uzunluğunu seçin. Google, “Alan adı sağlayıcınız 2048 bit anahtarları destekliyorsa” 2048 seçmenizi söyler, çünkü “Daha uzun anahtarlar, daha kısa anahtarlardan daha güvenlidir,” ve 1024 değerini yalnızca “Alan adı sağlayıcınız 2048 bit anahtarları desteklemiyorsa” seçmenizi söyler.
4. Varsayılan önek seçicisini, google değerini koruyun — Google, Workspace için bunu “önerilen seçenek” olarak adlandırır.
5. Google size bir DNS ana bilgisayar adı olan google._domainkey ve v=DKIM1 ile başlayan bir TXT değeri gösterir. İkisini de DNS sağlayıcınızdaki yeni bir TXT kaydına kopyalayın.
6. Yönetici Konsolu'na dönün ve Kimlik doğrulamasını başlat seçeneğine tıklayın.

Google'ın oluşturduğu TXT değeri şu biçimdedir (anahtarın kendisi, alan adınıza özgü uzun bir dizedir):

v=DKIM1; k=rsa; p=MIIBIjANBgkqh...(your public key continues)

Süre: Google, anahtarı ekledikten sonra “DKIM kimlik doğrulamasının çalışmaya başlaması 48 saate kadar sürebilir” der. Gmail'i yeni bir alan adı için yeni kurduysanız, Google DKIM anahtarı Yönetici Konsolu'nda kullanılabilir olmadan önce “24–72 saat beklemeniz gerektiğini” belirtir.

Adınıza başka bir hizmet posta gönderiyorsa, size kendi seçicisiyle kendi DKIM kaydını verecektir. Onu da yayımlayın — SPF'nin aksine, farklı seçicilere sahip birden fazla DKIM anahtarı bir arada bulunabilir.

Kendi postanızı engellemeden DMARC nasıl kurulur?

Önce _dmarc.yourcompany.com adresinde p=none ile bir TXT kaydı yayımlayın, raporları okuyun ve politikayı ancak ondan sonra sıkılaştırın. Google'ın DMARC kurulum sayfası şunu söyler: “DMARC kullanmaya başladığınızda politika seçeneğini (p) none olarak ayarlamanızı öneririz.” Ayrıca “DMARC'ı kurmadan önce SPF ve/veya DKIM'i kurduktan sonra 48 saat beklemenizi” de tavsiye eder.

Google'ın sayfası şu tam örnek kaydı verir:

v=DMARC1; p=reject; rua=mailto:postmaster@example.com, mailto:dmarc@example.com; pct=100; adkim=s; aspf=s

Bu örnek, bitmiş ve en katı durumu gösterir. İlk kayıt için aynı biçimin izleme politikası ve tek bir rapor adresiyle kullanılması yeterlidir — örneğin v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com. rua etiketi toplu raporları o posta kutusuna gönderir; raporlar çok sayıda gelebileceği için Google ayrılmış bir posta kutusu veya grup önerir.

DMARC belirtiminde tanımlandığı şekliyle üç politika değeri:

Bir alan adı tek bir DMARC kaydına sahip olur. RFC 9989 uyarınca birden fazla DMARC kaydı döndürülürse “hepsi atılır” — yani hiçbir politika uygulanmaz.

“Hizalama” ne anlama gelir ve SPF geçerken DMARC neden başarısız olur?

DMARC yalnızca SPF veya DKIM, insanların gördüğü From adresiyle eşleşen bir alan adı için geçtiğinde geçer. SPF, From satırı sizin alan adınızı gösterirken gönderim hizmetinizin kendi alan adı için geçebilir — ve bu durumda DMARC yine de başarısız olur, çünkü geçen alan adı hizalı değildir.

DMARC belirtimi, en az bir kimlik doğrulama yöntemi “hizalı bir tanımlayıcıya dayalı” bir geçiş ürettiğinde iletinin geçtiğini belirtir (RFC 7489, artık RFC 9989 ile sürdürülüyor). Varsayılan olarak hizalama gevşektir (adkim ve aspf varsayılan olarak r değerini alır): mail.yourcompany.com ve yourcompany.com aynı kurumsal alan adını paylaştığı için eşleşme sayılır. Google'ın örneğindeki gibi katı mod (s) ise tam eşleşme gerektirir.

Uygulamada DKIM'in soğuk e-posta için bu kadar önemli olmasının nedeni budur: gönderim hizmetiniz sizin alan adınızla imzaladığında, SPF hizalaması geçmese bile DKIM hizalaması geçer.

DMARC standardı 2026'da değişti mi?

Evet. Mayıs 2026'da Standards Track belgesi olarak yayımlanan RFC 9989, özgün RFC 7489'u geçersiz kılar — ve pct etiketini kaldırır. Mevcut v=DMARC1 kayıtları çalışmaya devam eder.

Çoğu göndericinin fark edeceği ana değişiklik şudur: pct (politikayı başarısız postanın yalnızca bir yüzdesine uygulama) artık yok. RFC şunu açıklar: “Operasyonel deneyim, belirtilen değer 0 veya 100 olmadıkça 'pct' etiketinin genellikle doğru uygulanmadığını gösterdi.” Onun yerine bir test bayrağı olan t=y gelir; bu bayrak, siz politikayı test ederken alıcılardan belirttiğiniz politikayı uygulamamalarını ister.

Google'ın yardım sayfası örneğinde hâlâ pct=100 gösteriyor. Bu hiçbir şeyi bozmaz: RFC 9989 “bilinmeyen etiketler mutlaka yok sayılmalıdır” der, bu yüzden kalıntı bir pct basitçe atlanır. Kaydınızı bir sonraki düzenleyişinizde onu kaldırabilirsiniz.

Her şeyin çalıştığını nasıl kontrol edersiniz?

Yayımladığınız kayıtları sorgulayın, ardından bir Gmail adresine gerçek bir ileti gönderin ve kimlik doğrulama sonuçlarını okuyun. İki hızlı kontrol:

1. DNS kayıtlarını sorgulayın. Ücretsiz kontrol aracımız, girdiğiniz adresin alan adı için SPF, DKIM ve DMARC kayıtlarını sorgular — kayıt gerekmez. Google'ın varsayılan DKIM seçicisini (google._domainkey) kontrol eder; gönderim hizmetiniz farklı bir seçici kullanıyorsa, DKIM kurulu olsa bile araç DKIM'i doğrulanmadı olarak bildirir. Araç İngilizce ve Korece olarak kullanılabilir; gönderen e-posta adresinizi girin.
2. Gerçek bir iletiyi kontrol edin. Kontrolünüzdeki bir Gmail hesabına e-posta gönderin, açın, “Orijinali göster” seçeneğini seçin ve SPF: PASS, DKIM: PASS ve DMARC: PASS ifadelerini arayın.

Ardından DMARC raporlarına bir iki hafta tanıyın. Kullandığınız her meşru kaynak geçer görünüyorsa p=none değerinden p=quarantine değerine geçin; kimlik taklidine karşı en güçlü korumayı istiyorsanız daha sonra p=reject değerine geçin.

Kimlik doğrulamayı en sık hangi hatalar bozar?

İki SPF kaydı, çok fazla SPF sorgusu, oluşturulup hiç başlatılmayan DKIM ve SPF ile DKIM'in çalışmaya zaman bulamadan yayımlanan DMARC. Bir kontrol listesi:

• Tek bir SPF kaydı; her gönderici onun içinde bir include: olarak yer alır ve en fazla 10 sorgu terimi bulunur.
• DKIM anahtarını yayımladıktan sonra “Kimlik doğrulamasını başlat” seçeneğine tıklayın — tek başına DNS kaydı yeterli değildir.
• DMARC eklemeden önce SPF ve DKIM'den sonra yaklaşık 48 saat bekleyin ve onu kökte değil _dmarc adresinde yayımlayın.
• Kontrolünüzdeki bir alan adından gönderin. Bir @gmail.com adresi için DMARC yayımlayamazsınız.

Kimlik doğrulama, postanızın değerlendirmeye alınmasını sağlar; alıcıların onu istemesini sağlamaz. Spam şikâyetleri yine de sayılır — Google ve Yahoo ikisi de spam oranınızı 0.3%'in altında tutmanızı söyler; bunu soğuk e-postalar neden spam'e düşer yazımızda ele alıyoruz. Var olmayan adreslere göndermek geri dönenler yaratır; bu yüzden göndermeden önce adresleri doğrulamanızı öneriyoruz.

Kısa özet

• Google ve Yahoo her göndericiden SPF veya DKIM ister; toplu e-posta gönderenlerden (Gmail'e günde 5.000+ ileti) ise üçünü ve hizalamayı ister.
• SPF: @ adresinde tek bir TXT kaydı, örneğin v=spf1 include:_spf.google.com ~all; 10 DNS sorgu terimi sınırı içinde kalın.
• DKIM: 2048 bit anahtar, seçici google, google._domainkey adresinde TXT, ardından Kimlik doğrulamasını başlat.
• DMARC: _dmarc adresinde tek bir TXT kaydı, rapor adresiyle p=none ile başlayın, sonra sıkılaştırın. RFC 9989 (Mayıs 2026) pct etiketinin yerine t=y getirdi.
• Kayıtlarınızı ücretsiz e-posta kimlik doğrulama kontrol aracımızla kontrol edin, ardından gerçek bir iletiyle doğrulayın.