Bagaimana kami mengkonfigurasi area DNS TXT untuk SPF, DKIM dan DMARC dan bagaimana kami menghindari pesan email bisnis ditolak oleh Gmail – Pengiriman surat gagal

Administrator dari email pribadi yang parah untuk bisnis sering menghadapi banyak permasalahan dan tantangan. Dari gelombang SPAM yang harus diblokir oleh filter tertentu, keamanan korespondensi di server email lokal dan server jarak jauh, Konfigurasi dan memantau layanan SMTP, POP, IMAP, ditambah banyak lagi detail lainnya Konfigurasi SPF, DKIM dan DMARC untuk mematuhi praktik yang baik dalam mengirim pesan email yang aman.

Banyak masalah mengirim pesan email atau penerima barang ke / dari penyedia Anda, muncul karena konfigurasi area yang salah DNS, bagaimana dengan layanan email.

Agar email dapat dikirim dari nama domain, itu harus dihosting di server email dikonfigurasi dengan benar, dan nama domain harus memiliki zona DNS untuk SPF, MX, DMARC DAN DKIM diatur dengan benar di manajer DNS TXT dari domain.

Dalam artikel hari ini kita akan fokus pada masalah yang cukup umum server email pribadi untuk bisnis. Ketidakmampuan mengirim pesan email ke akun Gmail, Yahoo! atau iCloud.

Pesan yang dikirim ke @Gmail.com otomatis ditolak. “Pengiriman email gagal: mengembalikan pesan ke pengirim”

Saya baru-baru ini mengalami masalah pada domain email perusahaan, dari mana pesan email dikirim secara teratur ke perusahaan lain dan individu, beberapa di antaranya memiliki alamat @gmail.com. Semua pesan yang dikirim ke akun Gmail segera dikembalikan ke pengirimnya. “Pengiriman email gagal: mengembalikan pesan ke pengirim”.

Pesan kesalahan dikembalikan ke server email aktif Exim terlihat seperti ini:

1nSeUV-0005zz-De ** [email protected] R=dnslookup T=remote_smtp H=gmail-smtp-in.l.google.com [142.x.x.27] X=TLS1.2:ECDHE-ECDSA-AES128-GCM-SHA256:128 CV=yes: SMTP error from remote mail server after pipelined end of data: 550-5.7.26 This message does not have authentication information or fails to\n550-5.7.26 pass authentication checks. To best protect our users from spam, the\n550-5.7.26 message has been blocked. Please visit\n550-5.7.26  https://support.google.com/mail/answer/81126#authentication for more\n550 5.7.26 information. d3-20020adff843000000b001f1d7bdaeb7si6107985wrq.510 - gsmtp

Dalam skenario ini, ini bukanlah sesuatu yang sangat serius, seperti termasuk nama domain pengirim atau IP pengirim dalam daftar SPAM global atau o kesalahan konfigurasi besar layanan email di sevrer (Exim).
Bahkan jika banyak orang, ketika mereka melihat pesan ini, langsung memikirkan kesalahan konfigurasi SPAM atau SMTP, masalahnya disebabkan oleh area tersebut DNS TXT dari lapangan. Seringkali, DKIM tidak dikonfigurasi di zona DNS atau tidak dimasukkan dengan benar di pengelola DNS domain. Masalah ini sering ditemui oleh mereka yang menggunakannya CloudFlare sebagai Manajer DNS dan lupa melewatinya DNS TXT: mail._domainkey (DKIM), DMARC dan SPF.

Seperti yang diberitahukan dalam pesan penolakan dari Gmail, keaslian dan otentikasi domain pengirim telah gagal. “This message does not have authentication information or fails to\n550-5.7.26 pass authentication checks.”. Artinya domain tersebut tidak memiliki DNS TXT yang dikonfigurasi untuk memastikan kredibilitas server email penerima. Gmail, dalam skenario kami.

Saat kami menambahkan domain web dengan layanan email aktif di cPanel atau VestaCP, file dari zona DNS domain masing-masing secara otomatis dibuat. Zona DNS yang juga berisi konfigurasi layanan email: MX, SPF, DKIM, DMARC.
Dalam situasi di mana kita memilih domain untuk menjadi pengelola DNS CloudFlare, zona DNS dari akun hosting domain, harus disalin ke CloudFlare agar domain email berfungsi dengan benar. Itulah masalah dalam skenario di atas. Di pengelola DNS pihak ketiga, tidak ada entri DKIM, meskipun ada di pengelola DNS server lokal.

Apa itu DKIM dan mengapa email ditolak jika kita tidak memiliki fitur ini di domain email?

Email Teridentifikasi DomainKeys (DKIM) adalah solusi standar untuk otentikasi domain email, yang menambahkan a tanda tangan digital untuk setiap pesan yang dikirim. Server tujuan dapat memeriksa melalui DKIM apakah pesan tersebut berasal dari domain sah pengirim dan bukan dari domain lain yang menggunakan identitas pengirim sebagai topeng. Tentu saja, jika Anda memiliki domainnya abcdqwerty.com tanpa DKIM, pesan email dapat dikirim dari server lain menggunakan nama domain Anda. Itu jika Anda menginginkan pencurian identitas, yang dalam istilah teknis disebut pemalsuan email.
Teknik umum ketika pesan email dikirim melalui phishing dan spam.

Melalui DKIM juga dapat dipastikan, isi pesan tidak diubah setelah dikirim oleh pengirim.

Dengan mengatur DKIM dengan benar di server host sistem email dan di zona DNS, kemungkinan pesan Anda sampai ke penerima dalam SPAM atau tidak sampai sama sekali dihilangkan.

Contoh DKIM adalah:

mail._domainkey: "v=DKIM1; k=rsa; p=MIGfMA0GCSqGfdSIb3DQEBAQUAA4GN ... ocqWffd4cwIDAQAB"

Tentu saja nilai DKIM yang didapat Algoritma enkripsi RSA itu unik untuk setiap nama domain dan dapat dibuat ulang dari server host layanan email.

Telah menginstal dan mengatur DKIM dengan benar DNS TXT pengelola, sangat mungkin untuk mengatasi masalah pesan yang dikembalikan ke akun Gmail. Setidaknya untuk kesalahannya “Pengiriman surat gagal”:

“Kesalahan SMTP dari server email jarak jauh setelah akhir data yang disalurkan: 550-5.7.26 Pesan ini tidak memiliki informasi autentikasi atau gagaln550-5.7.26 lulus pemeriksaan autentikasi. Untuk melindungi pengguna kami dari spam, pesann550-5.7.26 telah diblokir.”

Sebagai rekap singkat, DKIM menambahkan tanda tangan digital pada setiap pesan yang dikirim, yang memungkinkan server tujuan memverifikasi keaslian pengirim. Jika pesan tersebut berasal dari perusahaan Anda dan alamatnya tidak digunakan oleh pihak ketiga untuk menggunakan identitas Anda.

Gmail (Google) bisa secara otomatis menolak semua pesan yang berasal dari domain yang tidak memiliki tanda tangan digital DKIM tersebut.

Apa itu SPF dan mengapa penting untuk mengirim pesan email dengan aman?

Serta DKIM, dan SPF bertujuan untuk mencegah pesan phishing dan pemalsuan email. Dengan cara ini, pesan terkirim tidak lagi ditandai sebagai spam.

Kerangka Kebijakan Pengirim (SPF)adalah metode standar untuk mengautentikasi domain tempat pesan dikirim. Entri SPF sudah diatur manajer DNS TXT domain Anda dan dalam entri ini akan ditentukan nama domain, IP atau domain yang berhak mengirim pesan email menggunakan nama domain Anda atau organisasi Anda.

Domain tanpa SPF dapat memungkinkan pelaku spam mengirim pesan email dari server lain, menggunakan nama domain Anda sebagai topeng. Dengan cara ini mereka bisa menyebar informasi palsu atau data sensitif mungkin diminta atas nama organisasi Anda

Tentu saja, pesan masih dapat dikirim atas nama Anda dari server lain, namun pesan tersebut akan ditandai sebagai spam atau ditolak jika server atau nama domain tersebut tidak ditentukan dalam entri SPF TXT domain Anda.

Nilai SPF di manajer DNS terlihat seperti ini:

@ : "v=spf1 a mx ip4:x.x.x.x ?all"

Di mana “ip4” mewakili IPv4 server email Anda.

Bagaimana cara menetapkan SPF untuk beberapa domain?

Jika kami ingin mengotorisasi domain lain untuk mengirim pesan email atas nama domain kami, kami akan menentukannya dengan nilainya “include” dalam SPF TXT:

v=spf1 ip4:x.x.x.x include:example1.com include:example2.com ~all

Artinya, pesan email dapat dikirim dari nama domain email kami dan dari example1.com dan example2.com.
Ini adalah catatan yang sangat berguna jika kita memiliki, misalnya, satu Majalah online di alamatnya “contoh1.com“, tapi kami ingin pesan dari toko online ke pelanggan berasal alamat domain perusahaan, makhluk ini “contoh.com“. Di dalam SPF TXT untuk “contoh.com”, karena kita perlu menentukan bersama dengan IP dan “termasuk:example1.com”. Sehingga pesan dapat dikirimkan atas nama organisasi.

Bagaimana cara mengatur SPF untuk IPv4 dan IPv6?

Kami memiliki server email dengan keduanya IPv4 juga IPv6, sangat penting bahwa kedua IP ditentukan dalam SPF TXT.

v=spf1 ip4:196.255.100.26 ip6:2001:db8:8:4::2 ~all

Selanjutnya, setelahnya “aku p” arahan dapat digunakan “include” untuk menambahkan domain yang diotorisasi untuk pengiriman.

Apa artinya ini “~all“, “-all” dan “+all” bir SPF?

Seperti yang saya katakan di atas, ISP masih dapat menerima pesan email atas nama organisasi Anda meskipun dikirim dari domain atau IP yang tidak ditentukan dalam kebijakan SPF. Label “semua” memberi tahu server tujuan cara menangani pesan ini dari domain lain yang tidak diotorisasi dan mengirimkan pesan atas nama Anda atau organisasi Anda.

~all : Jika pesan diterima dari domain yang tidak terdaftar di SPF TXT, pesan tersebut akan diterima di server tujuan, namun akan ditandai sebagai spam atau mencurigakan. Mereka akan tunduk pada praktik filter anti-spam yang baik dari penyedia penerima.

-all : Ini adalah tag paling ketat yang ditambahkan ke entri SPF. Jika domain tidak terdaftar, pesan akan ditandai sebagai tidak sah dan akan ditolak oleh penyedia. Itu bahkan tidak akan dikirim ke spam.

+all : Sangat jarang digunakan dan sama sekali tidak disarankan, tag ini memungkinkan orang lain mengirim pesan email atas nama Anda atau organisasi Anda. Kebanyakan penyedia secara otomatis menolak semua pesan email yang berasal dari domain dengan SPF TXT “+all“. Justru karena keaslian pengirimnya tidak bisa diverifikasi, hanya setelah dilakukan verifikasi oleh “tajuk email”.

Ringkasan: Apa itu Kerangka Kebijakan Pengirim (SPF)?

• Cacat & Hapus cache DNS – Windows 7, Vista & Xp
• Gunakan server alternatif DNS untuk pemuatan halaman web yang lebih cepat
• Bagaimana kita bisa mengubah alamat DNS di OS X
• Bagaimana kita bisa mereset Cache DNS di OS X
• Meningkatkan kecepatan penelusuran internet dengan DNS publik Google

Ini memberi otorisasi, melalui zona DNS TXT / SPF, IP dan nama domain yang dapat mengirim pesan email dari domain Anda atau perusahaan Anda. Hal ini juga menerapkan konsekuensi yang berlaku pada pesan yang dikirim dari domain tidak sah.

Apa itu DMARC dan mengapa penting untuk server email?

DMARC (Pelaporan dan Kesesuaian Otentikasi Pesan Berbasis Domain) berkaitan erat dengan standar kebijakan SPF dan DKIM.
DMARC adalah sistem validasi dirancang untuk melindungi nama domain email Anda atau perusahaan, praktik seperti spoofing email dan penipuan phishing.

Menggunakan standar kontrol SPF (Sender Policy Framework) dan DKIM (Domain Keys Identified Mail), DMARC menambahkan fitur yang sangat penting. laporan.

Ketika pemilik domain mempublikasikan DMARC di zona DNS TXT, dia akan mendapatkan informasi tentang siapa yang mengirim pesan email atas namanya atau atas nama perusahaan pemilik domain yang dilindungi SPF dan DKIM. Pada saat yang sama, penyedia penerima pesan akan mengetahui apakah dan bagaimana kebijakan praktik terbaik ini dipantau oleh pemilik domain pengirim.

Data DMARC di DNS TXT dapat berbentuk:

V=DMARC1; rua=mailto:[email protected]; ruf=mailto:[email protected]; p=none; sp=none; fo=0;

Di DMARC, beberapa kondisi pelaporan insiden dapat diatur, serta alamat email tujuan pengiriman analisis dan laporan. Disarankan untuk menggunakan alamat email khusus untuk DMARC karena volume pesan yang diterima bisa sangat besar.

Tag DMARC dapat diatur sesuai dengan kebijakan yang diberlakukan oleh Anda atau organisasi:

v – versi protokol DMARC yang ada.
p – terapkan kebijakan ini ketika verifikasi DMARC untuk pesan email tidak dapat dilakukan. Itu dapat memiliki arti: “none“, “quarantine” atau “reject“. Itu digunakan “none” untuk mendapatkan laporan tentang aliran pesan dan statusnya.
rua – Ini adalah daftar URL yang dapat dikirimi umpan balik oleh ISP dalam format XML. Jika kita menambahkan alamat email di sini, linknya akan berbentuk: “rua=mailto:[email protected]” .
ruf – Daftar URL tempat ISP dapat mengirimkan laporan insiden cyber dan kejahatan yang dilakukan atas nama organisasi Anda. Alamatnya akan berbentuk: “ruf=mailto:[email protected]“.
rf – Format pelaporan kejahatan dunia maya. Itu bisa dibentuk “afrf” atau “iodef“.
pct – Memberi tahu penyedia Internet/ISP untuk menerapkan kebijakan DMARC hanya pada persentase tertentu dari pesan yang gagal. Misalnya, kita dapat memiliki: “pct=50%” atau kebijakan “quarantine” dan “reject“. Itu tidak akan pernah diterima “none“.
adkim – Menentukan “Mode Penyelarasan” untuk tanda tangan digital DKIM. Artinya, kecocokan tanda tangan digital entri DKIM dengan domain telah diperiksa. adkim dapat memiliki nilai: r (Relaxed) atau s (Strict).
aspf – Dengan cara yang sama seperti dalam kasus ini adkim ditentukan “Mode Penyelarasan” untuk SPF dan mendukung nilai yang sama. r (Relaxed) atau s (Strict).
sp – Kebijakan ini berlaku untuk mengizinkan subdomain yang berasal dari domain organisasi menggunakan nilai DMARC domain tersebut. Hal ini menghindari penggunaan kebijakan terpisah untuk setiap domain individual. Ini pada dasarnya adalah a “karakter pengganti” untuk semua subbidang.
ri – Nilai ini menetapkan interval penerimaan laporan XML untuk DMARC. Seringkali, pelaporan lebih baik dilakukan setiap hari.
fo – Opsi pelaporan penipuan. “Opsi forensik“. Mereka dapat memiliki nilai-nilai tersebut “0” untuk melaporkan insiden ketika verifikasi SPF dan DKIM gagal, atau nilainya “1” untuk skenario dimana SPF atau DKIM tidak ada atau tidak lolos pemeriksaan.

Jadi, untuk memastikan pesan email Anda atau perusahaan Anda sampai ke penerima di Kotak Masuk, ketiga standar komunikasi ini perlu diperhatikan. “praktik terbaik untuk mengirim pesan email“. DKIM, SPF dan DMARC. Ketiga standar ini milik DNS TXT dan dapat dikelola dari manajer DNS domain.