רשומת DMARC ומדיניות: הגדרה, יישור ודוחות

רשומת DMARC תקינה ראויה לתשומת לב ב-2026, במיוחד במסגרת דרישות שולחים החלות עליכם. ל-Google ו-Yahoo כללים לקבוצות מסוימות של שולחים בהיקף גדול, ול-Microsoft דרישות משלה. היעדר אימות יכול להשפיע על סינון או דחייה, אך אינו הופך כל שליחה לבלתי אפשרית או בלתי נראית.

רשומת DMARC (Domain-based Message Authentication, Reporting, and Conformance) היא רשומת DNS TXT המבקשת טיפול בהודעות שמשתמשות בדומיין From הגלוי בלי אימות תקין ומיושר. היא מבוססת על SPF ו-DKIM, והמקבל שומר על מדיניות מקומית. מפרסמים בשם _dmarc של דומיין From בפועל; כמה רשומות DMARC באותו שם אינן תקינות, בניגוד לרשומות TXT לא קשורות.

מייסד עשוי להתמודד עם דואר שלא מגיע למשקיע, וספק עם 500 דומיינים עם פניות על חשבוניות QuickBooks חסרות. בדקו את הסיבה האמיתית. אימות אינו מבטיח הגעה לתיבת הדואר הנכנס בכל היקף.

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

מה רשומת DMARC עושה

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

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

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

שלוש אפשרויות המדיניות: תג p=

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

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

הכינו את המעבר. הפרקים הבאים מציעים מסלול, לא לוח זמנים מובטח לכל סביבה.

אימות עם SPF, DKIM ו-DMARC

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

כך שלושת המרכיבים משתלבים:

SPF (Sender Policy Framework)

תפקיד: מתיר מערכות שליחה לדומיין מעטפת MAIL FROM או HELO במקרים המתאימים. אינו מאמת לבדו את From הגלוי.

מגבלה: העברה עלולה להכשיל SPF כששולח המעטפת המקורי נשמר וכתובת המעביר אינה מורשית. לא כל תצורת העברה פועלת כך.

ראו הגדרת SPF, יסודות SPF לדוא״ל וטיפול במגבלת חיפוש SPF להנחיות והערכה.

DKIM (DomainKeys Identified Mail)

תפקיד: חתימה בכותרת ההודעה מכסה כותרות נבחרות וגוף בתחום החתימה. המקבל מאמת במפתח ציבורי ב-DNS לפי קנוניזציה.

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

DMARC (שכבת המדיניות)

הכלל: SPF מצליח ומיושר עם Header From, או לפחות חתימת DKIM תקינה ומיושרת אחת, מאפשרים הצלחת DMARC. הגדרת שתי השיטות מועילה, אך שיטה מצליחה ומיושרת אחת מספיקה.

ראו סדר הגדרת SPF, DKIM ו-DMARC לתמונה מלאה.

יישור בשפה פשוטה

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

להודעה יש בין היתר שתי זהויות שולח:

• Header From: הכתובת שהנמען רואה, למשל support@yourcompany.com.
• Envelope From (Return-Path): כתובת טכנית להחזרות, שיכולה להיות בניהול ספק חיצוני.

DMARC משווה From לדומיין SPF או DKIM. יישור מקל משווה דומיין ארגוני, ומחמיר דורש התאמה מדויקת. כשל נוצר רק בלי שיטה תקינה ומיושרת שמצליחה.

דוגמת Mailchimp או שירות שיווק

זו תצורת עלון להמחשה, לא אישור לברירת מחדל עדכנית:

• Header From: news@yourcompany.com
• Return-Path: דוגמת דומיין החזרות mail12.mailchimp.com, לא כתובת דוא״ל מלאה
• חתימת DKIM: עם d=mailchimp.com

ההערכה המשוערת בדוגמה:

• SPF משתמש במדיניות דומיין המעטפת בפועל תחת mailchimp.com; מניחים כאן הצלחה שיש לאמת.
• מניחים הצלחת DKIM עבור mailchimp.com.
• האם yourcompany.com מיושר עם mailchimp.com? לא.
• בלי שיטה מיושרת אחרת, תוצאת DMARC: כשל.

שתי בדיקות יכולות להצליח בלי הצלחת DMARC. זו המחשת יישור, לא טענה שכל הודעת ESP רגילה נכשלת.

הגישה: אימות דומיין מותאם

מפו כלי שיווק, CRM ושירותי הודעות תפעוליות והגדירו אימות נתמך למסלולים בפועל:

• יישור SPF: הגדירו דומיין החזרות משלכם כגון bounces.yourcompany.com עם TXT, MX או CNAME שהספק דורש. פרסום לבדו אינו משנה MAIL FROM. בדקו הצלחה ויישור: דומיין ארגוני משותף במצב מקל, והתאמה מדויקת במחמיר.
• יישור DKIM: פרסמו מפתח או האצלה נדרשים והגדירו לשירות חתימה עם d=yourcompany.com היכן שנתמך. בדקו הודעות אמיתיות.

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

ראו גם יישור DMARC.

החלה מדורגת: מודל הגשר

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

שלב 1: פרסום ניטור (שבועות 1-4)

הדוגמה אינה מבקשת הסגר או דחיית DMARC. החליפו דומיין וכתובת דיווח בערכים אמיתיים מאומתים:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

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

שלב 2: זיהוי כלי שליחה לא מוכרים

פתחו דוחות בכלי מתאים, ראו פרק הדוחות, וחלקו לשלוש קבוצות:

• מורשה ומיושר: פלטפורמות ידועות שאמורות להצליח ב-DMARC. חקרו כשל לפני הידוק.
• מורשה ולא מיושר: כלי שיווק ללא ידיעת IT, שירות תמיכה או CRM שפועל מאז 2022. אשרו בעלות ותקנו מסלולים לגיטימיים.
• איומים אפשריים: IP לא מוכר עשוי להעיד על התחזות, שירות שנשכח או העברה. חקרו; p=reject יכול לצמצם הודעות המתחזות ישירות לדומיין ונכשלות באימות מיושר, אצל מקבלים שמיישמים אותו.

תקנו ובדקו את כל המסלולים הלגיטימיים הידועים לפני המשך, גם אלה שלא מופיעים בדוחות.

שלב 3: בדיקת הסגר

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

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

pct= היה שדה אחוזים במפרט הישן והוסר מהמפרט הנוכחי. הדוגמה ההיסטורית pct=25 מתארת 25%, אך תיעוד ומימושים ישנים עשויים להתנהג אחרת. אחרי שלבים 1 ו-2 אל תקפצו באופן עיוור ל-100%; בדקו תמיכה בפועל וקצב עם תוכנית חזרה.

שלב 4: אכיפה

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

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

ראו הגדרת DMARC ודוגמאות רשומות, ואמתו אותן לפני פרסום.

העברה, ARC וחשיבות DKIM

״הדואר עובד, אבל לעורך הדין הוא חוזר״. העברה היא סיבה אפשרית, אך תשעה מתוך עשרה הוא ביטוי המחשה, לא נתון מאומת. בדקו מסלול ומדיניות בפועל.

איך העברה עלולה להכשיל SPF

שולחים ל-contact@smallfirm.com, שמועבר ל-personal@gmail.com. Gmail רואה את כתובת שרת smallfirm.com. אם MAIL FROM המקורי נשמר ו-SPF אינו מתיר smallfirm.com, הבדיקה עלולה להיכשל.

SPF בלבד יכול להפוך מסלול כזה לפגיע, לא לדחייה בלתי נמנעת. תצורה, אימות אחר ומדיניות קובעים.

מתי DKIM נשמר

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

לכן DKIM הוא מסלול משלים חשוב וחלק מדרישות שולחים החלות, לא הבטחה לכל העברה.

ARC כשגם DKIM מושפע

רשימת תפוצה יכולה להוסיף תוכן ושער דואר לשנות גוף, וכך להשפיע על DKIM לפי כיסוי וקנוניזציה. ARC (Authenticated Received Chain) מאפשר למתווכים להעביר תוצאות אימות קודמות עם חתימות. הוא אינו הופך כשל DMARC אוטומטית להצלחה.

Google ו-Microsoft יכולות לבדוק שרשרת ARC לפי תקינות, אמון במתווך ומדיניות מקומית. תשתית העברה מטפלת בכך בדרך כלל, אך מפעילי ממסר עצמאי עשויים להזדקק להגדרה. כותרות ARC אינן הוכחת תקלה או קבלה מובטחת.

ראו כשל DMARC והעברה.

RUA ו-RUF: אילו דוחות מועילים

אפשר לבקש דוחות מצטברים, בדרך כלל XML, באמצעות rua=. לא כל מקבל מדווח על כל הודעה, ויעד חיצוני עשוי לדרוש הרשאה נוספת. XML קריא, אך כלי ניתוח מועיל בהיקף גדול.

RUA: דוחות מצטברים

התג: rua=mailto:reports@yourdomain.com

התוצאות נאספות בדרך כלל פעם ביום, ללא הבטחת מועד. לדוגמה, IP 203.0.113.12 שלח 300 הודעות, 295 עברו ו-5 נכשלו. כיסוי ועיכובים משתנים, והצלחה וכשל אינם בהכרח מיקום סופי.

dmarc.org מציג כלים; בדקו יכולות עדכניות של Postmark ו-Valimail. חקרו מקורות מוכרים ולא מוכרים. IP לא מוכר אינו בהכרח תקיפה, ו-p=reject אינו מוכיח שכל הודעה שנכשלה בדוח אכן נחסמה.

מאמרי דוחות DMARC ו-RUA מספקים הקשר לניתוח נוסף.

RUF: דוחות כשל מפורטים

התג: ruf=mailto:forensics@yourdomain.com

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

בהודעות סודיות עולות שאלות פרטיות וציות. העריכו יעד, גישה, שמירה ובסיס חוקי וצמצמו את המידע הנאסף.

תמיכת RUF אצל מקבלים גדולים משתנה; Gmail אינו שולח דוחות כאלה. RUA הוא לכן לעיתים קרובות התחלה מעשית. בחרו דוחות מפורטים עם צורך ברור והגנות מתאימות; תועלת ורעש תלויים בסביבה.

מאמר DMARC RUF דן בשיקולי חקירה ופרטיות אלה.

זהירות בהערכת רעש

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

מתי לשקול p=reject

שקלו p=reject לאחר בדיקה מספקת של מסלולים לגיטימיים. הרשימה תומכת בהחלטה, לא מבטיחה תוצאה:

• דוגמת ניטור של 30 ימים: בדקו זרמים חודשיים ורבעוניים בפועל; התקופה אינה מבטיחה כיסוי, ושבוע יכול להיות מוגבל יותר.
• יישור מסלולים ראשיים: TrekMail, Google Workspace ו-Microsoft 365 עוברים DMARC באמת, לא רק SPF או DKIM בנפרד.
• בדיקת ספקים חיצוניים: לשיווק, הודעות תפעוליות, CRM ותמיכה יש שיטת אימות תקינה ומיושרת.
• אישור צוותי שיווק: שאלו את כל הצוותים על כלים חדשים; שירות שהחל ביום שלישי הקודם עשוי עדיין לא להופיע בדוחות.
• מדיניות תת-דומיין: בדקו גילוי וירושה כאשר אין מדיניות עצמאית. sp=none יכול לקבוע בקשה שונה לתת-דומיינים מכוסים בדוגמה: v=DMARC1; p=reject; sp=none; rua=mailto:reports@yourdomain.com. נטרו את פער ההגנה המתוכנן ובדקו sp= ורשומות תת-דומיין בנפרד.

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

ראו הסבר מדיניות reject וכשל DMARC: אבחון ותיקון.

ניהול דומיינים רבים ב-TrekMail

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

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

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

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

SMTP מנוהל עשוי לתמוך בחתימה עם הדומיין שלכם. בדקו בורר, DNS ויישור בכל דומיין; SMTP חיצוני ושירותים נוספים דורשים תצורה משלהם.

ההשוואה ההיסטורית מציגה Pro ב-$8 לחודש עם 100 דומיינים, 300 משתמשים לדומיין ו-50GB אחסון משותף, מול $6-12 למשתמש בשירותים אחרים. בדקו חוזים, מחירים, שירותים וגבולות כיום. מחיר פלטפורמה אינו מבטיח גידול בלתי מוגבל או הגדרת DNS חיצוני אוטומטית.

Agency מתוארת ל-1,000+ דומיינים. בדקו יכולות, קיבולת ותנאים בפירוט המחירים.

השורה התחתונה על רשומת DMARC

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

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

דומיין משלכם יכול להיראות כמשימת אחר צהריים, אך צריך תחזוקה. תיק לקוחות מחייב תהליך חוזר; TrekMail יכולה לעזור לפי יכולות ותצורה נוכחיות.

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

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