Bir teklif gönderdiniz, cevap gelmedi. İki gün sonra müşteriyi aradınız, "Maili görmedim, bir bakayım" dedi ve birkaç dakika sonra "Aa, spam klasörüymüş" diye ekledi. Bir kez olursa tesadüf diyebilirsiniz. Ama bu sizin başınıza sürekli geliyorsa, yani kurumsal mailleriniz spama düşüyorsa, sorun büyük ihtimalle sizin yazdığınız içerikte değil, alan adınızın arka planındaki üç küçük ayarda: SPF, DKIM ve DMARC. Bu yazıda bu üç kısaltmayı hiç teknik bilmeyen bir işletme sahibine anlatır gibi açıklayacağım, neyin bozuk olabileceğini nasıl anlayacağınızı göstereceğim ve işi ne zaman bir uzmana bırakmanız gerektiğini söyleyeceğim.
Ben Ümit Kırkoç, İstanbul'da tek başıma çalışan bir web tasarımcı ve SEO/GEO danışmanıyım. Mail ayarları asıl uzmanlık alanım değil, ama bir web sitesi kurduğumda alan adı, hosting ve mail konusu mutlaka karşıma çıkıyor; çünkü sitenizin formundan gelen mesajlar ve sizin müşteriye gönderdiğiniz mailler aynı düzenin parçası. Eğer sıfırdan bir site düşünüyorsanız, web sitesi yaptırma sürecinde bu mail altyapısını da baştan doğru kurmaya özen gösteriyorum. Çünkü sonradan düzeltmek mümkün ama aylarca kaybedilen mailler geri gelmiyor.
Neden kurumsal mailler spama düşer?
Önce şunu söyleyeyim: posta kutusu sağlayıcıları (Gmail, Outlook, Yahoo gibi) her gün sayısız sahte mail görür. Dolandırıcılar, bir bankanın ya da bir firmanın adını taklit ederek mail atar. Sağlayıcılar bu yüzden kendilerine gelen her maile bir soru sorar: "Bu mektup gerçekten kendisini söylediği yerden mi geliyor?" Sorunun cevabını bulamazsa mail ya spama atılır ya da hiç teslim edilmez.
Bunu bir apartmandaki kapıcıya benzetebilirim. Kapıya bir zarf getirildi, üstünde "Ornek Firma A.Ş." yazıyor. Kapıcı bu firmayı tanıyorsa ve zarfın gerçekten o firmadan geldiğine dair bir işaret görüyorsa zarfı içeri alır. İşaret yoksa, ya da işaret şüpheliyse, zarfı "belki de sahtedir" kutusuna koyar. SPF, DKIM ve DMARC, sizin zarfa koyduğunuz işaretlerdir. Bu işaretler yoksa ya da yanlışsa, içeriği ne kadar masum olursa olsun mektubunuz o kutuya gidebilir.
Aşağıdaki görsel, doğrulanmış bir mail ile doğrulanmamış bir mailin alıcı tarafında nasıl farklı karşılandığını özetliyor.
Görselde de görüldüğü gibi, aynı cümleleri içeren iki mailin kaderi, arkalarındaki kimlik işaretlerine göre değişebiliyor. Yani mesele sizin yazdığınız satırlar değil, mailin "kimlik kartı".
Spam kelimeleri tek sebep değil
İnsanların aklına ilk gelen şey genellikle "Belki de çok fazla ünlem kullandım" ya da "Belki 'ücretsiz' kelimesini yazdım" olur. İçerik gerçekten etkili olabilir; sürekli büyük harfle yazılmış, tek satırlık bir görsel yollayan, bağlantı dolu bir mail şüphe çeker. Ama sade bir teklif maili yazan, düzgün Türkçe kullanan bir işletmenin mailleri hâlâ spama düşüyorsa, içerikten çok altyapıya bakmak gerekir. Çünkü içeriği düzeltmek kolaydır ve çoğu kişi bunu zaten yapmıştır; kimlik ayarları ise çoğu zaman hiç kimsenin dokunmadığı bir köşede, yanlış ya da eksik halde bekler.
SPF, DKIM ve DMARC ne demek? Üç soru, üç cevap
Üç kısaltmanın her biri ayrı bir soruya cevap veriyor. Hepsi alan adınızın (örneğin ornek-firma.com) DNS ayarlarında, yani alan adının "telefon rehberi" bölümünde duran küçük metin kayıtlarıdır. Bu kayıtları siz yazmazsanız, alıcı sağlayıcı sizin hakkınızda hiçbir şey bilmez.
SPF (gönderici izin listesi). Sorusu şu: "Bu alan adı adına mail atmaya hangi sunucular yetkili?" Siz alan adınız için bir liste yayımlarsınız: "Mailimi şu servisler gönderebilir." Alıcı sağlayıcı gelen mailin hangi sunucudan çıktığına bakar, listeye bakar; eşleşirse tamam, eşleşmezse şüphelenir. Bir telefon rehberine "bu numaralar benim adıma arayabilir" diye not düşmek gibi düşünün.
DKIM (mühür). Sorusu şu: "Bu mektup yolda değişti mi?" Mailiniz gönderilirken sunucu, mailin içeriğine görünmez bir dijital mühür vurur. Bu mührün doğrulanma bilgisi de DNS'te durur. Alıcı mührü kontrol eder; mühür tutuyorsa mektubun yolda kimse tarafından değiştirilmediği ve gerçekten o alan adının sahibinden çıktığı anlaşılır.
DMARC (kural kitabı). Sorusu şu: "Kontroller tutmazsa ne yapılsın?" DMARC, SPF ve DKIM'in sonucunu okuyan ve alıcıya bir talimat veren kayıttır. "Hiçbir şey yapma, sadece bana rapor ver", "Şüpheli maili spama at" ya da "Reddet" gibi seçenekler sunar. Ayrıca raporlar size mail ile gönderilebilir; böylece sizin adınıza kimlerin mail yolladığını görebilirsiniz.
Üçünün farkını tek bakışta görmek için aşağıdaki tabloyu hazırladım.
Tabloyu okurken şuna dikkat edin: üç kayıt birbirinin yerine geçmiyor, birbirini tamamlıyor. SPF tek başına, DKIM tek başına ya da DMARC tek başına eksik bir güvence verir. Büyük posta sağlayıcıları, özellikle çok mail gönderen alan adlarından üçünün birlikte doğru kurulmasını bekliyor.
Bir mail yola çıkınca neler oluyor?
Bu süreci adım adım görürseniz, hangi noktada bir şeyin ters gidebileceğini daha iyi anlarsınız. Mail gönder tuşuna bastığınızda önce sizin mail sağlayıcınız (örneğin Google Workspace, Microsoft 365 ya da hosting firmanızın posta sunucusu) mektubu alır, gerekirse DKIM mührünü vurur ve alıcının sunucusuna iletir. Alıcı sunucu, gelen mailin hangi alan adından olduğunu okur, o alan adının DNS kayıtlarına bakar ve SPF listesini, DKIM mührünü, DMARC kuralını kontrol eder. Sonuca göre mail gelen kutusuna, spama ya da hiç teslim edilmemek üzere reddedilenlere gider.
Yukarıdaki şemadan çıkaracağımız ders şu: karar, mail alıcıya ulaştıktan sonra veriliyor ve bu karar sizin elinizde olmayan bir sunucuda, sizin yayımladığınız kayıtlara bakılarak veriliyor. O yüzden kayıtlar doğru, güncel ve eksiksiz olmak zorunda.
Mailleriniz neden kimlik kontrolünden kalıyor olabilir?
Gerçek hayatta gördüğüm nedenler genellikle birkaç tanesinin birleşimi. En sık rastlananlar şöyle.
Hiç kayıt yok
Alan adını bir yerden aldınız, siteyi başka birine yaptırdınız, mail de bir paket içinde geldi. Kimse DNS tarafına bakmamış. Bu durumda alıcı sağlayıcı sizin alan adınızdan hiçbir kimlik bilgisi bulamaz. Bu, özellikle sitenin ilk kurulduğu dönemde ve alan adının yeni olduğu zamanlarda sık görülür.
Kayıt var ama yanlış servisi yazıyor
Önceki hosting firmasının ayarı duruyor, siz ise artık başka bir servisten mail gönderiyorsunuz. Ya da muhasebe programınız fatura maillerini kendi sunucusundan çıkarıyor ama SPF listesinde yok. Alıcı mailin geldiği sunucuyu listede bulamıyor ve işareti "şüpheli" olarak kaydediyor.
Birden fazla servis aynı alan adından mail gönderiyor
Kurumsal mailiniz bir yerde, sitenizdeki iletişim formu başka bir yerde, bülten programınız bir başka yerde olabilir. Her biri sizin alan adınız adına mail atıyorsa, hepsinin kimlik ayarlarının yapılması gerekir. En sık yapılan hatalardan biri, bu servislerden sadece birini ayarlayıp diğerlerini unutmaktır.
SPF kaydı birden fazla
Teknik bir ayrıntı ama önemli: bir alan adında yalnızca bir SPF kaydı olabilir. Birisi yeni bir servis eklerken eskisini silmeden ikinci bir kayıt açarsa, alıcı sağlayıcı ikisini de geçersiz sayabilir. Bu tür hatalar, kayıtlara bakmadan göremeyeceğiniz sessiz sorunlardır.
Alan adı yeni ya da hareketsiz
Yeni açılmış bir alan adından birden çok mail çıkmaya başlarsa sağlayıcılar temkinli davranır. Kimlik kayıtları da yoksa bu temkin spam kararına dönüşebilir. Burada çare, kayıtları baştan doğru yapmak ve gönderim hacmini yavaş yavaş artırmaktır.
İçerik ve gönderim alışkanlıkları
Kimlik ayarları doğru olsa bile sürekli aynı şablonu yüzlerce kişiye göndermek, kimsenin cevap vermediği toplu mailler atmak ya da satın alınmış listelere yazmak itibarınızı düşürür. Bu yazıda ağırlığı kimlik ayarlarına veriyorum ama içeriği tamamen gözden kaçırmayın.
İki örnek senaryo
Aşağıdaki iki senaryo tamamen varsayımsaldır; gerçek bir firma ya da kişiyi anlatmıyor. Amacım, benzer bir durumda olan birinin kendini tanıması.
Örnek senaryo 1: Teklif mailleri kaybolan bir ambalaj firması
Varsayalım ki küçük bir ambalaj üreticisi, bilgi@ornek-firma.com adresinden müşterilere teklif gönderiyor. Mailleri Gmail kullanan alıcıların spam klasörüne düşüyor, bazıları ise hiç ulaşmıyor. Firma sahibi sorunu önce "içeriğim kötü olmalı" diye düşünüp mailleri defalarca yeniden yazıyor, ama değişen bir şey olmuyor.
Bakıldığında şu görülüyor: alan adı iki yıl önce başka bir hosting firmasıyla alınmış, mail şimdi başka bir servisten çıkıyor, ama SPF kaydı eski hosting firmasını gösteriyor. DKIM hiç kurulmamış. DMARC kaydı yok. Yani alıcı, mailin geldiği sunucuyu listede bulamıyor, mühür göremiyor ve ne yapacağına dair bir kural bulamıyor.
Çözüm sırasıyla şöyle ilerliyor: önce hangi servislerin bu alan adından mail gönderdiği listelenir; sonra SPF kaydı bu listeye göre yeniden yazılır; mail sağlayıcıdan DKIM anahtarı alınıp DNS'e eklenir; en son "sadece izle" modunda bir DMARC kaydı yayımlanır. Birkaç gün içinde mailler kontrol edilir. Bu varsayımsal örnekte teslimat sorununun büyük kısmı çözülür; çünkü sebep içerik değil, eksik kimlikmiş. Sonuç elbette her durumda aynı olmaz ve garanti verilemez.
Örnek senaryo 2: Form mailleri gelmeyen bir klinik
Bir diğer varsayımsal örnek: küçük bir klinik, web sitesindeki randevu formundan gelen mesajların kendi kutusuna ulaşmadığından şikayet ediyor. Hastalar "formu doldurdum, kimse dönmedi" diyor. Kliniğin kurumsal maili ayrı bir serviste, site ise başka bir sunucuda duruyor.
İnceleme sonucunda sitenin formu, mesajı "randevu@ornek-klinik.com" adresinden kendi kutusuna göndermeye çalışıyor ama bu mail, sitenin sunucusundan çıkıyor ve bu sunucu SPF listesinde yok. Alıcı tarafı, kendi alan adı adına dışarıdan gelen bu maili sahte sayıp çöpe atıyor. Yani mail aslında kliniğin kendi sitesinden, kendi kutusuna gidiyor ama kimlik kontrolünden geçemiyor.
Çözümün bir yolu formu doğrudan düzgün bir mail servisi üzerinden göndermek, bir yolu da sunucuyu SPF listesine eklemek. Kalıcı çözüm genellikle ilkidir; çünkü form mesajları için ayrı ve tanınmış bir gönderim servisi kullanmak daha sağlam bir düzendir. Bu örnekte de sonuç önceden vaat edilemez, ama sorunun yeri doğru tespit edilmiş olur.
Bu şema iki senaryodaki ortak mantığı gösteriyor: önce mailin hangi servislerden çıktığını bilmek gerekiyor. Tek servis varsa iş basit, birden fazlaysa hepsini kayıtlara yazmak gerekiyor.
Adım adım nasıl düzeltilir?
Yazının en pratik kısmı burası. Teknik bilginiz sınırlı olsa bile adımların mantığını bilmek, hem kendi kontrolünüzü yapmanıza hem de bir uzmanla konuşurken ne istediğinizi bilmenize yardımcı olur.
1. Önce mailinizin kaderini ölçün
Hangi alıcılarda sorun yaşandığını not edin. Sadece Gmail'e mi düşüyor, hepsine mi? Sadece teklif mailleri mi, her mail mi? Kendinize ait iki üç farklı posta adresine (Gmail, Outlook, bir de başka) test maili gönderin. Birçok posta kutusunda mailin "üst bilgisi" bölümünde SPF, DKIM ve DMARC sonucunun "pass" (geçti) ya da "fail" (kaldı) olarak yazıldığını görebilirsiniz. Bu ekranı genellikle "orijinali göster" ya da "mailin kaynağını göster" gibi bir menüden açarsınız; sorunu teşhis etmek için çok değerlidir.
2. Mailin hangi servislerden çıktığını listeleyin
Kurumsal posta servisiniz, web sitenizin formu, e-bülten programınız, muhasebe ya da e-ticaret yazılımınız, CRM sisteminiz. Sizin alan adınız adına mail gönderen her şeyi bir kâğıda yazın. Bu liste, SPF'nin temelidir.
3. SPF kaydını doğru kurun
Listedeki her servisin, kendi dokümantasyonunda "SPF için şu ifadeyi ekleyin" diye bir satırı vardır. Bu satırları tek bir SPF kaydında birleştirmek gerekir. Unutmayın, bir alan adında tek SPF kaydı olmalı. Ayrıca çok fazla servis eklemek kaydı fazla uzatır ve SPF'nin izin verdiği sorgu sınırını aşar; bu yüzden kullanılmayan eski servisleri listeden çıkarmak da önemli.
4. Her servis için DKIM'i etkinleştirin
DKIM'i alan adı sahibi olarak siz üretmezsiniz; mail sağlayıcınız size bir anahtar verir ve siz de bunu DNS'e eklersiniz. Her gönderen servis için bu işlem ayrı yapılır. Kurumsal posta servisinizin yönetim panelinde "DKIM'i etkinleştir" ya da benzeri bir seçenek bulunur.
5. DMARC'ı "izleme" modunda başlatın
DMARC'ı ilk günden sert bir kuralla açmak risklidir; çünkü unuttuğunuz bir servisin maili de reddedilebilir. Bu yüzden ilk aşamada "sadece izle ve bana rapor gönder" şeklinde kurulur. Birkaç hafta raporlara bakıp tüm meşru servislerin geçtiğinden emin olduktan sonra daha sıkı bir kurala geçilir.
Yukarıdaki görsel bu beş adımın kısa özeti. Sıranın önemli olduğunu not edin: önce tespit, sonra liste, sonra kayıtlar, en son sıkılaştırma.
DNS panelinde ne göreceksiniz?
Kayıtların yazıldığı yer, alan adını satın aldığınız firmanın ya da DNS hizmetini sağlayan servisin yönetim panelidir. Genellikle "DNS yönetimi", "DNS kayıtları" ya da "Alan adı ayarları" gibi bir başlık altında bulunur. Burada "TXT" tipinde kayıtlar göreceksiniz. SPF ve DMARC birer TXT kaydıdır; DKIM de çoğunlukla TXT ya da bazı servislerde CNAME olarak eklenir.
Görseldeki panel örnektir; her firmanın arayüzü farklıdır ama mantık aynıdır. DMARC kaydı "_dmarc" adıyla, DKIM kaydı ise servisin verdiği bir "seçici" adıyla yazılır. Bu adları kendi kafanıza göre değiştirmemelisiniz; mail sağlayıcınızın verdiği ifadeyi birebir kopyalamak gerekir. Bir harf bile hatalı olsa kayıt çalışmaz.
Sık yapılan hatalar
Bu işte hata yapmak çok kolay, çünkü sonuç hemen görünmüyor. En sık gördüklerimi sıralıyorum.
Listeyi biraz açayım. İkinci SPF kaydı eklemek: Yeni bir servis geldiğinde elle yeni bir satır açılır, eskisi silinmez. Sonuç, iki kayıt ve ikisinin de geçersiz sayılması. DMARC'ı doğrudan "reddet" moduyla başlatmak: Hangi servislerin mail gönderdiğini bilmiyorsanız, kendi önemli maillerinizi bile reddettirebilirsiniz. DKIM'i sadece ana posta servisi için kurmak: Form mailleri ve bülten servisleri unutulur. Eski hosting kaydını bırakmak: Taşınma sonrası eski firmanın kaydı silinmez, yeni servis eklenmez. Sorunu içerikte aramak: Haftalarca mail metnini değiştirip altyapıya hiç bakmamak. Kontrol etmeden güvenmek: Kayıt eklendikten sonra test maili göndermemek.
Hata sonrası kurtarma
Eğer yanlış bir kayıt eklediyseniz, çoğu zaman kaydı düzeltmek yeterli olur. Ama DNS değişikliklerinin her yerde yayılması bir süre alabilir; bu yüzden değişiklik yaptıktan hemen sonra sonucu görmeyebilirsiniz. Sabırlı olun, birkaç saat sonra tekrar test edin ve aynı gün içinde peş peşe değişiklik yapmaktan kaçının.
DMARC politikası kademeleri
DMARC'ın üç ana kuralı vardır ve hepsini bir anda kullanmak gerekmez. Bunu kademeli düşünmek iyi bir yöntemdir.
Birinci kademe "izle" (none): hiçbir mail engellenmez, yalnızca rapor alırsınız. İkinci kademe "karantina" (quarantine): kontrolden geçmeyen mailler spama yönlendirilir. Üçüncü kademe "reddet" (reject): kontrolden geçemeyen mailler hiç teslim edilmez. Çoğu işletme için "izle" ile başlayıp sonuçlar temiz görününce karantinaya, emin olunca reddetmeye geçmek en güvenli yoldur.
Bu kademeli yaklaşımın amacı, sahte mail gönderenlere karşı koruma sağlarken kendi meşru maillerinizi de kaybetmemek. Sıkı kural iyidir ama ancak altyapınızı tanıdıktan sonra.
Kendiniz neler yapabilirsiniz, ne zaman uzman gerekir?
Dürüst olmak gerekirse, bu işin bir kısmını teknik bilgisi olmayan biri de yapabilir. Bir kısmı ise hata kaldırmaz.
Kendiniz yapabilecekleriniz: mailin hangi servislerden çıktığını listelemek, kendi posta servisinizin yönetim panelinde DKIM ve SPF talimatlarını okumak, test mailleri göndererek sonucu gözlemlemek, spam klasöründeki maillerinizi "spam değil" olarak işaretlemek ve sık yazıştığınız müşterilere adresinizi kişi listesine eklemelerini rica etmek.
Bir uzmanın bakması gereken durumlar: birden fazla servis aynı alan adından mail gönderiyorsa, SPF kaydı karmaşıksa, DMARC'ı sıkılaştırmayı planlıyorsanız, hosting değiştirdiyseniz, sitenizdeki form mailleri kaybolduysa ya da e-ticaret sitenizin sipariş bildirimleri müşteriye ulaşmıyorsa. Yanlış bir DNS değişikliği hem sitenizi hem mailinizi aynı anda etkileyebilir; bu yüzden DNS panelinde "deneme yanılma" yapmanızı önermem.
Bu kontrol listesi, uzmana gitmeden önce yapabileceğiniz hazırlığı gösteriyor. Listeyle gelen biri, "Mailim spama düşüyor" demekten çok daha net bir tablo sunmuş olur ve bu da hem zamanı hem maliyeti azaltır.
Maliyeti neler belirler?
Bu tür bir düzenlemenin ücretini sabit bir rakamla söylemiyorum; çünkü iş, sizin durumunuzun karmaşıklığına göre değişir. Fiyatı belirleyen başlıca unsurlar şunlar: alan adınızdan kaç farklı servisin mail gönderdiği, mevcut kayıtların ne kadar dağınık olduğu, mail sağlayıcınızın hangi platformda olduğu, DNS yönetiminin kimde olduğu (erişiminiz yoksa önce erişimi geri almak gerekebilir), kaç alan adı olduğu, DMARC raporlarının izlenmesinin istenip istenmediği ve işin tek seferlik mi yoksa süreklilik gerektiren mi olduğu.
Tek servisli, temiz bir alan adı kısa sürede çözülebilir. Birden çok servis, eski kalıntılar ve belirsiz erişimler ise daha fazla inceleme gerektirir. İş başlamadan önce kapsamı net olarak konuşmak, sonradan sürpriz yaşamamanızı sağlar.
Benimle nasıl çalışıyorum?
Ben tek kişiyim ve işi ben yapıyorum; yani sizinle konuşan kişi ile DNS paneline giren kişi aynı. Süreç kabaca şöyle: önce sorunu dinliyorum ve hangi alıcılarda, hangi maillerde sorun olduğunu öğreniyorum. Sonra mevcut kayıtlara bakıyorum, hangi servislerin mail gönderdiğini sizinle birlikte listeliyorum. Düzeltmeyi yapmadan önce neyi değiştireceğimi size sade bir dille anlatıyorum, onayınızla uyguluyorum, ardından test mailleriyle sonucu doğruluyorum.
Mail altyapısı benim ana uzmanlığım olmadığı için, işin sadece web sitesi ve alan adı tarafıyla ilgili olanını üstleniyorum. Sunucu içi derin mail yapılandırması gerekiyorsa bunu açıkça söylerim ve sizi doğru kişiye yönlendiririm. Garanti vermem; ancak sebebi doğru tespit etmek ve yapılanları sizin anlayacağınız dille aktarmak benim sözüm.
Bugün birçok kişi bu soruyu önce bir yapay zekâ asistanına soruyor. Yukarıdaki örnek cevap, doğru yönü gösteriyor ama sizin alan adınızın gerçek durumunu göremiyor. Asistan genel bir yol çizebilir; kayıtlarınıza bakıp hangi satırın yanlış olduğunu söylemek ise alan adınıza gerçekten bakmayı gerektirir.
Mail sorunu çözüldükten sonra neler izlenmeli?
Kayıtları bir kez düzeltmek yeterli değil, düzen zamanla bozulabilir. Yeni bir servis eklediğinizde (örneğin yeni bir e-bülten aracı ya da yeni bir CRM) kimlik ayarlarının da güncellenmesi gerekir. Hosting değiştirdiğinizde ya da alan adını başka firmaya taşıdığınızda kayıtlar yeniden gözden geçirilmeli. DMARC raporlarını düzenli okumak, sizin adınıza yetkisiz mail gönderilip gönderilmediğini de gösterir. Ayrıca yılda bir kez kendi adresinize farklı sağlayıcılardan test maili göndermek, küçük bir sigorta gibi çalışır.
Müşteri tarafında da küçük alışkanlıklar yardımcı olur: önemli bir teklif gönderdikten sonra alıcıya kısa bir mesajla haber vermek, mailin ulaşıp ulaşmadığını teyit etmek, çok önemli belgeleri tek bir yola bağlı bırakmamak. Kimlik ayarları ne kadar iyi olsa da hiçbir sistem yüzde yüz teslimat garantisi sunmaz; bu yüzden kritik iletilerde ikinci bir kanal bulundurmak akıllıca.
Sıkça Sorulan Sorular
Mailim spama düşüyor ama içeriğim normal, yine de altyapı sorunu olabilir mi?
Evet. Sade ve düzgün yazılmış bir mail bile, alan adınızın SPF, DKIM ve DMARC kayıtları eksik ya da yanlışsa şüpheli sayılabilir. Önce kayıtlara bakmak, içeriği tekrar tekrar yazmaktan daha mantıklıdır.
SPF, DKIM ve DMARC'ı üçünü de kurmam şart mı?
Üçünü birlikte kurmak en sağlam yoldur. Özellikle çok sayıda alıcıya mail gönderiyorsanız büyük posta sağlayıcıları bunları bekler. Tek başına SPF ya da tek başına DKIM kısmi koruma sağlar, ama tam resmi vermez.
Bu ayarları kendim yapabilir miyim?
Posta servisiniz adım adım yönergeler sunuyorsa ve DNS paneline erişiminiz varsa basit durumlarda yapabilirsiniz. Birden fazla servis varsa ya da emin değilseniz, yanlış bir değişiklik mailinizi ya da sitenizi etkileyebileceği için bir uzmana danışmanız daha güvenlidir.
Ayarları düzelttim, mailler hemen düzelir mi?
Hemen olmayabilir. DNS değişikliklerinin yayılması zaman alır ve posta sağlayıcıları itibarınızı yeniden değerlendirirken biraz süre geçebilir. Düzelmenin hızı alan adınızın geçmişine bağlıdır; kesin bir süre veya sonuç vaat edilemez.
Ücretsiz mail adresi (Gmail gibi) kullanmak daha mı güvenli?
Teslimat açısından ücretsiz adresler bu üç ayarı sizin yerinize taşır, ama müşterinize güven veren şey kendi alan adınızla gönderilen maildir. Doğru kurulmuş bir kurumsal adres hem daha profesyonel görünür hem de itibarı size ait olur.
DMARC raporlarını okumak zorunda mıyım?
Zorunlu değil ama faydalı. Raporlar, adınıza kimlerin mail gönderdiğini ve hangi servislerin kontrolden geçemediğini gösterir. Okumak istemiyorsanız, raporları sizin yerinize izleyip sade bir özet çıkaran bir uzmanla çalışabilirsiniz.
Sitemin iletişim formundan gelen mailler de aynı sebeple kaybolur mu?
Evet, çoğu zaman. Form mesajı sitenizin sunucusundan çıkıp sizin alan adınız adına gönderiliyorsa ve o sunucu SPF listesinde yoksa mesaj spama düşebilir ya da hiç ulaşmayabilir. Formları tanınmış bir mail servisi üzerinden göndermek daha sağlam bir çözümdür.
Mevzuat açısından mail gönderiminde dikkat edilecek bir şey var mı?
Ticari ileti gönderimi konusunda izin ve bilgilendirme kuralları var. Bunların ayrıntıları işinize göre değişebilir; bu konuda kesin bir şey söylemem doğru olmaz, bir hukukçuya danışmanızı öneririm.
Mailleriniz müşterilere ulaşsın istiyorsanız
Kurumsal mailleriniz spama düşüyorsa bunun çoğu zaman bir çaresi vardır ve çare, tahmin yürütmekten önce alan adınızın kayıtlarına bakmaktan geçer. Mail ayarları bir web sitesinin kurulum ve bakım sürecinin doğal parçası; web sitesi yaptırma hizmet sayfamdan işimi ve çalışma biçimimi görebilir, durumunuzu kısaca yazarak benimle iletişime geçebilirsiniz. Önce neyin bozuk olduğuna birlikte bakar, ne yapılması gerektiğini sade bir dille anlatırım.