Bir web sitesindeki iletişim formu ekranda “Gönderildi” diyebilir; bu ifade tek başına bildirimin doğru posta kutusuna ulaştığını kanıtlamaz. Form verisi kaydedilmiş, uygulama bir e-posta isteği oluşturmuş, gönderici sunucu mesajı kabul etmiş olabilir; sonraki aktarımda ileti ertelenmiş, reddedilmiş ya da istenmeyen posta klasörüne düşmüş olabilir. Ulus Web Tasarım hizmetini değerlendiren işletmeler için rehber, bildirim e-postasının kurulumu ve kabul ölçütlerini ele alır; bölgede ofis veya müşteri iddiasında bulunmaz.

Buradaki kapsam, ziyaretçinin formu nasıl dolduracağını veya hangi alanların sorulacağını seçmek değildir. Bu konular için iletişim formu tasarımı rehberine bakabilirsiniz. Burada odak; form verisinin kaydı, e-posta servisinin yanıtı, alan adı kimlik doğrulaması ve işletmenin gerçek posta kutusunda yaptığı teslim kontrolüdür. Birinin başarılı görünmesi diğerini doğrulamaz.

Önce “başarılı” durumunun neyi kanıtladığını tanımlayın

Bir form akışında en az dört ayrı olay bulunabilir: tarayıcı isteği gönderir; site uygulaması doğrulama yapıp talebi kaydeder; posta bileşeni gönderim isteğini e-posta hizmetine iletir; alıcı altyapısı mesajı kabul eder ve posta kutusu kuralları iletiyi bir klasöre yerleştirir. Site, yalnız kendi denetleyebildiği ilk adımları güvenle bildirmelidir. Örneğin kayıt oluşmuş, fakat e-posta gönderim servisi yanıt vermemişse ekranda “Talebiniz alındı” demek daha doğru olabilir; “E-posta ekibe ulaştı” demek için ayrı kanıt gerekir.

Akış tablosunda olay, oluştuğu sistem, zaman veya kimlik, başarısızlık mesajı ve inceleme rolü bulunsun. Ziyaretçi mesajını sade tutun; ekip kaydında gereksiz kişisel içerik yerine form kimliği, zaman ve hata sınıfı yeterli olabilir. E-posta gövdesini günlük kaydına kopyalamayın.

Gönderici adresini ve yanıt adresini ayrı düşünün

Bir bildirimde ziyaretçinin adresini “Gönderen” gibi kullanmak kolay görünür, fakat sistem bu alan adına mesaj gönderme yetkisine sahip olmayabilir. Daha yönetilebilir bir tasarımda gönderen kimliği, işletmenin kontrol ettiği ve gönderim hizmetinin yetkilendirildiği alan adı üzerinde kalır; ziyaretçinin verdiği adres, yanıt gerekiyorsa yanıt adresi olarak değerlendirilir. Bu ayrım, mesajın hangi sistem adına gönderildiğini alıcıya daha tutarlı gösterir. Yine de tek başına teslim garantisi değildir; posta sağlayıcısının kuralları, alan adı ayarları ve alıcı politikaları sonucu etkiler.

Teslim notunda görünen ad, “From” ve yanıt adresi, gönderim hizmeti, ekip alıcısı ve kullanıcıya kopya gönderilip gönderilmeyeceği yazsın. Ziyaretçi adresini kontrolsüz biçimde gönderen adresine çevirmeyin. Testte ileti başlıklarını ve yanıt düğmesinin hedefini doğrulayın.

SPF, DKIM ve DMARC birbirinin yerine geçmez

SPF, alan adı sahibinin hangi gönderim sunucularına yetki verdiğini DNS üzerinden duyurmasına dayanır. Gönderim hizmeti değiştiğinde mevcut SPF kaydına ikinci, çakışan bir SPF satırı eklemek yerine alan adı yöneticisiyle geçerli gönderen listesini gözden geçirin. Yetkilendirilmemiş bir gönderici kayıt dışında kalırsa alıcı denetimi başarısız olabilir. SPF değerlendirmesi iletinin görünen “From” alanına bakarak yapılmaz; teknik olarak hangi gönderen kimliğinin kullanıldığı ve aktarım zinciri önem taşır.

DKIM, giden iletiye gönderici alan adının özel anahtarıyla imza eklenmesini ve alıcının DNS’te yayımlanmış açık anahtarla bu imzayı doğrulamasını sağlar. Seçici adı ve imzayı açma adımları sağlayıcıya bağlıdır. Sağlayıcı değişirse eski/yeni anahtar geçişini ve eski kaydın kaldırılma zamanını kendi yönergesine göre planlayın. İletinin imzalı olması, içeriğin alıcı tarafından mutlaka gelen kutusuna konacağı anlamına gelmez.

DMARC, görünen gönderen alan adı ile SPF veya DKIM doğrulamasında kullanılan alan adları arasındaki uyumu ve alan adı sahibinin başarısız doğrulamalar için beyan ettiği politikayı ele alır. IETF’nin güncel DMARC standardı RFC 9989’dur; önceki RFC 7489’un yerini alır. Eski kurulum notlarını aynen uygulamak yerine güncel sağlayıcı ve standart dokümanını kontrol edin. Google’ın gönderici yönergeleri kendi alıcıları için kimlik doğrulama ve alan adı uyumunu açıklar. Bir denetimde “geçti” görülmesi her hedefe teslim anlamına gelmez.

DNS değişikliği, yalnız web tasarım ekranından yapılan bir metin düzenlemesi değildir. Alan adının DNS yönetim yetkisinin kimde olduğunu, mevcut posta ve web kayıtlarını kimin koruduğunu, değişiklik öncesi ve sonrası hangi kayıtların karşılaştırılacağını ve geri alma sorumlusunu belirleyin. Sağlayıcının verdiği SPF içeriğini gelişigüzel başka örnekle değiştirmeyin; bütün geçerli göndericileri dışarıda bırakmak, işletmenin başka mesaj akışlarını etkileyebilir. Aynı alan adından birden fazla uygulama gönderiyorsa tümünü listeleyin.

Teknik kabulü katman katman sınayın

Önce formu yayımlanmamış veya kontrollü bir deneme adresinde deneyin. Gönderimden sonra ekranda görünen mesajı, talebin gerçekten kaydedildiğini ve ekibin kuyruğunda görülebildiğini ayrı ayrı kontrol edin. Ardından e-posta hizmetinin yanıtını izleyin: bir ileti kimliği, gönderim zaman damgası veya belgelenmiş kabul/ret sonucu var mı? Bu kayıt, “posta kutusuna ulaştı” kanıtı değildir; yalnızca hizmetin hangi aşamada ne yanıt verdiğini gösterir. Alıcı posta kutusunda gelen, istenmeyen posta, karantina ve yönlendirme kuralları ayrıca gözden geçirilmelidir.

Deneme listesini işletmenin gerçek akışına göre belirleyin: ekip içi posta kutusu; farklı bir posta sağlayıcısındaki kontrollü alıcı; Türkçe karakter içeren ad ve konu; yinelenen gönderim; eksik zorunlu alan; servis kesintisi veya başarısızlık yanıtı. Her örnekte kişisel veriyi gereksiz yere kullanmayın ve gerçek müşteri başvurularını test verisi olarak kopyalamayın. Deneme adreslerini sonuç kaydında maskeleyebilir, mesaj içeriğini değil durum ve kimlik bilgisini saklayabilirsiniz. Test e-posta sağlayıcılarının deneme sınırları olduğundan, seri denemeleri sağlayıcı koşullarını kontrol etmeden çalıştırmayın.

Canlıya geçiş kullanıcı turu; mesajın anlaşılır olup olmadığını, hatadan dönüşü ve tamamlanma durumunu birlikte sınamak için yardımcı olabilir. İçerik güncellendiğinde alıcı adresi veya sorumlu ekip değişmiş olabilir; web sitesi içerik bakımı rehberindeki sahiplik yaklaşımı bildirim bilgisinin güncel kalmasına da uygulanabilir.

Hata belirtisini doğru katmana yönlendirin

Hiçbir kayıt oluşmadıysa sorun form doğrulaması, sunucu isteği veya kayıt katmanında olabilir. Kayıt var fakat gönderim isteği yoksa uygulama ile e-posta servisi arasındaki bağlantıyı inceleyin. Servis gönderim isteğini reddediyorsa dönen kodu ve sağlayıcı yapılandırmasını yetkili teknik ekibe iletin. Servis mesajı kabul etmiş görünüyorsa fakat alıcı bulamıyorsa e-posta başlıkları, kimlik doğrulama sonuçları, yönlendirme, karantina ve alıcı politikaları araştırılır. Aynı gözlemi her durumda “spam filtresi” diye adlandırmak, gerçek hata yerini saklar.

Kayıtta hata kodu, sağlayıcı olay kimliği, zaman, gönderici alan adı ve test ortamı bulunsun. Kimlik bilgisi, ileti içeriği veya parolayı ekran görüntüsüne eklemeyin. Hata bir üçüncü taraf servis tarafından dönmüşse, kodu kendi kelimelerinizle yorumlamadan önce sağlayıcının o kod için yayımladığı açıklamayı kontrol edin. Destek kaydı tekrarlanabilir olmalı; kullanıcının özel mesajını gereksiz kişilere açmamalıdır.

İşletme ve teknik ekip için teslim listesi oluşturun

Uygulama tarafında kimin bildirim alacağı, yedek iletişim yolunun bulunup bulunmadığı ve başarısız gönderimde form kaydının korunup korunmadığı işletme kararıdır. Alan adı DNS kayıtlarını değiştirme yetkisi, SMTP veya API anahtarlarını saklama, hizmet paneline erişim ve hata günlüklerinin saklama süresi ise görev ve güvenlik sorumluluğu belirlenerek yürütülmelidir. Tasarım tesliminde parola veya gizli anahtarları belgeye eklemeyin; erişimi yetki sistemi üzerinden verin. Bu, site devredildiğinde hesap sahipliğini ve kapatılacak erişimleri görünür kılar.

Kabul belgesinde en az şu maddeleri yazın: test formunun adresi ve sürümü; kayıt oluştuğunu doğrulayan kanıt; kullanılan gönderici hizmeti; SPF, DKIM ve DMARC denetiminin hangi tarihte ve hangi alan adı için yapıldığı; gönderim hizmetinin verdiği sonuç; alıcı posta kutusunda yapılan gözlem; başarısızlık halinde kullanıcıya gösterilen ifade; takip sorumlusu ve tekrar test tarihi. “Her e-postanın teslimi garanti” demeyin; alıcı sistemleri ayrı karar verir.

Sık Sorulan Sorular

Formda başarı mesajı görünüyorsa bildirim e-postası da teslim edilmiş midir?

Her zaman değil. Başarı mesajı, tasarımına göre yalnızca tarayıcı isteğinin işlendiğini veya talebin siteye kaydedildiğini anlatabilir. E-posta hizmetinin isteği kabul etmesi ve alıcı sunucunun mesajı işlemesi ayrı adımlardır. İşletme, kullanıcıya hangi olayın gerçekleştiğini açıkça söylemeli; “ekibe ulaştı” ifadesini ancak bu iddiayı destekleyen kayıt ve kontrol varsa kullanmalıdır.

SPF, DKIM ve DMARC kayıtlarını kim eklemeli?

DNS yetkisi bulunan alan adı yöneticisi ve kullanılan gönderim hizmetini bilen teknik sorumlu birlikte çalışmalıdır. Web sitesi tasarımcısının, işletmenin mevcut e-posta göndericilerini bilmeden kayıt değiştirmesi doğru bir varsayım değildir. Önce web sitesi, ekip posta kutuları ve üçüncü taraf bildirim servisleri dahil göndericileri listeleyin; sonra sağlayıcının güncel yönergesini ve mevcut DNS kayıtlarını karşılaştırın. Değişiklik sonrası test ve geri alma sorumlusunu yazın.

SPF kaydında her servis için ayrı TXT satırı açabilir miyim?

Bir alan adı için birden çok SPF politikası çakışmaya yol açabilir. Gönderim hizmetlerinin talimatlarını tek kayıt yaklaşımında nasıl birleştireceğinizi DNS sorumlusuyla doğrulayın; rastgele “include” değerleri eklemeyin. SPF değerlendirmesinin sınırları ve geçişte dikkat edilmesi gerekenler RFC 7208’de açıklanır. Var olan kayıt başka iş akışlarına da hizmet edebileceği için düzenlemeden önce yedek alın ve gerçek gönderimleri kapsadığını kontrol edin.

DKIM imzası başarılıysa e-posta mutlaka gelen kutusuna düşer mi?

Hayır. DKIM, imzalayan alan adıyla iletinin ilişkisini doğrulamak için kullanılır; alıcının gelen kutusu kararı tek başına bu imzaya dayanmaz. Alıcı politikaları, ileti içeriği, itibar, yönlendirme ve kullanıcı kuralları da rol oynayabilir. Deneme sırasında ileti başlıklarındaki doğrulama sonucunu inceleyin, ardından alıcı posta kutusu ve klasörlerini ayrıca kontrol edin. Bir tek test sonucu bütün alıcıları temsil etmez.

DMARC politikası ne zaman daha kısıtlayıcı hale getirilmelidir?

Bu karar, alan adı adına gönderim yapan bütün hizmetlerin belirlenmesine ve DMARC raporlarının anlaşılmasına bağlıdır. Bilinmeyen veya meşru göndericiler varken daha kısıtlayıcı politika bazı mesajların reddedilmesine ya da karantinaya alınmasına neden olabilir. RFC 9989 ve sağlayıcının güncel belgeleri incelenmeli; SPF kaydı düzenli gözden geçirilmeli ve değişiklik planı yetkili alan adı yöneticisiyle yapılmalıdır. Hazır şablonu doğrudan kopyalamak yeterli bir değerlendirme değildir.

Hizmet “gönderildi” diyorsa alıcıya ulaştığını nasıl anlarım?

“Gönderildi” ifadesinin sağlayıcıda ne anlama geldiğini belgeleyin: API isteğinin kabulü, SMTP aktarımı veya alıcı sunucudan gelen yanıt farklı durumlar olabilir. Sağlayıcı olay kaydı ve ileti kimliğiyle hedef posta kutusunu, istenmeyen posta klasörünü ve varsa karantina kayıtlarını kontrol edin. Alıcının sunucusu kabul etti bilgisi bile kullanıcının gelen kutusunda görünme garantisi vermez; gerekiyorsa test alıcısıyla başlık incelemesi yapın.

Form bildirimi için işletme adresini mi, ziyaretçinin adresini mi kullanmalıyım?

Gönderici adresi genellikle işletmenin veya yetkilendirilmiş hizmetin kontrol ettiği alan adıyla tutarlı olmalıdır. Ziyaretçinin verdiği adres, yanıt gerekiyorsa yanıt adresi olarak kullanılabilir; ancak sistem adına gönderme yetkisi varmış gibi “From” alanına yerleştirilmemelidir. Kurulum, kullandığınız e-posta hizmetinin başlık ve doğrulama desteğine göre incelenmelidir. Deneme mesajında yanıtın beklenen adrese gittiğini teyit edin.

Test e-postası ulaşıyorsa canlı bildirim akışı tamam mı?

Tek test yalnız o adres, o zaman, o sürüm ve o sağlayıcı yanıtı hakkında kanıt verir. Canlı akışta kayıt, tekrar gönderim, hata yanıtı, ekip alıcısı, spam/karantina ve DNS değişikliği sonrası durum ayrıca sınanmalıdır. Kontrollü testte farklı alıcı türlerini ve başarısızlık senaryosunu da deneyin; gerçek başvuruları test verisi yapmayın. Kabul notunda hangi kontrollerin yapıldığını ve hangi sınırların açık kaldığını belirtin.