E-posta teslimatı: SPF, DKIM ve DMARC üçlüsünü doğru kurmak

Gmail ve Outlook, 2024'ten bu yana toplu gönderim yapan alan adlarında kimlik doğrulamayı zorunlu tutuyor. SPF, DKIM ve DMARC kurulu değilse iletiniz ya spam klasörüne düşer ya doğrudan reddedilir. Üçü birbirini tamamlar; birini kurup diğerlerini atlamak yarım çözümdür.

Üç kayıt, üç ayrı soru

• SPF — "Bu alan adı adına hangi sunucular posta gönderebilir?" Alıcı, bağlantıyı kuran IP adresini bu listeyle karşılaştırır.
• DKIM — "İleti yolda değiştirildi mi ve gerçekten bu alan adından mı çıktı?" Gönderen sunucu iletiyi özel anahtarla imzalar; alıcı, DNS'teki genel anahtarla doğrular.
• DMARC — "SPF ve DKIM başarısız olursa ne yapayım, sonucu kime bildireyim?" Politika ve raporlama katmanıdır.

SPF: tek satır, üç tuzak

SPF, alan adının kökünde bir TXT kaydıdır:

v=spf1 a mx include:_spf.turklokasyon.com ~all

Üç hata sık tekrarlanır:

1. Birden fazla SPF kaydı. Alan adı başına yalnız bir TXT SPF kaydı olabilir. İkincisini eklemek doğrulamayı tamamen geçersiz kılar; yeni sunucuları mevcut satıra include: ile ekleyin.
2. On DNS sorgusu sınırının aşılması. Her include, a ve mx ifadesi bir sorgu harcar; toplam onu geçerse kayıt "permerror" verir. Kullanmadığınız servislerin include satırlarını silin.
3. Yanlış son ek. ~all yumuşak başarısızlık, -all sert reddir. Geçiş dönemindeyken ~all ile başlayın; raporlar temiz çıktıktan sonra -all yapın.

DKIM: anahtarı üretin, yayınlayın, doğrulayın

cPanel'de Email Deliverability ekranı DKIM anahtarını üretir ve önerilen TXT kaydını gösterir. Alan adınızın DNS'i başka bir yerde yönetiliyorsa kaydı oraya elle eklemeniz gerekir. Seçici (selector) adı önemlidir: kayıt secici._domainkey.alanadiniz.com biçiminde yayınlanır.

Kurulumdan sonra kendinize değil, dışarıdaki bir adrese test iletisi gönderin. Gmail'de iletiyi açıp "Orijinali göster" dediğinizde başlıkta üç satırı da görmelisiniz:

spf=pass · dkim=pass · dmarc=pass

Anahtar uzunluğunu 2048 bit seçin. Bazı DNS sağlayıcıları 255 karakterden uzun TXT değerini kabul etmez; bu durumda kayıt tırnaklarla parçalara bölünerek girilir.

DMARC: gözlemle başlayın, sonra sıkıştırın

_dmarc.alanadiniz.com altında bir TXT kaydı oluşturun. İlk gün şu satırla başlayın:

v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

p=none hiçbir iletiyi engellemez, yalnız rapor toplar. Bir iki hafta raporları okuyun: alan adınız adına gönderim yapan ama sizin bilmediğiniz servisler çıkabilir — fatura sistemi, haber bülteni aracı, CRM. Hepsini SPF ve DKIM'e ekledikten sonra politikayı kademeli sıkıştırın: p=quarantine, ardından p=reject. Doğrudan p=reject ile başlamak, kendi faturalarınızın müşterilere ulaşmamasıyla sonuçlanabilir.

Üç kaydı da tek oturumda doğrulayın

Panelde "kaydedildi" yazısını görmek yeterli değildir; kayıtların DNS'te yayınlandığını dışarıdan sorgulayın:

• dig +short TXT alanadiniz.com — çıktıda v=spf1 ile başlayan tek satır olmalı. İki satır dönüyorsa doğrulama zaten bozuktur.
• dig +short TXT secici._domainkey.alanadiniz.com — v=DKIM1 ve p= ile başlayan uzun anahtar dönmeli. Boş dönüyorsa seçici adı yanlış yazılmıştır.
• dig +short TXT _dmarc.alanadiniz.com — tek bir v=DMARC1 satırı.

Değişiklikten sonra hâlâ eski değeri görüyorsanız TTL süresi dolmamıştır. Kayıtlarla uğraşmaya başlamadan önce TTL'i 300 saniyeye düşürün; hatalı bir satırı saatler yerine dakikalar içinde geri alırsınız. Her şey oturduktan sonra 3600'e çıkarmayı unutmayın.

Hizalama (alignment) neden önemli?

DMARC yalnız SPF veya DKIM'in geçmesini istemez; geçen kimliğin From: başlığındaki alan adıyla hizalı olmasını da ister. Üçüncü taraf bir bülten servisi kendi alan adıyla imzalıyorsa SPF geçer ama hizalama başarısız olur ve DMARC düşer. Çözüm, servisin kendi alt alan adınız üzerinden gönderim yapmasını sağlamak ve DKIM anahtarını sizin alan adınıza tanımlamaktır.

Gelen DMARC raporlarını okumak

Raporlar sıkıştırılmış XML dosyaları olarak gelir; her biri bir günlük gönderimi kaynak IP adresine göre gruplar. Dört alan işinizi görür:

• source_ip — gönderimi yapan sunucu. Tanımadığınız her adres araştırılır.
• count — o adresten kaç ileti geçtiği. Tek haneli sayılar genelde yönlendirmedir; binli sayılar gerçek bir gönderim kaynağını gösterir.
• policy_evaluated altındaki spf ve dkim — hizalama dahil edilerek hesaplanmış sonuç. Asıl bakılacak yer burasıdır.
• header_from — alıcının ekranda gördüğü alan adı.

İlk hafta neredeyse her kurumda aynı üç sürpriz çıkar: muhasebe yazılımının kendi SMTP sunucusu, e-ticaret altyapısının sipariş bildirimleri ve çalışanların kişisel araçlarla yaptığı gönderimler. Politikayı sıkıştırmadan önce bu üçünü kayıtlara eklemek, kesintiyi tamamen önler.

XML'i elle okumak zorunda değilsiniz; ücretsiz bir rapor toplayıcıya rua adresini vermek çıktıyı tabloya çevirir. Kendi kutunuza da bir kopya gidecek şekilde iki adres tanımlayın, servis kapanırsa görünürlüğü toptan kaybetmeyin.

Başlıktaki hata satırı ne anlama geliyor?

Kimlik doğrulama tek başına yetmez

Kayıtlar doğruyken de spam klasörüne düşülebilir. Geriye kalan üç etken:

• IP itibarı. Yeni bir gönderim IP'si "ısıtılmadan" günde binlerce ileti göndermek doğrudan bloklanma sebebidir. Hacmi birkaç hafta içinde kademeli artırın.
• Liste hijyeni. Geri dönen (bounce) adresleri listeden çıkarın. Yüksek geri dönüş oranı, alan adının itibarını doğrudan düşürür.
• İçerik ve abonelik. Toplu iletilerde List-Unsubscribe başlığı bulunsun; şikâyet oranını en çok bu düşürür.

Sonraki katman: aktarımın şifreli olduğunu garantiye almak

Üçlü, iletinin kimliğini doğrular; yolda şifreli gittiğini garanti etmez. Bunun için iki kayıt daha vardır. _mta-sts altında yayınlanan politika, gönderen sunuculara size yalnız geçerli sertifikayla ve TLS üzerinden bağlanmalarını şart koşar; _smtp._tls altındaki TLS-RPT kaydı ise başarısız bağlantıları günlük rapor olarak gönderir. Politikanın çalışması için posta sunucunuzun sertifikasının MX adıyla eşleşmesi gerekir — sertifika yazısındaki ad doğrulama kuralları burada da geçerlidir. Bu katman zorunlu değildir; kimlik doğrulama üçlüsü tam oturmadan başlamayın.

Toplu gönderen kuralları: büyük posta sağlayıcıları ne istiyor?

SPF, DKIM ve DMARC uzun süre "olsa iyi olur" listesindeydi. 2024'ün başından itibaren Gmail ve Yahoo, 2025'te de Microsoft'un tüketici e-posta hizmetleri, belirli bir hacmin üzerinde gönderen alan adları için bunları zorunlu tuttu. Kural metinleri ayrıntıda farklılaşsa da ortak çekirdek şudur:

• Her gönderen için: SPF ya da DKIM'den en az biri geçmeli; gönderen IP adresinin geçerli bir ters DNS (PTR) kaydı olmalı ve bu kayıt ileri yönde aynı IP'ye çözülmeli; bağlantı TLS ile kurulmalı; kullanıcıların spam olarak işaretleme oranı düşük tutulmalı.
• Günde binlerce ileti gönderenler için: SPF ve DKIM birlikte geçmeli; bir DMARC kaydı yayınlanmalı (en az p=none); From adresindeki alan adı SPF ya da DKIM alan adıyla hizalı olmalı; pazarlama iletilerinde tek tıkla abonelikten çıkma desteklenmeli.

Eşik Gmail için kişisel hesaplara günde yaklaşık 5.000 iletidir ve alan adı bir kez bu eşiği geçtiğinde kalıcı olarak toplu gönderen sayılır. Kampanya döneminde bir kez sınırı aşan küçük bir işletme de bu kapsama girer; bu yüzden kayıtları hacimden bağımsız olarak baştan kurmak en güvenli yoldur.

DMARC için p=none yeter mi?

Kuralların istediği asgari değer p=none, yani "yalnız raporla". Büyük sağlayıcıların kendi alan adlarına bakmak bu konuda öğreticidir; 17 Ekim 2026'da sorguladığımızda kayıtlar şöyleydi:

dig +short TXT _dmarc.gmail.com
"v=DMARC1; p=none; sp=quarantine; rua=mailto:[email protected]"
dig +short TXT _dmarc.yahoo.com
"v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; ..."

Gmail kendi ana alan adında p=none ile yetiniyor ama alt alan adları için (sp=) karantina istiyor; Yahoo doğrudan reddediyor. Ders şudur: p=none kuralı karşılar, ama alan adınızın taklit edilmesini durdurmaz. Raporlar meşru tüm göndericilerinizin hizalı geçtiğini gösterdikten sonra quarantine ve reject adımlarına ilerleyin.

Tek tıkla abonelikten çıkma

Pazarlama ve bülten iletilerinde gövdedeki bağlantı yetmez; ileti başlığında iki satır bulunmalıdır:

List-Unsubscribe: <https://ornek.com/abonelik/iptal?id=...>, <mailto:[email protected]>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Toplu gönderim servislerinin çoğu bu başlıkları kendisi ekler; kendi sunucunuzdan ya da kendi yazdığınız uygulamadan gönderiyorsanız eklemek size kalır. İşlem talebinin iki gün içinde yerine getirilmesi beklenir. Kayıtlarınızın üçünü de tek seferde denetlemek için SPF, DKIM ve DMARC kontrolü aracını kullanabilirsiniz.

Kontrol listesi

1. MX kayıtlarını doğrulayın; posta hangi sunucuya geliyor?
2. Tek bir SPF kaydı var, on sorgu sınırının altında.
3. DKIM anahtarı yayınlandı ve dış bir alıcıda dkim=pass görülüyor.
4. DMARC p=none ile açıldı, raporlar bir adrese geliyor.
5. İki hafta sonra raporlar temizse politika sıkıştırıldı.

Alan adınızın DNS kayıtlarını nasıl yöneteceğinizden emin değilseniz DNS kayıt türleri yazısına göz atın; alan adı ve DNS yönetimini tek panelden yapmak isterseniz alan adı hizmetimiz bu kayıtları arayüzden düzenlemenize izin verir.

Sık sorulan sorular