อีเมลและโดเมน
ตรวจสอบ SPF
ขอบเขต: ใช้ได้กับโดเมนจากทุกประเทศ เราอ่านระเบียนแบบเดียวกับเซิร์ฟเวอร์ผู้รับ (RFC 7208): กลไกต่าง ๆ การลงท้ายของระเบียน include และ redirect ทุกรายการโดยติดตามได้สูงสุด 30 การค้นหา และจำนวนการค้นหา DNS เมื่อเทียบกับขีดจำกัด 10 ครั้ง
เปิดเครื่องมือในหน้านี้
วัตถุประสงค์
ตรวจสอบระเบียน SPF ของโดเมน: เซิร์ฟเวอร์ใดส่งอีเมลในนามโดเมนได้ เซิร์ฟเวอร์อื่นทั้งหมดจะเป็นอย่างไร (“-all”, “~all”, “+all”) ต้องใช้การค้นหา DNS กี่ครั้งเมื่อเทียบกับขีดจำกัด 10 ครั้ง และ include ทุกรายการ
ข้อกำหนด
ทุกคนอ่านคู่มือเหล่านี้ได้โดยไม่ต้องมีบัญชี เครื่องมือบางอย่างต้องใช้ Pro ตามที่ระบุในแต่ละคู่มือ
SPF คือระเบียน DNS ที่โดเมนใช้ระบุเซิร์ฟเวอร์ที่ได้รับอนุญาตให้ส่งอีเมลของโดเมน หากไม่มีระเบียนนี้ หรือมีแต่เสียหรือเปิดกว้างเกินไป ก็จะส่งอีเมลปลอมในนามโดเมนนั้นได้ง่ายขึ้น พิมพ์โดเมน ที่อยู่อีเมล หรือลิงก์ แล้วเราจะอ่าน SPF ของโดเมนและอธิบายให้คุณเข้าใจ
วิธีใช้งาน
พิมพ์โดเมนที่ต้องการตรวจสอบ หรือวางที่อยู่อีเมลหรือลิงก์: เราใช้เฉพาะส่วนโดเมนเท่านั้น
กด “ตรวจสอบ SPF” เราจะอ่านระเบียน SPF และติดตาม include ทุกรายการ เหมือนที่เซิร์ฟเวอร์ผู้รับทำ
ดูว่าระเบียนลงท้ายอย่างไรและดูจำนวนการค้นหา: สิ่งที่ควรเห็นคือ “-all” หรือ “~all” และการค้นหาไม่เกิน 10 ครั้ง
ตัวอย่างสมมติ
ตัวอย่างสมมติ ไม่ใช่ผลการค้นหาจริง ห้ามโทรหรือเปิดลิงก์ในตัวอย่าง
v=spf1 include:_spf.example.com ~allทำความเข้าใจผลลัพธ์
โดเมนนี้ไม่มี SPF: โดเมนนี้ไม่ได้ระบุว่าเซิร์ฟเวอร์ใดส่งอีเมลของโดเมนได้ จึงถูกแอบอ้างได้ง่ายขึ้น หากเป็นโดเมนของคุณ ให้เผยแพร่ระเบียน SPF
ระเบียน SPF มีข้อผิดพลาด: เซิร์ฟเวอร์ผู้รับนำระเบียนนี้ไปใช้ไม่ได้ สำหรับเซิร์ฟเวอร์เหล่านั้นจึงเท่ากับว่าโดเมนไม่มี SPF สัญญาณด้านล่างจะบอกว่าผิดพลาดตรงไหน
ใครก็ส่งอีเมลในนามโดเมนนี้ได้: ระเบียนลงท้ายด้วย “+all” ซึ่งอนุญาตเซิร์ฟเวอร์ทุกเครื่องในโลก เมื่อตั้งค่าแบบนี้ SPF จะไม่ได้ป้องกันอะไรเลย
SPF ป้องกันโดเมนได้ไม่เต็มที่: ระเบียนไม่ได้ระบุว่าจะทำอย่างไรกับเซิร์ฟเวอร์ที่ไม่อยู่ในรายชื่อ อีเมลปลอมในนามโดเมนจึงไม่ถูกทำเครื่องหมาย
SPF ตั้งค่าไว้อย่างถูกต้อง: โดเมนระบุเซิร์ฟเวอร์ที่ส่งอีเมลของโดเมนได้ และขอให้เซิร์ฟเวอร์ผู้รับทำเครื่องหมายหรือปฏิเสธอีเมลจากเซิร์ฟเวอร์อื่น SPF อย่างเดียวหยุดการแอบอ้างไม่ได้: DMARC คือสิ่งที่บอกเซิร์ฟเวอร์ผู้รับว่าต้องทำอย่างไร
+all: เซิร์ฟเวอร์ใดก็ส่งได้ (อันตราย)
?all: ระเบียนไม่ได้ระบุอะไรเกี่ยวกับเซิร์ฟเวอร์เหล่านี้
~all: ถูกทำเครื่องหมายว่าน่าสงสัย
-all: ถูกปฏิเสธ
ไม่มี “all”: ระเบียนไม่ได้ระบุอะไรเกี่ยวกับเซิร์ฟเวอร์เหล่านี้
ข้อจำกัด
เราอ่านระเบียน DNS สาธารณะของโดเมน หากคุณพิมพ์ที่อยู่อีเมลหรือลิงก์ จะมีเพียงส่วนโดเมนเท่านั้นที่ออกจากเบราว์เซอร์ของคุณ เราไม่บันทึกโดเมนที่คุณค้นหา
การแก้ไขปัญหา
ดูเหมือนว่านี่ไม่ใช่โดเมนสาธารณะ ลองพิมพ์แบบ example.com
DNS ไม่ตอบกลับภายในเวลาที่กำหนด ลองอีกครั้งในอีกไม่กี่วินาที
คุณตรวจสอบติดต่อกันหลายครั้งเกินไป รอสักหนึ่งนาทีแล้วลองอีกครั้ง
ใช้งานผ่าน API
ต้องมีคีย์ API และเครดิต การเรียกที่สำเร็จแต่ละครั้งใช้ 1 เครดิต แม้ไม่มีข้อมูลก็ตาม บัญชี Pro ที่ใช้งานอยู่มี 20 เครดิตต่อเดือนปฏิทินตามเวลา UTC ใช้ร่วมกันทุกเส้นทาง API และถูกใช้ก่อน เครดิตรายเดือนที่ไม่ได้ใช้จะไม่ทบไปเดือนถัดไป เครดิตที่ซื้อในหน้าบัญชีของคุณใช้ได้โดยไม่ต้องมี Pro และไม่มีวันหมดอายุ
ข้อผิดพลาดไม่ถูกคิดเครดิต: 401 invalid_api_key (ไม่มีคีย์หรือคีย์ไม่ถูกต้อง), 403 pro_required (ไม่มีเครดิต Pro และไม่มีเครดิตที่ซื้อไว้), 422 ข้อมูลนำเข้าไม่ถูกต้อง, 429 quota_exceeded (เครดิตหมด), rate_limit_exceeded หรือ ai_busy (AI ของ sms-check ใช้งานเต็มความสามารถ), 503 tool_warming (ข้อมูลยังเตรียมไม่เสร็จ) หรือ tool หรือผู้ให้บริการไม่พร้อมใช้งาน หลังได้รับ 429 หรือ 503 ให้ลองใหม่เมื่อครบจำนวนวินาทีในเฮดเดอร์ Retry-After
อ่านระเบียน SPF ของโดเมนแบบเดียวกับเซิร์ฟเวอร์ผู้รับ (RFC 7208): ส่วนประกอบ (term) ต่าง ๆ การลงท้ายของระเบียน การค้นหา DNS ทั่วทั้งโครงสร้าง include เทียบกับขีดจำกัด 10 ครั้ง include ทุกรายการและแต่ละรายการเผยแพร่ SPF หรือไม่ รวมถึงปัญหาของระเบียนในรูปแบบสัญญาณ ไม่มีการจัดเก็บข้อมูลใด
ส่ง JSON body ไปยังเส้นทางของ tool นั้นโดยตรง หรือไปยัง POST /v2/tools โดยเพิ่มฟิลด์ tool ทั้งสองเส้นทางให้ผลลัพธ์เหมือนกัน
POST https://api.nocall.io/v2/spf-check
POST https://api.nocall.io/v2/tools {"tool":"spf-check","domain":"example.com"}พารามิเตอร์
| ชื่อ | ชนิด | จำเป็น | คำอธิบาย |
|---|---|---|---|
| domain | string (1–320) | ใช่ | โดเมน หรือที่อยู่อีเมลหรือลิงก์ที่จะใช้ส่วนโดเมน ไม่เกิน 320 อักขระ เฉพาะชื่อสาธารณะเท่านั้น: ที่อยู่ IP ชื่อที่มีเลเบลเดียว และชื่อสำหรับใช้งานพิเศษ (.local, .internal, .test…) จะได้ผลเป็น 422 |
REQUEST_ID="$(uuidgen)" && [ -n "$REQUEST_ID" ] &&
curl --request POST 'https://api.nocall.io/v2/spf-check' \
--header "Authorization: Bearer $NOCALL_API_KEY" \
--header 'Content-Type: application/json' \
--header "Idempotency-Key: $REQUEST_ID" \
--data '{"domain":"example.com"}'import json
import os
import urllib.request
import uuid
api_key = os.environ.get('NOCALL_API_KEY')
if not api_key:
raise SystemExit('Set NOCALL_API_KEY')
request = urllib.request.Request(
'https://api.nocall.io/v2/spf-check',
method='POST',
data=json.dumps({'domain': 'example.com'}).encode(),
headers={
'Authorization': 'Bearer ' + api_key,
'Content-Type': 'application/json',
'Idempotency-Key': str(uuid.uuid4()),
},
)
with urllib.request.urlopen(request, timeout=30) as response:
result = json.load(response)
print(result['data']['result'], result['meta']['unitsCharged'])import { randomUUID } from 'node:crypto';
const requestId = randomUUID();
const apiKey = process.env.NOCALL_API_KEY;
if (!apiKey) throw new Error('Set NOCALL_API_KEY');
const response = await fetch('https://api.nocall.io/v2/spf-check', {
method: 'POST',
headers: {
Authorization: 'Bearer ' + apiKey,
'Content-Type': 'application/json',
'Idempotency-Key': requestId,
},
body: JSON.stringify({ domain: 'example.com' }),
});
const result = await response.json();
if (!response.ok) throw new Error(result.error?.code ?? 'request_failed');
console.log(result.data.result, result.meta.unitsCharged);ตัวอย่างการตอบกลับ (200)
นี่คือตัวอย่างที่ระบุไว้ในเอกสารอ้างอิง API การค้นหาใช้หมายเลขสมมติ ส่วนข้อมูลรวมและคำตอบจาก AI แสดงเพียงโครงสร้างของผลลัพธ์ ไม่ใช่ข้อมูลจริง
{
"data": {
"tool": "spf-check",
"result": {
"domain": "example.com",
"domainAscii": "example.com",
"found": true,
"record": "v=spf1 include:_spf.google.com ~all",
"recordCount": 1,
"terms": [
{
"qualifier": "pass",
"mechanism": "include",
"value": "_spf.google.com"
},
{
"qualifier": "softfail",
"mechanism": "all",
"value": null
}
],
"allResult": "softfail",
"lookups": 1,
"includes": [
{
"domain": "_spf.google.com",
"found": true
}
],
"signals": [
"softfail_all"
],
"valid": true,
"attention": false
}
},
"meta": {
"requestId": "req_example",
"unitsCharged": 1,
"usage": {
"periodStart": "2026-10-01",
"unitLimit": 20,
"unitsUsed": 3,
"unitsRemaining": 17
}
}
}ฟิลด์ผลลัพธ์ (data.result)
| ฟิลด์ | ชนิด | คำอธิบาย |
|---|---|---|
| domain | string | โดเมนในรูปแบบ Unicode |
| domainAscii | string | โดเมนเดียวกันในรูปแบบ ASCII (punycode) ตามที่ DNS เห็น |
| found | boolean | โดเมนเผยแพร่ระเบียน SPF หรือไม่ |
| record | string | null | ระเบียน SPF ตามที่เผยแพร่ เป็น null เมื่อไม่มีหรือมีมากกว่าหนึ่งระเบียน |
| recordCount | integer | จำนวนระเบียน SPF ที่โดเมนเผยแพร่ หากมากกว่าหนึ่งถือเป็นข้อผิดพลาด |
| terms | array<object> | กลไกและตัวปรับแต่ง (modifier) ของระเบียนตามลำดับ แต่ละรายการมี qualifier (pass, fail, softfail หรือ neutral; null สำหรับ redirect และ exp) และค่า |
| allResult | "pass" | "fail" | "softfail" | "neutral" | null | สิ่งที่ระเบียนลงท้าย (all ของระเบียนเอง หรือของปลายทาง redirect): pass, fail, softfail หรือ neutral เป็น null เมื่อไม่มี |
| lookups | integer | กลไกและตัวปรับแต่งที่ต้องค้นหา DNS ทั่วทั้งโครงสร้าง include เซิร์ฟเวอร์ผู้รับจะหยุดเมื่อเกิน 10 ครั้ง (permerror) |
| includes | array<object> | ปลายทางของ include และ redirect ทุกรายการตามลำดับที่อ่าน และแต่ละรายการเผยแพร่ SPF หรือไม่ |
| signals | array<string (enum, 12)> | no_spf, multiple_records, syntax_error, too_many_lookups, include_not_found, include_loop, plus_all, neutral_all, softfail_all, no_all, ptr_mechanism หรือ macros |
| valid | boolean | เซิร์ฟเวอร์ผู้รับประเมินระเบียนได้หรือไม่: มีระเบียนเดียว ไม่มีข้อผิดพลาดทางไวยากรณ์ ค้นหาไม่เกิน 10 ครั้ง พบ include ทุกรายการ และไม่มีลูป |
| attention | boolean | ผลลัพธ์ควรได้รับการตรวจดูหรือไม่: ไม่มี SPF ระเบียนไม่ถูกต้อง หรือระเบียนที่ลงท้ายด้วย +all, ?all หรือไม่มี all |
คำถามที่พบบ่อย
SPF คืออะไร
Sender Policy Framework: ระเบียน DNS ที่โดเมนใช้ระบุเซิร์ฟเวอร์ที่ได้รับอนุญาตให้ส่งอีเมลของโดเมน เซิร์ฟเวอร์ที่รับข้อความจะตรวจว่าเซิร์ฟเวอร์ที่ส่งข้อความมาให้อยู่ในรายชื่อนั้นหรือไม่
“-all” กับ “~all” แบบไหนดีกว่า
“-all” ขอให้เซิร์ฟเวอร์ผู้รับปฏิเสธอีเมลจากเซิร์ฟเวอร์ที่ไม่อยู่ในรายชื่อ ส่วน “~all” ขอให้ทำเครื่องหมายว่าน่าสงสัย ทั้งสองแบบช่วยป้องกันได้ และหลายโดเมนใช้ “~all” แล้วให้ DMARC เป็นตัวตัดสินว่าจะทำอย่างไร “+all” และ “?all” ไม่ได้ป้องกัน
ทำไมขีดจำกัดการค้นหา 10 ครั้งจึงสำคัญ
include, a, mx, ptr, exists และ redirect แต่ละรายการทำให้เซิร์ฟเวอร์ผู้รับต้องค้นหา DNS หากทั้งระเบียนต้องค้นหามากกว่า 10 ครั้ง ระเบียนจะถูกถือว่าผิดพลาดและ SPF จะหยุดทำงาน ให้ลบบริการที่คุณไม่ได้ใช้แล้ว หรือขอ include ที่เรียบง่ายกว่านี้จากผู้ให้บริการของคุณ
SPF หยุดอีเมลปลอมได้ด้วยตัวเองหรือไม่
ไม่ได้ SPF ตรวจสอบผู้ส่งบนซองจดหมาย (envelope) ที่ซ่อนอยู่ ไม่ใช่ที่อยู่ที่คุณเห็นในช่อง “จาก” DMARC คือสิ่งที่เชื่อมทั้งสองอย่างเข้าด้วยกัน และขอให้เซิร์ฟเวอร์ผู้รับส่งอีเมลที่ไม่ผ่านไปที่สแปมหรือปฏิเสธ ควรตรวจสอบ DMARC ของโดเมนด้วย
