DMARC reject: התאמה, בדיקות ומעבר מבוקר

מדיניות reject ב-DMARC מבקשת מנמענים לדחות הודעות שנכשלות ב-DMARC. עם p=none אין בקשת אכיפה לפי DMARC; דיווח עשוי לספק מידע אך אינו מובטח. quarantine הוא כבר אכיפה. מעבר מוקדם מדי ל-p=reject עלול לפגוע בחשבוניות, באיפוסי סיסמה ובתשובות תמיכה. לבסיס ההגדרה, התחילו בדואר עסקי.

תוקפים אינם מחכים להכנה, אך מדיניות מחמירה לא מתקנת אימות לקוי. המדריך מסייע להעריך מדיניות reject ב-DMARC, את התנאים והשלבים ואת דפוסי הכשל החשובים ב-2025 וב-2026.

תנאי	יעד	החשיבות לפני reject
תצפית מייצגת	30 יום כהנחיה מעשית ראשונית	בדיקת תעבורה חודשית; תעבורה רבעונית ונדירה עשויה לדרוש יותר זמן
בדיקת התאמה	התאמה תקינה של 100% מהשולחים הלגיטימיים	הצלחת אימות SPF או DKIM בלבד אינה מספיקה; דוחות אינם מוכיחים כיסוי מלא
בדיקת מוניטין	שיעור ספאם מתחת ל-0.1%	DMARC מחמיר אינו מתקן מוניטין ירוד
בדיקת העברה	DKIM נשאר תקין ומותאם	SPF המקורי עשוי להיכשל בהעברה
מדיניות תת-דומיינים	בחינת התג `sp`	מדיניות בירושה עשויה להשפיע על פיתוח ותת-דומיינים ישנים

מה מדיניות reject עושה בפועל?

מדיניות reject ב-DMARC מבקשת לדחות דואר כאשר לא SPF ולא DKIM עוברים עם התאמה. היא עשויה לצמצם התחזות ישירה לדומיין אצל נמענים שמיישמים אותה, אך מדיניות מקומית שלהם יכולה לקבל קדימות.

התאמה היא העיקר: DMARC משווה את הדומיין המאומת לדומיין From המוצג. לפי המצב, עשוי להספיק אותו דומיין ארגוני או להידרש זהות מלאה. אימות שעובר אינו מוכיח תוכן בטוח.

RFC 7489 מתאר pct ושיקול דעת מקומי. התמיכה באחוזים ויישומם משתנים. מדיניות reject ב-DMARC אינה מתקנת מוניטין, תוכן לא רצוי או הגדרת שליחה שגויה.

תנאי 1: תצפית של 30 יום והערכת הכיסוי

אל תבססו מדיניות reject ב-DMARC רק על תקופה קצרה ללא כשלים. שלושים יום הם הנחיה מעשית, לא כלל עולמי שמוכיח מוכנות. דיווח רבעוני ואוטומציות נדירות עשויים לדרוש יותר זמן או בדיקות ממוקדות.

שבוע של דוחות תקינים יכול לפספס מקור חשוב. אחרי פרסום p=reject, השגיאה עשויה להתגלות רק במחזור החשבוניות הבא.

לדוגמה: כלי חיוב SaaS שולח רק בתחילת החודש. DKIM משתמש בדומיין הספק וגם דומיין ההחזרות אינו מותאם. עם p=none אפשר לפספס זאת אם לא בוחנים דוחות; עם p=reject חשבוניות עשויות להידחות.

בדקו גם מקורות נדירים אך חשובים: חיוב, משאבי אנוש, התראות סורק, טפסים ותמיכה. מדיניות reject ב-DMARC באה אחרי מיפוי מקורות השליחה ובדיקות, לא לפניהם.

בדקו DNS תחילה. המדריך לרשומות DNS נדרשות של TrekMail מתאר SPF, DKIM, MX ו-DMARC לפי ההגדרה המתאימה.

תנאי 2: בדקו אימות והתאמה יחד

לפני מדיניות reject ב-DMARC, ודאו שכל מקור תקין עובר SPF או DKIM עם התאמה. פלטפורמה יכולה לאמת את דומיין הספק ועדיין להיכשל ב-DMARC לדומיין From שלכם.

מלכודת SaaS נפוצה:

From: support@yourcompany.com
Return-Path: bounce.vendor-mail.com ו-SPF עובר עבורו
DKIM: d=vendor-mail.com ו-DKIM עובר עבורו
תוצאה: DMARC נכשל עבור yourcompany.com

לוח הספק עשוי להציג אימות תקין, אך הדומיין שלכם אינו מותאם. עם מדיניות reject ב-DMARC, הודעות כאלה עשויות להידחות.

הגדירו אימות דומיין אצל הספק:

פרסמו רשומות DKIM שסופקו והפעילו חתימה לדומיין שלכם.
הגדירו דומיין החזרות או return-path משלכם לפי הצורך בהתאמת SPF.
בדקו הודעות אמיתיות וכותרות, לא רק סימון תקין בלוח.

SPF מוגבל לעשרה מנגנונים ופרמטרים משנים שמפעילים חיפוש DNS בזמן ההערכה; זה אינו מספר כל חבילות השאילתות. כמה רשומות SPF גורמות לשגיאה קבועה. ראו מדריך הגדרת דומיין והתאימו אותו לשולח בפועל.

תנאי 3: בדקו מוניטין

מדיניות reject ב-DMARC יכולה להגביל שליחה לא מורשית בשם הדומיין, אך אינה משפרת מוניטין בעצמה. גם דואר מאומת ומותאם יכול להיות לא רצוי. חקרו תלונות ואימות בנפרד.

Google ממליצה לשולחים בתפוצה רחבה לשמור על שיעור ספאם מתחת ל-0.1% ולהימנע מ-0.3% ומעלה, שעשויים להשפיע על זכאות לצעדי טיפול. Yahoo ממליצה גם על פחות מ-0.3%. בדקו הגדרות ותנאים עדכניים.

אם Postmaster מציג 0.18%, חקרו איכות רשימה ורלוונטיות. הדבר אינו שולל בעיית DMARC במקביל: תלונות ושגיאות אימות יכולות להתקיים יחד.

לפני מדיניות reject ב-DMARC, בדקו:

נתוני הספאם ב-Google Postmaster Tools לדומיין השליחה הראשי.
עלייה בתלונות לפי קמפיין, רשימה או כלי.
החזרות שמצביעות על נתונים ישנים או חשבונות תפקיד.
סיכון מוניטין משותף לדואר תפעולי ושיווקי.

מקורות: שאלות נפוצות על הנחיות Google לשולחים והמלצות Yahoo לשולחים.

תנאי 4: בדקו נתיבי העברה חשובים

בהעברה, שרת החיבור משתנה ו-SPF המקורי עשוי להיכשל. DKIM תקין ומותאם יכול לאפשר ל-DMARC לעבור. לפני מדיניות reject ב-DMARC, בדקו נתיבים בפועל: DKIM או שירות העברה אינם מבטיחים טיפול תקין בכל מצב.

כשל SPF בדוחות אינו התחזות אוטומטית. חקרו מעבירים, רשימות תפוצה ושערים. אם הנתונים החתומים נשמרים לאחר קנוניזציה ו-DKIM מותאם, DMARC יכול לעבור.

בדקו חתימה והתאמה בכל זרם חשוב לפני מדיניות reject ב-DMARC. SRS עשוי לסייע ל-SPF של זהות מעטפת משוכתבת, אך אינו מתאים אותה אוטומטית ל-From המקורי.

תיעוד TrekMail מתאר כשל SPF בהעברה וחתימת דומיין בנתיב מנוהל נתמך. בדקו הגדרות ותוצאות אמיתיות וקראו גם על העברת דואר.

ראו ההודעות שלי מגיעות לספאם והגדרות IMAP ו-SMTP לבחינת אימות ושליחה לפי מסלול. הנמען מחליט אם להשתמש ב-ARC, והוא אינו מבטיח קבלה.

תנאי 5: בחנו מדיניות תת-דומיינים בירושה

מדיניות reject ב-DMARC של הדומיין הארגוני עשויה לעבור בירושה ל-dev.example.com ול-alerts.example.com כשאין להם רשומת DMARC עצמאית רלוונטית. בחנו sp וגילוי מדיניות.

דואר הייצור יכול להיות תקין בעוד שסביבת בדיקות, מדפסות, סורקים וכלים ישנים לא נבדקו. מדיניות בירושה עשויה להשפיע עליהם.

דוגמה עם sp:

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.com

זו בקשת reject לדומיין הראשי ו-none לתת-דומיינים שיורשים אותה. רשומה עצמאית בתת-דומיין עשויה לקבל קדימות. אין זו הגדרה לתת-דומיין בדיקה אחד בלבד; בדקו את כל המקורות הרלוונטיים.

דיווח סביב מדיניות reject ב-DMARC עשוי לחשוף CRM ישן, כלי שיווק או שרתי יישומים. הכיסוי חלקי וממסר לא מוכר אינו הוכחת שימוש לרעה. השלימו מלאי פנימי.

החילו reject בהדרגה

מדיניות reject ב-DMARC יכולה לבוא אחרי ניטור ו-quarantine. התמיכה ב-pct משתנה ואינה מוכיחה שהמעבר בטוח. שלבו דוחות מייצגים, בדיקות ותוכנית התאוששות.

דוגמה לשלבים:

בקשו 10% quarantine למשך שבוע ראשון, אצל נמענים שתומכים בכך.
העריכו 100% quarantine במשך עוד שבוע עד שבועיים, בהתאמה לתעבורה שלכם.
שקלו reject אחרי בדיקת תמיכה, חיוב, אימות והעברה.

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

הרשומות הן חלופות עוקבות, לא לפרסום יחד. quarantine אינו מבטיח עותק ספאם שניתן לשחזר, ו-reject אינו אומר שתמיד אין הודעת החזרה או ניסיון חוזר. מדיניות reject ב-DMARC עלולה לדחות דואר תקין לפני שהמשתמש רואה אותו.

ניהול reject לכמה דומיינים

מדיניות reject ב-DMARC דורשת תשומת לב גם בדומיין אחד. בעשרה, בחמישים או בחמש מאות נוספים ספקים שונים, הגדרות DKIM וסטיות DNS. זהו מקורות בכל דומיין ואל תסתמכו רק על זיכרון המשתמשים.

ניהול מפוצל: ניתוח XML ידני, זיהוי ספקים ותיקון רשומות בכל דומיין, בעוד מקור חדש עשוי להישאר מחוץ למלאי.

ניהול משולב: ריכוז דומיינים, נהלי DNS עקביים ובדיקת אימות לפי נתיב השליחה בפועל.

TrekMail עשוי לעזור. המחירים בתשלום המוזכרים מתחילים ב-$3.50 לחודש וכוללים SMTP מנוהל וניהול דומיינים, IMAP, העברה ו-DNS. Nano מתואר כחינמי לעד 10 דומיינים עם SMTP משלכם. בדקו תנאים עדכניים. לכמה מותגים ולקוחות, ראו אירוח דואר למספר דומיינים.

אחידות בתהליכי העבודה יכולה להקל על צוותים וסוכנויות, אך אינה מבטיחה חיסכון או פחות פניות אחרי מדיניות reject ב-DMARC. התוצאה תלויה במערכות ובתהליכים.

ראו רשומות DNS נדרשות וtrekmail.net/pricing. למסלולים בתשלום עשויה להיות תקופת ניסיון של 14 יום שדורשת כרטיס אשראי; Nano מתואר ללא דרישת כרטיס. בדקו הצעות עדכניות.

סיכום: מתי לפרסם reject?

שקלו מדיניות reject ב-DMARC אחרי תצפית מייצגת, למשל 30 יום כהנחיה ראשונית, התאמה של מקורות תקינים, בקרה על תלונות, DKIM שנבדק בהעברה ומדיניות תת-דומיינים מכוונת. הזמן לבדו אינו מוכיח מוכנות; בדקו גם תעבורה נדירה.

זהו שולחים, קראו כותרות ותקנו DNS ושליחה. פרסמו לאחר מכן מדיניות reject ב-DMARC מתאימה עם ניטור ותוכנית התאוששות. היא עשויה לצמצם התחזות ישירה, אך אינה מונעת כל מתקפה או בעיית מסירה.

לניהול דומיינים וליכולות עדכניות, ראו TrekMail או השוו מסלולים בtrekmail.net/pricing.