DKIM, SPF, DMARC: E-posta Deliverability Net Rehberi

E-posta deliverability (alıcı posta kutusuna düşebilme oranı) çoğu zaman içerikten değil, alan adınızın e-posta doğrulamasından etkilenir. DKIM, SPF ve DMARC bu doğrulamanın temel taşlarıdır. Bu rehberde, bu üç kaydın ne işe yaradığını, hangi sırayla ilerlemeniz gerektiğini ve en sık yapılan hataları “ölçülebilir” şekilde ele alacaksınız. Ayrıca paylaşımlı hosting, VDS veya posta sunucusu fark etmeksizin doğru kurulum yaklaşımını netleştireceğiz.

DKIM, SPF, DMARC neyi çözer? (Deliverability haritası)

SPF (Sender Policy Framework)

SPF, alan adınız adına gönderilen e-postanın yetkili IP veya sistemlerden geldiğini doğrular. Alıcı sunucusu DNS’teki SPF kaydını kontrol eder; e-postanın “envelope from” (MAIL FROM) kısmının doğruluğuna bakar.

Tek cümlelik hedef: “Bu gönderimi yapmak için bu IP/servis yetkili mi?”

DKIM (DomainKeys Identified Mail)

DKIM, e-postanın gövdesi ve seçili başlıkları üzerinde kriptografik imza (public-private key) doğrular. Alıcı sunucusu, DNS’ten yayınlanan DKIM public key ile imzayı kontrol eder.

Tek cümlelik hedef: “Bu e-posta yolda değiştirildi mi, gerçekten alan adı mı imzaladı?”

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC; SPF ve DKIM sonuçlarını bir araya getirir ve sonuçların başarısız olması halinde alıcının ne yapacağını (quarantine/reject) tanımlar. Ayrıca raporlamayla hataları görünür hale getirir.

Tek cümlelik hedef: “SPF/DKIM başarısız olursa, alıcı nasıl aksiyon alacak ve ben ne göreceğim?”

Pratikte alıcılar DKIM ve SPF’yi kontrol eder; DMARC ise bu kontrollerin nasıl bağlanacağını ve hangi politikanın uygulanacağını belirler.

Doğru kurulum sırası: SPF → DKIM → DMARC

E-posta doğrulamasında en sık sorun, üç kaydı “aynı anda uydurmak” ve ölçmeden politikalara geçmektir. Net ve güvenli yol şudur:

SPF’i doğru kurun: Tüm gönderen kaynaklarını (kurum içi sunucu, pazarlama aracı, e-posta altyapısı) kapsayacak şekilde listeleyin.
DKIM’i etkinleştirin: Seçtiğiniz imza alanını (selector) belirleyip yayınlanan DNS kaydını doğru ekleyin.
DMARC’ı raporlama modundan başlatın: Önce p=none ile rapor toplayın, ardından kademeli olarak quarantine ve en son reject uygulayın.

Hedef kayıt ayarları (başlangıç seviyesi)

DMARC için başlangıç önerileri net olsun: - v=DMARC1 - p=none (ilk aşama) - rua= (aggregate rapor alma adresi) - sp= (alt alanlar için ayrı politika gerekiyorsa) - adkim= ve aspf= (varsayılan “relaxed” genelde başlangıçta uyumludur)

SPF ve DKIM’de “kapsam” farkı

SPF, yetkiyi kaynak IP üzerinden doğrular.
DKIM, bütünlük ve alan doğrulamasını imza üzerinden doğrular.
DMARC ise hem SPF/DKIM sonuçlarını policy + alignment mantığıyla bağlar.

Kayıt örnekleri: DNS’te birebir ne yazılır?

Not: Aşağıdaki örnekler öğreticidir. Kullandığınız servis sağlayıcı (Microsoft 365, Google Workspace, Postfix/Exim, özel mail gateway, pazarlama aracı) hangi alan/selector kullanıyorsa ona göre değerler değişir.

SPF kaydı örneği

Ana etki: SPF kaydınız tek bir TXT kaydı olmalı; birden fazla SPF TXT kaydı eklemek alıcılar tarafından hatalı değerlendirilebilir.

Örnek (yalnızca format gösterimi):

Alan adı: example.com
TXT: v=spf1 include:_spf.google.com ip4:203.0.113.10 -all

Kritik nokta: - Pazarlama aracı kullanıyorsanız kendi gönderim IP aralıklarını değil, sağlayıcının verdiği include değerini kullanın. - Sunucunuzdan doğrudan gönderiyorsanız ip4/ip6 değerlerini net ekleyin.

DKIM kaydı örneği

DKIM’de “selector” kullanılır. Örn: mail selector ise DNS kaydı mail._domainkey.example.com şeklinde olur.

TXT adı: mail._domainkey.example.com
TXT içeriği: v=DKIM1; k=rsa; p=PUBLIC_KEY_BURAYA

Kritik nokta: - DKIM anahtarını mail sisteminiz oluşturur. DNS’e koyacağınız p= değeri “aynı” olmalıdır. - Yanlış selector veya yanlış key, DKIM başarısızlığını doğrudan tetikler.

DMARC kaydı örneği

Örnek (başlangıç):

Alan adı: _dmarc.example.com
TXT: v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100

Kritik nokta: - rua adresi gerçek bir mail kutusu olmalı. - Raporda “SPF/DKIM alignment” durumlarını izleyin; yanlış hizalama (alignment) deliverability’i etkiler.

Test etme: Kurduktan sonra deliverability’i nasıl doğrularsınız?

DMARC ve DKIM için tek doğrulama “kayıt ekledim” değildir. Net test yaklaşımı şöyledir:

1) SPF/DKIM doğrulama sonuçlarını kontrol edin

Aldığınız test e-postasının başlığında (mail headers) Authentication-Results satırlarını inceleyin.
SPF için “pass/fail” ve hangi mechanism ile geçtiği/kalarmadığı görünebilir.
DKIM için d= (domain), s= (selector) ve “pass”/“fail” durumunu kontrol edin.

2) DMARC raporlarını okuyun

DMARC raporları, gönderiminiz ile hangi kaynakların hizalamada başarısız olduğunu gösterebilir.

Aggregate rapor (RUA) genellikle günlük/periodik özet verir.
Raporlarda en sık görülen alanlar:
Başarısız SPF veya DKIM oranı
Fail olan “source IP” veya gönderim servisleri
Hangi alt alan veya hangi envelope domain hizalanmıyor

3) Kademeli politika geçişi

Net politika geçişi (örnek): - İlk 7-14 gün: p=none - Sonra: gözlemler stabil ise p=quarantine - En son: net ölçümden sonra p=reject

Amaç, bir gecede tüm e-posta trafiğini “bloke” etmemektir. Kademeli geçiş, deliverability kaybını yönetilebilir hale getirir.

Yaygın hatalar: Deliverability’i en çok düşüren 10 sebep

Aşağıdaki sorunlar genellikle doğru kaydı “doğru biçimde” ama “yanlış kapsamla” eklemekten çıkar.

Birden fazla SPF TXT kaydı yayınlamak.
SPF içinde gereksiz a/mx mekanizmaları kullanıp beklenmeyen davranış üretmek.
SPF’te gönderici IP yerine sadece alan adı referanslarıyla ilerlemek.
DKIM’de yanlış selector kullanmak.
DKIM public key değerini DNS’e koyarken karakter/boşluk hatası yapmak.
DKIM imzası var sanıp DMARC’ta adkim=s (strict) ile uyumluluğu sıkılaştırmak.
DMARC’ta rua adresini yanlış (ulaşılamayan) yapmak; rapor alamayınca sorun körleşir.
Alt alanlar (ör. mail.example.com) için DMARC kapsamı ihmal etmek (sp= ayarı).
Üçüncü parti e-posta servisinin gönderim alanını ve envelope from davranışını bilmeden tek alan üzerinden politika kurmak.
“SPF ve DKIM var” diye p=rejecte hızlı geçmek.

SPF/DKIM/DMARC’ı altyapınıza göre nasıl konumlandırırsınız?

Paylaşımlı hosting kullanıyorsanız

Paylaşımlı hostingde posta gönderimi çoğu zaman sağlayıcının MTA’sı üzerinden olur. Bu durumda: - SPF kaydında “kendi sunucunuzun IP’si” yerine sağlayıcının verdiği yetkilendirmeleri kullanmanız gerekir. - DKIM genellikle kontrol paneli üzerinden etkinleştirilebilir (ör. cPanel/benzeri sistemlerde “DKIM” seçeneği). - DMARC kaydını kendi alan adınız için kurarsınız; gönderim servisiniz sağlayıcı ise yine raporlardan uyumluluğu görürsünüz.

VDS/VPS veya dedicated kullanıyorsanız

Kendi MTA’nızı (Postfix/Exim) çalıştırıyorsanız: - SPF’te gerçek çıkış IP’lerini ekleyin. - DKIM’i MTA üzerinde doğru şekilde imzalayacak şekilde ayarlayın. - DMARC’ta alignment konusunu net izleyin: envelope from (SPF) ile header From (DKIM) arasındaki ilişki deliverability etkiler.

Net kontrol listesi: DKIM, SPF, DMARC hazır mı?

Aşağıdaki listeyi “evet/hayır” şeklinde tamamlayın:

SPF kontrolü

[ ] Tek bir SPF TXT kaydı var.
[ ] Tüm gönderim kaynakları (kurum içi, dış servis, pazarlama aracı) doğru include/IP ile kapsandı.
[ ] -all veya ~all gibi politika sonu net bir şekilde tanımlandı.

DKIM kontrolü

[ ] DKIM selector adı mail sisteminizle DNS’te aynı.
[ ] DNS’teki DKIM public key değeri eksiksiz.
[ ] Test e-postada DKIM “pass”.

DMARC kontrolü

[ ] _dmarc kaydı doğru değerlerle yayımlandı.
[ ] İlk aşamada p=none ile rapor toplanıyor.
[ ] Raporlarda alignment sorunları net biçimde görülüyor (ve aksiyon planı var).

Ne zaman “reject”e geçmelisiniz? (Net karar kuralı)

p=reject kalıcı teslimat iyileştirmesi sağlayabilir; ancak yanlış yapılandırma, bazı servislerin e-postalarını tamamen kesebilir. Bu yüzden şu karar kuralını uygulayın:

“Reject” için uygun olma koşulları

[ ] Son 14 günde raporlar; SPF/DKIM fail oranlarında belirgin düşüş gösteriyor.
[ ] Fail olan kaynaklar ya tespit edildi ve düzeltildi ya da yanlış trafik olduğu kanıtlandı.
[ ] Kritik iş akışlarını (şifre sıfırlama, sipariş bildirimi, fatura e-postası) etkileyen sistemler doğrulandı.

Uygulanmaması gereken durumlar

[ ] Raporlar hiç gelmiyor (DMARC rua sorunu veya ölçüm altyapısı yok).
[ ] Birden fazla üçüncü parti servis aynı anda devrede ve envelope/header davranışları belirsiz.

Kurulumdan sonra deliverability’i sürekli artırma yöntemleri

Raporları düzenli kontrol edin: Haftalık DMARC raporu, yeni bir servis eklendiğinde oluşacak uyumsuzlukları erken yakalar.
Yeni gönderim araçlarını kayıtlarla eşleştirin: Örneğin CRM, e-fatura, kampanya aracı devreye girdiğinde SPF/DKIM kapsamı güncellenmelidir.
Gönderim başlıklarınızı standardize edin: Özellikle From alanı, DKIM ile imzalanan alanla uyumlu olmalı.
Yedek kontrol: Hosting/posta altyapısı değişince (panel, MTA sürümü, IP değişimi) SPF/DKIM yeniden doğrulanmalıdır.

Sonuç: Bugün yapmanız gereken net aksiyonlar

DKIM, SPF ve DMARC’ı tek tek kurmak yetmez; deliverability performansı ancak doğru kapsam, doğru alignment ve kademeli DMARC politikası ile kalıcı hale gelir. Bugün atacağınız net adımlar: önce SPF’te tek kaydı ve yetkileri doğrulayın, DKIM’i selector ve public key ile test edin, ardından DMARC’ı p=none ile 7-14 gün raporlayarak başlayın. Raporlar stabil hale geldiğinde quarantine ve en son reject geçişini uygulayın. Bu yaklaşım, hem spam klasörüne düşmeyi azaltır hem de kurulum kaynaklı kesintileri önler.