Ana sayfa › Rehberler

SPF, DKIM ve DMARC Kurulumu: Kayıtlar, Sık Hatalar ve Kontroller

Yayın tarihi 2026-11-03 ／ Güncelleme 2026-11-03 ／ Yayımlayan Yuki Nakazawa

Kendi alan adınızdan e-posta gönderiyorsanız SPF, DKIM ve DMARC kurulumu artık isteğe bağlı değildir. Bunu şu sırayla yapın: tek bir SPF kaydı yayımlayın, 2048 bit anahtarla DKIM imzalamayı açın, ardından raporlama etkin şekilde p=none ile başlayan bir DMARC kaydı yayımlayın. Bu arada postanızı gönderen IP adresinin eşleşen bir ters DNS (PTR) kaydına sahip olduğundan da emin olun.

Bu rehber; paylaşımlı hosting, kendi VPS'iniz, Google Workspace, Microsoft 365 veya bir toplu e-posta hizmeti üzerinden gönderim yapsanız da işinize yarar. Size uyarlayabileceğiniz kayıtları, kimlik doğrulamayı en sık bozan hataları ve gerçek bir ileti başlığından her şeyin çalıştığını nasıl doğrulayacağınızı gösterir.

Aşağıdaki bilgiler, Kasım 2026 itibarıyla RFC'ler ve Google, Yahoo ve Microsoft'un resmî sayfalarıyla karşılaştırılarak kontrol edilmiştir. Posta sağlayıcılarının gereksinimleri değişir; son söz için onların sayfalarını esas alın.

SPF, DKIM ve DMARC neyi kanıtlar ve hangi sırayla kurulur

SPF (Sender Policy Framework), bir alan adının hangi sunucuların kendi adına posta gönderebileceğini DNS'te listelemesini sağlar. Alıcı sunucu zarf göndericisine (daha sonra Return-Path olarak görünen SMTP MAIL FROM adresi) bakar, o alan adının SPF kaydını alır ve bağlanan IP adresinin listede olup olmadığını kontrol eder. SPF tek başına, okuyucunun gördüğü From adresi hakkında hiçbir şey söylemez.

DKIM (DomainKeys Identified Mail), her iletiye kriptografik bir imza ekler. Gönderen sistem özel anahtarla imzalar, alıcılar ise imzayı DNS'te yayımlanan ortak anahtarla doğrular. Geçerli bir imza, imzalayan alan adının (d= değeri) iletinin sorumluluğunu üstlendiğini ve imzalanan başlıkların ve gövdenin yolda değiştirilmediğini kanıtlar.

DMARC (Domain-based Message Authentication, Reporting and Conformance), bu ikisini görünen From alan adına bağlar. Bir ileti DMARC'tan yalnızca SPF veya DKIM geçtiğinde ve kimliği doğrulanan alan adı From alan adıyla hizalı olduğunda geçer. DMARC kaydı ayrıca alıcılara başarısız iletilerle ne yapılmasını istediğinizi (hiçbir şey, karantina veya ret) ve toplu raporların nereye gönderileceğini bildirir; unuttuğunuz gönderim kaynaklarını da bu raporlar sayesinde bulursunuz.

Kurulum sırası

1. Alan adınız adına posta gönderen tüm sistemleri listeleyin: kendi sunucunuz, Google Workspace veya Microsoft 365, bülten ve işlemsel e-posta hizmetleri, web formları, faturalama ve yardım masası araçları.
2. Bunların hepsini kapsayan tek bir SPF kaydı yayımlayın.
3. Her gönderim sisteminde DKIM'i etkinleştirin ve ortak anahtarını yayımlayın.
4. DMARC'ı p=none ve bir rua rapor adresiyle yayımlayın. Google, SPF ve DKIM'i kurduktan sonra DMARC eklemeden önce 48 saat beklemeyi önerir.
5. Raporları okuyun, başarısız olan kaynakları düzeltin, ardından p=quarantine'e ve son olarak p=reject'e geçin.

SPF kurulumu: tek kayıt, on sorgu

SPF, alan adının kendisinde bulunan bir TXT kaydıdır. Aşağıda, kendi sunucusundan IPv4 ve IPv6 üzerinden gönderim yapan ve ayrıca Google Workspace kullanan bir alan adı örneği var:

example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.google.com ~all"

Çoğu DNS kontrol panelinde ana bilgisayar (host) alanını boş bırakır (veya @ girer), TXT'yi seçer ve v=spf1 ile başlayan değeri yapıştırırsınız. Sık kullanılan yapı taşları:

SPF'de sık yapılan hatalar

• Her ad için tek SPF kaydı. RFC 7208, aynı alan adı için birden fazla SPF kaydını yasaklar; alıcılar permerror döndürür ve SPF her şey için başarısız olur. Bir hizmet eklediğinizde ikinci bir v=spf1 kaydı oluşturmak yerine mevcut kaydı düzenleyip hizmetin include: ifadesini sona ekleyin.
• 10 sorgu sınırı. include, a, mx, ptr ve exists mekanizmalarının ve redirect değiştiricisinin her biri DNS sorgusu tetikler ve iç içe include'ların içindeki sorgular dahil tüm değerlendirme boyunca toplam sayı 10'u aşmamalıdır. Sınırı aşmak permerror ile sonuçlanır. ip4:, ip6: ve all sorgu harcamaz. RFC 7208 ayrıca alıcıların yanıt döndürmeyen iki sorgudan sonra durması gerektiğini söyler; bu nedenle artık kullanmadığınız hizmetlerin include'larını kaldırın.
• ~all ile -all farkı. -all, listede olmayan kaynakların yetkili olmadığı (fail) anlamına gelir; ~all ise muhtemelen yetkili olmadıkları (softfail) anlamına gelir. Google, Workspace alan adları için ~all önerir; Microsoft ise DKIM ve DMARC da kullanan Microsoft 365 alan adları için -all önerir. Tüm gönderenleri bulduğunuzdan henüz emin değilseniz ~all ile başlayın ve yaptırımı DMARC'a bırakın.
• Alt alan adlarının kendi kaydı gerekir. example.com üzerindeki SPF kaydı news.example.com alan adını kapsamaz. Bir toplu e-posta hizmetini kendi alt alan adına almak, ona ayrı bir 10 sorguluk bütçe de sağlar ve itibarını çalışanlarınızın postalarından ayrı tutar.
• Söz dizimi hataları. Microsoft yaygın olanları şöyle sıralar: include: yerine include= yazmak, iki noktadan sonra boşluk bırakmak ve eklenen alan adının sonuna nokta koymak.

Hiç posta göndermeyen alan adları için v=spf1 -all yayımlayın; böylece bu alan adlarının taklit edilmesi zorlaşır.

DKIM kurulumu: 2048 bit anahtarlar ve seçiciler

DKIM iki parçadan oluşur: gönderen sistem özel anahtarla imzalar, DNS ise eşleşen ortak anahtarı yayımlar. Google Workspace, Microsoft 365, çoğu hosting kontrol paneli ve çoğu e-posta hizmetinde anahtarı yönetim konsolunda oluşturur ve gösterilen DNS değerini kopyalarsınız.

Anahtar uzunluğu ve seçiciler

2048 bit RSA anahtarı kullanın. RFC 8301, 1024 biti asgari değer olarak belirler ve imzalayanların en az 2048 bit kullanması gerektiğini söyler; ayrıca rsa-sha1 kullanımını yasaklar. Google'ın yönergeleri de aynı doğrultudadır: DNS sağlayıcınız destekliyorsa 2048 bit seçin, yalnızca desteklemiyorsa 1024 bite geri dönün.

Seçici (selector), bir iletiyi hangi anahtarın imzaladığını belirten bir etikettir; bu sayede bir alan adı aynı anda, her gönderim hizmeti veya her anahtar değişim dönemi için bir tane olmak üzere birden fazla anahtara sahip olabilir. Ortak anahtar selector._domainkey.yourdomain adresinde bulunur. Google Workspace varsayılan seçici olarak google kullanır. Microsoft 365 ise Microsoft'un barındırdığı anahtarları gösteren selector1._domainkey ve selector2._domainkey adlı iki CNAME kaydı kullanır; biçim kiracıya (tenant) göre değiştiği için hedefleri tam olarak Defender portalından veya Get-DkimSigningConfig ile alın.

Uzun bir ortak anahtarı yayımlamak

2048 bit bir ortak anahtar, tek bir DNS karakter dizisinde izin verilen 255 karakterden uzundur; bu nedenle bölge dosyası (zone file) biçiminde tek bir TXT kaydı içinde birden fazla tırnaklı dize olarak yazılır:

selector1._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA(first part of your key)"
    "(rest of your key)IDAQAB" )

Parantez içindeki kısımları kendi anahtarınızla değiştirin. Alıcılar dizeleri aralarına boşluk koymadan birleştirir; bu yüzden anahtarın içinde herhangi bir yerden bölebilirsiniz. Birçok kontrol paneli uzun değerleri otomatik olarak böler: önce değerin tamamını yapıştırın, yalnızca panel kabul etmezse kendiniz bölün. Kopyalarken hiçbir şeyin kaybolmadığından emin olun; boş bir p= anahtarın iptal edildiği anlamına gelir.

Postfix veya benzeri bir MTA çalıştıran kendi VPS'inizde, OpenDKIM gibi bir imzalama milter'ı anahtar çiftini oluşturabilir; örneğin opendkim-genkey -b 2048 -s selector1 -d example.com. Oluşturulan ortak anahtar dosyasının içeriğini yukarıda gösterildiği gibi yayımlayın.

İletilerin gerçekten imzalandığını kontrol edin

Gönderdiğiniz bir iletiyi açın ve DKIM-Signature: başlığını arayın. Bu başlıktaki d= etiketi sizin alan adınız, s= ise yayımladığınız seçici olmalıdır. Birçok e-posta hizmeti varsayılan olarak kendi alan adıyla imzalar; bu DKIM'den geçer ancak From alan adınızla hizalı olmadığı için DMARC'a katkı sağlamaz. Hizmetin özel alan adı kimlik doğrulamasını açın; böylece d= sizin alan adınız olur.

DMARC kurulumu: p=none ile başlayın, sonra yaptırım uygulayın

DMARC, alan adınızın altındaki _dmarc adresinde bulunan bir TXT kaydıdır. Alıcılardan postanızı işleme biçimlerini değiştirmemelerini isteyen izleme modunda başlayın ve toplu rapor talep edin:

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

Toplu raporlar, hangi IP adreslerinin alan adınız adına posta gönderdiğini ve bu postaların doğrulamadan geçip geçmediğini gösteren, makinece okunabilir özetlerdir; Google bunları almak için ayrı bir posta kutusu veya grup kullanılmasını önerir. Raporlar tüm meşru kaynakların hizalı olarak geçtiğini gösterdiğinde, ikinci bir kayıt eklemek yerine aynı kaydı düzenleyerek politikayı sıkılaştırın:

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

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

Basitçe hizalama

DMARC'tan geçmek için SPF veya DKIM'den en az birinin, From alan adıyla eşleşen bir alan adı için başarılı olması gerekir. Esnek (relaxed) modda kurumsal alan adlarının eşleşmesi gerekir; dolayısıyla d=example.com içeren bir DKIM imzası, alerts@news.example.com adresinden gelen postayla hizalıdır. Katı (strict) mod ise tam eşleşme gerektirir. E-posta hizmetleri Return-Path'te çoğu zaman kendi alan adlarını kullanır; bu nedenle SPF başarılı olsa bile hizalı olmaz. Bu iletileri DMARC'tan geçirmenin pratik yolu hizalı DKIM'dir.

Alt alan adları için farklı bir politika istiyorsanız sp= ekleyin. Örneğin p=reject; sp=quarantine, ana alan adından gelen başarısız postaları reddederken alt alan adlarından gelen başarısız postaları yalnızca karantinaya alır.

Güncellenen standart hakkında bir not

Mayıs 2026'da DMARC, RFC 7489'u geçersiz kılan RFC 9989 olarak yeniden yayımlandı. Mevcut kayıtlar çalışmaya devam eder ve hâlâ v=DMARC1 ile başlar. Yeni standart, 0 veya 100 dışındaki değerlerde nadiren doğru uygulanan pct etiketini kaldırır ve t=y (test modu) ile np (var olmayan alt alan adları için politika) gibi etiketler ekler. Bazı sağlayıcıların yardım sayfaları hâlâ pct gösterdiğinden, yaptırımı devreye almanın en az belirsiz yolu p= değerlerini adım adım değiştirmektir.

Gönderen IP'niz için ters DNS (PTR)

Ters DNS, bir IP adresini bir ana bilgisayar adına geri eşler. Google, kişisel Gmail hesaplarına gönderim yapan tüm gönderenlerin, ana bilgisayar adı aynı gönderen IP'ye geri çözümlenen bir PTR kaydına sahip olmasını şart koşar; Yahoo ise gönderen IP'ler için geçerli ileri ve ters DNS ister ve genel kalıp olmayan, anlamlı bir PTR kaydı önerir.

203.0.113.10       PTR  mail.example.com.
mail.example.com.  A    203.0.113.10

PTR kaydı alan adınızın bölgesinde (zone) bulunmaz. IP adresinin sahibi kim ise kaydı o kontrol eder; bu nedenle VPS'te bunu sağlayıcının kontrol panelinde (genellikle reverse DNS veya rDNS olarak adlandırılır) ayarlar, ardından kendi DNS'inizde eşleşen bir A kaydı (IPv6 için AAAA) oluşturursunuz. IPv6 üzerinden gönderim yapıyorsanız IPv6 adresine de aynı işlem uygulanmalıdır. Google Workspace, Microsoft 365, e-posta hizmetleri ve çoğu paylaşımlı hostingde gönderen IP'leri ve bunların ters DNS kayıtlarını sağlayıcı sizin için yönetir.

Kurulumunuzu nasıl doğrularsınız

Authentication-Results başlığını okuyun

Harici bir posta kutusuna test iletisi gönderin ve başlıkların tamamını görüntüleyin. Gmail'de iletiyi açıp Orijinali göster'i seçin. Google'ın DKIM yardım sayfası, kendinize değil başka bir kullanıcıya göndermeniz gerektiğini belirtir. Şuna benzer bir başlık arayın:

Authentication-Results: mx.example.net;
       dkim=pass header.i=@example.com header.s=selector1;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

Tam düzen alıcıya göre değişir. Önemli olan; header.i veya header.d ile header.from içinde kendi alan adınızın bulunduğu spf=pass, dkim=pass ve dmarc=pass sonuçlarıdır. SPF bir hizmetin alan adı için geçiyor ama DKIM başka bir alan adı gösteriyorsa DMARC başarısız olur: önce DKIM hizalamasını düzeltin.

DNS'i doğrudan sorgulayın

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

Windows'ta nslookup -type=TXT _dmarc.example.com aynı işi görür. DNS değişikliklerinin yayılması zaman alabilir; Google, SPF ve DKIM'in her birinin çalışmaya başlamasının 48 saate kadar sürebileceğini söyler. Ücretsiz çevrim içi denetleyiciler de kayıtlarınızı ayrıştırabilir ve SPF sorgularını sizin için sayabilir.

Kimlik doğrulama başarılı olduğu hâlde posta hâlâ geri dönüyor veya spam'e düşüyorsa, gönderen IP'nizin veya alan adınızın bir DNSBL'de listelenip listelenmediğini kara liste kontrol aracımızla kontrol edin ve sonraki adımlar için e-posta kara liste nedeniyle teslim edilmiyorsa rehberine bakın.

Gmail, Yahoo ve Outlook.com gönderen gereksinimleri

Büyük posta sağlayıcıları artık kimlik doğrulamayı zorunlu tutuyor. Kasım 2026 itibarıyla resmî sayfalarında şunlar yazmaktadır.

• Gmail (1 Şubat 2024'ten beri geçerli): kişisel Gmail hesaplarına gönderim yapan herkesin SPF veya DKIM'e, eşleşen ileri ve ters DNS'e, TLS bağlantısına ve Postmaster Tools'ta %0,3'ün altında bir spam oranına ihtiyacı vardır. Günde 5.000'den fazla ileti gönderenlerin ayrıca hem SPF hem de DKIM'e, bir DMARC kaydına (p=none kabul edilir), SPF veya DKIM ile hizalı bir From alan adına ve pazarlama postaları için tek tıkla abonelikten çıkmaya ihtiyacı vardır. DKIM anahtarları en az 1024 bit olmalıdır; 2048 bit önerilir.
• Yahoo (Şubat 2024'ten itibaren uygulanıyor): tüm gönderenlerin SPF veya DKIM'e, geçerli ileri ve ters DNS'e ve %0,3'ün altında bir spam oranına ihtiyacı vardır. Toplu gönderenlerin hem SPF hem DKIM'e, en az p=none düzeyinde ve doğrulamadan geçen bir DMARC politikasına, From hizalamasına (esnek mod yeterlidir), çalışan bir tek tıkla abonelikten çıkma özelliğine ve gönderen IP'ler için geçerli ileri ve ters DNS'e ihtiyacı vardır.
• Outlook.com (outlook.com, hotmail.com ve live.com'un arkasındaki bireysel hizmet): günde 5.000'den fazla e-posta gönderen alan adları SPF ve DKIM'den geçmeli ve SPF veya DKIM ile hizalı, en az p=none düzeyinde bir DMARC yayımlamalıdır. Microsoft, 5 Mayıs 2025'ten itibaren uyumsuz iletilerin 550; 5.7.515 hatasıyla reddedileceğini açıklamıştır.

Metnin tamamını Google e-posta gönderen yönergeleri, Yahoo gönderen en iyi uygulamaları ve Microsoft'un Outlook.com duyurusu sayfalarında okuyun. Çok daha az ileti gönderseniz bile üçünü de şimdi kurmak, ileride eşik düşürüldüğünde hazırlıksız yakalanmamanızı sağlar. Gmail'e özgü sorun giderme için Gmail e-postanızı teslim etmiyorsa rehberine bakın.

Sık yapılan hatalar

• İkinci bir SPF kaydı. Her hizmet için yeni bir v=spf1 kaydı eklemek, tüm alan adı için SPF'yi geçersiz kılar. Her şeyi tek bir kayıtta birleştirin.
• Çok fazla include. SPF'de bırakılan eski hizmetler 10 sorguluk bütçeyi tüketir. Artık kullanmadıklarınızı kaldırın ve toplu postaları bir alt alan adına taşıyın.
• Anahtar yayımlanmış, imzalama etkin değil. Google Workspace'te DNS kaydı yayına girdikten sonra yine de Kimlik doğrulamayı başlat'a tıklamanız gerekir; diğer platformlarda da benzer bir anahtar vardır.
• Hizmet kendi alan adıyla imzalıyor. SPF ve DKIM geçer, DMARC başarısız olur. Özel alan adıyla imzalamayı etkinleştirin.
• Doğrudan p=reject'e geçmek. Unutulmuş bir web formu veya faturalama sistemi bir gecede posta teslim edemez hâle gelir. p=none ile başlayın ve raporları okuyun.
• Kopyala-yapıştır hasarı. Değerin içinde fazladan tırnak işaretleri, kesilmiş bir anahtar veya panel alan adını sizin yerinize eklediği için _dmarc.example.com.example.com hâline gelen bir ana bilgisayar adı. Kısa bir dig sorgusu bunların hepsini yakalar.

Sık sorulan sorular

Kullanılan resmî sayfalar

Bu makaledeki bilgiler, yayın tarihinde aşağıdaki resmî sayfalarla karşılaştırılarak doğrulanmıştır. Politikalar ve işleyiş haber verilmeden değişebilir; önemli bir konuda karar vermeden önce resmî sayfaları kontrol edin.

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9989: DMARC (obsoletes RFC 7489)
• Google: Email sender guidelines
• Google Workspace: Set up SPF
• Google Workspace: Set up DKIM
• Google Workspace: Set up DMARC
• Yahoo Sender Hub: Sender Best Practices
• Microsoft Community Hub: Outlook's New Requirements for High-Volume Senders
• Microsoft Learn: Set up SPF for your Microsoft 365 domain
• Microsoft Learn: How to use DKIM for email in your custom domain

İlgili rehberler

Tüm rehberler →