E-posta Kimlik Doğrulama Rehberi – SPF, DKIM ve DMARC

Gönderdiğiniz kurumsal e-postalar sürekli spam klasörüne düşüyor ya da alıcının gelen kutusuna hiç ulaşmıyorsa, sorun çoğu zaman e-postanın içeriğinde değil, alan adınızın DNS kayıtlarındadır. Modern e-posta sunucuları (Gmail, Outlook, Yandex) artık bir maili kabul etmeden önce "bu mail gerçekten bu alan adının yetkili sunucusundan mı geldi?" sorusunu sorar. Bu sorunun cevabını veremeyen alan adlarının mailleri ya spam'e düşer ya da doğrudan reddedilir. 2024'ten itibaren Google ve Yahoo, toplu mail gönderenler için bu kayıtları zorunlu hale getirmiştir; yani kimlik doğrulama artık bir "iyi olur" değil, bir gerekliliktir.

Bu üç sorunun cevabını veren üç DNS kaydı vardır: SPF (hangi sunucular adınıza mail gönderebilir), DKIM (mail yolda değiştirilmedi ve gerçekten sizden geldi) ve DMARC (bu kontrollerden geçemeyen maillere ne yapılsın). Bu rehberde üçünü de sıfırdan, örnek kayıtlarla ve yaygın hataların çözümleriyle ele alacağız. DNS mantığını hiç duymadıysanız devam etmeden önce DNS nedir yazısına göz atmanız her şeyi çok daha anlaşılır kılar.

Sorunun Kökeni: Sahtecilik (Spoofing) ve Spam#

E-postanın temelini oluşturan SMTP protokolü 1980'lerde, güvenlik değil güvenilirlik düşünülerek tasarlandı. Bu protokolde bir mailin "Kimden" (From) adresini yazmak, bir zarfın üzerine istediğiniz gönderici adresini yazmak kadar kolaydır. Yani herhangi biri, hiçbir yetkisi olmadan [email protected] adresinden geliyormuş gibi görünen bir mail gönderebilir. Buna spoofing (sahtecilik) denir ve dolandırıcılık (phishing) saldırılarının temelidir.

Alıcı posta sunucuları bu tehdide karşı savunma geliştirdi: gelen her maili puanlayan filtreler. Bu filtreler için en güçlü sinyal, gönderen alan adının kimlik doğrulama kayıtlarının olup olmadığıdır. Kayıtları eksik bir alan adından gelen mail, "kimliği belirsiz" kabul edilir ve şüpheyle karşılanır. İşte tam da bu yüzden, hiçbir spam kelimesi içermeyen sıradan bir maliniz bile SPF/DKIM eksikse spam'e düşebilir. Üç kaydı doğru kurmak hem başkalarının sizin adınıza mail göndermesini engeller hem de kendi maillerinizin güvenle teslim edilmesini sağlar.

SPF Kaydı – Kim Sizin Adınıza Mail Gönderebilir?#

SPF (Sender Policy Framework), alan adınız adına hangi sunucuların (IP adreslerinin) mail gönderme yetkisi olduğunu ilan eden bir TXT kaydıdır. Alıcı sunucu, gelen mailin geldiği IP adresini bu listeyle karşılaştırır; IP listedeyse mail SPF kontrolünden geçer, değilse başarısız olur.

SPF kaydı alan adınızın köküne (sirketiniz.com) eklenen tek bir TXT kaydıdır ve şuna benzer:

Tür   : TXT
Ad    : sirketiniz.com   (veya @)
Değer : v=spf1 +a +mx include:_spf.saglayici.com -all

Kaydın parçalarını çözelim:

• v=spf1 — Kaydın SPF sürüm 1 olduğunu belirtir; her SPF kaydı bununla başlar.
• +a — Alan adının A kaydındaki IP'ye (yani sitenizin sunucusuna) gönderme yetkisi verir.
• +mx — Alan adının MX kaydındaki mail sunucularına yetki verir. Mailinizi hosting'inizde tutuyorsanız bu genellikle yeterlidir.
• include:_spf.saglayici.com — Başka bir servisin SPF listesini dahil eder. Google Workspace kullanıyorsanız include:_spf.google.com, bir e-posta pazarlama aracı kullanıyorsanız onun include değerini eklersiniz.
• -all — "Yukarıdakiler dışındaki tüm kaynakları reddet" anlamına gelir. En güvenli bitiş budur.

~all mı -all mı? (Softfail vs Hardfail)#

Kaydın sonundaki mekanizma, listede olmayan bir sunucudan gelen maile ne olacağını belirler:

Yeni kuruyorsanız birkaç gün ~all ile başlayıp tüm mail kaynaklarınızın (hosting, pazarlama aracı, muhasebe yazılımı) çalıştığını doğruladıktan sonra -all'a geçmek en güvenli yoldur.

10 DNS Sorgu Limiti (Kritik Tuzak)#

SPF'in az bilinen ama sık soruna yol açan bir kuralı vardır: bir SPF kaydı değerlendirilirken en fazla 10 DNS sorgusu yapılabilir. Her include, a, mx ve redirect mekanizması sorgu üretir. Çok sayıda harici servis eklerseniz (Google + pazarlama aracı + muhasebe + CRM…) bu limit aşılır ve SPF kaydınız permerror verir, yani tümüyle geçersiz sayılır. Çözüm: gereksiz include'ları kaldırmak, +a/+mx'i gerçekten gerekmiyorsa silmek veya SPF'i düzleştiren (flattening) bir servis kullanmaktır. Alan adı başına yalnızca bir tane SPF (TXT) kaydınız olmalıdır; iki ayrı SPF kaydı da geçersizliğe yol açar.

DKIM Kaydı – Mailin Kriptografik İmzası#

SPF gönderen IP'yi doğrular ama mailin içeriğinin yolda değiştirilmediğini kanıtlamaz. İşte burada DKIM (DomainKeys Identified Mail) devreye girer. DKIM, gönderdiğiniz her maile görünmez bir kriptografik imza ekler. Bu imza, mail sunucunuzda saklanan bir özel anahtarla üretilir; eşleşen genel anahtar ise DNS'inizde bir TXT kaydı olarak yayınlanır.

Alıcı sunucu maili aldığında, DNS'inizdeki genel anahtarı çeker ve imzayı doğrular. İmza tutuyorsa iki şey kanıtlanmış olur: (1) mail gerçekten sizin sunucunuzdan geldi ve (2) içeriği (konu, gövde, gönderen) yolda hiç değiştirilmedi. DKIM kaydı bir selector (seçici) üzerinden yayınlanır — böylece aynı alan adında birden fazla anahtar (örneğin farklı servisler için) tutabilirsiniz:

Tür   : TXT
Ad    : default._domainkey.sirketiniz.com
Değer : v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD...uzun...anahtar...IDAQAB

Buradaki default selector adıdır (sunucunuz farklı bir ad da kullanabilir: cpanel, dkim, s1 gibi). p= sonrası gelen uzun dize genel anahtarınızdır. cPanel kullanıyorsanız bu kaydı elle üretmenize gerek yok: cPanel → Email → Email Deliverability aracı hem SPF hem DKIM için gereken kayıtları otomatik oluşturur ve eksik olanları tek tıkla düzeltmeyi (Repair) önerir. Anahtarı elle kopyalarken araya boşluk veya satır sonu karışmamasına dikkat edin; en güvenlisi panelin ürettiği değeri olduğu gibi yapıştırmaktır.

DMARC Kaydı – Politika ve Raporlama#

SPF ve DKIM'i kurdunuz. Peki bir mail bu kontrollerden geçemezse ne olacak? Cevabı alıcı sunucunun keyfine bırakmak yerine kendiniz belirlemek istersiniz. İşte DMARC (Domain-based Message Authentication, Reporting and Conformance) tam olarak bunu yapar: SPF ve DKIM'in üzerine oturan bir politika katmanıdır.

DMARC kaydı, _dmarc alt alanına eklenen bir TXT kaydıdır:

Tür   : TXT
Ad    : _dmarc.sirketiniz.com
Değer : v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100; adkim=s; aspf=s

Etiketleri açıklayalım:

• p= — Ana politika. Başarısız maillere ne yapılacağını söyler (aşağıda üç seçenek).
• rua=mailto:... — Toplu (aggregate) raporların gönderileceği adres. Alıcı sunucular size adınıza kimin mail göndermeye çalıştığına dair günlük özet raporlar yollar.
• pct=100 — Politikanın maillerin yüzde kaçına uygulanacağı. Kademeli geçiş için pct=25 gibi başlayabilirsiniz.
• adkim=s / aspf=s — Alignment (hizalama) sıkılığı; s (strict) tam eşleşme, r (relaxed) alt alan esnekliği ister.

p=none, quarantine, reject Politikaları#

DMARC'ı doğru uygulamanın anahtarı, politikayı kademeli olarak sıkılaştırmaktır:

Asla p=reject ile başlamayın. Önce birkaç hafta p=none ile çalışın, rua adresine gelen raporları inceleyin. Bu raporlar, unuttuğunuz meşru mail kaynaklarını (örneğin fatura gönderen bir muhasebe servisi) ortaya çıkarır. Hepsini SPF/DKIM'e ekleyip raporlar temizlendikten sonra quarantine, en sonunda reject'e geçin. Bu kademeli yaklaşım, yanlışlıkla kendi meşru maillerinizi engellemeden alan adınızı koruma altına alır.

Alignment (Hizalama) Neden Önemli?#

DMARC'ın en kritik ama en çok gözden kaçan kısmı alignment'tır. Bir mailin DMARC'tan geçmesi için yalnızca SPF veya DKIM'in geçmesi yetmez; geçen kaydın alan adının, mailin görünen "Kimden" adresiyle eşleşmesi de gerekir. Örneğin bir pazarlama servisi kendi SPF'iyle mail gönderirse SPF teknik olarak geçer ama alan adı sizinkiyle hizalı olmadığı için DMARC başarısız olur. Bu yüzden pazarlama araçlarında "custom domain / özel gönderen alan adı" doğrulamasını mutlaka yapın; aksi halde DMARC p=reject'e geçtiğinizde o mailler engellenir.

Üçü Birlikte Nasıl Çalışır?#

Bu üç kayıt bir zincir oluşturur. Gmail'e bir mail gönderdiğinizi düşünün:

1. SPF kontrolü — Gmail, mailin geldiği IP'yi alan adınızın SPF listesiyle karşılaştırır. Sunucunuz listedeyse geçer.
2. DKIM kontrolü — Gmail, DNS'inizdeki genel anahtarla maildeki imzayı doğrular. İmza tutuyorsa ve içerik değişmemişse geçer.
3. DMARC değerlendirmesi — Gmail, SPF veya DKIM'in geçtiğini ve hizalı olduğunu kontrol eder. Geçtiyse mail gelen kutusuna girer; başarısızsa DMARC politikanıza (none/quarantine/reject) göre işlem yapılır ve size bir rapor gönderilir.

Kısacası SPF ve DKIM iki bağımsız kanıt sunar, DMARC ise bu kanıtların sonucunda ne olacağını yönetir ve size görünürlük (raporlama) sağlar. Üçü birlikte kurulduğunda hem teslim oranınız belirgin şekilde artar hem de alan adınız dolandırıcıların sahte mail göndermesine karşı kilitlenir.

Adım Adım DNS'e Ekleme ve Doğrulama#

Kayıtları eklemek için alan adınızın DNS yönetim paneline (hosting'inizin DNS Zone Editor'ı veya alan adı sağlayıcınızın paneli) girin.

1. SPF ekleyin — Yeni bir TXT kaydı oluşturun. Ad alanına @ (kök alan adı), değer alanına v=spf1 +a +mx -all (gerekiyorsa include'larla) yazın. Kurulum aşamasındaysanız -all yerine ~all kullanın.
2. DKIM'i etkinleştirin — cPanel'de Email Deliverability aracını açın, alan adınızın yanındaki Manage → eksik DKIM için Repair'e basın. Panel kaydı otomatik ekler. Harici bir servis (Google Workspace) kullanıyorsanız o servisin verdiği selector._domainkey TXT kaydını girin.
3. DMARC ekleyin — _dmarc adında bir TXT kaydı oluşturun, değer olarak v=DMARC1; p=none; rua=mailto:[email protected] ile başlayın.
4. Yayılmayı bekleyin — DNS değişiklikleri tüm dünyaya yayılana kadar birkaç saat sürebilir. Yayılma süresini merak ediyorsanız DNS propagasyon süresi mantığı burada da geçerlidir.

dig ile Doğrulama#

Kayıtların yayınlandığını komut satırından hızlıca kontrol edebilirsiniz:

# SPF kaydını sorgula
dig +short TXT sirketiniz.com

# DKIM kaydını sorgula (selector'ınızı yazın)
dig +short TXT default._domainkey.sirketiniz.com

# DMARC kaydını sorgula
dig +short TXT _dmarc.sirketiniz.com

Her komut, eklediğiniz TXT değerini döndürmelidir. Komut satırı yerine tarayıcı tercih ederseniz MXToolbox (mxtoolbox.com/spf.aspx, /dkim.aspx, /dmarc.aspx) veya Google'ın Admin Toolbox → Check MX aracı aynı doğrulamayı görsel olarak yapar. En sağlam test ise, kendinize bir Gmail hesabından mail atıp gelen mailde "Orijinali göster" ile SPF: PASS, DKIM: PASS, DMARC: PASS satırlarını görmektir.

rDNS / PTR Kaydına Kısa Bir Not#

SPF, DKIM ve DMARC alan adı seviyesinde çalışır; bir de IP seviyesinde önemli bir kayıt vardır: rDNS (ters DNS) / PTR kaydı. Bu kayıt, mail sunucunuzun IP adresinin hangi hostname'e ait olduğunu söyler (örneğin 1.2.3.4 → mail.sirketiniz.com). Birçok alıcı sunucu, PTR kaydı olmayan veya IP ile eşleşmeyen sunuculardan gelen maili şüpheli bulur ve reddedebilir.

Paylaşımlı hosting kullanıyorsanız PTR kaydını genellikle hosting sağlayıcınız ayarlar ve sizin bir şey yapmanız gerekmez. Ancak kendi sunucunuzu yönetiyor ve doğrudan mail gönderiyorsanız, IP'nizin PTR kaydının mail hostname'inizle birebir eşleştiğinden emin olun. İdeal kurulumda "ileri DNS" (mail.sirketiniz.com → IP) ve "ters DNS" (IP → mail.sirketiniz.com) birbirini doğrular; buna FCrDNS (Forward-Confirmed reverse DNS) denir ve teslim edilebilirliği gözle görülür şekilde artırır.

Yaygın Hatalar ve Çözümleri#

• İki SPF kaydı var — Alan adı başına yalnızca bir SPF (TXT) kaydı olabilir. Google ve hosting için ayrı ayrı iki kayıt oluşturduysanız bunları tek kayıtta birleştirin: v=spf1 +mx include:_spf.google.com -all.
• SPF permerror veriyor — 10 DNS sorgu limiti aşılmıştır. Gereksiz include'ları kaldırın, +a/+mx'i gerekmiyorsa silin.
• DKIM doğrulanmıyor — Genel anahtarı DNS'e kopyalarken araya boşluk veya satır sonu karışmıştır. Kaydı silip cPanel'in ürettiği değeri olduğu gibi tek satırda yeniden yapıştırın. Selector adının maildeki s= değeriyle eşleştiğinden emin olun.
• DMARC reject sonrası meşru mailler engellendi — Bir mail kaynağı (pazarlama aracı, fatura servisi) SPF/DKIM'e eklenmemiş veya hizalı değildir. p=none'a geri dönün, rua raporlarından eksik kaynağı bulun, ekleyin, sonra kademeli olarak sıkılaştırın.
• Kayıtları ekledim ama mailler hâlâ spam'de — DNS yayılması birkaç saat sürer; hemen sonuç beklemeyin. Ayrıca sunucu IP'nizin bir kara listede (blacklist) olup olmadığını MXToolbox Blacklist Check ile kontrol edin.

Kritik yazışmalarınızı ve posta kutularınızı korumak için hosting paketinizin otomatik yedekleme özelliğinin açık olduğundan da emin olun; kimlik doğrulama teslimatı garantiler ama içerik kaybına karşı yedek şarttır.

Sıkça Sorulan Sorular#

SPF, DKIM ve DMARC'tan hangisi öncelikli, sadece birini kursam yeter mi?#

Üçü birbirini tamamlar ve ideal olan üçünü de kurmaktır. Yine de bir öncelik sırası verilirse, önce SPF ve DKIM'i kurmalısınız çünkü DMARC bu ikisinin üzerine oturur ve onlar olmadan işe yaramaz. Yalnızca SPF, temel bir koruma sağlar ama içerik bütünlüğünü kanıtlamaz; en güvenli sonuç için üçünü birlikte yapılandırın.

E-postalarım neden spam klasörüne düşüyor?#

En yaygın sebep eksik veya hatalı SPF ve DKIM kayıtlarıdır. Bu kayıtlar olmadan alıcı sunucular mailinizin kimliğini doğrulayamaz ve şüpheyle karşılar. cPanel'in Email Deliverability aracıyla kayıtları onarın, DMARC ekleyin ve sunucu IP'nizin kara listede olmadığından emin olun; bunlar düzeldiğinde teslim oranınız belirgin şekilde artar.

DMARC politikasını doğrudan p=reject yapabilir miyim?#

Hayır, bu riskli bir yaklaşımdır ve meşru maillerinizin engellenmesine yol açabilir. Önce birkaç hafta p=none ile başlayıp rua adresine gelen raporları inceleyin; unuttuğunuz mail kaynaklarını bu raporlardan görürsünüz. Hepsini SPF/DKIM'e ekledikten ve raporlar temizlendikten sonra önce quarantine, en son reject'e kademeli geçin.

SPF kaydının sonundaki -all ile ~all arasındaki fark nedir?#

-all (hardfail), listede olmayan bir sunucudan gelen mailin kesinlikle reddedilmesini söyler ve en güvenli seçenektir. ~all (softfail) ise böyle bir maili reddetmez, yalnızca şüpheli olarak işaretler. Kurulum aşamasında, tüm mail kaynaklarınızı henüz listelediğinizden emin değilken ~all ile başlayıp her şeyi doğruladıktan sonra -all'a geçmek en güvenli yöntemdir.

Kayıtları ekledikten sonra ne kadar sürede aktif olur?#

DNS değişiklikleri gibi bu kayıtlar da dünya genelindeki sunuculara yayılana (propagasyon) kadar birkaç saat, bazen 24-48 saate kadar sürebilir. Bu süre içinde bazı alıcılar yeni kaydı görürken bazıları eskisini görebilir. Değişiklikten hemen sonra sonuç beklemeyin; birkaç saat sonra dig veya MXToolbox ile kayıtların yayınlandığını doğrulayın.

Google Workspace veya Microsoft 365 kullanıyorum, yine de bu kayıtları kurmalı mıyım?#

Evet, kesinlikle. Bu servisler mail gönderme altyapısını sağlar ama SPF, DKIM ve DMARC kayıtlarını sizin alan adınızın DNS'ine eklemek yine sizin sorumluluğunuzdadır. Google Workspace için include:_spf.google.com içeren bir SPF, panelden aldığınız DKIM anahtarı ve bir DMARC kaydı eklemeniz gerekir; bunlar olmadan bu servislerle bile mailleriniz doğrulanamaz.

Kapanış#

SPF, DKIM ve DMARC üçlüsü, kurumsal e-postalarınızın hem güvenle teslim edilmesini hem de alan adınızın sahtecilikten korunmasını sağlayan modern e-postanın temel taşlarıdır. Kayıtları kurmak birkaç dakikalık bir işlem gibi görünse de doğru yapılandırma ve kademeli DMARC geçişi, uzun vadede spam sorunlarını kökten çözer. cPanel içeren bir web hosting paketi, Email Deliverability aracıyla SPF ve DKIM'i tek tıkla üretir; alan adınızı Clou.TR üzerinden yönetiyorsanız DMARC kaydını da aynı panelden ekleyebilirsiniz.

Henüz kurumsal bir e-posta altyapınız yoksa e-posta çözümlerimize göz atabilir, hesap oluşturma adımları için cPanel'de e-posta hesabı oluşturma rehberini takip edebilirsiniz. Teslim edilebilirlik sorunlarında ve kayıt kurulumunda ekibimiz yardımcı olmaktan memnuniyet duyar.