อ่านรายงาน DMARC ให้เข้าใจว่าใครส่งอีเมลแทนโดเมนคุณ
เมื่อตั้งระเบียน DMARC พร้อมที่อยู่รับรายงาน ผู้ให้บริการอีเมลรายใหญ่จะส่งรายงานสรุปมาให้ทุกวัน บอกว่ามีใครส่งอีเมลในนามโดเมนของคุณบ้าง จาก IP ไหน และผ่านการตรวจสอบหรือไม่
ข้อมูลนี้มีค่ามาก แต่มาในรูปแบบ XML ที่บีบอัดไว้และอ่านด้วยตาเปล่าแทบไม่ได้ คู่มือนี้แปลงให้อ่านรู้เรื่องและอธิบายว่าต้องดูอะไร
สิ่งที่ต้องเตรียม
- ระเบียน DMARC ที่ตั้งพร้อมที่อยู่รับรายงานแล้ว
- กล่องจดหมายที่รับรายงาน ซึ่งควรเป็นบัญชีเฉพาะเพราะได้รับหลายฉบับต่อวัน
- เครื่อง Linux สำหรับแปลงไฟล์
dig +short TXT _dmarc.example.comขั้นตอนที่ 1: เข้าใจสิ่งที่ DMARC ตรวจ
DMARC ไม่ได้ตรวจแค่ว่า SPF หรือ DKIM ผ่านหรือไม่ แต่ตรวจเพิ่มว่าโดเมนที่ผ่านนั้นตรงกับโดเมนที่แสดงในช่องผู้ส่งหรือไม่ ซึ่งเรียกว่า alignment
ตัวอย่างที่ทำให้เข้าใจ อีเมลที่ส่งผ่านบริการส่งจดหมายข่าว
- ช่อง From แสดง
[email protected] - SPF ตรวจจากโดเมนของผู้ให้บริการ เช่น
mailer.provider.comซึ่งผ่าน - แต่ SPF alignment ไม่ผ่าน เพราะสองโดเมนไม่ตรงกัน
DMARC จะผ่านก็ต่อเมื่ออย่างน้อยหนึ่งใน SPF หรือ DKIM ผ่านพร้อม alignment นี่คือเหตุผลที่บริการภายนอกต้องตั้ง DKIM ด้วยโดเมนของคุณเอง
ขั้นตอนที่ 2: แปลงรายงานให้อ่านได้
บันทึกไฟล์แนบจากอีเมลรายงานลงเครื่อง แล้วแตกไฟล์
cd /tmp/dmarc
gunzip *.xml.gz 2>/dev/null
unzip -o '*.zip' 2>/dev/null
# ดูโครงสร้าง
xmllint --format report.xml | head -40เขียนสคริปต์แปลงเป็นตารางที่อ่านง่าย
#!/bin/bash
# /usr/local/bin/dmarc-summary.sh
for f in "$@"; do
org=$(xmllint --xpath 'string(//report_metadata/org_name)' "$f" 2>/dev/null)
dom=$(xmllint --xpath 'string(//policy_published/domain)' "$f" 2>/dev/null)
echo "=== รายงานจาก $org สำหรับ $dom"
printf '%-16s %-7s %-9s %-9s %s\n' "IP" "จำนวน" "SPF" "DKIM" "ผล"
n=$(xmllint --xpath 'count(//record)' "$f" 2>/dev/null)
for i in $(seq 1 "$n"); do
ip=$(xmllint --xpath "string((//record)[$i]/row/source_ip)" "$f")
ct=$(xmllint --xpath "string((//record)[$i]/row/count)" "$f")
sp=$(xmllint --xpath "string((//record)[$i]/row/policy_evaluated/spf)" "$f")
dk=$(xmllint --xpath "string((//record)[$i]/row/policy_evaluated/dkim)" "$f")
ds=$(xmllint --xpath "string((//record)[$i]/row/policy_evaluated/disposition)" "$f")
host=$(dig +short -x "$ip" | head -1)
printf '%-16s %-7s %-9s %-9s %-10s %s\n' "$ip" "$ct" "$sp" "$dk" "$ds" "${host:-}"
done
echo
donesudo chmod +x /usr/local/bin/dmarc-summary.sh
/usr/local/bin/dmarc-summary.sh /tmp/dmarc/*.xmlขั้นตอนที่ 3: อ่านผลและจัดกลุ่มผู้ส่ง
จากตารางที่ได้ ให้แยก IP ออกเป็นสามกลุ่ม
กลุ่มที่ 1 ผู้ส่งที่ถูกต้องและผ่านทั้งหมด
ไม่ต้องทำอะไร นี่คือสิ่งที่ควรเป็น
กลุ่มที่ 2 ผู้ส่งที่ถูกต้องแต่ไม่ผ่าน
นี่คือกลุ่มที่ต้องแก้ก่อนเข้มนโยบาย มักเป็น
- เซิร์ฟเวอร์เว็บที่ส่งอีเมลยืนยันคำสั่งซื้อแต่ไม่ได้อยู่ใน SPF
- บริการส่งจดหมายข่าวที่ยังไม่ได้ตั้ง DKIM ด้วยโดเมนของคุณ
- ระบบ CRM หรือระบบบัญชีที่ส่งอีเมลแทนโดเมน
- เครื่องพิมพ์หรืออุปกรณ์ที่ตั้งให้ส่งอีเมล
ค้นหาว่าเป็นใครจาก Reverse DNS และปริมาณอีเมล
dig +short -x 203.0.113.99
whois 203.0.113.99 | grep -iE 'orgname|netname|descr' | head -3กลุ่มที่ 3 ผู้ส่งที่ไม่รู้จักและไม่ผ่าน
อาจเป็นการปลอมแปลงจริง หรืออาจเป็นการส่งต่ออีเมลซึ่งทำให้ SPF ไม่ผ่านโดยธรรมชาติ ดูปริมาณประกอบ หากมีเพียงไม่กี่ฉบับมักเป็นการส่งต่อ หากมีหลายพันฉบับต่อวันคือการปลอมแปลง
ขั้นตอนที่ 4: แก้ผู้ส่งที่ถูกต้องให้ผ่าน
สำหรับเซิร์ฟเวอร์ของคุณเอง เพิ่มเข้า SPF
"v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all"สำหรับบริการภายนอก ให้ตั้ง DKIM ด้วยโดเมนของคุณ ซึ่งดีกว่าการเพิ่มเข้า SPF เพราะ
- DKIM ยังผ่านแม้อีเมลถูกส่งต่อ ส่วน SPF ไม่ผ่าน
- ไม่กินโควตาการค้นหา DNS ที่จำกัดไว้ 10 ครั้ง
ผู้ให้บริการที่จริงจังทุกรายมีตัวเลือกให้ตั้ง DKIM ด้วยโดเมนของลูกค้า มองหาคำว่า Domain Authentication หรือ Sender Authentication
ขั้นตอนที่ 5: เข้มนโยบายทีละขั้น
อย่ากระโดดไป p=reject ทันที ทำทีละขั้นโดยรอสองถึงสี่สัปดาห์ในแต่ละขั้น
# ขั้นที่ 1 สังเกตการณ์ เริ่มต้นที่นี่
"v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"
# ขั้นที่ 2 กักไว้ส่วนหนึ่ง
"v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]"
# ขั้นที่ 3 กักทั้งหมด
"v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]"
# ขั้นที่ 4 ปฏิเสธ
"v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; sp=reject; adkim=s; aspf=s"เกณฑ์ที่ควรใช้ตัดสินว่าพร้อมไปขั้นถัดไปหรือไม่คือ อีเมลที่ถูกต้องผ่าน DMARC มากกว่า 98% ติดต่อกันอย่างน้อยสองสัปดาห์
ตัวเลือกเพิ่มเติม sp=reject ใช้นโยบายเดียวกันกับซับโดเมน และ adkim=s กับ aspf=s คือบังคับให้โดเมนตรงกันแบบเข้มงวด ซึ่งควรใช้เมื่อผ่านขั้นก่อนหน้าแล้วเท่านั้น
ขั้นตอนที่ 6: ตั้งระบบเก็บรายงานอัตโนมัติ
#!/bin/bash
# ดึงไฟล์แนบจากกล่องรายงานแล้วสรุปอัตโนมัติ
MAILDIR=/home/vmail/example.com/dmarc/Maildir/new
WORK=/tmp/dmarc-work
mkdir -p "$WORK"
cd "$WORK"
for m in "$MAILDIR"/*; do
[ -f "$m" ] || continue
munpack -q -f "$m" >/dev/null 2>&1
done
gunzip -f *.gz 2>/dev/null
for z in *.zip; do [ -f "$z" ] && unzip -oq "$z"; done
/usr/local/bin/dmarc-summary.sh *.xml > /var/log/dmarc-$(date +%F).txt
rm -f "$WORK"/*
echo "สรุปรายงาน DMARC ประจำวัน" | mail -s "รายงาน DMARC" \
-a /var/log/dmarc-$(date +%F).txt [email protected]หากไม่อยากเขียนเอง มีบริการวิเคราะห์รายงาน DMARC ที่ให้ใช้ฟรีสำหรับปริมาณน้อย ซึ่งแสดงผลเป็นกราฟและติดตามแนวโน้มได้ดีกว่า
ขั้นตอนที่ 7: ระวังเรื่องปริมาณรายงาน
โดเมนที่ส่งอีเมลมากจะได้รับรายงานหลายสิบฉบับต่อวัน ซึ่งทำให้กล่องจดหมายเต็ม
- ใช้บัญชีเฉพาะสำหรับรับรายงาน อย่าใช้อีเมลส่วนตัว
- ตั้งโควตาให้เพียงพอและล้างอัตโนมัติหลังประมวลผลแล้ว
- พิจารณาปิด
rufซึ่งคือรายงานรายฉบับ เพราะมีปริมาณมากและมีข้อมูลส่วนบุคคล ผู้ให้บริการหลายรายไม่ส่งให้อยู่แล้ว
ปัญหาที่พบบ่อย
ไม่ได้รับรายงานเลย
ตรวจว่าระเบียน DMARC ถูกต้องและที่อยู่ในช่อง rua รับอีเมลได้จริง หากที่อยู่รับรายงานอยู่คนละโดเมนกับที่รายงาน ต้องเพิ่มระเบียนอนุญาตที่โดเมนปลายทาง
example.com._report._dmarc.otherdomain.com. TXT "v=DMARC1"เห็น IP แปลกจำนวนมาก
ตรวจว่าเป็นการส่งต่ออีเมลหรือการปลอมแปลง การส่งต่อมักมีปริมาณน้อยและ DKIM ผ่านแม้ SPF ไม่ผ่าน ส่วนการปลอมแปลงมักไม่ผ่านทั้งคู่
เข้มนโยบายแล้วอีเมลที่ถูกต้องถูกปฏิเสธ
ลดกลับไป p=none ทันที แล้วหาว่าผู้ส่งรายใดยังไม่ผ่านจากรายงาน แก้ให้ครบก่อนลองใหม่
รายงานอ่านไม่ออกเพราะรูปแบบต่างกัน
ผู้ให้บริการบางรายใช้โครงสร้าง XML ที่ต่างเล็กน้อย ใช้ xmllint --format ดูโครงสร้างจริงก่อนแล้วปรับสคริปต์ให้ตรง
ต้องการที่ปรึกษาด้านความปลอดภัยของระบบอีเมลองค์กร ติดต่อ THAI DATA CLOUD ได้ที่ https://thaidata.cloud/contact/
- Categories:
- Cloud
