Yeni Domain'de SPF, DKIM, DMARC Sıfırdan Nasıl Kurulur?

Yeni aldığınız domain'e ilk e-postayı gönderdiğinizde mesajlarınız spam klasörüne düşüyorsa ya da alıcı sunucu tarafından reddediliyorsa, büyük ihtimalle SPF, DKIM ve DMARC kayıtlarınız eksik veya hatalıdır. Bu üç DNS kaydı, RFC 7208, RFC 6376 ve RFC 7489 ile standartlaştırılmış kimlik doğrulama katmanlarıdır; birbirini tamamlarlar ve hiçbiri tek başına yeterli değildir. Bu rehberde sıfırdan, adım adım doğru sırayla kurulum yapacaksınız.

Neden Bu Üç Kayıt Birlikte Gerekli?

SPF (Sender Policy Framework, RFC 7208), hangi IP adreslerinin sizin domain'iniz adına e-posta gönderebileceğini bildirir. DKIM (DomainKeys Identified Mail, RFC 6376), mesaj içeriğine kriptografik imza ekler; alıcı sunucu bu imzayı DNS'teki genel anahtarla doğrular. DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) ise SPF veya DKIM doğrulaması başarısız olan mesajlara ne yapılacağını —izle, karantinaya al ya da reddet— politika olarak bildirir ve size raporlama sağlar.

Google Postmaster Tools ve Microsoft'un SNDS (Smart Network Data Services) portalı, bu üç kaydın eksikliğini doğrudan gönderen itibar puanına yansıtır. Gmail, Outlook.com ve Yahoo, 2024 yılında yayımladıkları ortak yönergelerde günlük 5.000'den fazla mesaj gönderen domain'ler için DMARC zorunluluğunu açıkça duyurmuştur.

Adım 1 — SPF Kaydı Oluşturma

SPF, TXT türünde bir DNS kaydıdır ve her domain için yalnızca tek bir SPF kaydı olmalıdır (RFC 7208, Bölüm 3.1). Birden fazla v=spf1 kaydı olması, alıcı sunucuların her ikisini de geçersiz saymasına yol açar —bu en yaygın SPF hatasıdır.

Temel bir SPF kaydı şu yapıya sahiptir:

v=spf1 include:posta-saglayiciniz.com ~all

Buradaki ~all (softfail) kaydı, yetkisiz kaynaklardan gelen postayı reddetmez; yalnızca şüpheli olarak işaretler. Üretim ortamında, kaynakları netleştirdikten sonra -all (hardfail) kullanmanız önerilir. SPF doğrulama zinciri en fazla 10 DNS sorgusu içerebilir; bunu aşmak PermError sonucuna yol açar ve mesajınız reddedilir. SPF kaydınızı MXToolbox SPF Checker veya dmarcian SPF Surveyor gibi araçlarla denetleyin.

Connect365 altyapısı üzerinden gönderim yapıyorsanız, size özel include: mekanizmasını Hesap Ayarları → DNS Yardımcısı bölümünden kopyalayabilirsiniz.

Adım 2 — DKIM Anahtarı Yayınlama

DKIM kurulumu iki aşamalıdır: önce gönderen platformunuz bir anahtar çifti üretir ve özel anahtarı kendi bünyesinde saklar; siz de genel anahtarı DNS'e TXT kaydı olarak eklersiniz. Kaydın adı genellikle şu biçimdedir:

selector._domainkey.example.com

selector değeri platform tarafından belirlenir (örneğin connect365, s1, google). Değer şu yapıdadır:

v=DKIM1; k=rsa; p=MIIBIjANBgkq...

RFC 6376, minimum 1024-bit RSA anahtarı tanımlamış olsa da günümüzde 2048-bit tercih edilmektedir; 512-bit anahtarlar büyük e-posta sağlayıcıları tarafından artık kabul edilmemektedir. DKIM kaydınızın yayıldığını doğrulamak için Google Admin Toolbox — Check MX veya dig TXT selector._domainkey.example.com komutunu kullanabilirsiniz. DNS yayılımı 5 dakika ile 48 saat arasında sürebilir; TTL değerinizi başlangıçta düşük tutmak (örneğin 300 saniye) test sürecini hızlandırır.

Adım 3 — DMARC Politikası Tanımlama

DMARC kaydı _dmarc.example.com adresine eklenen bir TXT kaydıdır. Yeni domain için her zaman p=none (izleme modu) ile başlayın:

v=DMARC1; p=none; rua=mailto:dmarc-raporlar@example.com; ruf=mailto:dmarc-raporlar@example.com; fo=1;

rua parametresi toplu (aggregate) raporların gönderileceği adresi, ruf adli (forensic) raporların adresini belirtir. fo=1 etiketi, SPF veya DKIM kontrollerinden herhangi biri başarısız olduğunda adli rapor üretilmesini sağlar. RFC 7489, DMARC uyumluluğu için SPF veya DKIM'den en az birinin "hizalanmış" (aligned) geçmesini yeterli kabul eder; bu nedenle SPF ve DKIM'i sırasıyla kurmak kritik önem taşır.

İki ila dört hafta boyunca p=none modunda raporları izleyin. dmarcian, Postmark DMARC veya Google Postmaster Tools ile raporları görselleştirebilirsiniz. Raporlarda yalnızca meşru kaynaklarınızı görüyorsanız önce p=quarantine, ardından p=reject'e geçin.

Kayıt Kontrol Tablosu

Sık Yapılan Hatalar ve Çözümleri

Birden fazla SPF kaydı: DNS panelinizdeki tüm v=spf1 kayıtlarını tek bir satırda birleştirin. Örneğin iki ayrı include: ifadesi varsa bunları tek kayıtta yan yana yazın.

DKIM kaydında boşluk veya satır sonu: Bazı DNS yönetim panelleri uzun TXT değerlerini otomatik olarak tırnak içinde böler. Bu bölünme, imza doğrulamasını bozabilir. DNS panelindeki ham değeri dig çıktısıyla karşılaştırarak denetleyin.

DMARC'ta hizalama hatası: SPF geçse bile From: başlığındaki domain ile Return-Path domain'i eşleşmiyorsa DMARC hizalaması başarısız olur. Bu durumu adli raporlardan tespit edebilir, aspf=r (esnek hizalama) parametresiyle geçici olarak çözüme kavuşturabilirsiniz.

10 DNS sorgu sınırı aşımı: SPF kaydınız çok sayıda include: zinciri içeriyorsa SPF düzleştirme (flattening) araçları kullanın; ancak bu araçların IP aralıklarınızı güncel tuttuğundan emin olun.

Kayıtların Yayılma Sürecini Yönetmek

DNS değişikliklerinin yayılması TTL değerinize bağlıdır. Yeni domain'lerde TTL genellikle 3600 saniye (1 saat) ile 86400 saniye (24 saat) arasında ayarlıdır. Acil değişiklikler için önce TTL'yi 300 saniyeye düşürün, değişikliği yapın ve eski TTL süresi kadar bekleyin. Yayılma durumunu whatsmydns.net ile küresel ölçekte izleyebilirsiniz. IETF'in RFC 1034 ve RFC 1035'i, DNS kayıtlarının önbellek davranışını temel düzeyde tanımlar; alıcı sunucular bu sürelere uygun şekilde TTL'yi önbelleğe alır.

DMARC Politikasını Kademeli Sıkılaştırma

Yeni domain'de acele politika sıkılaştırması, meşru e-postaların reddedilmesine yol açabilir. Önerilen yol haritası şudur: İlk iki hafta p=none ile raporları toplayın. Sonraki iki haftada p=quarantine; pct=10 ile trafiğin yüzde onunu karantinaya alın, kademeli olarak yüzde yüze çıkın. Ardından p=reject'e geçin. pct parametresi RFC 7489 tarafından tanımlanmış olup politikanın uygulanacağı mesaj yüzdesini belirler; bu sayede kademeli geçişi kontrollü biçimde yönetebilirsiniz.

Sık Sorulan Sorular