מה צריך להיות ידוע לפני המעבר
מפו תיבות, CRM, אתר, דיוור, חשבוניות, תמיכה ודומייני משנה. לכל מקור רשמו בעל אחריות, תדירות שליחה, דומיין From ומסלול אימות שעובר וגם תואם. דואר חודשי או עונתי עלול לא להופיע בחלון תצפית קצר.
דוחות מצטברים אינם תחליף להודעת בדיקה מכל מערכת. אין להסיק שהיעדר דיווח מוכיח היעדר בעיה: לא כל מקבל שולח דוחות, ואיסוף שלהם יכול להיכשל. בדקו גם שכתובת הדוחות וההרשאות לספק דוחות חיצוני הוגדרו כראוי.
תקן חדש ותיעוד ספקים: למה לא להסתמך על pct
RFC 9989 פורסם במאי 2026 והחליף את RFC 7489. הוא הסיר את תג pct בעקבות חוסר עקביות ביישום והוסיף תג בדיקה t. בזמן בדיקת המקורות, תיעוד הפריסה של Google עדיין מתאר מעבר לפי אחוזים.
לכן אין להניח ש-pct=10 יגן באופן אחיד על שאר הדואר מפני אכיפה, ואין להעתיק p=reject עם תג בדיקה כהגדרה בטוחה לכל המקבלים. מימושים ותיקים עשויים להתעלם מתג חדש. המדריך משתמש בהחלטות מוכנות, בבדיקת התנהגות ובתיאום עם הספק.
תיעוד Recommended DMARC rollout של Google נבדק ב-29.10.2026 ועדיין הציג דוגמאות pct. אין בכך הבטחה שכל מקבל יישם אותן לפי התקן החדש. לכן תהליך ההחלטה כאן נשען על ראיות משולחים לגיטימיים, ולא על מתכון אחוזים להעתקה.
תנאים להתקדמות בין השלבים
הטבלה היא מסגרת החלטה מוצעת של CyberFixCrew, ולא לוח זמנים אוניברסלי או תוצאת בדיקה של תשתית לקוח.
| שלב | ראיה נדרשת | סיבה להמתין |
|---|---|---|
| תצפית עם none | מפת שולחים ודוחות שמגיעים למי שמטפל בהם | אין בעל אחריות למקור שליחה |
| תיקון מקורות | הודעות חדשות עם SPF או DKIM תקפים ותואמים | חשבוניות או אוטומציה שטרם נבדקו |
| בחינת quarantine | תוכנית מעקב, דרך חזרה ומדגם תהליכים עסקיים | הודעות לגיטימיות ממשיכות להיכשל |
| החלטה על reject | חריגים מוסברים, אישור בעל המערכת ובדיקת השפעות | לא ברור מי מטפל בדחייה אחרי השינוי |
ביצוע מבוקר ותיעוד שינוי
תעדו את הרשומה המלאה הקיימת ואת מועד השינוי. בדקו אם לדומייני משנה יש מדיניות עצמאית ומהי הירושה הרלוונטית. אם מתחילים בתחום מצומצם, ודאו שהשליחה אכן משתמשת בו ושאין השפעה לא מכוונת על שירות אחר.
בעל הדומיין או נציגו המאושר מאשר חריגים והתקדמות. ממנים גורם לבדיקת דחיות ודיווחים אחרי השינוי, מתעדים מה יגרום לעצירה ומי מוסמך להחזיר תצורה. אין מספר ימים קבוע שמחליף מיפוי שולחים.
- מאשרים את התכולה ואת האחראי לביצוע ולמעקב.
- מפרסמים את השינוי שהוחלט עליו, תוך שמירת יעד הדוחות והגדרות ההתאמה הרלוונטיות.
- בודקים הודעות חדשות מכל זרם חיוני ומול נמעני בדיקה מתאימים.
- עוקבים אחר דחיות, תלונות ודוחות ומסווגים חריגים לפני תיקון נוסף.
- אם נפגע דואר לגיטימי, מפעילים את תוכנית החזרה ומבררים את הסיבה.
מה אכיפה אינה מבטיחה
reject מבטא העדפה של בעל הדומיין לטיפול בהודעות שנכשלות; המקבל מפעיל גם מדיניות משלו. חזרה ל-none אינה משחזרת הודעה שנדחתה קודם, ושינוי DNS עשוי להיראות בזמנים שונים בגלל מטמון.
DMARC אינו מונע התחזות בשם תצוגה, דומיין דומה או הונאה מחשבון לגיטימי שנפרץ. לכן ממשיכים גם באימות גישה ובבדיקה עצמאית של בקשות תשלום.
