Otel e-postaları için SPF, DKIM ve DMARC: rezervasyon onayı spama düşmesin

SPF, DKIM ve DMARC, otelinizin adına gönderilen e-postalara güvenilip güvenilmeyeceğini belirleyen üç DNS kaydıdır. SPF gönderme yetkisi olan sunucuları listeler, DKIM her iletiyi imzalar ve yolda değiştirilip değiştirilmediğini görünür kılar, DMARC ise denetimlerden biri başarısız olduğunda alıcı posta kutusunun ne yapacağını söyler ve size rapor gönderir.

Bir misafir gece yarısı web sitenizden rezervasyon yapar, onay e-postası spam klasörüne düşer ve resepsiyon sabahı rezervasyonun var olduğunu kanıtlamakla geçirir. O onayı ulaştıramayan alan adı, bir yabancının misafirden kart ödemesi istemek için kullanabileceği aynı alan adıdır. Bu yazının sonunda oteliniz adına posta gönderen tüm sistemleri listeleyebilecek, her satıcıya doğru soruları yazılı olarak sorabilecek ve üç kaydı rezervasyon kaybettirmeyecek bir sırayla sıkılaştırabileceksiniz.

Onay e-postaları neden spam'a düşerken sahte postalar misafire ulaşıyor?#

Çünkü alıcı posta kutuları iletiyi değil, alan adını yargılar. Kimlik doğrulama kaydı yayımlamamış bir otel, adına yazan bir yabancıdan farksız görünür.

Alıcı posta kutusu tüm denetimlerini misafir iletiyi görmeden önce yapar. Başarısız bir ileti filtrelenir, karantinaya alınır veya reddedilir; gönderene hiçbir bildirim gitmez, otel olaydan habersiz kalır. İlk belirti genellikle bir telefon çağrısıdır, hata mesajı değil.

Bir otel alan adının altında genellikle birden çok gönderen vardır: onay postalarını gönderen otel yönetim sistemi, rezervasyon motoru, bülten aracı, resepsiyon ve satış posta kutuları, muhasebe sistemi. Her biri ayrı ayrı yargılanır ve her birinin listelenmesi gerekir. PMS'nin geçtiği ama bülten aracının kaldığı bir alan adı onayları ulaştırırken kampanyaları kaybeder, ya da tersi.

İletme SPF'yi bozar. Bir acentenin veya misafirin kendi e-posta kuralının ilettiği bir onay, SPF'nin adını verdiği sunucudan farklı bir sunucudan geldiği için SPF denetiminden geçemez. DKIM ise imza iletinin içinde taşındığı için iletmeye karşı daha dayanıklıdır; iki kaydın birlikte önem taşımasının nedeni budur.

DMARC kaydı yoksa, From: satırında otelinizin tam adresi duran bir sahte ileti her denetimden geçer. Alıcıya, doğrulanmamış bir iletiyle ne yapılacağını söyleyen hiçbir şey yoktur; posta kutusu kendi tahminine kalır. Bu tahmin çoğu zaman dolandırıcının lehine sonuçlanır, çünkü sahte ileti ikna edici yazılmıştır.

Kimlik doğrulama bir spam filtresi değildir. Gönderene güvenilip güvenilmediğine karar verir; içeriğin istenip istenmediğine değil. Google'ın yönergeleri ayrıca gönderenlerden, Postmaster Tools'ta görünen spam oranını %0,3'ün altında tutmalarını istiyor (Gmail Help, 81126 numaralı yanıt, 2026); bu kayıtlarla değil içerik ve liste kalitesiyle ilgili bir konudur. Ayrıca OTA extranet hesaplarından gönderilen sahte rezervasyon mesajları ayrı bir sorundur ve ayrı bir çözümü vardır; kimlik doğrulama bunlara hiçbir şey yapmaz.

Oteliniz adına kimler e-posta gönderiyor? Gönderen envanteriyle başlayın#

Tek bir kayda dokunmadan önce, From: satırına alan adınızı yazan her sistemi listeleyin; çünkü göndereni bilmeden yayımladığınız bir kayıt, o göndereni kilitleyecektir.

Her gönderen için altı şey kaydedin: sistemin adı, satıcısı, From: satırındaki tam alan adı (ana alan adı mı, alt alan adı mı), misafirlere mi personele mi yazdığı, kimlik bilgilerini kimin tuttuğu ve ayarlarını kimin değiştirebildiği. E-posta kimlik doğrulamanın işinin çoğu bu listedir, kayıtların kendisi değil. Bu listeyi ortaya koyamayan bir otel hiçbir şeyi güvenle zorunlu kılamaz.

Tipik maddeler arasında onay postaları gönderen otel işletim sistemi, rezervasyon motoru, bülten ve kampanya aracı, resepsiyon ve satış posta kutuları, muhasebe veya e-fatura göndericisi, web sitesi iletişim formu, anket aracı ve otel adına gönderim yapan acente sayılabilir. Sizin adınıza gönderenleri de not edin: bir grup merkez ofisi, temsilcilik acentesi veya kampanya ortağı From: satırına alan adınızı yazıyor olabilir ve her biri bu listeye aittir.

Her satıcıya yazılı olarak iki soru sorun: sizin için hangi SPF kaydını eklememiz gerekiyor ve DKIM seçiciniz (selector) ile anahtar uzunluğunuz nedir. İkisine de yanıt veremeyen bir satıcı, postası başarısız olacak satıcıdır. Yanıtları yazılı alın ki ilerde sözlerini hatırlatabilesiniz.

Pazarlama postaları için bir alt alan adı tercih edin. Ayrı bir alt alan adından gönderilen bülten kendi kayıtlarını ve kendi politikasını taşır; oradaki bir hata rezervasyon onaylarına hiç dokunmaz. Envanteri tarih ve sorumlu kişi adıyla yaşayan bir belge olarak tutun; bir onay postası gelmemeye başladığında ihtiyaç duyulan ilk şey budur.

Postalarınızı gönderen sistemler, misafir verisini tutan aynı sistemler olduğu için bu envanter, otelde siber güvenlik kontrol listesinin de parçası olmalıdır.

SPF, DKIM ve DMARC nedir, düz sözle?#

Üçü de internetin adres defteri olan alan adı sisteminde (DNS) duran kayıtlardır ve her biri iletiyle ilgili farklı bir soruyu yanıtlar.

SPF, DNS'te yayımlanan, o alan adı adına posta göndermesine izin verilen sunucuların listesidir. Alıcı sunucu, iletiyi teslim eden sunucuyu bu listeyle karşılaştırır. Bir alan adına bir SPF kaydı düşer, asla iki değil; ayrıca yapabileceği ek sorgu sayısında sabit bir üst sınır vardır, bu yüzden çok sayıda satıcı kaydını üst üste yığmak kaydı bozabilir. Bir otel dördüncü göndereni kontrol etmeden eklediğinde kaydın tamamı sessizce çalışmaz hâle gelebilir.

DKIM bir imzadır. Gönderen sistem her iletiyi özel bir anahtarla imzalar; eşleşen açık anahtar DNS'te bir seçici adının altında durur. Alıcı imzayı denetler; yolda değiştirilmiş bir ileti bu nedenle başarısız olur. Google, anahtarın en az 1024 bit olmasını şart koşuyor ve 2048 bit öneriyor (Gmail Help, 81126 numaralı yanıt, 2026).

DMARC bir politikadır. Alan adının altında sabit bir adda durur ve bir ileti, görünür From: alan adıyla SPF ve DKIM hizalamasının ikisinde de başarısız olduğunda alıcının ne yapacağını söyler: hiçbir şey yapma (none), şüpheli say (quarantine) ya da reddet. Ayrıca raporların nereye gönderileceğini belirtir; adınıza neler olduğunu bu sayede öğrenirsiniz.

Hizalama, üçünü birbirine bağlayan fikirdir. SPF veya DKIM, misafirin From: satırında gördüğü aynı alan adı için geçmelidir; iletideki başka bir alan adı için değil. DMARC, ikisinden en az birinin geçmesini ve hizalanmasını ister; ikisi de yoksa politikanın dayanacağı bir şey kalmaz ve ileti doğrulanmamış sayılır.

Üçünden hiçbiri bir şeyi şifrelemez veya içeriği okumaz. Yalnızca iki soruyu yanıtlar: bunu alan adı sahibinin izin verdiği biri mi gönderdi ve yolda değiştirildi mi.

Bir otel bunu hangi sırayla kurmalı?#

Önce her göndereni doğrulayın, sonra DMARC'ı izleme modunda yayımlayın, sonra sıkılaştırın. Bu sırayı tersine çevirmek, otellerin kendi onay postalarını kaybetme yoludur.

Birinci adım gönderen envanteridir. İkinci adım, listedeki her göndereni kapsayan tek bir SPF kaydıdır. Üçüncü adım, her gönderen için DKIM'nin açılması ve bir sonrakine geçmeden imzanın geçtiğinin doğrulanmasıdır. Dördüncü adım, rapor adresiyle birlikte "none" politikasında DMARC yayımlamak ve raporlar birikene kadar öyle bırakmaktır. Beşinci adım, raporlarda başarısız görünen meşru her kaynağı düzeltmek veya çıkarmaktır. Altıncı adım, raporlar temizlendiğinde karantinaya, ardından reddetmeye geçmektir.

Google'ın gönderen yönergeleri (Gmail Help, 81126 numaralı yanıt, 2026) Gmail hesaplarına gönderim yapan herkesten SPF veya DKIM kurmasını, günde 5.000 veya daha fazla ileti gönderenlerden ise ikisinin birlikte ve DMARC'la kurulmasını istiyor; DMARC politikasının "none" olması kabul ediliyor. Aynı kaynağa göre Google, Kasım 2025'ten bu yana kurallara uymayan trafiğe yaptırımı artırıyor ve şartları karşılamayan iletiler geçici veya kalıcı olarak reddedilebiliyor. Beklemek bir strateji değildir; kurallar uygulanmaya başlamıştır.

Bir geri alma notu tutun: her kaydın bir önceki tam değeri, kimin değiştirdiği ve ne zaman. Böylece bir hata bir gün değil dakikalar içinde geri alınır. Bir satıcıyla çalışmayı bıraktığınız gün kaydını silmeyin; önce o sistemden hâlâ bir şey gönderilmediğini doğrulayın. Ve yapabiliyorsanız işlem postaları ile pazarlama postalarını ayırın; ikisinin bozulma biçimleri ve itibarları farklıdır.

DMARC raporları BT sağlayıcınızla nasıl okunur?#

Raporlar, alan adınız adına posta gönderen her sunucuyu ve geçip geçmediğini listeleyen makine dosyalarıdır. Tek işlevi, hangi kaynakların tutulacağını ve hangilerinin durdurulacağını size söylemektir.

İki tür rapor gelir: büyük e-posta sağlayıcılarının çoğunun günlük gönderdiği toplu raporlar ve bazılarının gönderdiği, bazılarının göndermediği hata raporları. Toplu raporları esas alın, gerisini bonus sayın. Her kayıt, gönderen sunucunun adresini, iddia ettiği alan adını, kaç ileti gönderdiğini ve SPF ile DKIM'nin geçip geçtiğini ve hizalandığını gösterir.

Raporları üç liste olarak okuyun: tanıdığınız ve adını koyabildiğiniz kaynaklar; tanıdığınız ama unuttuğunuz kaynaklar (eski bir bülten aracı, rezervasyon motorunun test ortamı); ve açıklayamadığınız kaynaklar. Üçüncü liste ya unutulmuş bir sistemdir ya da sizin adınıza gönderen biridir. Ay sonunda ortaya çıkan kaynaklara dikkat edin: muhasebe, raporlama veya yedekleme sistemleri zamanlanmış görevle gönderiyor olabilir.

Sağlayıcıdan tek sayfalık bir aylık özet isteyin: her kaynak, sahibi, geçti veya kaldı, alınan önlem. Kimsenin okumadığı ham bir dosya hiçbir şeyi korumaz. Raporlar "none" politikasında bile gelir; izleme aşamasının var olmasının ve saatler değil haftalar sürmesinin nedeni tam olarak budur.

Rapor sözlüğü yabancıysa, oltalama, fidye yazılımı ve iki adımlı doğrulamayla aynı düz dil disiplini geçerlidir: terimler azdır ve her biri somut bir şeyi adlandırır.

Onay e-postası misafir tarafından nasıl kontrol edilir?#

Elinizdeki bir posta kutusuna gerçek bir onay gönderin, iletinin özgün başlıklarını açın ve üç satırı okuyun: spf, dkim ve dmarc.

Gmail'de "özgün iletiyi göster" görünümü kimlik doğrulama sonuçlarını verir; Outlook'ta ileti başlıklarında aynı satırlar durur. BT sağlayıcınızdan bunu bir kez birlikte yapmasını isteyin, sonra alışkanlık hâline getirin. spf=pass, dkim=pass ve dmarc=pass arayın; sonuçlardaki alan adının misafirin gördüğü alan adı olduğunu, satıcının alan adı olmadığını denetleyin.

Görünür From: adını ve adresini, yanıtlanacak (reply-to) adresi ve bağlantıların satıcının ya da kısaltılmış bir adresin değil otelinizin alan adına işaret ettiğini kontrol edin. Ardından yalnızca kaydı değil, yolculuğu denetleyin: akşam geç bir saatte telefondan web sitesinden rezervasyon yapın ve onayın bir dakika içinde gelip gelmediğini, küçük ekranda düzgün görünüp görünmediğine bakın. Pazarlama postaları için görünür bir abonelikten çıkma bağlantısı ve tek tıkla çıkma özelliğini doğrulayın; Google'ın yönergeleri toplu gönderenlerden bunları istiyor (Gmail Help, 81126 numaralı yanıt, 2026).

Satıcı, alan adı veya DNS barındırıcısı her değiştiğinde ve bunların dışında üç ayda bir kontrolü yineleyin. Sonucu tarihle birlikte kaydedin ki bir şey bozulduğunda neyin ne zaman değiştiğini bilin.

Aynı deneyim, varış öncesi misafir mesajlarınızın yalnızca gönderildiğini değil, gerçekten ulaştığını da söyler.

Alan adını ve DNS ayarlarını kim tutmalı?#

Alan adı kaydını ve DNS ayarlarına doğrudan erişimi otel tutmalıdır. Ajans yetkilendirilmiş erişimle çalışmalı, asla sahiplikle değil.

Alan adını otel şirketi adına, otelin denetlediği bir kayıt kuruluşu hesabında ve otelin kendi sahibi olduğu bir iletişim adresiyle kaydedin. Kayıt kuruluşuna ve DNS barındırıcısına otelden en az iki kişinin girebilmesini sağlayın; yenileme tarihlerini ve aktarım kilidini yazılı bir kayda alın. Ajansa, ihtiyaç duyduğu kayıtlara erişimi olan kendi hesabını verin ki ilişki değiştiğinde bu erişim tek adımda kaldırılabilsin.

Bir değişiklik günlüğü tutun: tarih, kayıt, eski değer, yeni değer, yapan kişi, neden. Kimlik doğrulama bozulmalarının neredeyse tamamı, iyi niyetli birinin kayda geçirmemiş bir değişikliğidir. DMARC politikasını değiştirebilecek tek bir kişi belirleyin ve değişiklikten önce günlük kaydının girilmesini isteyin, sonra değil. İlişki biterse alan adı, DNS bölgesi ve kayıtlar otelde kalır; ihtiyaç duymadan önce onlara hâlâ erişebildiğinizi sınayın.

Şimdi ne yapmalı#

Bu hafta gönderen envanterini yazın ve üzerindeki her satıcıya aynı iki soruyu gönderin: sizin için hangi SPF kaydını eklememiz gerekiyor ve DKIM seçiciniz nedir. Ardından DMARC'ı "none" politikasıyla yayımlayın ve sıkılaştırmadan önce bir ay raporları okuyun. Kayıtların kendisi küçüktür; asıl iş, arkalarındaki gönderen listesidir ve onay postasının ulaşmasını ve sahtenin ulaşmamasını belirleyen kısım odur.