# การสแกนความปลอดภัยเว็บไซต์

URL: https://discuvr.org/security-scan/?hl=th
Last updated: 2026-11-07
MCP tool: `security_scan`

สแกนโดเมนเพื่อหาเฮดเดอร์ความปลอดภัยที่ขาดหาย ปัญหา TLS และไฟล์ที่เปิดเผย ทุกผลลัพธ์แสดงหลักฐานดิบและคำสั่งที่แน่นอนสำหรับทำซ้ำ

เครื่องมือสแกนจำนวนมากให้เกรดเป็นตัวอักษรพร้อมรายการคำที่ฟังดูน่ากลัว เครื่องมือนี้ก็ให้เกรดเช่นกัน แต่ทุกคะแนนที่หักผูกกับผลการตรวจที่แสดงคำตอบที่ได้รับจริงและคำสั่งบรรทัดเดียวที่ให้คำตอบเดียวกันกับคุณ ผลการตรวจจึงเป็นสิ่งที่คุณยืนยันได้ ไม่ใช่สิ่งที่ต้องเชื่อตาม

## การทำงาน

- ตรวจ DNS และ CAA, SPF และ DMARC, ใบรับรอง TLS และ TLS 1.0/1.1, การเปลี่ยนเส้นทางไป HTTPS, เฮดเดอร์ความปลอดภัย, แอตทริบิวต์คุกกี้, CORS, แบนเนอร์เวอร์ชัน, เมธอด HTTP, เนื้อหาผสม, พาธที่อ่อนไหว 23 รายการ, การแสดงรายการไดเรกทอรี, robots.txt, security.txt และพอร์ตบริการ 12 พอร์ต
- ผลการตรวจพบแต่ละรายการมีข้อสังเกตดิบและคำสั่ง shell สำหรับทำซ้ำ
- การตรวจสอบที่ไม่สามารถรันได้จะถูกรายงานว่า "ไม่ได้ตรวจสอบ" - ไม่ใช่การผ่านอย่างเงียบ ๆ
- รายงานดาวน์โหลดเป็น Markdown หรือ JSON

## วิธีใช้งาน

1. ป้อนโดเมนที่คุณรับผิดชอบ
2. การสแกนรันการตรวจสอบแบบพาสซีฟ - คำขอทั่วไป ไม่มีการโจมตี
3. อ่านผลการตรวจพบ แต่ละรายการพร้อมหลักฐาน และตรวจสอบรายการที่สำคัญ

## ไม่มีผลการตรวจพบที่ถูกสร้างขึ้น

เครื่องสแกนนี้ไม่มีโมเดลภาษาใดๆ ระดับความรุนแรง ผลกระทบ และวิธีแก้ถูกกำหนดไว้ตายตัวสำหรับแต่ละการตรวจ และผลการตรวจทุกข้อสร้างจากสิ่งที่สังเกตได้จริง รายงานบนหน้าจอและไฟล์ดาวน์โหลด Markdown และ JSON สร้างจากผลการตรวจชุดเดียวกัน โดยไม่มีโมเดลเกี่ยวข้องเลย

## เกรดคำนวณอย่างไร

คะแนนเริ่มที่ 100 และหัก 34 คะแนนต่อผลการตรวจระดับวิกฤต 13 ต่อระดับสูง 5 ต่อระดับกลาง และ 1.5 ต่อระดับต่ำ โดยแต่ละระดับมีเพดานรวม (สูง 45 กลาง 22 ต่ำ 9) ผลเชิงข้อมูลและผลที่ผ่านไม่หักคะแนน 90 ขึ้นไปคือ A ตั้งแต่ 75 คือ B ตั้งแต่ 60 คือ C ตั้งแต่ 40 คือ D ต่ำกว่านั้นคือ F ไฟล์ .env ที่เปิดเผยเพียงไฟล์เดียวหรือพอร์ตฐานข้อมูลที่เข้าถึงได้ ทำให้เว็บไซต์ที่สะอาดตกจาก 100 เหลือ 66 คือ C และผลแบบนี้สองข้อให้ 32 คือ F

## การหลีกเลี่ยงสัญญาณเตือนผิด

ก่อนลองพาธอย่าง /.git/HEAD หรือ /backup.sql เครื่องสแกนจะขอที่อยู่สุ่มที่ไม่มีทางมีอยู่จริงและบันทึกว่าเว็บไซต์ตอบอย่างไร พาธจะถูกรายงานว่าเปิดเผยก็ต่อเมื่อตอบ HTTP 200 แตกต่างจากคำตอบอ้างอิงแบบไม่พบนั้น และตรงกับลายเซ็นของไฟล์นั้นเอง เว็บไซต์ที่ตอบทุก URL ด้วยหน้าแรกจึงไม่เต็มไปด้วยผลระดับวิกฤต

## รายงานที่สะอาดไม่ใช่ใบรับรอง

นี่คือการตรวจสอบแบบพาสซีฟต่อไซต์ที่กำลังทำงานอยู่ ไม่ครอบคลุมตรรกะของแอปพลิเคชัน การยืนยันตัวตน การควบคุมการเข้าถึง หรือสิ่งใดก็ตามที่อยู่หลังการเข้าสู่ระบบ - สถานที่ที่การละเมิดจริงมักเริ่มต้น การตรวจสอบที่ไม่สามารถเสร็จสมบูรณ์ได้ถูกระบุว่าไม่ได้ตรวจสอบด้วยเหตุผลนี้โดยเฉพาะ: ผลผ่านที่ได้มาจากการเชื่อมต่อที่ล้มเหลวคือความมั่นใจที่ผิด และการสแกนที่ไม่มีผลการตรวจพบหมายความว่าไม่พบสิ่งใด ไม่ได้หมายความว่าไม่มีอะไรอยู่ที่นั่น

## สแกนเฉพาะสิ่งที่เป็นของคุณ

สแกนโดเมนที่คุณเป็นเจ้าของหรือมีสิทธิ์เป็นลายลักษณ์อักษรในการทดสอบ เครื่องมือนี้ปฏิเสธโฮสต์ที่แปลงเป็นที่อยู่ส่วนตัวหรือภายใน และมีการจำกัดอัตราต่อ IP แต่การอนุญาตยังคงเป็นความรับผิดชอบของคุณ

## คำถาม

**นี่เป็นการโจมตีที่ใช้งานอยู่หรือไม่**

ไม่ใช่ เครื่องมือส่งคำขอ GET, HEAD และ OPTIONS ธรรมดา ทำ TLS handshake (รวมถึงการลอง TLS 1.0 และ 1.1) ค้นหา DNS ผ่าน DNS-over-HTTPS ของ Cloudflare และเชื่อมต่อ TCP แบบธรรมดาไปยัง 12 พอร์ต ไม่มีการโจมตีช่องโหว่ ไม่มีการส่งฟอร์ม และไม่มีการแก้ไขสิ่งใด

**ฉันสามารถสแกนเว็บไซต์ใดก็ได้หรือไม่**

เฉพาะเว็บไซต์ที่คุณเป็นเจ้าของหรือได้รับอนุญาตให้ทดสอบเท่านั้น การสแกนโครงสร้างพื้นฐานของบุคคลที่สามโดยไม่ได้รับอนุญาตอาจผิดกฎหมายในพื้นที่ของคุณ

**ทำไมการตรวจสอบจึงบอกว่า "ไม่ได้ตรวจสอบ"**

เพราะไม่สามารถเสร็จสมบูรณ์ได้ - ปกติเพราะไม่มีการตอบสนองจากต้นทางนั้น มันถูกรายงานอย่างตรงไปตรงมาแทนที่จะถูกบันทึกว่าผ่าน

**ฉันสามารถส่งออกรายงานได้หรือไม่**

ได้ ในรูปแบบ Markdown หรือ JSON ภายในหนึ่งชั่วโมง: รายงานถูกเก็บในแคชของเซิร์ฟเวอร์ตลอดชั่วโมงนั้นเพื่อให้ดาวน์โหลดได้ แล้วจึงหมดอายุ การส่งออกทุกแบบไม่ใช้โมเดล บันทึกการใช้งานเก็บจำนวนผลการตรวจและเกรด ไม่เก็บชื่อโดเมน

**ตรวจไฟล์และพอร์ตใดบ้าง**

ไฟล์: พาธคงที่ 23 รายการ เช่น /.git/HEAD, /.git/config, /.env, /.env.local, /.env.production, /.aws/credentials, /id_rsa, /backup.zip, /backup.sql, /dump.sql, /wp-config.php.bak, /phpinfo.php, /server-status, /actuator/env แต่ละรายการจะถูกรายงานก็ต่อเมื่อคำตอบตรงกับลายเซ็นเฉพาะของไฟล์นั้น ส่วน /.well-known/security.txt จะนับเป็นผลดีหากเผยแพร่ไว้ พอร์ต: การเชื่อมต่อ TCP ธรรมดา ไม่มีการพยายามล็อกอิน ไปยัง 21 FTP, 23 Telnet, 25 SMTP, 3306 MySQL, 5432 PostgreSQL, 6379 Redis, 27017 MongoDB, 9200 Elasticsearch, 3389 RDP, 5900 VNC, 11211 Memcached, 8080 พอร์ตฐานข้อมูลที่เข้าถึงได้ (MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch) หรือ Telnet จัดเป็นระดับวิกฤต

**การตรวจ SPF และ DMARC แจ้งอะไรบ้าง**

ระเบียนทั้งสองอ่านจาก DNS สาธารณะ แม้เว็บไซต์จะไม่ส่งอีเมลก็ตาม เพราะหากไม่มี ใครก็ส่งอีเมลที่อ้างว่ามาจากโดเมนของคุณได้ ไม่มีระเบียน SPF เป็นระดับกลาง ระเบียน SPF ที่มี +all ซึ่งอนุญาตทุกเซิร์ฟเวอร์บนอินเทอร์เน็ต เป็นระดับสูง ไม่มีระเบียน DMARC ที่ _dmarc เป็นระดับกลาง p=none (หรือไม่มีแท็ก p=) แค่เฝ้าดูและเป็นระดับต่ำ ส่วน p=quarantine หรือ p=reject ผ่าน โดเมนที่ไม่ส่งอีเมลเลยสามารถเผยแพร่ v=spf1 -all ได้

**ตรวจเฮดเดอร์ความปลอดภัยตัวใดบ้าง และค่าแบบไหนจึงผ่าน**

เฮดเดอร์หกตัวในการตอบกลับของหน้าแรกของคุณ หากไม่มี HSTS และ Content-Security-Policy เป็นระดับสูง X-Content-Type-Options และ X-Frame-Options ระดับกลาง Referrer-Policy และ Permissions-Policy ระดับต่ำ Strict-Transport-Security ต้องมี max-age อย่างน้อย 15552000 (180 วัน) ถ้าสั้นกว่าเป็นระดับต่ำ และ max-age=0 เป็นระดับกลาง Content-Security-Policy จะถูกระบุว่าอ่อนลง (ระดับกลาง) หาก script-src อนุญาต 'unsafe-inline' นโยบายอนุญาต 'unsafe-eval' หรือ default-src หรือ script-src มีไวลด์การ์ด * เดี่ยว ๆ X-Content-Type-Options ต้องเป็น nosniff เท่านั้น X-Frame-Options ควรเป็น DENY หรือ SAMEORIGIN และไม่จำเป็นหาก CSP กำหนด frame-ancestors ไว้แล้ว Referrer-Policy จะถูกแจ้งเฉพาะเมื่อเป็น unsafe-url หรือ no-referrer-when-downgrade ส่วน Permissions-Policy แค่มีอยู่ก็พอ เฮดเดอร์ที่ขาดหรืออ่อนทุกตัวมาพร้อมคำสั่ง curl -sI ให้คุณตรวจเองได้

**ตรวจแอตทริบิวต์ของคุกกี้ (Secure, HttpOnly, SameSite) อย่างไร**

เครื่องมืออ่านเฮดเดอร์ Set-Cookie ทุกตัวในการตอบกลับของหน้าแรกของคุณ (สูงสุด 12 คุกกี้) และตรวจ Secure, HttpOnly และ SameSite ในแต่ละตัว ถ้าไม่มี Secure หรือ HttpOnly เป็นระดับกลาง ถ้าขาดเพียง SameSite เป็นระดับต่ำ และ SameSite=None ที่ไม่มี Secure จะถูกระบุแยก เพราะเบราว์เซอร์ปฏิเสธคุกกี้นั้น คุกกี้ที่มีครบทั้งสามผ่าน วิธีแก้ทั่วไปคือ Secure; HttpOnly; SameSite=Lax (ใน Django: SESSION_COOKIE_SECURE, SESSION_COOKIE_HTTPONLY และ SESSION_COOKIE_SAMESITE) การสแกนไม่ได้ล็อกอิน จึงไม่เห็นคุกกี้ที่ตั้งหลังล็อกอินเท่านั้น ตรวจเองได้ด้วย curl -sI https://your-site/ | grep -i set-cookie

**การตรวจ CORS ทำงานอย่างไร และเมื่อใดเป็นระดับวิกฤต**

เครื่องมือส่งคำขอ GET หนึ่งครั้งไปยังหน้าแรกของคุณพร้อม Origin: https://scanner-probe.example แล้วอ่าน Access-Control-Allow-Origin และ Access-Control-Allow-Credentials ในคำตอบ ถ้าไม่มีเฮดเดอร์ Access-Control-Allow-Origin หรือมี origin คงที่ที่ไม่สะท้อน origin ทดสอบกลับมา ถือว่าผ่าน การสะท้อน origin ทดสอบพร้อม Access-Control-Allow-Credentials: true เป็นระดับวิกฤต เพราะเว็บไซต์ใดก็ตามที่ผู้ใช้ที่ล็อกอินอยู่เปิดจะอ่านการตอบกลับของเขาได้ การสะท้อน origin โดยไม่มีข้อมูลรับรองเป็นระดับกลาง ไวลด์การ์ด * เป็นระดับต่ำ หรือระดับกลางหากอนุญาตข้อมูลรับรองด้วย (เบราว์เซอร์ปฏิเสธการรวมกันนี้) ทดสอบเฉพาะหน้าแรกและไม่ส่งคำขอ preflight OPTIONS จึงควรทดสอบเส้นทาง API แยกต่างหากด้วย curl -sI -H "Origin: https://scanner-probe.example" https://your-site/api/ | grep -i access-control

**การตรวจ TLS ทดสอบอะไรบ้าง (วันหมดอายุใบรับรอง, TLS 1.0 และ 1.1)**

เครื่องมือเชื่อมต่อพอร์ต 443 และตรวจสอบสายใบรับรองกับชื่อโฮสต์ ใบรับรองที่ตรวจสอบไม่ผ่านมีระดับสูง ใบที่หมดอายุแล้วจะถูกระบุเป็นวิกฤตเพิ่มด้วย และใบที่เหลือน้อยกว่า 15 วันมีระดับกลาง ถ้าไม่เข้ากรณีเหล่านี้ จะแสดงผู้ถือ ผู้ออก วันหมดอายุ และชื่อ SAN ว่าผ่าน โปรโตคอลที่ตกลงกันต้องเป็น TLS 1.2 หรือ TLS 1.3 เวอร์ชันที่เก่ากว่าถือเป็นระดับสูง จากนั้นจะลองแฮนด์เชก TLS 1.0 และ TLS 1.1 แยกกัน เซิร์ฟเวอร์ที่ยอมรับอย่างใดอย่างหนึ่งจะได้ผลระดับกลาง เพราะทั้งสองถูกเลิกใช้ตาม RFC 8996 หาก OpenSSL ของตัวสแกนเองเสนอเวอร์ชันเก่าไม่ได้ จะไม่รายงานอะไรแทนการเดา วิธีแก้ใน nginx คือ ssl_protocols TLSv1.2 TLSv1.3; ตรวจวันที่ด้วยตัวเองด้วยคำสั่ง echo | openssl s_client -connect your-site:443 -servername your-site 2>/dev/null | openssl x509 -noout -dates

**เครื่องมือตรวจว่า HTTP เปลี่ยนเส้นทางไป HTTPS หรือไม่**

ตรวจ เครื่องมือขอ http://your-site/ โดยไม่ตามการเปลี่ยนเส้นทาง 301 หรือ 308 ไปยังที่อยู่ https:// ถือว่าผ่าน 302, 303 หรือ 307 ไปยัง HTTPS มีระดับต่ำ เพราะเบราว์เซอร์ไม่จำการเปลี่ยนเส้นทางชั่วคราว ทุกการเข้าชมใหม่จึงเริ่มด้วยคำขอที่ไม่เข้ารหัสหนึ่งครั้ง หน้าที่ให้บริการผ่าน HTTP ที่ไม่เข้ารหัส (คำตอบ 2xx) มีระดับสูง ถ้าพอร์ต 80 ไม่ตอบเลย ถือเป็นข้อมูล ไม่ใช่ความล้มเหลว วิธีแก้ใน nginx คือ server { listen 80; return 301 https://$host$request_uri; } แล้วเพิ่ม Strict-Transport-Security ตรวจด้วยตัวเองด้วยคำสั่ง curl -I http://your-site/

**เครื่องมือแจ้งเตือนเมธอด HTTP ใดบ้าง (TRACE, PUT, DELETE)**

เครื่องมือส่งคำขอ OPTIONS หนึ่งครั้งไปที่หน้าแรกของคุณ แล้วอ่านเฮดเดอร์ Allow หรือ Access-Control-Allow-Methods ถ้าไม่มี Allow ถ้าประกาศ TRACE, TRACK, PUT หรือ DELETE จะมีระดับกลาง มีแค่ PATCH หรือ CONNECT มีระดับต่ำ มีเพียงเมธอดอ่านมาตรฐานถือว่าผ่าน ถ้าเซิร์ฟเวอร์ไม่ส่งเฮดเดอร์ทั้งสองนี้เลย จะไม่มีการรายงาน การประกาศเมธอดไม่ได้พิสูจน์ว่าใช้งานได้จริง จึงควรยืนยันก่อนแก้ไขอะไร TRACE สามารถสะท้อนเฮดเดอร์ของคำขอ รวมถึงคุกกี้ กลับไปยังผู้เรียก (Cross-Site Tracing) โดยค่าเริ่มต้น nginx ปฏิเสธ TRACE ส่วน Apache ให้ตั้ง TraceEnable Off จำกัด PUT และ DELETE ไว้เฉพาะเส้นทาง API ที่ต้องใช้ และอยู่หลังการยืนยันตัวตน ตรวจด้วยตัวเองด้วยคำสั่ง curl -X OPTIONS -i https://your-site/

**เครื่องมือตรวจพบการแสดงรายการไดเรกทอรี ("Index of /") อย่างไร**

เครื่องมือขอ 7 พาธ: /, /static/, /assets/, /uploads/, /images/, /files/ และ /backup/ พาธที่ตอบ HTTP 200 พร้อมหน้าที่ชื่อเรื่องหรือหัวข้อหลักขึ้นต้นด้วย "Index of /" จะถูกรายงานระดับกลาง (CWE-548) เพราะรายการนั้นเผยไฟล์ที่ไม่มีลิงก์จากที่ใดเลย เช่น ไฟล์สำรอง ไฟล์ส่งออก และเวอร์ชันเก่า ถ้าไม่มีพาธใดเป็นแบบนั้น ถือว่าผ่าน ถ้าเข้าถึงเว็บไซต์ไม่ได้ จะรายงานว่าไม่ได้ตรวจ วิธีแก้ใน nginx คือ autoindex off; (เป็นค่าเริ่มต้นอยู่แล้ว จึงให้มองหา autoindex on ที่เขียนไว้ชัดเจน) ใน Apache คือ Options -Indexes แล้วย้ายทุกอย่างที่อ่อนไหวออกจากรูทของเว็บ ตรวจด้วยตัวเองด้วยคำสั่ง curl -s https://your-site/uploads/ | head -20

**ตรวจพบเนื้อหาแบบผสมและฟอร์มที่ส่งผ่าน HTTP ได้ไหม**

ได้ บนหน้าแรก เครื่องมืออ่าน HTML ตามที่เซิร์ฟเวอร์ส่งมา (ไม่รัน JavaScript) และแสดงแท็ก script, link, iframe หรือ img ทุกตัวที่ src หรือ href ขึ้นต้นด้วย http:// ถ้ามีไฟล์ .js หรือ .css อยู่ด้วย ผลจะเป็นระดับกลาง เพราะสคริปต์หรือสไตล์ชีตที่ถูกสลับระหว่างทางจะทำงานในหน้า HTTPS ของคุณ ถ้ามีแค่รูปภาพและเฟรมเป็นระดับต่ำ ถ้าไม่มีเลยถือว่าผ่าน (CWE-311) ฟอร์มที่ action ขึ้นต้นด้วย http:// จะถูกรายงานเป็นระดับสูง (CWE-319) เพราะทุกอย่างที่พิมพ์ลงไป รวมถึงรหัสผ่าน ถูกส่งโดยไม่เข้ารหัส วิธีแก้คือเปลี่ยน URL เหล่านั้นเป็น https:// หรือทำเป็นแบบสัมพัทธ์ และเพิ่มเฮดเดอร์ Content-Security-Policy: upgrade-insecure-requests ไว้เป็นตาข่ายนิรภัย ตรวจเองได้ด้วย curl -s https://your-site/ | grep -Eo "(src|href|action)=.http://[^ >]*"

**ตรวจอะไรใน robots.txt และ security.txt**

robots.txt: เครื่องมือดึง /robots.txt และถ้าได้ HTTP 200 เป็นไฟล์ข้อความ จะอ่านบรรทัด Disallow ใน 8000 อักขระแรก เส้นทาง Disallow ที่มีคำ admin, internal, private, backup, config, staging, test, api, secret, dev จะถูกรายงานเป็นระดับต่ำ (CWE-200) เพราะ robots.txt เป็นไฟล์สาธารณะและแค่ขอให้ครอว์เลอร์ที่ทำตามกฎอย่าเข้า การระบุเส้นทางเหล่านั้นจึงเท่ากับประกาศให้รู้ ควรป้องกันด้วยการล็อกอิน และใช้ noindex เพื่อไม่ให้หน้าขึ้นในผลการค้นหา security.txt: เครื่องมือขอ /.well-known/security.txt ซึ่งเป็นตำแหน่งที่ RFC 9116 กำหนด และนับเป็นคะแนนบวกเมื่อไฟล์มีบรรทัด Contact: ถ้าไม่มีไฟล์ก็ไม่ถูกหักคะแนน RFC 9116 ยังกำหนดให้ต้องมีฟิลด์ Expires: ซึ่งการสแกนไม่ได้ตรวจ จึงควรเผยแพร่ทั้งสองอย่าง เช่น Contact: mailto:security@your-site, Expires: 2027-06-30T23:00:00Z ตรวจเองได้ด้วย curl -s https://your-site/.well-known/security.txt

**การตรวจ CAA ดูอะไร และจะเพิ่มเรคคอร์ด CAA อย่างไร**

เครื่องมือค้นหาเรคคอร์ด CAA (RFC 8659) ของชื่อโฮสต์ที่คุณป้อนผ่าน DNS-over-HTTPS ของ Cloudflare ถ้าพบ การตรวจจะผ่านและหลักฐานแสดงได้สูงสุด 5 รายการ ถ้าไม่พบเลยจะรายงาน "No CAA record" ระดับต่ำ เพราะเมื่อไม่มีเรคคอร์ดนี้ ผู้ออกใบรับรองสาธารณะรายใดก็ออกใบรับรองให้ชื่อนี้ได้ เรคคอร์ด CAA ระบุ CA ที่คุณใช้จริง เช่น your-site. IN CAA 0 issue "letsencrypt.org" พร้อม 0 iodef "mailto:security@your-site" เพื่อรับรายงาน เพิ่มบรรทัด issue หนึ่งบรรทัดต่อ CA ที่ใช้ และบรรทัด issuewild หากใบรับรองแบบ wildcard ต้องมาจาก CA อื่น ตรวจเองได้ด้วย dig CAA your-site

**ทำไมการสแกน www หรือโดเมนย่อยจึงรายงานว่าไม่มี CAA, SPF หรือ DMARC**

การตรวจ DNS ทุกข้อทำกับชื่อที่คุณป้อนตรงตัว ดังนั้น www.example.com จะถูกค้นเป็น www.example.com ไม่ใช่ example.com และทั้งสามเรคคอร์ดสืบทอดต่างกัน CAA: ผู้ออกใบรับรองที่ไม่พบเรคคอร์ด CAA บน www.example.com จะขึ้นไปใช้ของ example.com (RFC 8659 หัวข้อ 3) ดังนั้น "No CAA record" บนโดเมนย่อยอาจเป็นการเตือนผิด DMARC: ผู้รับจะย้อนไปใช้นโยบายของโดเมนองค์กร ซึ่งกำหนดนโยบายแยกสำหรับโดเมนย่อยได้ด้วย sp= (RFC 9989 ซึ่งแทนที่ RFC 7489) ดังนั้นการไม่มีเรคคอร์ดที่ _dmarc.www.example.com มักครอบคลุมแล้วโดย _dmarc.example.com SPF: ไม่มีการสืบทอด (RFC 7208) ดังนั้น "No SPF record" ถูกต้องสำหรับชื่อนั้น ชื่อโฮสต์ที่ไม่ส่งอีเมลสามารถเผยแพร่ v=spf1 -all ได้ การค้นหา DNS ที่ล้มเหลวก็แสดงเป็นไม่มีเรคคอร์ดเช่นกัน ให้สแกนโดเมนหลักด้วย หรือยืนยันด้วย dig CAA example.com และ dig TXT _dmarc.example.com

## เพิ่มเติมใน ความเป็นส่วนตัวและความปลอดภัย

- [ล้างข้อมูลรูปภาพ](https://discuvr.org/image-scrub/?hl=th)

## มักใช้ร่วมกับ

- [IP ของฉันคืออะไร](https://discuvr.org/what-is-my-ip/?hl=th)
- [ตัวสร้างรหัสผ่าน](https://discuvr.org/password-generator/?hl=th)

---

Part of Discuvr (https://discuvr.org/): Discuvr is a collection of free, focused tools for day-to-day professional work - office and data utilities, legal and compliance helpers, privacy and security checks, and developer formatters. Every tool has its own page, and most can also be called from ChatGPT or Claude over MCP.