read receipts
כיצד לקרוא את מדיניות DMARC של חברה בעשר שניות (ומה היא לא אומרת לך)
השורה שמציינת מה בעלי הדומיין רוצים שיעשו עם דואר מזויף היא ציבורית והיא רק חיפוש אחד משם. זו העדפה מוצהרת — לא מסנן ספאם, ולא הבטחה לגבי תיבת הדואר שלך.
חיפוש DNS אחד אומר לך מה חברה ביקשה משרתי הדואר בעולם לעשות עם דואר מזויף שנשלח בשמה. הרשומה היא ציבורית, והפקודה היא שורה אחת: dig +short TXT _dmarc.example.com. מה שחוזר היא מחרוזת קצרה של הגדרות, והיא מכילה הוראה אחת — p=none, p=quarantine או p=reject — המציינת את ההעדפה של בעל הדומיין כאשר הודעה המשתמשת בדומיין זה נכשלת בהתחייבות.
הספציפיקציה הנוכחית, RFC 9989, שפורסמה במאי 2026 כמסמך IETF Standards Track, החליפה את RFC 7489 הישנה יותר. היא מגדירה את שלוש הערכים כמעט בקיצור:
p=none— "בעל הדומיין לא מביע שום העדפה."p=quarantine— "בעל הדומיין סבור שדואר כזה חשוד. יתכן שהדואר תקף, אך הכשל יוצר חשש משמעותי."p=reject— "בעל הדומיין סבור שכל כשל כזה הוא ראיה ברורה לכך שהשימוש בשם הדומיין אינו תקף."
קרא את המילים האלה שוב, כי הן חלשות יותר מרוב ההסברים על DMARC שמודים. מדיניות היא העדפה, המפורסמת על ידי השולח למען מקבלים לשקול. היא לא הוראה שמקבל חייב לבצע. RFC 9989 אומר זאת במשפט אחד: "הטיפול הסופי בכל הודעה הוא תמיד עניין של מדיניות מקומית וזה משמור לשיקול דעתו של מקבל הדואר." אותו חלק מוסיף את שני הצדדים של ההשלכה — מקבלים "עשויים לבחור לדחות או להכניס בקווארנטינה הודעה גם אם היא עוברת את בדיקת DMARC", והם "לא צריכים לדחות הודעות רק בגלל מדיניות מפורסמת של 'דחיה'", בדיוק כדי שדואר לגיטימי שנשלח בדרכים ש-DMARC לא יכול לתאר, ורשימות תפוצה, לא יוכחסו.
אז מה בדיוק p=none מודה? פחות מאשר בדרך כלל מאשימים אותו. במונחי הספציפיקציה עצמה זו Monitoring Mode: בעל הדומיין אוסף דוחות מצטברים ו"לא מביע העדפת טיפול בהודעות הנכשלות בהתחייבות DMARC", בעוד שמקבל שפורס DMARC "יכול עדיין" לאמת את השימוש בדומיין. מה שזה לא עושה זה להחליף דברים באתר הקבלה. מסננת הספאם של הספק שלך, ניקוד המוניטין, בדיקות URL וניתוח קובץ הן מכונות נפרדות שפועלות ללא קשר למה שהשולח פירסם. הודעה מזויפת שמגיעה לדומיין p=none לא מוקדמת לתיבת הדואר שלך על ידי הרשומה; היא פשוט מסורה למקבל ללא העדפה מוצהרת, והמקבל מחליט.
החצי השני של אי-ההבנה רץ בדרך השנייה. DMARC לא קורא את החלק המסוכן של דואר דיוג. הספציפיקציה שלה עצמה מפרטת מה הוא מתכוון להיות מחוץ לטווח, ו"content analysis" הוא ברשימה הזו, בדיוק במילים האלה. היא גם קובעת של-DMARC "לא מטפל בשימוש בשמות דומיין הדומים מבחינה ויזואלית או בהשימוש לרעה בשם התצוגה הקריא לאדם RFC5322.From" — שתי הטריקים שנושאות את יותר הדואר של דוקלמציית מותגים. ובערך של מעבר: "מעבר DMARC בעצמו לא מובטח שההסלמה לתיבת הדואר של הנמען תהיה בטוחה או רצויה." הודעה משוחרת כראוי מדומיין זריקה עוברת DMARC בצורה נקייה. DMARC עונה על מי הוא מורשה להשתמש בדומיין בכותרת From:. כלום יותר.
זה המקום בו כללי השולח בעל הנפח של 2024 דווח באופן שגוי באופן שגוי, כולל בגרסה הראשונה של מאמר זה. הנחיות השולח של Google דורשות משדרנים של 5,000 הודעות או יותר ביום לחשבונות Gmail "להגדיר הנחיות DMARC אימייל לתחום השליחה שלך," ואז אומרים, באותו נשימה: "מדיניות אכיפת DMARC שלך יכולה להיות מוגדרת ללא משהו." Yahoo's own Sender Hub, שחייבת להיקרא בנפרד במקום להניח שמעתקת Google, קובעת את הדרישה כ"פרסום מדיניות DMARC חוקית עם לפחות p=none - DMARC חייב להעביר," ולא משפר ערך סף נפח מספרי כלל. שתי קבוצות הדרישות נכנסו לתוקף מפברואר 2024. אף אחת לא כופה על כל אחד הרחק מ-p=none. מה ששניהם כופים בעצם הוא הנחיות שמיישרות קו: Google דורש ש"הדומיין בכותרת From: של השולח חייב להיות מיושר עם דומיין SPF או דומיין DKIM," ו-Yahoo אומר שיישור רגוע הוא מקובל. יישור, לא חומרה, הוא השער.
מה שמשאיר את הסיבה האמיתית שדומיינים יושבים בניטור, והיא תפעולית ולא פחדנית. המעבר ל-quarantine או reject פירושו קודם לכן למצוא כל שירות ששולח דואר בשמך — משכורת, הנפקות, שיווק, שולחן תמיכה שלא היה מתועד — והנחיות כל אחד כך שזה מיישר קו. הסטנדרט עצמו מכיר בסכנות שהופכות את זה לאט: שולחי צד שלישי לא מצופים או לא נכללים על ידי DMARC, העברה והפצה רשימות יכולות לשבור יישור דרך שום באשמת השולח, והמפרט מצביע מקבלים ב-RFC 7960 בדיוק למצבי כשל אלה. ארגון הפורסם p=none וקורא את הדוחות שלו עושה את העבודה בסדר שהמפרט מתאר. אחד ש משדר p=none ומתעלם מהדוחות הוא לא. מבחוץ, הרשומה בלבד לא יכולה להגיד לך איזה מהשניים אתה מסתכל.
אתה לא צריך טרמינל להסתכל. כלים חינמיים של חיפוש — בודק דומיין של dmarcian, בדיקת DMARC של MXToolbox — להביא את הרשומה והדפס את המדיניות בשבילך. עשה זאת עבור הבנק שלך, ספק המשכורת שלך, חברת התעופה שאתה טס. פשוט קרא את התשובה בשביל מה שהיא: הצהרת כוונה על ידי בעל הדומיין, קלט אחד בין רבים לפי החלטה שספק הדואר שלך עושה בעצמו, על סוג ספציפי אחד של זיוף. זה דבר שימושי באמת להיות מסוגל לקרוא בעשר שניות. זה לא פסק דין לגבי אם ההודעה הבאה שטוענת להיות מהמותג הזה בטוחה.
תיקון, 20 באוקטובר 2026. גרסה קודמת של מאמר זה תיארה p=none כהסלמה של זיופים לתיבת הדואר ו-p=reject בתור ההגדרה היחידה שחוסמת הודעה זויפה, אמרה שכללי השולח בעל הנפח של 2024 של Google ויאהו כפו על שולחים הרחק מ-p=none, וציטטה דמות של בערך אחד משלוש דומיינים באכיפה. תיאורי המדיניות תוקנו מול RFC 9989; Google ויאהו למעשה מקבלים p=none, מצוטט לעיל מהתיעוד שלהם; והנתון אכיפה הוסר כי הדוח הבסיסי לא משדר את המדגם או המכנה שלו. המאמר כעת גם מציין מה DMARC לא בוחן.
מקורות
- RFC 9989 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) — IETF, Standards Track, May 2026; obsoletes RFC 7489. Policy values §4.7, Monitoring Mode §3.2.12, out-of-scope list §2.4, policy enforcement §5.4
- Google — Email sender guidelines — Requirements in force from 1 February 2024, including "Your DMARC enforcement policy can be set to none" and the 5,000-messages-a-day threshold (checked 20 October 2026)
- Yahoo Sender Hub — Best practices — Yahoo's own bulk-sender requirements: "Publish a valid DMARC policy with at least p=none"; no numeric volume threshold published (checked 20 October 2026)
- DMARC.org — Overview — Plain-language introduction to SPF, DKIM and identifier alignment
- dmarcian Domain Checker — Free lookup that fetches and reads a domain's DMARC record