หน้าแรก › คู่มือ

การตรวจติดตามบัญชีดำ: สคริปต์ API และการแจ้งเตือนผ่าน Webhook

เผยแพร่ 2026-11-03 ／ อัปเดต 2026-11-03 ／ โดย Yuki Nakazawa

การตรวจติดตามบัญชีดำ (blacklist monitoring) หมายถึงการสอบถามบัญชีดำแบบ DNS (DNSBL) หลายรายการสำหรับ IP และโดเมนที่ใช้ส่งอีเมลตามกำหนดเวลา และแจ้งเตือนเฉพาะเมื่อผลลัพธ์เปลี่ยนไป การพบการขึ้นบัญชีทันทีที่เกิดขึ้น แทนที่จะรู้เมื่อลูกค้าแจ้งว่าอีเมลตีกลับ ทำให้คุณมีเวลาหาสาเหตุและขอถอดรายชื่อก่อนที่ความเสียหายจะลุกลาม

ในทางปฏิบัติมีสองวิธี คือรันสคริปต์ dig และ cron ขนาดเล็กด้วยตนเอง หรือให้บริการภายนอกตรวจแทนผ่าน API และ webhook ไม่ว่าจะเลือกวิธีใด มีรายละเอียดสองข้อที่ตัดสินว่าระบบตรวจติดตามจะให้ผลที่ถูกต้องหรือไม่ คือ การสอบถามผ่าน resolver สาธารณะจะถูกปฏิเสธโดยรายชื่ออย่าง Spamhaus และให้คำตอบที่ทำให้เข้าใจผิด และต้องไม่นับรหัสข้อผิดพลาดเป็นการขึ้นบัญชีเด็ดขาด

กฎของผู้ดูแลรายชื่อที่อ้างถึงในที่นี้อิงตามหน้าทางการ ณ เดือนพฤศจิกายน 2026 นโยบายอาจเปลี่ยนแปลงได้ จึงควรยืนยันก่อนพึ่งพาการตั้งค่าใด ๆ สำหรับพื้นฐานการทำงานของ DNSBL ดู DNSBL (RBL) คืออะไร

กำหนดสิ่งที่ต้องติดตามและรายชื่อที่จะสอบถาม

เริ่มจากจดรายการสิ่งที่คุณต้องติดตามจริง ๆ

• ที่อยู่ IP ที่ใช้ส่ง คือที่อยู่ที่เซิร์ฟเวอร์อีเมลหรือผู้ให้บริการอีเมลของคุณใช้ส่งจริง เว็บไซต์และอีเมลมักออกจากเครื่องต่างกัน จึงควรยืนยันที่อยู่จากส่วนหัว Received ของอีเมลที่คุณส่ง หากคุณส่งผ่าน IPv6 ให้ติดตามที่อยู่เหล่านั้นด้วย
• โดเมน คือโดเมนในที่อยู่ From และโดเมนใด ๆ ที่ปรากฏในลิงก์ภายในข้อความ โดเมนจะถูกตรวจกับบัญชีดำแบบโดเมน ซึ่งแยกจากรายชื่อแบบ IP

รูปแบบการสอบถามกำหนดไว้ใน RFC 5782 สำหรับ IPv4 ให้กลับลำดับออกเท็ตแล้วต่อท้ายด้วยโซนของรายชื่อ ดังนั้น 192.0.2.99 บนรายชื่อหนึ่งจะกลายเป็น 99.2.0.192 ตามด้วยชื่อโซน สำหรับ IPv6 ที่อยู่จะเขียนเป็น nibble ฐานสิบหก 32 ตัวในลำดับกลับกัน ส่วนโดเมนเพียงนำไปต่อหน้าโซน รายการที่ถูกขึ้นบัญชีจะตอบกลับ A record ซึ่งตามธรรมเนียมอยู่ในช่วง 127.0.0.0/8 ส่วนรายการที่ไม่ถูกขึ้นบัญชีจะตอบกลับ NXDOMAIN RFC ยังระบุว่ารายชื่อควรเผยแพร่ TXT record ที่อธิบายเหตุผลของการขึ้นบัญชี

ควรติดตามหลายรายชื่อแทนที่จะเป็นรายชื่อเดียว เพราะฝั่งผู้รับไม่ได้ใช้รายชื่อเดียวกันทั้งหมด ความหมายของรหัสตอบกลับแต่ละค่าต่างกันไปตามผู้ดูแล คู่มือ รหัสตอบกลับของ DNSBL ของเราอธิบายรหัสที่พบบ่อย

ทำไม resolver สาธารณะจึงให้คำตอบที่ผิด

ข้อผิดพลาดที่พบบ่อยในระบบตรวจติดตามที่สร้างเองคือการส่งคำสอบถามผ่าน resolver สาธารณะ เช่น Google Public DNS (8.8.8.8) หรือ Cloudflare (1.1.1.1) คำถามที่พบบ่อยเรื่องการใช้ DNSBL อย่างเป็นทางการของ Spamhaus อธิบายสิ่งที่เกิดขึ้นไว้ดังนี้

• การใช้ DNSBL ของ Spamhaus แบบฟรีมีเงื่อนไขว่าต้องไม่ใช่การใช้เชิงพาณิชย์ และคำสอบถามต้องไม่มาจาก resolver สาธารณะหรือ open resolver หรือจาก IP ที่มี reverse DNS แบบทั่วไป
• เมื่อสอบถามผ่าน open resolver แบบฟรี เช่น Google Public DNS ในกรณีส่วนใหญ่จะได้คำตอบว่าไม่อยู่ในรายชื่อ (NXDOMAIN) กล่าวอีกนัยหนึ่ง IP ที่ถูกขึ้นบัญชีอาจดูเหมือนสะอาด
• การสอบถามผ่าน resolver สาธารณะอาจได้คำตอบ 127.255.255.254 ด้วย ซึ่งเป็นรหัสข้อผิดพลาด ไม่ใช่การขึ้นบัญชี ในทำนองเดียวกัน 127.255.255.252 หมายถึงพิมพ์ชื่อ DNSBL ผิด และ 127.255.255.255 หมายถึงสอบถามมากเกินไป Spamhaus ระบุว่าต้องไม่ตีความรหัสเหล่านี้ว่าสิ่งที่สอบถามถูกขึ้นบัญชี
• resolver ที่เขียนทับคำตอบ NXDOMAIN จะตอบกลับเป็นที่อยู่ IP แทน คุณจึงไม่เคยเห็น NXDOMAIN ที่ถูกต้อง

คำแนะนำอันดับแรกของคำถามที่พบบ่อยนี้คือใช้ DNS resolver ของคุณเอง สำหรับผู้ใช้ที่จำเป็นต้องใช้ resolver สาธารณะ Spamhaus แนะนำ Data Query Service (DQS) ของตน ให้ตรวจเงื่อนไขว่าส่วนใดใช้ได้ฟรี คำถามที่พบบ่อยยังแนะนำ dig txt whoami.fastly.net เพื่อดูว่าคุณใช้ resolver ใดอยู่จริง

RFC 5782 มีการตรวจความถูกต้องในตัว คือรายชื่อ IPv4 ต้องมีรายการสำหรับ 127.0.0.2 และต้องไม่มี 127.0.0.1 และไคลเอนต์ควรตรวจรายการทดสอบเหล่านี้เป็นระยะเพื่อยืนยันว่ารายชื่อทำงานอยู่ ในตัวอย่างของ Spamhaus 2.0.0.127.zen.spamhaus.org ตอบกลับ 127.0.0.10, 127.0.0.4 และ 127.0.0.2 ขณะที่ 1.0.0.127.zen.spamhaus.org ตอบกลับ NXDOMAIN ระบบตรวจติดตามควรทดสอบสิ่งนี้ก่อน และทิ้งผลของรอบนั้นหากไม่ผ่าน

ทางเลือกที่ 1: สคริปต์ dig และ cron

ต่อไปนี้คือสคริปต์ขั้นต่ำที่ตรวจที่อยู่ IPv4 หนึ่งรายการกับ Spamhaus ZEN และ SpamCop (bl.spamcop.net ซึ่ง SpamCop ระบุในเอกสารว่าตอบ 127.0.0.2 สำหรับ IP ที่ถูกขึ้นบัญชี) ให้แทนที่ที่อยู่และโซนด้วยของคุณเอง

#!/bin/sh
# สอบถามผ่าน recursive resolver ของคุณเอง (เช่น unbound บนโฮสต์เดียวกัน) ห้ามใช้ resolver สาธารณะ
RESOLVER=127.0.0.1
IP=192.0.2.10
ZONES="zen.spamhaus.org bl.spamcop.net"
REV=$(echo "$IP" | awk -F. '{print $4"."$3"."$2"."$1}')

q() {
  out=$(dig +time=3 +tries=1 @"$RESOLVER" "$1" A) || { echo ERR; return; }
  case "$out" in
    *"status: NOERROR"*) a=$(printf '%s\n' "$out" | awk '$4=="A"{print $5}'); echo "${a:-NX}" ;;
    *"status: NXDOMAIN"*) echo NX ;;
    *) echo ERR ;;
  esac
}

for Z in $ZONES; do
  # หากรายการทดสอบ 127.0.0.2 ไม่ได้ตอบเป็นรหัสการขึ้นบัญชี อย่าเชื่อถือผลของรอบนี้
  case "$(q "2.0.0.127.$Z")" in
    127.255.255.*|NX|ERR) echo "$Z ERROR test-entry"; continue ;;
    127.*) ;;
    *) echo "$Z ERROR test-entry"; continue ;;
  esac
  A=$(q "$REV.$Z")
  case "$A" in
    NX)            echo "$Z CLEAN" ;;
    ERR)           echo "$Z ERROR no-answer" ;;
    127.255.255.*) echo "$Z ERROR $A" ;;
    127.*)         echo "$Z LISTED $A" ;;
    *)             echo "$Z ERROR unexpected $A" ;;
  esac
done

สิ่งที่สคริปต์ทำ

• เฉพาะสถานะ NXDOMAIN เท่านั้นที่นับว่าสะอาด 127.255.255.x เป็นข้อผิดพลาด และค่า 127.x อื่น ๆ เป็นการขึ้นบัญชี ค่าใดที่อยู่นอก 127.0.0.0/8 จะถือเป็นความผิดปกติ เช่น resolver ที่เขียนทับคำตอบ
• การหมดเวลาทำให้ dig จบด้วยรหัสที่ไม่ใช่ศูนย์ ขณะที่ SERVFAIL และ REFUSED จบด้วยรหัส 0 ไม่มีกรณีใดถูกถือว่าสะอาด สคริปต์จะบันทึกเป็นข้อผิดพลาด
• รหัสตอบกลับเฉพาะเจาะจงกับแต่ละรายชื่อ ตัวอย่างเช่น บางรายชื่อใช้ 127.0.0.1 เพื่อบอกว่าคำสอบถามถูกปฏิเสธ จึงควรอ่านเอกสารของทุกรายชื่อที่เพิ่ม และขยายคำสั่ง case ตามที่จำเป็น

จากนั้นให้ cron เปรียบเทียบผลแต่ละรอบกับรอบก่อนหน้า และส่งอีเมลเฉพาะเมื่อมีการเปลี่ยนแปลง

# ตัวอย่าง: รันทุกชั่วโมง และส่งอีเมลเฉพาะเมื่อผลลัพธ์ต่างจากรอบก่อน
0 * * * * /usr/local/bin/dnsbl-watch.sh > /var/tmp/dnsbl.now 2>&1; cmp -s /var/tmp/dnsbl.now /var/tmp/dnsbl.prev || mail -s "DNSBL status changed" you@example.com < /var/tmp/dnsbl.now; mv /var/tmp/dnsbl.now /var/tmp/dnsbl.prev

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

ทางเลือกที่ 2: batch API และ webhook ของ DNSBL Checker

หากคุณไม่ต้องการดูแล resolver และกฎการแยกวิเคราะห์ของแต่ละรายชื่อเอง ก็สามารถให้บริการภายนอกตรวจแทนได้ ด้านล่างคือ API v1 ของเว็บไซต์นี้ โดยจำกัดเฉพาะสิ่งที่การทำงานฝั่งเซิร์ฟเวอร์ทำจริง เอกสารอ้างอิงอยู่ที่ /en/api-docs และคีย์ออกให้ในหน้าสมาชิกที่ /account การสมัครใช้เพียงที่อยู่อีเมล และเข้าสู่ระบบด้วยลิงก์ที่ส่งทางอีเมล

การยืนยันตัวตนและขีดจำกัด

• คีย์ขึ้นต้นด้วย dnsbl_ และแสดงเพียงครั้งเดียวทันทีหลังออกให้ ระบบเก็บไว้เพียงค่าแฮช การออกคีย์ใหม่จะทำให้คีย์เดิมใช้ไม่ได้
• ส่งคีย์ในส่วนหัว X-API-Key ทุกคำขอ ใช้ได้เฉพาะ HTTPS คำขอผ่าน http:// ธรรมดาจะถูกเปลี่ยนเส้นทางไปยัง https:// จึงควรเรียก https:// ตั้งแต่แรก
• ขีดจำกัดคือ 1,000 การตรวจต่อวัน (หนึ่งเป้าหมายนับเป็นหนึ่งครั้ง) 100 เป้าหมายต่อ batch และลงทะเบียน monitor ได้ 50 รายการ หากเกินขีดจำกัดรายวัน จะได้รับ 429 พร้อม daily_limit_exceeded และ timestamp resets_at

การตรวจแบบ batch

ส่งอาร์เรย์ targets ที่เป็นชื่อโดเมนหรือที่อยู่ IP ไปยัง POST /api/v1/batch

curl -X POST https://dnsblchecker.com/api/v1/batch \
  -H "X-API-Key: $DNSBL_API_KEY" -H "Content-Type: application/json" \
  -d '{"targets":["example.com"]}'

หากยังมีเป้าหมายที่ต้องตรวจ การตอบกลับจะเป็น 202 พร้อม batch_id ให้เรียก GET /api/v1/batch/{batch_id} ทุกไม่กี่วินาทีจนกว่า status จะเป็น done (ตัวอย่างแบบย่อ ตัวเลขและชื่อรายชื่อเป็นเพียงตัวอย่าง ไม่ใช่ผลจริง)

{
  "batch_id": 1, "status": "done", "created": "2026-11-03 09:10:41", "count": 1, "pending": 0,
  "results": [
    {
      "target": "example.com", "type": "domain",
      "status": "done", "verdict": "listed",
      "checked_at": "2026-11-03 09:12",
      "lists_checked": 80, "listed_count": 1, "error_count": 4,
      "listed_on": [
        { "list": "ZapBL RHSBL", "zone": "rhsbl.zapbl.net", "response": "127.0.0.2" }
      ]
    }
  ]
}

• verdict จะเป็น listed หากมีอย่างน้อยหนึ่งรายชื่อรายงานการขึ้นบัญชี มิฉะนั้นจะเป็น clean รายชื่อที่หมดเวลา หรือตอบด้วยรหัสข้อผิดพลาด เช่น 127.255.255.x จะนับใน error_count และไม่นับเป็นการขึ้นบัญชีเลย
• batch จะคืนผลที่เก็บไว้หากมีผลจากช่วง 30 วันที่ผ่านมา สำหรับการตรวจติดตามตามกำหนดเวลา ให้ดู checked_at ทุกครั้ง
• เป้าหมายที่รูปแบบไม่ถูกต้องจะกลับมาใน rejected พร้อมเหตุผล และไม่ถูกนับ หากส่ง URL ระบบจะใช้เฉพาะชื่อโฮสต์ ช่วงที่สงวนไว้สำหรับเอกสาร เช่น 192.0.2.0/24 จะถูกปฏิเสธ จึงควรทดสอบด้วย IP ที่ใช้ส่งจริง

การตรวจติดตามผ่าน webhook

ลงทะเบียน target และ callback_url ด้วย POST /api/v1/monitors จากนั้นแต่ละเป้าหมายที่ลงทะเบียนจะถูกตรวจวันละครั้งโดยไม่ใช้แคช (การตรวจครั้งแรกจะเกิดขึ้นภายในประมาณหนึ่งวันหลังลงทะเบียน) และจะส่ง POST แบบ JSON ไปยัง URL ของคุณเฉพาะในการตรวจครั้งแรก (monitor.initial) และเมื่อผลตัดสินเปลี่ยนระหว่าง listed กับ clean (monitor.status_changed)

curl -X POST https://dnsblchecker.com/api/v1/monitors \
  -H "X-API-Key: $DNSBL_API_KEY" -H "Content-Type: application/json" \
  -d '{"target":"example.com","callback_url":"https://your-app.example/hooks/dnsbl"}'

• signing_secret ในการตอบกลับจะแสดงเพียงครั้งเดียว การส่งแต่ละครั้งจะมีส่วนหัว X-DNSBL-Signature: sha256=... ซึ่งเป็น HMAC-SHA256 ของเนื้อหาดิบที่ใช้ secret นั้นเป็นคีย์ ให้ตรวจสอบลายเซ็นนี้ในฝั่งของคุณ
• callback_url ต้องเป็น https บนพอร์ต 443 และแปลงชื่อเป็น IP สาธารณะ ระบบไม่ติดตามการเปลี่ยนเส้นทาง และหมดเวลาใน 10 วินาที จึงควรนำงานหนักเข้าคิวแล้วตอบกลับโดยเร็ว
• หาก endpoint ของคุณตอบกลับด้วยค่าอื่นที่ไม่ใช่ 2xx หรือการเชื่อมต่อล้มเหลว ระบบจะลองส่งใหม่ในการตรวจรายวันครั้งถัดไป เหตุผลจะแสดงเป็น last_delivery_error ใน GET /api/v1/monitors และ DELETE /api/v1/monitors/{monitor_id} ใช้ลบ monitor

import hmac, hashlib
expected = "sha256=" + hmac.new(secret.encode(), raw_body, hashlib.sha256).hexdigest()
ok = hmac.compare_digest(expected, request.headers.get("X-DNSBL-Signature", ""))

การออกแบบการแจ้งเตือน: ความถี่ หลายรายชื่อ และการเตือนผิดพลาด

ระบบตรวจติดตามจะมีประโยชน์ก็ต่อเมื่อผู้คนยังอ่านการแจ้งเตือนหลังผ่านไปหลายเดือน ระบบที่แจ้งเตือนตลอดเวลาจะถูกเพิกเฉยในไม่ช้า

ความถี่

• แยกความถี่ในการสอบถามออกจากความถี่ในการแจ้งเตือน สอบถามตามกำหนดเวลา แต่แจ้งเตือนเฉพาะเมื่อสถานะเปลี่ยน ข้อความ "ทุกอย่างปกติ" ทุกวันจะกลบการแจ้งเตือนเดียวที่สำคัญ
• RFC 5782 ระบุว่า TTL ของรายชื่อควรสะท้อนความเร็วในการเปลี่ยนแปลงของรายชื่อ และรายชื่อแหล่งสแปมอาจใช้ TTL ระดับนาที ให้เลือกรอบการตรวจโดยคำนึงว่าการขึ้นบัญชีบางรายการปรากฏและหมดอายุอย่างรวดเร็ว
• การสอบถามปริมาณมากอาจละเมิดเงื่อนไขการใช้งานของรายชื่อ หรือทำให้ได้ 127.255.255.255 (สอบถามมากเกินไป) แทนคำตอบจริง

หลายรายชื่อ

• ใส่ชื่อรายชื่อในการแจ้งเตือนทุกครั้ง รายชื่อแต่ละรายการมีจำนวนผู้รับที่ใช้งานต่างกัน คุณจึงอาจแจ้งเตือนทันทีสำหรับรายชื่อที่สำคัญที่สุดต่อผู้รับของคุณ และรวมรายชื่อที่เหลือไว้ในสรุป
• webhook ข้างต้นจะทำงานเฉพาะเมื่อผลตัดสินเปลี่ยนระหว่าง listed กับ clean หากเป้าหมายถูกขึ้นบัญชีอยู่แล้วและปรากฏในรายชื่อที่สองเพิ่ม จะไม่มีการส่งเหตุการณ์ใด ๆ ให้ดู last_listed_count ใน GET /api/v1/monitors หรือรัน batch แล้วอ่าน listed_on เพื่อจับกรณีนี้

ผลบวกลวงและคำตอบชั่วคราว

• บันทึกข้อผิดพลาดแยกจากการขึ้นบัญชี Spamhaus เตือนผู้ดูแลระบบไม่ให้ปฏิเสธหรือกรองอีเมลตามรหัสข้อผิดพลาดของตน ตรรกะเดียวกันนี้ใช้กับการตรวจติดตาม การหมดเวลาหรือคำตอบ 127.255.255.x ต้องไม่ทำให้เกิดการแจ้งเตือนว่าถูกขึ้นบัญชี
• เพื่อไม่ให้ตอบสนองต่อผลแปลก ๆ เพียงครั้งเดียว ให้แจ้งเตือนหลังได้ผลเหมือนกันสองครั้งติดต่อกันเท่านั้น หรือสอบถามซ้ำในอีกไม่กี่นาทีก่อนส่งการแจ้งเตือน
• หากข้อผิดพลาดยังคงอยู่ ให้สงสัยว่ามีการเปลี่ยน resolver หรือมีการเปลี่ยนแปลงฝั่งรายชื่อ และตรวจผลของรายการทดสอบก่อน
• IP ตามบ้านที่อยู่ใน Spamhaus PBL เป็นการขึ้นบัญชีเชิงนโยบาย ไม่ใช่การกล่าวหา หมายความว่าที่อยู่นั้นไม่ควรส่งอีเมลโดยตรง ให้กำหนดแยกตามรายชื่อว่าอะไรนับเป็นการแจ้งเตือน (ดู การถอดรายชื่อจาก Spamhaus)

สิ่งที่ควรทำเมื่อพบการขึ้นบัญชี

1. ยืนยันผล ตรวจในหน้าตรวจสอบของผู้ดูแลรายชื่อเอง และจดชื่อรายชื่อ เวลา และเหตุผลที่แสดง
2. แก้ไขสาเหตุก่อน ตรวจหาบัญชีที่ถูกเจาะ เว็บฟอร์มที่ถูกนำไปใช้ในทางที่ผิด เครื่องที่ติดเชื้อ การดูแลรายชื่อผู้รับที่ไม่ดี และ reverse DNS (PTR) หรือชื่อ HELO ที่ไม่ตรงกัน การขอถอดรายชื่อขณะที่สาเหตุยังอยู่มักนำไปสู่การถูกขึ้นบัญชีใหม่
3. ทำตามขั้นตอนการถอดรายชื่อของรายชื่อนั้น การตัดสินใจถอดรายชื่อเป็นของผู้ดูแลแต่ละรายชื่อ และการยื่นคำขอไม่ได้รับประกันว่าจะถูกถอดรายชื่อ หากคุณไม่ได้ควบคุม IP เอง เช่น กรณี shared hosting ให้ติดต่อผู้ให้บริการโฮสติ้งหรือ ISP
4. ให้ระบบตรวจติดตามยืนยันผล ฝั่งผู้รับยังใช้ตัวกรองของตนเองด้วย จึงควรติดตามการส่งอีเมลต่อไปหลังผลตัดสินกลับมาเป็น clean

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

คำถามที่พบบ่อย

หน้าทางการที่ใช้อ้างอิง

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

• RFC 5782: DNS Blacklists and Whitelists
• Spamhaus FAQ: DNSBL Usage
• Spamhaus: Using our public mirrors? Check your return codes now
• SpamCop FAQ: How do I configure my mailserver to reject mail based on the blocklist?

คู่มือที่เกี่ยวข้อง

คู่มือทั้งหมด →