E-postalarınız neden spama düşüyor? SPF, DKIM ve DMARC rehberi

“Teklifi gönderdik ama müşteri görmemiş, spam klasöründen çıktı.” Bu cümleyi işletmelerden neredeyse her hafta duyuyoruz. E-posta spam sorunu çoğu zaman yazılan metinden değil, alan adınızın DNS ayarlarından kaynaklanır. Alıcı tarafındaki sunucu, iletinin gerçekten sizden gelip gelmediğini anlamak için birkaç basit soru sorar; DNS’te bu soruların cevabı yoksa ya da yanlışsa iletinize güvenmez.

Son yıllarda büyük posta sağlayıcıları bu konuda çok daha katı hâle geldi. Google, Yahoo ve Microsoft; kimlik doğrulaması yapılmamış, kimlik bilgileri tutarsız ya da çok şikâyet alan gönderimleri açıkça hedef alan kurallar yayımladı. Küçük bir işletme “biz toplu e-posta atmıyoruz” diye düşünse bile, web sitesindeki iletişim formundan, muhasebe yazılımından ya da e-fatura servisinden giden iletiler de aynı alan adı adına gönderilir ve aynı kontrollerden geçer.

Bu yazıda SPF, DKIM ve DMARC’ın ne işe yaradığını sade bir dille anlatıyor, ornek.com.tr üzerinden kopyalayıp uyarlayabileceğiniz kayıt örnekleri veriyor, DMARC raporlarının nasıl okunacağını gösteriyor ve hangi hosting paneli ya da alan adı firmasıyla çalışırsanız çalışın uygulayabileceğiniz adımları sıralıyoruz. Kurallar zaman zaman güncellendiği için yazıdaki gereklilikleri Ekim 2026 itibarıyla resmî kaynaklardan doğrulayarak aktarıyoruz.

E-posta spam klasörüne neden düşer?

Bir e-postanın gelen kutusuna mı, spam klasörüne mi gideceğine alıcı sağlayıcı karar verir ve bu kararın tam formülü açıklanmaz. Ancak sağlayıcıların yayımladığı yönergeler, kararı etkileyen ana başlıkları net biçimde ortaya koyar. Bunları üç grupta toplayabiliriz:

• Kimlik: İleti, From satırında yazan alan adı adına gönderilmeye yetkili bir sunucudan mı çıktı? İmzalı mı? İmza ile görünen gönderen tutarlı mı? SPF, DKIM ve DMARC tam olarak bu soruları yanıtlar.
• İtibar: Bu alan adı ve IP adresinden gelen iletileri alıcılar ne sıklıkla “spam” olarak işaretliyor? Geçersiz adreslere ne kadar gönderim yapılıyor? Google, kullanıcıların bildirdiği spam oranını gönderici yönergelerinin merkezine koyar.
• Biçim ve teknik uygunluk: İleti standartlara (RFC 5322) uygun mu, bağlantı TLS ile şifreli mi, sunucunun ileri ve ters DNS (PTR) kayıtları geçerli mi?

İçerik de elbette önemlidir; yanıltıcı konu satırları ya da alıcının hiç istemediği tanıtımlar şikâyet oranını artırır. Fakat kimlik katmanı eksikse içerik ne kadar iyi olursa olsun ileti baştan şüpheli kabul edilir. Bu nedenle e-posta teslim sorunlarında ilk baktığımız yer her zaman DNS’tir.

SPF, DKIM ve DMARC nedir? Üç kaydın görev paylaşımı

Bu üç mekanizma birbirinin eksiğini kapatan parçalardır. Microsoft’un e-posta kimlik doğrulama belgesi de bunların “birlikte çalışan yapı taşları” olduğunu, herhangi birinin eksik kalmasının korumayı zayıflattığını vurgular.

SPF: Kimler benim adıma gönderebilir?

SPF (Sender Policy Framework), RFC 7208 ile tanımlanır. Alan adınıza eklediğiniz bir TXT kaydıyla, alan adınız adına e-posta göndermeye yetkili sunucuları ya da servisleri listelersiniz. Alıcı sunucu, iletinin geldiği IP adresini bu listeyle karşılaştırır.

Burada sık atlanan bir ayrıntı var: SPF, kullanıcının gördüğü From adresini değil, “zarf göndereni” denen ve genellikle Return-Path başlığında görünen adresi kontrol eder. Bu yüzden tek başına SPF, sahte bir From satırını engellemeye yetmez.

DKIM: İleti gerçekten bu alan adından mı, yolda değişti mi?

DKIM (DomainKeys Identified Mail), RFC 6376 ile tanımlanır. Gönderen sunucu iletinin belirli başlıklarını ve gövdesini özel bir anahtarla imzalar; alıcı sunucu, DNS’te yayımlanan açık anahtarla bu imzayı doğrular. İmza, iletinin DKIM-Signature başlığında yer alır; bu başlıktaki d= değeri imzalayan alan adını, s= değeri ise hangi anahtarın (seçicinin, İngilizcesiyle selector) kullanıldığını gösterir.

DKIM’in en önemli avantajı, iletiler başka bir sunucu üzerinden yönlendirildiğinde (forward) de genellikle bozulmadan kalmasıdır. SPF ise yönlendirme sırasında çoğu zaman bozulur.

DMARC: Kurallar ve raporlar

DMARC, SPF ve DKIM sonuçlarını kullanıcının gördüğü From alan adıyla ilişkilendirir. Buna hizalama (alignment) denir: SPF’in ya da DKIM’in geçtiği alan adı, From satırındaki alan adıyla eşleşmelidir. DMARC ayrıca alan adı sahibinin, doğrulamadan geçemeyen iletilere ne yapılmasını istediğini (politika) ve sonuç raporlarının nereye gönderileceğini belirtmesini sağlar.

Standart tarafında güncel bir gelişme var: 2015’te bilgilendirme amaçlı yayımlanan RFC 7489, Mayıs 2026’da yayımlanan ve standartlar yolunda olan RFC 9989 (DMARC), RFC 9990 (toplu raporlama) ve RFC 9991 (hata raporlama) ile yürürlükten kaldırıldı. Temel mantık aynı kaldı; değişen birkaç etiketi aşağıda ayrıca ele alıyoruz.

Gmail, Yahoo ve Outlook.com ne istiyor? (Ekim 2026 itibarıyla)

Büyük sağlayıcıların gereklilikleri, “neden şimdi” sorusunun cevabıdır. Aşağıda yalnızca resmî sayfalarda doğrulayabildiğimiz maddeleri aktarıyoruz.

Google (Gmail)

Gmail e-posta gönderici yönergelerine göre 1 Şubat 2024’ten itibaren kişisel Gmail hesaplarına gönderim yapan tüm göndericiler için şunlar beklenir: gönderen alan adında SPF veya DKIM kurulu olması, gönderen alan adı ya da IP için geçerli ileri ve ters DNS (PTR) kayıtları, iletimde TLS kullanılması, Postmaster Tools’ta görülen spam oranının %0,3’ün altında tutulması, iletilerin RFC 5322 biçimine uyması ve Gmail From adreslerinin taklit edilmemesi.

Günde yaklaşık 5.000 ya da daha fazla iletiyi kişisel Gmail hesaplarına gönderenler “toplu gönderici” sayılır ve ek olarak şunlar beklenir: SPF ve DKIM birlikte, DMARC kaydı (politika p=none olabilir), From alan adının SPF ya da DKIM alan adıyla hizalı olması ve pazarlama iletilerinde tek tıkla abonelikten çıkma ile gövdede görünür bir çıkış bağlantısı. Google’ın SSS sayfası birkaç önemli ayrıntı daha ekler: toplu gönderici statüsü bir kez kazanıldıktan sonra kalıcıdır; aynı ana alan adının alt alan adlarından giden iletiler 5.000 sayımına birlikte dahil edilir; kullanıcı kaynaklı spam oranının %0,1’in altında tutulması ve %0,3’e hiç ulaşmaması önerilir; Kasım 2025’ten itibaren de uyumsuz trafiğe yönelik yaptırımlar artırılmaktadır.

DKIM anahtar uzunluğu için Google en az 1024 bit ister, sağlayıcınız destekliyorsa 2048 bit önerir.

Yahoo

Yahoo gönderici en iyi uygulamaları benzer bir çerçeve çizer: tüm göndericiler için en az SPF veya DKIM, %0,3’ün altında spam oranı, geçerli ileri/ters DNS ve RFC 5321/5322 uyumu. Toplu göndericiler için SPF ve DKIM birlikte, en az p=none olan ve geçen bir DMARC politikası, From alan adının SPF ya da DKIM alan adıyla hizalanması (gevşek hizalama kabul edilir), tek tıkla abonelikten çıkma ve çıkış taleplerinin 2 gün içinde işlenmesi istenir. Yahoo, toplu gönderici için bir hacim eşiği belirtmeyeceğini SSS sayfasında açıkça yazar.

Microsoft (Outlook.com)

Microsoft’un destek sayfasına göre Outlook.com gibi Microsoft tüketici e-posta hizmetlerine, aynı From alan adıyla 5.000 ve üzeri ileti gönderen “yüksek hacimli göndericilerden” SPF’in geçmesi, DKIM’in geçmesi, _dmarc adında en az v=DMARC1; p=none içeren bir DMARC kaydı yayımlanması ve SPF ya da DKIM’den en az birinin From alan adıyla hizalanması beklenir. Bu koşulları sağlamayan iletiler 550 5.7.515 hata koduyla reddedilebilir. Ayrıntılar Microsoft’un 550 5.7.515 hata sayfasında yer alır.

Önce envanter: Alan adınız adına kimler e-posta gönderiyor?

Kayıtları yazmadan önce yapılması gereken en önemli iş, alan adınız adına e-posta gönderen tüm sistemleri listelemektir. DMARC’ı sıkılaştırdığınızda listede unuttuğunuz her servis, kendi iletilerini spama gönderir. Tipik bir KOBİ’de bu liste şöyle olabilir:

• Kurumsal posta kutuları (Google Workspace, Microsoft 365 ya da hosting firmasının posta sunucusu)
• Web sitesindeki iletişim ve teklif formlarının bildirimleri
• E-ticaret altyapısının sipariş, kargo ve şifre sıfırlama e-postaları
• Bülten ya da kampanya gönderim servisi
• CRM, destek masası ya da randevu yazılımının otomatik e-postaları
• Muhasebe, e-fatura veya ön muhasebe programlarının gönderdiği iletiler
• Yazıcı/tarayıcı gibi cihazların “taranan belge” e-postaları

Bu envanteri çıkarmanın en pratik yolu, ilgili ekiplere sormak ve son birkaç ayda gönderilmiş örnek iletilerin başlıklarına bakmaktır. Gmail’de bir iletiyi açıp üç nokta menüsünden “Orijinali göster” dediğinizde SPF, DKIM ve DMARC sonuçlarını ve imzalayan alan adını özet olarak görebilirsiniz. Outlook’ta ise ileti başlıklarındaki Authentication-Results satırı aynı bilgiyi verir. DMARC’ı p=none ile yayımladıktan sonra gelen raporlar, unuttuğunuz kaynakları da ortaya çıkaracaktır.

Adım adım SPF kaydı (ornek.com.tr örnekleriyle)

SPF kaydı, alan adınızın köküne (yani ornek.com.tr adına) eklenen bir TXT kaydıdır ve v=spf1 ile başlar. Yalnızca Google Workspace kullanan bir alan adı için Google’ın önerdiği kayıt şudur:

Ad (Host):  @   (ya da ornek.com.tr)
Tür:        TXT
Değer:      v=spf1 include:_spf.google.com ~all

Yalnızca Microsoft 365 kullanan bir alan adı için Microsoft’un belgesindeki kayıt ise şöyledir:

Ad (Host):  @
Tür:        TXT
Değer:      v=spf1 include:spf.protection.outlook.com -all

Birden fazla kaynak varsa yeni bir SPF kaydı eklemeyin; mevcut kaydı genişletin. Örneğin posta kutuları Google Workspace’te, web sitesi formları kendi sunucunuzdan (belgelerde örnek olarak kullanılan 203.0.113.10 adresini temsilen) ve bülten bir gönderim servisinden çıkıyorsa kayıt şuna benzer:

v=spf1 ip4:203.0.113.10 include:_spf.google.com include:spf.bulten-servisi.example ~all

Buradaki spf.bulten-servisi.example temsilîdir; gerçek değeri kullandığınız servisin dokümantasyonundan almanız gerekir.

SPF’te en sık yapılan hatalar

Bu kuralların dayanağı RFC 7208’dir: Bir alan adında birden fazla SPF kaydı bulunması “permerror” sonucunu doğurur (bölüm 4.5); include, a, mx, ptr, exists ve redirect gibi DNS sorgusu gerektiren terimlerin toplamı 10 ile sınırlıdır ve aşılırsa yine “permerror” oluşur (bölüm 4.6.4). Dikkat edilmesi gereken nokta, her include’un kendi içinde başka include’lar barındırabilmesidir; on include’dan az yazmanız, on sorgunun altında kaldığınız anlamına gelmez. ip4: ve ip6: değerleri ise sorgu saymaz.

~all mı, -all mı?

Bu konuda iki büyük sağlayıcının önerisi farklıdır. Google, Workspace için ~all (softfail) kullanmayı önerir. Microsoft ise DKIM ve DMARC de kurulu olacağı varsayımıyla -all (hardfail) önerir ve önemli bir not düşer: DMARC her ikisini de SPF hatası olarak sayar, ancak DKIM imzası olmayan iletilerde ~all hatası pratikte DMARC politikasının uygulanmasını zayıflatabilir. Bizim yaklaşımımız şudur: envanteri bitirene ve DMARC raporlarıyla tüm kaynakları doğrulayana kadar ~all ile başlayın; tüm meşru akışlar DKIM imzalı ve hizalı hâle geldiğinde -all’a geçmeyi değerlendirin.

Adım adım DKIM kaydı

DKIM’i siz “yazmazsınız”; gönderim yapan servis bir anahtar çifti üretir, size DNS’e eklemeniz gereken açık anahtarı ya da yönlendirme kaydını verir. Bu yüzden DKIM, her gönderim servisi için ayrı ayrı kurulur.

1. Servisin yönetim panelinde DKIM bölümünü bulunGoogle Workspace’te bu ekran Yönetici konsolunda Uygulamalar > Google Workspace > Gmail > “E-postanın kimliğini doğrula” yolundadır. Microsoft 365’te Defender portalındaki e-posta kimlik doğrulama ayarlarında DKIM sekmesindedir. Bülten ve CRM servislerinde genellikle “alan adı doğrulama” ya da “gönderen alan adı” bölümünde yer alır.
2. Anahtar uzunluğunu seçinDNS sağlayıcınız destekliyorsa 2048 bit seçin. Google, sağlayıcı desteklemiyorsa 1024 bit kullanılabileceğini ve sonradan yükseltilebileceğini belirtir.
3. Verilen kaydı DNS’e ekleyinGoogle’da varsayılan seçici google olduğu için kayıt adı google._domainkey olur ve değer v=DKIM1; k=rsa; p=… biçimindedir. Microsoft 365 ise TXT yerine iki CNAME kaydı ister.
4. Bekleyin ve imzalamayı başlatınGoogle, DNS’e eklenen anahtarın çalışmaya başlamasının 48 saate kadar sürebileceğini söyler. Ardından panelde “kimlik doğrulamayı başlat” benzeri düğmeyle imzalamayı açarsınız.
5. Bir test iletisiyle doğrulayınKendinize bir Gmail adresine ileti gönderip “Orijinali göster” ekranında DKIM sonucunun PASS olduğunu ve imzalayan alan adının ornek.com.tr olduğunu kontrol edin.

Örnek kayıtlar şöyle görünür (anahtar kısaltılmıştır):

; Google Workspace
google._domainkey.ornek.com.tr.   TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"

; Microsoft 365 (değerleri Defender portalından kopyalayın)
selector1._domainkey.ornek.com.tr.  CNAME  selector1-ornek-com-tr._domainkey.<kiracı>.<x>-v1.dkim.mail.microsoft
selector2._domainkey.ornek.com.tr.  CNAME  selector2-ornek-com-tr._domainkey.<kiracı>.<x>-v1.dkim.mail.microsoft

Microsoft, belgesindeki değerlerin yalnızca örnek olduğunu ve gerçek değerlerin Defender portalından ya da Exchange Online PowerShell’den alınması gerektiğini vurgular; eski onmicrosoft.com biçimindeki hedeflerle yeni biçim aynı seçicide bir arada kullanılamaz.

Adım adım DMARC kaydı ve politika geçişi

DMARC kaydı _dmarc ön ekiyle eklenen bir TXT kaydıdır. Google, SPF ve/veya DKIM’i kurduktan sonra DMARC’a geçmeden önce 48 saat beklemeyi önerir. Ayrıca raporlar için kişisel adres yerine ayrı bir posta kutusu ya da grup açılmasını tavsiye eder; çünkü rapor hacmi yüksek olabilir.

İlk kayıt, yalnızca izleme yapan bir politika olmalıdır:

Ad (Host):  _dmarc
Tür:        TXT
Değer:      v=DMARC1; p=none; rua=mailto:dmarc-rapor@ornek.com.tr

Raporlar birkaç hafta boyunca toplanıp tüm meşru kaynaklar hizalandıktan sonra politika kademeli olarak sıkılaştırılır:

; Ara aşama: doğrulanamayan iletiler spam/karantinaya
v=DMARC1; p=quarantine; rua=mailto:dmarc-rapor@ornek.com.tr

; Hedef: doğrulanamayan iletiler reddedilsin
v=DMARC1; p=reject; rua=mailto:dmarc-rapor@ornek.com.tr

Etiketler ne anlama gelir?

Gevşek hizalamada (r) imzalayan ya da SPF’i geçen alan adının, From alan adıyla aynı “kurumsal alan adı”na ait olması yeterlidir; yani bulten.ornek.com.tr ile imzalanan bir ileti, From’u ornek.com.tr olan bir iletide hizalı sayılır. Sıkı hizalamada (s) alan adlarının birebir aynı olması gerekir. Çoğu KOBİ için gevşek hizalama hem yeterli hem de daha az sorunludur.

Rapor adresi başka bir alan adındaysa

Raporları bir DMARC analiz servisine ya da farklı bir alan adındaki kutuya gönderecekseniz, alıcı sunucular bu yetkilendirmeyi kontrol eder. RFC 7489 ve RFC 9990’da tanımlanan doğrulamaya göre rapor adresinin bulunduğu alan adı, ornek.com.tr._report._dmarc.rapor-alan-adi.example biçiminde, v=DMARC1 içeren bir TXT kaydı yayımlamalıdır. Bu kayıt yoksa raporlar gönderilmez. DMARC servisleri bu kaydı genellikle kendileri yönetir; siz yalnızca servisin verdiği rua adresini kullanırsınız.

DMARC raporları nasıl okunur?

DMARC’ın asıl gücü raporlardadır. Toplu (aggregate) raporlar, alıcı sağlayıcıların (Google, Yahoo, Microsoft ve DMARC raporu gönderen diğerleri) sizin alan adınız adına gördükleri trafiği özetleyen XML dosyalarıdır. Standarda göre varsayılan raporlama aralığı 86.400 saniye, yani bir gündür; dosyalar genellikle sıkıştırılmış (.xml.gz ya da .zip) ek olarak gelir. Google, Gmail’in tekil hata raporlarını (ruf) desteklemediğini belirtir; pratikte izleyeceğiniz ana veri toplu raporlardır.

Sadeleştirilmiş bir rapor parçası şöyle görünür:

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <date_range><begin>1761696000</begin><end>1761782399</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>ornek.com.tr</domain><p>none</p><adkim>r</adkim><aspf>r</aspf>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.10</source_ip>
      <count>42</count>
      <policy_evaluated>
        <disposition>none</disposition><dkim>fail</dkim><spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers><header_from>ornek.com.tr</header_from></identifiers>
    <auth_results>
      <spf><domain>ornek.com.tr</domain><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>

Bu raporu şöyle okuyoruz:

• org_name ve date_range: Raporu kim, hangi zaman aralığı için gönderdi? Tarihler Unix zaman damgasıdır; herhangi bir dönüştürücüyle okunabilir tarihe çevrilir.
• policy_published: Alıcının o sırada gördüğü DMARC kaydınız. Yeni bir politika yayımladıysanız raporlarda ne zaman göründüğünü buradan izlersiniz.
• source_ip ve count: Hangi IP’den kaç ileti geldi? Bu IP’nin kime ait olduğunu (kendi sunucunuz mu, Google mı, bir bülten servisi mi, tanımadığınız biri mi) belirlemek analizin özüdür.
• policy_evaluated: DMARC açısından hizalı SPF ve DKIM sonucu. Örnekteki satırda SPF geçmiş, DKIM başarısız; yani bu sunucudan giden iletiler DKIM ile imzalanmıyor. Bu, kendi web sunucunuzdan giden form e-postaları için tipik bir durumdur.
• auth_results: Hizalamadan bağımsız ham sonuçlar ve hangi alan adıyla geçtikleri.

Raporları elle okumak birkaç günlük veriyle mümkündür ama hacim arttıkça bir DMARC rapor analiz aracı kullanmak işi çok kolaylaştırır. Hangi aracı seçerseniz seçin, raporlardan çıkarmanız gereken üç liste aynıdır:

1. Tanıdık ve hizalı kaynaklarSPF ya da DKIM’i hizalı geçen, sizin bildiğiniz servisler. Burada yapılacak bir şey yok.
2. Tanıdık ama hizalı olmayan kaynaklarKendi sunucunuz, bir CRM ya da fatura servisi gibi meşru ama DMARC’tan geçemeyen akışlar. Bunları SPF’e ekleyin ve mümkünse alan adınızla DKIM imzalatın. Politikayı sıkılaştırmadan önce bu listenin boşalması gerekir.
3. Tanımadığınız kaynaklarAlan adınızı taklit eden ya da unutulmuş eski sistemler. Önce gerçekten size ait olmadıklarından emin olun; sonra DMARC politikası onların iletilerini engelleyecektir.

Panelden bağımsız kurulum: DNS nerede, kayıt nasıl eklenir?

Türkiye’de en sık karşılaştığımız kafa karışıklığı, DNS kayıtlarının nerede yönetildiğidir. Alan adını bir firmadan almış, hostingi başka bir firmadan kiralamış, e-postayı da Google ya da Microsoft’ta kullanıyor olabilirsiniz. Kayıtlar, alan adının ad sunucularının (NS) işaret ettiği yerde yönetilir. Plesk, cPanel, DirectAdmin ya da alan adı firmasının kendi paneli fark etmez; mantık aynıdır.

1. Ad sunucularını öğreninTerminalde dig +short NS ornek.com.tr (Windows’ta nslookup -type=NS ornek.com.tr) komutu, DNS’in hangi firmada olduğunu gösterir. Çıkan adlar hosting firmanızınsa kayıtları hosting panelinin DNS bölümünde; alan adı firmanızınsa o firmanın panelinde düzenlersiniz.
2. Mevcut kayıtları yedekleyinÖzellikle MX ve TXT kayıtlarının ekran görüntüsünü alın. Bir hata durumunda geri dönmek dakikalar sürer.
3. Kayıt adını panelin beklediği biçimde yazınBazı paneller kök alan adı için @, bazıları boş alan, bazıları tam adı (ornek.com.tr.) ister. _dmarc kaydı için kimi panel yalnızca _dmarc, kimi _dmarc.ornek.com.tr bekler. Panel alan adını otomatik ekliyorsa tam adı yazmak _dmarc.ornek.com.tr.ornek.com.tr gibi hatalı kayıtlar oluşturur.
4. Hosting panelinin otomatik kayıtlarına dikkat edinPlesk ve cPanel gibi paneller, alan adı eklendiğinde kendi posta sunucuları için otomatik SPF ve DKIM kayıtları oluşturabilir. E-postanız Google ya da Microsoft’taysa bu otomatik SPF kaydını silmeden yenisini eklemek “iki SPF kaydı” hatasına yol açar; mevcut kaydı düzenleyin.
5. DoğrulayınKayıt yayına girdikten sonra şu komutlarla kontrol edin ve ardından gerçek bir test iletisi gönderin.

dig +short TXT ornek.com.tr
dig +short TXT _dmarc.ornek.com.tr
dig +short TXT google._domainkey.ornek.com.tr
dig +short MX ornek.com.tr

:: Windows
nslookup -type=TXT _dmarc.ornek.com.tr

Google, SPF ve DKIM’in çalışmaya başlamasının 48 saate kadar sürebileceğini belirtir. Microsoft ise SPF kayıtları için en az 3600 saniyelik TTL önerir. Değişiklikten hemen sonra sonuç göremezseniz önce TTL’in dolmasını bekleyin.

Kayıtlar tamam, hâlâ spam: İtibar ve izleme

SPF, DKIM ve DMARC doğruysa ama iletiler hâlâ spama gidiyorsa sorun büyük olasılıkla itibar, liste kalitesi ya da içeriktedir. Bu noktada şu araçlar ve kontroller işe yarar:

• Google Postmaster Tools: postmaster.google.com üzerinden alan adınızı TXT ya da CNAME kaydıyla doğruladıktan sonra Gmail’e giden trafiğinizin spam oranını ve gönderici yönergelerine uyumunu gösteren “Uyumluluk durumu” panelini görebilirsiniz. Google, günlük hacim çok düşükse gizlilik nedeniyle bazı verilerin gösterilmeyebileceğini, eski arayüzdeki alan adı ve IP itibar panellerinin ise yeni sürümde kaldırılıp yenisiyle değiştirileceğini belirtir.
• Microsoft SNDS ve JMRP: Kendi IP adresinden gönderim yapan kurumlar, Outlook.com tarafındaki IP verilerini Smart Network Data Services üzerinden, kullanıcı şikâyetlerini ise Junk Email Reporting Program ile izleyebilir. Ortak IP’li hosting ya da bulut posta kullanan çoğu KOBİ için bu araçlar doğrudan gerekmez.
• Yahoo Complaint Feedback Loop: Yahoo, toplu göndericilerin Sender Hub üzerinden şikâyet geri bildirim döngüsüne kaydolmasını ister; gönderim servisleri bunu çoğu zaman sizin adınıza yapar.
• Liste kalitesi: Onay almadığınız kişilere gönderim, satın alınmış listeler ve yıllardır etkileşim olmayan adresler, spam oranını hızla yükseltir. Bu konuyu toplu e-postada gelen kutusuna düşmenin 15 kuralı yazımızda ayrıntılı ele alıyoruz.

Taklit edilmeye karşı da koruma

DMARC yalnızca kendi iletilerinizin teslimini değil, alan adınızın dolandırıcılar tarafından kullanılmasını da ilgilendirir. Müşterilerinize “fatura”, “ödeme bildirimi” gibi sahte iletiler gönderilmesi, hem itibarınızı hem de alan adınızın genel güvenilirliğini zedeler. p=reject politikası, DMARC destekleyen alıcıların bu sahte iletileri reddetmesini sağlar. Kullanmadığınız ama sahip olduğunuz alan adlarında da (örneğin .com sürümü) Microsoft’un önerdiği v=spf1 -all SPF kaydını yayımlamak, buna bir de p=reject içeren DMARC kaydı eklemek iyi bir alışkanlıktır.

Sık karşılaştığımız senaryolar

Aşağıdaki örnekler, kurgusal ama sahada çok sık karşılaştığımız durumları özetler.

Örneğin üç şubeli bir diş kliniği düşünelim: Randevu hatırlatmaları bir randevu yazılımından, faturalar e-fatura servisinden, kampanyalar bir bülten aracından, personel yazışmaları ise Google Workspace’ten çıkıyor. Kliniğin SPF kaydında yalnızca Google var; randevu yazılımı kendi alan adıyla imzalıyor. Sonuç: randevu hatırlatmalarının bir kısmı spama düşüyor ve hasta randevuyu kaçırıyor. Çözüm, dört kaynağın da envantere alınması, her birinin SPF’e ya da DKIM ile alan adına bağlanması ve ancak ondan sonra DMARC politikasının sıkılaştırılmasıdır.

Avri olarak nasıl çalışıyoruz?

E-posta teslim sorunlarında önce ölçüyoruz: alan adının mevcut DNS kayıtlarını, örnek iletilerin başlıklarını ve varsa DMARC raporlarını inceliyor, gönderim yapan tüm sistemlerin envanterini çıkarıyoruz. Ardından SPF’i sadeleştiriyor, her servis için alan adına bağlı DKIM imzasını kuruyor ve DMARC’ı izleme modunda yayımlıyoruz. Raporlar birkaç hafta boyunca temiz kaldığında politika geçişini birlikte planlıyoruz. Web sitesi, form ve CRM tarafında e-posta gönderen yazılımları geliştirdiğimiz projelerde bu ayarları teslimin parçası olarak yapıyor, kurumsal imzaları da e-posta imza oluşturucu aracımızla tutarlı hâle getiriyoruz. Altyapı seçimi henüz netleşmediyse kurumsal e-posta altyapısı karşılaştırmamız iyi bir başlangıç olur.

Sık sorulan sorular

E-postalarınızın spama düşmesi çoğu zaman şanssızlık değil, eksik bir kimlik kanıtıdır. Gönderim yapan tüm sistemleri listeleyin, tek ve sade bir SPF kaydı yazın, her servisi kendi alan adınızla DKIM imzalatın, DMARC’ı izleme modunda başlatıp raporlarla ilerleyin. Bu temel bir kez doğru kurulduğunda, içerik ve liste kalitesi üzerine yaptığınız her iyileştirme gerçekten karşılık bulur.

Kaynaklar

• Google: Email sender guidelines (Gmail gönderici yönergeleri)
• Google: Email sender guidelines FAQ
• Yahoo: Sender Best Practices
• Microsoft: Fix NDR error 550 5.7.515 in Outlook.com
• Microsoft Learn: Set up SPF for your Microsoft 365 domain
• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)