Bir etkinlik davetiyesi ve resmi web sitesi nasıl doğrulanır

Web sitesini, davetiyeleri, kayıt sürecini ve desteği, katılımcının resmi kaynağı hızla bulabileceği ve sahtekârlığı bildirebileceği şekilde nasıl birbirine bağlayabiliriz?

Sahte bir davetiye, gerçek etkinliğin tarihini, programını ve mekânını birebir tekrarlayabilir. Bu nedenle ilk gönderimden önce katılımcıya basit bir doğrulama yolu sunuyoruz: resmi siteyi kendisi açsın, göndericiyi kontrol etsin ve şüpheli mesajı ekibe iletsin.

Gerçek ayrıntılar davetiyeyi neden doğrulamıyor?

Kesin tarih, mekân ve program, e-postayı etkinlik ekibinin gönderdiğini kanıtlamaz. Bu bilgiler çoğu zaman zaten yayımlanmıştır ve kolayca kopyalanabilir. Katılımcının bağımsız bir doğrulama yöntemine, işverenin ise basit bir kurala ihtiyacı vardır: hangi site, gönderici ve kanal resmî kabul edilir ve şüphe durumunda doğrulama nerede aranır.

8 Ekim 2026'da Cisco Talos, Tayvan'daki bilimsel kuruluşlarla bağlantılı kişilere yönelik hedefli bir kampanyayı duyurdu. Davetiyelerde gerçek kuruluşların adları ve etkinliklere ilişkin kamuya açık bilgiler kullanıldı. Senaryolardan birinde saldırganlar bir afişi kopyalayıp üzerindeki QR kodunu değiştirdi.

Bu, alışılmış doğrulamayı değiştiriyor. Düzgün metin, tanıdık logo ve programın örtüşmesi artık yeterli işaret sayılamaz. Korunması gereken tek bir e-posta değil, katılımcının tüm yolculuğudur: ilk davetten kayıt, ödeme, güncellemeler ve mekâna girişe kadar.

Aventura olarak basit bir soruyla başlıyoruz: Kişi aldığı mesaja güvenmediğinde bilgiyi nerede doğrulayabilir? Yanıt, yöneticinin kişisel telefonuna veya aynı e-postadaki adrese bağlı olmamalıdır. Katılımcının kendi başına açtığı bir nokta gereklidir.

Doğrulama tek bir resmî adresle başlar

Etkinliğin tüm materyallerde aynı şekilde yayımlanan tek bir ana adresi olmalıdır. Katılımcı burada programı, kaydı, iletişim bilgilerini ve davetiye doğrulama sayfasını bulur. Harici hizmetlere izin verilir, ancak ekip bunların alan adlarını önceden tek bir listeye ekler ve ana sitede geçişi onaylar.

Tek bir resmî adres, misafirin göz kararıyla vermek zorunda kaldığı kararların sayısını azaltır. Birkaç benzer açılış sayfasını karşılaştırmaz ve hangi kayıt formunun güncel olduğunu tahmin etmez. Ekip, her değişikliği önce yayımladığı tek bir yere sahip olur.

Resmî adresler ve sorumlular listesinde şunları kaydediyoruz:

• ana alan adı ve izin verilen alt alan adları;
• resmî kayıt formu adresi;
• yayın, kişisel hesap ve ödeme platformları;
• e-posta alan adları ve gönderici adresleri;
• mesajlaşma uygulamaları ve sosyal medyadaki resmî hesaplar;
• her iletişim noktasının sahibi;
• yedek iletişim kanalı;
• son kontrol tarihi.

Proje harici kayıt kullanıyorsa, buna verilen bağlantı önce ana sitede görünür. Doğrudan bağlantı e-postayla gönderilebilir, ancak katılımcı siteyi kendi başına açıp aynı güzergâhı bulabilmelidir.

Kurumsal etkinlik organizasyonunda siteyi, kaydı, programı ve misafir yönetimini tek bir üretim planında birleştiriyoruz. Böylece iletişim, mekândan ve senaryodan ayrı yaşamaz.

Katılımcı davetiyeyi nasıl doğrular?

Doğrulama birkaç anlaşılır adımdan oluşmalı ve teknik bilgi gerektirmemelidir. Katılımcı resmi web sitesini kendisi açar, kalıcı doğrulama sayfasını bulur, kayıt alan adını ve gönderen adresini karşılaştırır. Şüphe duyduğunda şüpheli adrese veya mesajlaşma uygulamasındaki yeni bir kişiye yanıt vermek yerine sitedeki iletişim kanalı üzerinden yazar.

Ana alan adında kalıcı bir «Davetiye nasıl doğrulanır» sayfası faydalıdır. Bu sayfa etkinlikten önce, etkinlik sırasında ve sonrasında aynı adreste kalır. İçerik değişir, ancak ona giden yol değişmez.

Sayfa şunları içerir:

1. Etkinliğin tam resmi adresi.
2. İzin verilen kayıt ve yayın alan adları.
3. E-postaların gelebileceği adresler.
4. Resmi hesapların ve botların adları.
5. Ekibin e-posta veya sohbet yoluyla talep etmediği bilgiler.
6. Şüpheli bir e-postayı, siteyi veya QR kodu bildirmek için kanal.
7. Son güncelleme tarihi ve saati.
8. Bilinen sahtekârlıklara ilişkin kısa uyarılar.

Doğrulama, kodların iç yapısını veya misafir listesini açığa çıkarmamalıdır. Davetiye kişiye özelse form tarafsız bir sonuç döndürür: durum onaylandı ya da destek ekibine başvurulması gerekiyor. Başka bir katılımcı, unvan veya ret nedeni hakkında fazladan bilgi gösterilmez.

Alanlar ve onaylarla ilgili çalışmaların ayrı olarak tasarlanması daha iyidir. Ayrıntılı bir inceleme, 152-FZ kapsamında etkinlik kaydı hakkındaki makalede yer alıyor.

Etkinlik hazırlığına dair kısa ve pratik incelemeler işinize yarıyorsa, Aventura'nın Telegram kanalına abone olun.

İzin Verilen Göndericiler ve Harici Platformlar

Ekip, katılımcılara kimin, hangi alan adından ve hangi konularda yazma yetkisi olduğunu önceden belirler. Liste kısa ve konuk için anlaşılır kalır. Yüklenici otomatik olarak güvenilir gönderici haline gelmez: adresi, rolü, erişim süresi ve mesaj türü ilk gönderimden önce kararlaştırılır ve proje sonrasında erişim kapatılır.

Kişisel e-posta kutuları iş görüşmeleri için uygundur. Toplu değişiklikleri ortak bir adresten gönderiyoruz: koordinatör hastalansa veya projeden ayrılsa bile bu adres çalışmaya devam eder ve yeni çalışan önceki yazışmaları görebilir.

Konuşmacılar, ortaklar ve yükleniciler için ayrı bir kayıt gereklidir. Tanınmış bir kişinin veya şirketin gerçek adı kolayca kopyalanabilir. Ekip böyle bir sayfayı resmi web sitesinden bir bağlantıyla doğrular ve güncel tutulmasından sorumlu bir çalışan atar.

QR kodlar için de aynı ilke geçerlidir, ancak basılı materyallerin ek riskleri vardır. Bunları etkinlikte güvenli QR kodları hakkındaki materyalde ele aldık.

E-posta kimlik doğrulaması neden yeterli değil?

Kısaca: SPF, gönderim sunucusunun e-postanın teknik alan adı için yetkili olup olmadığını kontrol eder. DKIM dijital bir imza ekler ve imzalanan bölümlerin değiştirilip değiştirilmediğini fark etmeye yardımcı olur. DMARC, görünür gönderen alanındaki alan adını bu kontrollerden birini geçen alan adıyla karşılaştırır. Bu mekanizmalar kendi alan adınızın doğrudan taklit edilmesini zorlaştırır, ancak benzer bir adresi, ele geçirilmiş bir posta kutusunu veya sahte bir siteyi engellemez.

Müşterinin DNS kayıtlarını kendi başına düzenlemesi gerekmez. Onun görevi, alan adı sahibinden ve gönderim hizmetinden doğrulanabilir bir sonuç talep etmektir.

Toplu gönderimden önce şunları teyit etmelerini isteriz:

• etkinlik adına e-posta gönderen tüm hizmetlerin listesi;
• her hizmetin kimlik doğrulama şemasında dikkate alınması;
• görünür gönderenle uyumlu bir alan adına sahip geçerli DKIM imzası;
• DMARC'ın geçilmesi ve doğrulamayı geçemeyen e-postalar için seçilen işleme kuralı;
• ana e-posta sistemlerine test gönderimi;
• raporların ve hataların sahibi;
• eski veya ele geçirilmiş bir hizmeti hızla devre dışı bırakma yöntemi.

Başarıyla doğrulanmış bir e-posta bile, gerçek hesap ele geçirilmişse veya bir çalışan doğrulanmamış bir bağlantı gönderdiyse hatalı bilgi içerebilir. Tersi durum da mümkündür: meşru bir e-posta, yapılandırma hatası nedeniyle spam'e düşer. Bu nedenle hem teknolojiyi hem içeriği hem de misafir için doğrulama yolunu test ederiz.

Değişiklik kuralı: önce resmi web sitesi

Tarih, mekân, giriş düzeni, kayıt bağlantısı veya hesap bilgilerinde yapılan değişiklik önce resmi web sitesinde yayınlanır. Ardından katılımcılara bu sayfaya bağlantı içeren bir bildirim gönderilir. Bu yöntem hızı korur, ancak bir e-postanın, telefon aramasının veya sohbetin kritik bir değişikliğin tek kanıtı olmasını engeller.

Ekip hem normal bir günde hem de etkinlikten önceki akşam aynı sıralamayı kullanır.

1. İlgili alanın sorumlusu neyin değiştiğini ve kimleri etkilediğini belirler.
2. Yetkili yönetici kararı ve metni onaylar.
3. Editör resmi web sitesini günceller.
4. İkinci bir çalışan adresi, tarihi, saati ve misafirin yapması gerekenleri kontrol eder.
5. Ekip, yayınlanan sürüme bağlantı içeren bildirimleri gönderir.
6. Destek ekibi hazır yanıtı ve etkilenen grupların listesini alır.
7. Değişiklik; yazarı, zamanı ve önceki değeriyle birlikte kayıt defterine işlenir.

Karar henüz alınmadıysa «bilgiler netleştiriliyor» şeklindeki acil ifade kullanılabilir. Sadece hız uğruna bir varsayım nihai durum olarak sunulmamalıdır.

SMS için de aynı ilke geçerlidir: kısa mesaj tüm ayrıntıları sığdırmaya çalışmak yerine doğrulanmış bir sayfaya yönlendirir. Kanal uygulamasını katılımcılara spam göndermeden SMS bildirimleri başlıklı makalemizde anlattık.

Şüpheli bir mesajla ne yapmalı?

Kısaca: katılımcının şüphe bildirimi için tek ve basit bir yolu olmalıdır. Kişi yazışmayı sürdürmez, resmi web sitesini kendisi açar, bilgileri karşılaştırır ve e-postayı veya bağlantıyı belirtilen iletişim kanalı üzerinden iletir. Ekip, bildirimin alındığını teyit eder ve inceleme sürerken hangi resmi adresin kullanılması gerektiğini açıklar.

Kamuya açık talimat dört adımdan oluşabilir:

1. Ek bağlantılara tıklamayın ve istenen bilgileri göndermeyin.
2. Resmi web sitesini adresi kendiniz yazarak açın.
3. Mesajı doğrulama sayfasıyla karşılaştırın.
4. Materyali ortak destek kuyruğuna iletin veya formu doldurun.

Kişiden kaynağı kendi başına araştırmasını istemiyoruz. İlk inceleme için mesajın alınma zamanı, şüpheli sayfanın adresi ve onaylanmış güvenli kanal üzerinden iletilen mesaj kopyası yeterlidir. Göndermeden önce başkalarına ait gereksiz kişisel veriler gizlenmelidir. Yanıt için iletişim bilgisini yalnızca gerekli ölçüde talep ediyoruz. Parolalar, doğrulama kodları ve tam ödeme belgeleri toplanmamalıdır.

Kişi parolasını veya ödeme bilgilerini zaten girdiyse standart yanıt değişir. Ekip, kişiden resmi iletişim kanalı üzerinden kurumsal BT birimine veya bankasına başvurmasını ister. Bu makale, şirketin kendi bilgi güvenliği prosedürünün yerini tutmaz.

Ekibin doğrulanmış sahteciliğe tepkisi

Kısaca: doğrulamanın ardından ekip yanlış bilginin yayılmasını durdurur, katılımcılara tek ve güvenilir bir dayanak noktası sunar ve materyalleri iç ile hukuki inceleme için saklar. Kamuya açık mesajda, tespit edilen olgu henüz doğrulanmakta olanlardan ayrılır. Sahteciliğin tekrarlanmasına yardımcı olabilecek teknik ayrıntılar yayımlanmaz.

Şüpheli mesaj genel adrese ulaşır ve koordinatör bir denetleyici atar. İletişim sorumlusu katılımcılara verilecek yanıtı hazırlar, teknik uzman web sitesini ve e-posta gönderimini kontrol eder, yönetici başka kimlerin sürece dahil edileceğine karar verir. Küçük bir projede roller birleştirilebilir, ancak ekip yedekleri ve karar sınırlarını önceden yazılı hale getirir.

Ekip adım adım hareket eder:

1. Başvuruyu, zamanı ve mevcut materyalleri kayıt altına almak.
2. Tartışmalı kanalı kanıt olarak kullanmadan, olguyu iç kaynaklar üzerinden doğrulamak.
3. Etkilenen erişimi kısıtlamak veya ekip yetkisi dahilindeyse gönderimi durdurmak.
4. Resmî web sitesini, kaydı ve geçerli davetleri kontrol etmek.
5. Kalıcı doğrulama sayfasında bir uyarı yayımlamak.
6. Katılımcıları izin verilen göndericiler aracılığıyla bilgilendirmek.
7. Destek ekibine tek bir yanıt ifadesi iletmek.
8. Durum gerektiriyorsa platform sahibini, kurumsal bilgi güvenliği birimini ve hukukçuyu sürece dahil etmek.
9. Kararların ve güncellemelerin kaydını tutmak.

İlk mesaj pratik soruları yanıtlar: hangi e-postalar veya sayfalar şüpheli sayılmalı, katılımcı geçici olarak ne yapmamalı, güncel adres nerede ve bir sonraki güncelleme ne zaman beklenmeli. Ekip mutlak bir güvence vermek yerine doğrulanmış durumu yazar, örneğin: «Tespit edilen kanal engellendi. Diğer olası kanalların kontrolü sürüyor».

Roller ve tırmandırma konusundaki genel mantık, etkinlik kriz yönetimi planı makalesinde daha ayrıntılı ele alınmıştır.

Olay sonrası: güven nasıl yeniden kazanılır

Sahtecilik giderildikten sonra ekip teknik nedeni inceler ve katılımcıların mesaja neden inanmış olabileceğini araştırır. Ardından tek adres ve sorumlular listesini, doğrulama sayfasını, erişimleri ve şablonları günceller. Katılımcılara hangi talimatların geçerli olduğu, bilginin nihai sürümünün nerede bulunduğu ve bundan sonra hangi kanalın kullanılacağı bildirilir.

İnceleme belirli soruları yanıtlar:

• etkilenen kanallar ve gruplar;
• ilk sinyalin zamanı;
• başvurunun geciktiği yer;
• doğrulanmış olgular;
• yardımcı olan veya kafa karışıklığını artıran mesajlar;
• değiştirilmesi gereken erişimler ve roller;
• kararların uygulanmasını kimin denetleyeceği;
• katılımcı yolunun baştan sona ne zaman yeniden test edileceği.

Bir sonraki davet dalgasından önce ekip ana adresi açar, doğrulama sayfasını bulur, göndericileri karşılaştırır, kayıt sürecinden geçer ve bir test başvurusu gönderir. Bu, tüm doğrulama şemasının kısa bir provasıdır.

Konferans organizasyonu sırasında web sitesini, e-posta gönderimini ve desteği ortak bir plana dahil ederiz: web sitesi, program, kayıt, konuşmacılar, teknik ekip ve mekândaki çalışmalar bilginin tek bir sürümünü kullanmalıdır.

Kaynaklar

• Cisco Talos: sahte etkinlik davetiyeleri ve değiştirilmiş QR kodları
• European Union Centre in Taiwan: sahte e-postalara ilişkin resmi uyarı
• NCSC: şüpheli bir mesaj nasıl kontrol edilir
• Şüpheli bir bağlantıya tıklandıktan veya veri paylaşıldıktan sonra yapılması gerekenler
• ICANN Lookup: alan adının herkese açık kayıt bilgileri
• ICANN önerilerine göre kayıt kuruluşu hesabının ve alan adının korunması
• Microsoft Learn: SPF, DKIM ve DMARC
• Google: e-posta gönderenlere yönelik gereksinimler
• IETF RFC 9989: güncel DMARC spesifikasyonu
• NIST SP 800-61r3: siber olaylara müdahale yönetimine ilişkin öneriler
• Cloudflare: benzer alan adlarının izlenmesine ilişkin örnek