Kurumsal E-Posta Altyapısı Marka İmajını Nasıl Etkiler? Domain Uzantılı Mail Rehberi

Kurumsal e-posta nedir ve marka imajını nasıl etkiler?

Kurumsal e-posta, adresin sonunda Gmail veya Hotmail yerine şirketinizin kendi alan adının yer aldığı e-posta hesabıdır; örneğin ad@firmaniz.com. Bu adres müşteriye kim olduğunuzu ilk satırda söyler, sahteciliği zorlaştırır ve doğru kurulduğunda gönderdiğiniz mesajların gelen kutusuna ulaşma ihtimalini yükseltir.

2012'den beri müşterilerimin dijital altyapısını kurarken en çok ertelenen konulardan biri bu oldu. Web sitesi hazır, logo hazır, reklamlar dönüyor; ancak teklif maili hâlâ firmaadi.satis@gmail.com adresinden çıkıyor. Bu yazıda alan adlı mailin güvene ve teslim edilebilirliğe etkisini, SPF, DKIM ve DMARC kayıtlarını, sağlayıcı seçimini ve adres adlandırma standardını birlikte ele alıyorum.

Kısacası mesele yalnızca görüntü değil. Adresiniz, alıcının posta sunucusuna "bu mesajı gerçekten bu şirket mi gönderdi?" sorusunun cevabını da taşır. O cevabı teknik kayıtlarla verirsiniz ve marka imajınız o kayıtların sağlamlığına göre ya güçlenir ya da sessizce zarar görür.

Bu yazı teknik bir kurulum kılavuzu gibi görünse de asıl sorusu yöneticiye yöneliktir: müşteriniz size ilk kez yazdığında, adresiniz ve mesajınızın vardığı yer hakkında ne düşünüyor? Aşağıdaki bölümleri bu soruyu cevaplayacak sırayla dizdim; önce algıyı, ardından teknik kayıtları, en sonda da günlük kullanım standartlarını anlatıyorum.

Gmail veya Hotmail adresiyle iş yapmanın gerçek maliyeti nedir?

Ücretsiz bir adres ilk bakışta masrafsız görünür. Öte yandan maliyet faturada değil, alıcının kafasında oluşur. Bir satın alma müdürü aynı gün üç teklif alıyorsa, biri alan adlı adresten, ikisi ücretsiz adreslerden geliyorsa, ilk izlenimde kurumsal olanı daha köklü bir işletme olarak algılaması doğaldır. Bu bir önyargıdır, ama gerçek bir önyargıdır.

İkinci maliyet kontrol kaybıdır. Ücretsiz hesap bir çalışanın şahsi hesabına bağlandığında, o kişi ayrıldığında müşteri yazışmaları da onunla birlikte gider. Şirket hesabında ise yönetici olarak siz hesabı askıya alır, yazışmaları başka bir çalışana devreder ve erişimi tek tıkla kapatırsınız.

Üçüncü maliyet ise teknik tarafta çıkar. Gmail.com veya hotmail.com alan adının DNS kayıtları size ait değildir. Bu yüzden kendi e-posta pazarlama aracınızdan "gmail.com" görünümlü bir gönderici adresiyle toplu mesaj atarsanız, kimlik doğrulama sizin lehinize çalışmaz. Nitekim Google'ın e-posta gönderen yönergeleri, Gmail adresini taklit eden From başlıkları için DMARC karantina politikasını uygulayacağını açıkça yazar.

• Güven kaybı: alıcı, şirketin gerçekten var olup olmadığını sorgular.
• Kontrol kaybı: yazışmalar kişiye ait olur, şirkete değil.
• Teslim kaybı: kimlik doğrulama kayıtlarını siz yönetemezsiniz.
• Tutarlılık kaybı: her çalışan farklı bir adres biçimi uydurur.

Alan adlı mail güveni hangi anlarda somut olarak etkiler?

Güven etkisini en net gördüğüm yer ilk temas anıdır. Web sitenizdeki formu dolduran bir ziyaretçiye otomatik yanıt gittiğinde, gönderen adresin sitenin alan adıyla aynı olması yolculuğu tutarlı kılar. Aksi halde ziyaretçi "bu mail doğru yerden mi geldi?" diye durur. Formdan gelen talebi nasıl karşıladığınızı teklif ve demo formu tasarımı yazısında ayrıntılı anlattım.

İkinci an ödeme ve fatura yazışmalarıdır. Banka hesap bilgisi içeren bir e-postanın alan adlı adresten gelmesi, alıcının dolandırıcılık şüphesini azaltır. Üstelik alıcı sizin alan adınızı tanıdığı için, benzer görünümlü sahte bir adres geldiğinde farkı daha kolay fark eder.

Üçüncü an ise çevrim dışı dünyadır. Kartvizitte, araç giydirmede, fuar standında ve Google İşletme Profili'nde aynı alan adını görmek, markanın tek bir kimlik altında toplandığını gösterir. İşletme profilinizdeki iletişim bilgisinin tutarlılığını Google Haritalar SEO yazısında ele almıştım; e-posta adresi de o tutarlılığın bir parçasıdır.

E-posta teslim edilebilirliği neden marka imajının bir parçasıdır?

Teslim edilebilirlik, gönderdiğiniz mesajın alıcının gelen kutusuna ulaşma oranıdır. Güzel bir imza ve özenli bir metin hazırladığınızı düşünün; mesaj spam klasörüne düşerse alıcı onu hiç görmez. Dolayısıyla marka imajınızı en iyi temsil eden e-posta bile, teknik olarak doğrulanmadığında hiç var olmamış gibi sonuç verir.

Büyük posta sağlayıcıları bu konuda standartları yükseltti. Google, Şubat 2024'ten itibaren kişisel Gmail hesaplarına günde yaklaşık 5.000 veya daha fazla mesaj gönderenleri toplu gönderici sayıyor ve onlardan kimlik doğrulama, kolay abonelikten çıkma ve düşük spam oranı istiyor. Ayrıca Google'ın sıkça sorulan sorular sayfası, Kasım 2025'ten itibaren uyumsuz trafiğe karşı yaptırımı artırdığını ve geçici ile kalıcı reddetmelerin devreye girdiğini belirtiyor.

Peki küçük bir şirket günde 5.000 mesaj göndermiyorsa ne olur? Google, tüm göndericilerden en az SPF veya DKIM, geçerli ters DNS kaydı ve TLS bağlantısı bekliyor. Yani kural yalnızca büyük gönderenler için değil; eşik yalnızca ek şartların sınırını çiziyor.

Bu şartların pratik anlamı şudur: teklif, fatura ve form bildirimi gibi gündelik mesajlarınız bile artık kimliğini kanıtlamak zorunda. Kimliğini kanıtlayamayan mesaj, içeriği ne kadar düzgün olursa olsun, alıcının gözünde tanımadığı bir göndericiden gelmiş gibi muamele görür. Dolayısıyla teknik kayıtlar, marka imajının görünmeyen ama belirleyici katmanıdır.

MX kaydı nedir ve kurumsal e-posta için neden ilk adımdır?

MX kaydı, alan adınıza gelen e-postaların hangi posta sunucusuna teslim edileceğini söyleyen DNS kaydıdır. Kurumsal e-posta kurulumunun ilk adımı budur, çünkü MX yanlışsa size yazan müşterinin mesajı hiç ulaşmaz ve çoğu zaman gönderen tarafa bile net bir hata dönmez.

Google Workspace veya Microsoft 365 kullanacaksanız, sağlayıcı size eklemeniz gereken MX değerlerini verir. Hosting paketinin mail hizmetini kullanacaksanız MX genellikle hosting sunucusunu gösterir. Burada en sık gördüğüm hata, sağlayıcı değiştirdikten sonra eski MX kaydını silmeyi unutmaktır. Böylece bazı mesajlar yeni kutuya, bazıları eski sunucuya düşer ve ekip kayıp mesajın izini haftalarca sürer.

Kayıtlarınızı kontrol etmek için DNS sorgulama aracı ile alan adınızı sorgulayabilir, MX, TXT ve diğer kayıtların gerçekten beklediğiniz değerleri döndürüp döndürmediğini görebilirsiniz. Değişiklikten sonra DNS önbellekleri nedeniyle yeni değerin her yerde görünmesi biraz zaman alabilir; bu yüzden geçişi mesai dışında planlamanızı öneririm.

MX kayıtlarının bir de öncelik değeri vardır. Birden fazla MX tanımladığınızda, düşük sayıya sahip sunucu önce devreye girer ve o sunucu yanıt vermezse sıradakine geçer. Ancak yedek olarak eklediğiniz sunucunun da sizin sağlayıcınıza ait olması gerekir; aksi halde mesajlarınız tanımadığınız bir sunucuda bekler. Kısacası sağlayıcınızın verdiği listeyi eksiksiz eklemek, kendi yorumunuzu katmaktan daha güvenlidir.

SPF kaydı ne işe yarar ve nasıl kurarsınız?

SPF, alan adınız adına hangi sunucuların e-posta göndermeye yetkili olduğunu listeleyen bir TXT kaydıdır. Alıcı sunucu mesajı aldığında, gönderen sunucunun bu listede olup olmadığına bakar. Listede yoksa mesaj şüpheli sayılır.

Kurarken dikkat etmeniz gereken üç kural var. İlk olarak alan adında yalnızca bir SPF kaydı bulunmalıdır; iki ayrı "v=spf1" kaydı eklerseniz doğrulama bozulur. İkinci olarak SPF standardı (RFC 7208) değerlendirme sırasında en fazla 10 DNS sorgusuna izin verir. Her "include" bir sorgu harcadığı için, pazarlama aracı, CRM, fatura sistemi ve web sitesi formunu tek tek eklediğinizde bu sınırı fark etmeden aşabilirsiniz.

Üçüncü kural, kaydın sonundaki ifadeyle ilgilidir. "~all" yetkisiz sunucuları yumuşak başarısız sayar, "-all" ise kesin reddi ister. Kurulumun ilk haftalarında "~all" ile başlayıp, tüm gönderim kaynaklarınızı doğruladıktan sonra "-all" seçeneğine geçmek genelde daha güvenli bir yoldur.

• Web sitenizin form bildirimlerini hangi sunucu gönderiyor?
• Bülten aracınız kendi alan adınız adına mı gönderim yapıyor?
• E-fatura veya muhasebe sisteminiz müşteriye mail atıyor mu?
• CRM veya destek yazılımınız müşteriye doğrudan yanıt gönderiyor mu?

DKIM imzası neyi kanıtlar?

DKIM, giden her mesaja kriptografik bir imza ekler ve alıcı sunucu bu imzayı alan adınızın DNS kaydındaki açık anahtarla doğrular. Böylece mesajın yolda değiştirilmediğini ve gerçekten sizin alan adınızla ilişkili bir sistemden çıktığını kanıtlarsınız.

Google'ın toplu gönderici şartlarına göre kişisel Gmail hesaplarına gönderim için DKIM anahtarı en az 1024 bit olmalıdır. Ancak DNS sağlayıcınız destekliyorsa 2048 bit anahtar seçmenizi öneririm; Google Workspace yönetici panelinde de varsayılan önerinin bu yönde olduğunu görürsünüz.

Pratikte DKIM'i her gönderim kaynağı için ayrı ayrı açarsınız. Posta kutusu sağlayıcınız bir anahtar üretir, bülten aracınız başka bir anahtar üretir. Her biri farklı bir "seçici" adıyla DNS'e girer. Bu yüzden yeni bir araç devreye aldığınızda "DKIM'i kurduk" demek yetmez; o aracın imzasının da sizin alan adınızla eşleştiğini kontrol etmeniz gerekir.

DKIM'in bir faydası daha var: mesaj bir yönlendirme zincirinden geçtiğinde SPF çoğu zaman bozulur, çünkü son teslimi yapan sunucu artık sizin listenizde değildir. DKIM imzası ise mesajın içeriği değişmediği sürece geçerli kalır. Bu yüzden yönlendirme kullanan müşterilere yazışıyorsanız, DMARC sonucunuz büyük ölçüde DKIM'e bağlıdır. Örneğin bir bayinin adresi başka bir kutuya yönlendiriliyorsa, sağlam bir DKIM imzası mesajınızı kurtarır.

DMARC politikasını nasıl kademeli olarak sıkılaştırırsınız?

DMARC, SPF ve DKIM sonuçlarını From adresindeki alan adıyla eşleştirir ve doğrulamayı geçemeyen mesajlara ne olacağını alıcı sunucuya söyler. Ayrıca size düzenli raporlar göndererek alan adınız adına kimlerin mail attığını görmenizi sağlar.

DMARC'ı tek adımda en sert haline getirmek, meşru mesajlarınızı da engelleyebilir. Bu nedenle ben müşterilerimde şu sırayı izliyorum:

1. "p=none" ile başlarsınız ve rapor adresi (rua) eklersiniz; bu aşamada hiçbir mesaj engellenmez, yalnızca veri toplarsınız.
2. Raporlarda tanımadığınız ama meşru olan gönderim kaynaklarını bulur, onlara SPF ve DKIM eklersiniz.
3. Meşru trafiğin tamamı doğrulamayı geçtiğinde "p=quarantine" seviyesine çıkarsınız; şüpheli mesajlar spam klasörüne gider.
4. Birkaç hafta sorunsuz geçtikten sonra "p=reject" ile sahte mesajların tamamen reddedilmesini istersiniz.

Google ve Yahoo toplu göndericiler için en az "p=none" politikasını yeterli sayıyor. Yine de marka koruması açısından asıl fayda quarantine ve reject seviyelerinde başlar; çünkü ancak o noktada alan adınızı taklit eden bir dolandırıcının mesajı alıcıya ulaşmakta zorlanır.

Google, Yahoo ve Microsoft gönderici kuralları size ne anlatıyor?

Üç büyük sağlayıcının kuralları birbirine çok benziyor ve bu tesadüf değil. Yahoo gönderici en iyi uygulamaları tüm göndericilerden en az SPF veya DKIM, toplu göndericilerden ise SPF ile DKIM'in ikisini birden, en az p=none olan bir DMARC kaydını ve iki gün içinde işlenen abonelikten çıkma taleplerini istiyor. Spam şikâyet oranının yüzde 0,3'ün altında kalmasını bekliyor.

Microsoft da 5 Mayıs 2025'ten itibaren Outlook.com, Hotmail.com ve Live.com adreslerine günde 5.000'den fazla mesaj gönderenler için SPF, DKIM ve DMARC şartını devreye aldı. Microsoft duyurusuna göre şartları karşılamayan mesajlar önce önemsiz klasörüne düşüyor, ardından 550 5.7.515 hata koduyla reddedilebiliyor.

Google tarafında ise hedef çizgi daha da net: kullanıcıların bildirdiği spam oranını yüzde 0,1'in altında tutmanızı ve yüzde 0,3'e hiç ulaştırmamanızı öneriyor. Üstelik bir kez toplu gönderici sayılırsanız, bu statünün bir son kullanma tarihi olmadığını belirtiyor. Kısacası bülten ve kampanya gönderen her şirket için kimlik doğrulama artık tercih değil, giriş bileti.

Google Workspace, Microsoft 365 ve hosting maili arasında nasıl seçim yaparsınız?

Sağlayıcı seçimi, ekibinizin çalışma alışkanlığına ve güvenlik beklentinize bağlıdır. Aşağıdaki tabloyu, müşterilerimle yaptığım ilk görüşmelerde kullandığım karşılaştırmanın sade bir hali olarak düşünebilirsiniz. Fiyatlar ülkeye ve kura göre değiştiği için tabloya fiyat yazmadım; güncel rakamları sağlayıcıların kendi sayfalarından kontrol edin.

Google Workspace plan sayfası depolama ve toplantı kapasitesini plan bazında açıkça listeliyor. Microsoft tarafında ise iş planlarının kullanıcı sınırı 300 kişidir; daha büyük ekipler kurumsal planlara geçer.

Hosting maili hangi durumda yeterlidir, hangi durumda risklidir?

Hosting paketindeki mail hizmeti, iki üç kişilik bir işletme için mantıklı bir başlangıç olabilir. Ek ücret istemez, alan adınızla hemen çalışır ve temel ihtiyaçları karşılar. Bu yüzden her müşterime Google Workspace veya Microsoft 365 önermiyorum.

Ancak bazı durumlarda risk büyür. Paylaşımlı bir sunucuda aynı IP adresini kullanan başka bir site spam gönderirse, sizin mesajlarınız da o itibardan etkilenebilir. Ayrıca disk alanı web sitenizle ortak olduğu için dolu bir posta kutusu, sitenizin yedek almasını veya güncelleme yapmasını da engelleyebilir. Hosting firmasını değiştirdiğinizde posta kutularını taşımak ayrı bir iş yükü getirir.

Benim kullandığım basit ölçüt şu: ekipte beşten fazla kişi varsa, düzenli bülten gönderiyorsanız veya müşteri yazışmaları şirketin en değerli arşiviyse, posta hizmetini web sitesinden ayırırım. Web sitesini ve alan adı altyapısını birlikte planladığım web tasarım projelerinde bu ayrımı ilk toplantıda netleştiririm.

Adres adlandırma standardını nasıl belirlersiniz?

Adres adlandırma standardı, çalışanların ve departmanların e-posta adreslerinin hangi kurala göre oluşturulacağını belirleyen yazılı bir karardır. Standart olmadığında bir çalışan ahmet@, diğeri a.yilmaz@, bir diğeri ayilmaz1985@ adresini seçer ve dışarıdan bakan biri şirketin düzensiz olduğunu düşünür.

Standardı belirlerken şu kararları baştan yazıya dökmenizi öneririm:

• Biçim: ad.soyad@ mi, ad@ mi, adın baş harfi ve soyad mı? Büyüyen ekipler için ad.soyad@ çakışmayı en aza indirir.
• Türkçe karakter: ç, ş, ğ, ı, ö, ü harflerini c, s, g, i, o, u olarak yazarsınız; alıcıların klavyesinde sorun çıkmaz.
• Aynı isim: iki Mehmet Demir olduğunda ikinci adın baş harfini eklersiniz, doğum yılı eklemezsiniz.
• Rol adresleri: info@, satis@, destek@, fatura@ gibi adresleri bir listede sabitlersiniz.
• Ayrılan çalışan: hesabın silinmeyeceğini, yönlendirileceğini veya arşivleneceğini önceden belirlersiniz.

Bu standardı marka kılavuzunun bir bölümü olarak saklamak mantıklıdır. Marka kimliği çalışmalarında logo ve renk kadar bu tür dijital kuralları da teslim dosyasına ekliyorum.

Kişisel adres mi, rol adresi mi: hangisini ne zaman kullanmalısınız?

Kişisel adres, ilişkinin bir insanla kurulduğu yerlerde güven verir. Satış temsilcisi, proje yöneticisi veya muhasebe sorumlusu müşteriyle kendi adıyla yazıştığında, alıcı karşısında gerçek bir muhatap görür. Öte yandan rol adresi, sürekliliği korur; satis@ adresine yazan müşteri, temsilci izne çıktığında da yanıt alır.

Uygulamada ikisini birlikte kullanırsınız. Web sitenizde ve kartvizitte rol adresini gösterir, yazışma başladıktan sonra kişisel adresten devam edersiniz. Rol adreslerini tek bir kişinin posta kutusuna değil, ortak bir gelen kutusuna veya gruba bağlamak ise daha sağlıklıdır; çünkü böylece hiçbir talep bir kişinin tatil dönüşünü beklemez.

Bir de gizli kalması gereken adresler vardır. Alan adı kaydı, sosyal medya hesapları ve reklam hesapları gibi kritik hizmetleri tek bir çalışanın kişisel adresine bağlamak, o kişi ayrıldığında erişim sorunu çıkarır. Bu hesaplar için yalnızca yönetimin erişebildiği ayrı bir yönetim adresi açar ve güçlü bir parolayla korursunuz; şifre oluşturucu bu iş için pratik bir başlangıçtır.

Kurumsal e-posta imzası marka dilini nasıl taşır?

Kurumsal e-posta imzası, adresin taşıdığı güveni her mesajın sonunda tamamlayan kısa bir kimlik kartıdır. İmzanın görsel tasarımını, logo dosyasını ve renk uyumunu basılı kimliği dijitale taşıma yazımda ayrıntılı anlattığım için burada yalnızca içerik standardına odaklanıyorum.

İçerik tarafında her çalışanın imzası aynı sırayı izlemelidir: ad soyad, unvan, şirket adı, tek bir telefon numarası ve web sitesi. Kişisel sosyal medya hesapları, motivasyon sözleri ve üç farklı telefon numarası imzayı kalabalıklaştırır. Ayrıca yasal bilgilendirme ve şirket bilgileri gibi zorunlu olabilecek ifadeler için mali müşavirinizin veya hukuk danışmanınızın onayını alırsınız.

İmzadaki web sitesi bağlantısına kampanya parametresi eklemek de işinize yarar. Böylece e-posta yazışmalarından sitenize gelen ziyaretleri ayrı bir kaynak olarak görürsünüz. Bunun için UTM oluşturucu ile tek bir bağlantı hazırlayıp tüm imzalarda aynı bağlantıyı kullanırsınız.

İmzada sık gördüğüm bir sorun da tutarsız unvanlardır. Aynı pozisyondaki iki çalışanın biri "Satış Müdürü", diğeri "Sales Manager" yazıyorsa, müşteri hangi dilin resmi olduğunu anlayamaz. Bu nedenle unvanların listesini de adlandırma standardının yanına eklersiniz. Üstelik yurt dışıyla yazışan ekipler için ayrı bir İngilizce imza şablonu tanımlamak, karışıklığı baştan önler.

Alan adı seçimi ve benzer alan adları sahtecilikte nasıl kullanılır?

Dolandırıcılar çoğu zaman sizin alan adınızı değil, ona çok benzeyen bir alan adını kullanır. Harflerden birinin yer değiştirdiği, "l" yerine "1" yazılan veya uzantının farklı olduğu bir adres, dikkatsiz bir muhasebe çalışanına sahte fatura göndermek için yeterlidir. DMARC sizin gerçek alan adınızı korur, ancak benzer alan adlarını korumaz.

Bu nedenle markanız için kritik olan varyasyonları önceden kaydetmeyi değerlendirirsiniz: .com ve .com.tr gibi ana uzantılar, sık yapılan yazım hataları ve tireli versiyon. Bu alan adlarını kullanmasanız bile ana sitenize yönlendirir ve üzerlerine "p=reject" DMARC ile boş bir SPF kaydı koyarsınız; böylece o alan adlarından mail gönderilemez.

Alan adının kendisi de bir marka varlığıdır. Kısa, akılda kalan ve telefonda harf harf söylenmesi gerekmeyen bir alan adı, e-posta adresinizi de kolay hatırlanır kılar. Mevcut alan adınızın değerini merak ediyorsanız domain değeri hesaplama aracı kaba bir fikir verir.

Kurumsal e-postaya geçişi hangi sırayla yaparsınız?

Geçişte en büyük risk, eski yazışmaların kaybolması ve geçiş günü gelen mesajların kaybolmasıdır. Bu riski azaltmak için şu sırayı öneririm:

1. Envanter çıkarırsınız: kim hangi adresi kullanıyor, hangi hizmetler hangi adrese bağlı?
2. Adlandırma standardını yazıya döker ve yeni adresleri bu standarda göre açarsınız.
3. Sağlayıcıda alan adınızı doğrular, SPF ve DKIM kayıtlarını ekler, DMARC'ı "p=none" ile başlatırsınız.
4. Eski posta kutularındaki arşivi yeni hesaplara aktarırsınız.
5. MX kaydını mesai dışında değiştirir, birkaç gün boyunca eski kutuyu da kontrol edersiniz.
6. Web sitesi formları, fatura sistemi ve bülten aracı gibi tüm gönderim kaynaklarını yeni adrese ve doğru kimlik doğrulamaya bağlarsınız.
7. Kartvizit, web sitesi, sosyal medya profilleri ve işletme profilindeki adresleri tek seferde güncellersiniz.

Eski ücretsiz adresi hemen kapatmayın. Birkaç ay boyunca otomatik yanıtla yeni adresi bildirmesi, eski bağlantıların size ulaşmaya devam etmesini sağlar. Web sitenizdeki form bildirimlerinin hangi hedefe bağlı olduğunu da bu sırada gözden geçirmek iyi olur; dönüşüm hedefi belirleme yazısında bu bağı ayrıca ele aldım.

Geçişten sonra hangi hatalar sık görülür?

En sık hata, web sitesi formlarının hâlâ eski yöntemle, yani sunucunun kendi mail fonksiyonuyla gönderim yapmasıdır. Bu durumda mesaj sizin alan adınızla çıkar ama SPF listenizde olmayan bir sunucudan gelir. Sonuç olarak müşteriye giden otomatik yanıt spam klasörüne düşer ve siz bunu ancak müşteri telefonla aradığında öğrenirsiniz.

İkinci hata, pazarlama aracının "kendi alan adı" ile gönderim yapmasıdır. Bülten, aracın paylaşılan alan adı üzerinden imzalandığında DMARC eşleşmesi sağlanmaz. Bu yüzden aracın ayarlarında özel gönderici alan adı doğrulamasını açarsınız.

Üçüncü hata ise gereksiz yönlendirmelerdir. Kurumsal adresi kişisel Gmail hesabına otomatik yönlendirmek, hem güvenlik açığı yaratır hem de yönlendirilen mesajların doğrulamayı geçememesine neden olabilir. Son olarak çok sık gördüğüm bir hata daha var: DMARC raporları için bir adres tanımlanır ama o kutuya kimse bakmaz. Raporları okumuyorsanız, politikayı sıkılaştırmak için gereken bilgiyi de kaçırırsınız.

Kurumsal e-posta altyapısını nasıl denetler ve güncel tutarsınız?

Kurumsal e-posta altyapısı bir kez kurup unutacağınız bir sistem değildir. Yeni bir yazılım eklediğinizde, bir çalışan ayrıldığında veya alan adınızı yenilediğinizde kayıtların doğruluğunu yeniden kontrol edersiniz. Ben müşterilerimde üç ayda bir kısa bir denetim yapıyorum ve şu listeyi kullanıyorum:

• MX kaydı yalnızca kullandığınız sağlayıcıyı mı gösteriyor?
• Tek bir SPF kaydı var mı ve 10 sorgu sınırının altında mı?
• Tüm gönderim araçları DKIM ile sizin alan adınızı imzalıyor mu?
• DMARC raporlarında tanımadığınız bir kaynak görünüyor mu?
• Ayrılan çalışanların hesapları kapatıldı veya devredildi mi?
• Yönetici hesaplarında iki adımlı doğrulama açık mı?
• Alan adının yenileme tarihi ve kayıt e-posta adresi güncel mi?

Toplu gönderim yapıyorsanız Google Postmaster Tools üzerinden spam oranınızı da izlersiniz. Oran yükseldiğinde sorun çoğu zaman listeyi temizlememek veya izinsiz kayıtlara mail atmaktır.

Bu denetimi kendi ekibinizle yapabilirsiniz. Ancak alan adı, web sitesi ve reklam hesapları aynı çatı altında karmaşık hale geldiyse, dışarıdan bir göz işinizi hızlandırır. Altyapınızı birlikte gözden geçirmek isterseniz iletişim sayfasından bana yazabilirsiniz.