איך להגדיר DMARC ולבדוק מקורות שליחה

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

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

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

מה עושה DMARC?

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

DMARC הוא קיצור של Domain-based Message Authentication, Reporting, and Conformance. מפרסמים מדיניות ומבקשים דוחות על זרימות שנצפו. המפרט הבסיסי הוא RFC 7489.

אלה הכללים החשובים:

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

Google דורשת משולחים בכמויות גדולות SPF, DKIM ו-DMARC עם מדיניות של לפחות p=none, לצד דרישות ההתאמה הרלוונטיות. לא כל דרישות השליחה בכמויות גדולות חלות אוטומטית על כל שולח. ראו שאלות נפוצות על הנחיות השולחים של Google.

מה בודקים לפני DMARC?

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

בדקו שלושה דברים:

1. SPF: השתמשו ברשומה אחת לכל דומיין מעטפת רלוונטי, במסגרת מגבלת 10 המנגנונים והפרמטרים המשנים המחייבים DNS, כולל הערכה מקוננת. זו אינה מגבלה על כל שאילתות ה-DNS יחד.
2. DKIM: הפעילו במקום שנתמך והשתמשו במפתחות של 2048 ביט כשהספק תומך בכך.
3. מיפוי מקורות: כללו דואר, CRM, חיוב, תמיכה, טפסים, סורקים ושיווק.

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

אפליקציית החיוב שולחת מ-billing@yourdomain.com, אך חותמת בדומיין הספק ומשתמשת ב-return-path שלו. SPF ו-DKIM עשויים לעבור עבורו, אך DMARC עלול להיכשל עבור דומיין From שלכם משום שאין אימות שהצליח ומתאים.

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

שלב 1: פרסום רשומת ניטור בלבד

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

צרו TXT ב-_dmarc.yourdomain.com עם הערך:

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

אותו ערך בפורמט קובץ אזור, לא רשומה נוספת לפרסום לצדו:

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

זה תואם לדוגמת RFC 7489. השתמשו בכתובת ייעודית או בכינוי שמישהו מנהל; דוחות מצטברים הם XML ועלולים להיערם. בדקו פרטיות, גישה והרשאת DNS אפשרית ליעד חיצוני.

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

שלב 2: קריאת דוחות ובדיקת מקורות

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

דוחות עשויים להציג:

• כתובות IP שנצפו בשליחה
• תוצאות אימות SPF
• תוצאות אימות DKIM
• תוצאות DMARC הכוללות התאמה ל-From
• הטיפול שעליו דיווח הנמען

הבחינו בין מקורות שנבדקו לתעבורה שעדיין דורשת בדיקה.

תקנו שגיאות במקורות לגיטימיים מאומתים. IP לא מוכר עשוי להיות שרת העברה או ממסר משותף ולא הוכחה לניצול לרעה. הצלחת אימות אינה מוכיחה תוכן בטוח.

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

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

שלב 3: תיקון התאמה, לא רק אימות

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

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

פתרונות נפוצים:

• פלטפורמות שיווק: הגדירו חתימת DKIM לדומיין שלכם במקום שנתמך.
• טיפול בהחזרות: הגדירו return-path מותאם או דומיין החזרות אם הספק תומך בכך.
• Microsoft 365: הפעילו ובדקו DKIM לדומיין שלכם לפני אכיפה.
• שליחה מנוהלת של TrekMail: פרסמו את ערכי SPF ו-DKIM הנדרשים להגדרה בפועל.

פעלו לפי ספק השליחה היוצאת האמיתי. TrekMail עשויה להציע עזרה בהגדרה, SMTP משלכם ב-Nano או SMTP מנוהל בתוכניות בתשלום. הפרדת התיבות ממנוע השליחה והיקף המשאבים תלויים בתוכנית ובהגדרות.

Nano מתוארת עם SMTP משלכם, והתוכניות בתשלום עם SMTP מנוהל. מחיר הפתיחה המוזכר הוא $3.50 לחודש, לצד ניסיון חינם של 14 ימים בתוכניות בתשלום ואפשרות Nano חינמית ללא כרטיס. בדקו מחירים, תכונות ותנאי ניסיון עדכניים במחירי TrekMail.

שלב 4: בחינת quarantine

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

אם מתאים, החליפו את ערך הרשומה הנוכחית:

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

מדוע אפשר לשקול הסגר לפני סירוב?

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

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

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

שלב 5: בחינת reject לאחר בדיקה מספקת

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

מדיניות סופית מתאימה עשויה להחליף את הרשומה הנוכחית:

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

RFC 7489 מתאר בקשת סירוב עם p=reject. נמענים יכולים להחיל חריגים מקומיים; אין הבטחה שכל הודעה תיחסם.

לפני המעבר בדקו:

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

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

טעויות נפוצות שפוגעות בדואר

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

• אכיפה לפני בדיקת DKIM והמסלולים
• פרסום רשומות SPF מרובות במקום רשומה מתאימה אחת
• הנחה שהצלחת SPF פירושה הצלחת DMARC
• שכחת ספקים ששולחים מעט דואר
• מעבר ישיר מהיעדר DMARC ל-p=reject
• שליחת דוחות לכתובת שאיש אינו בודק

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

רשימה קצרה להגדרת DMARC

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

1. מפו מקורות המשתמשים בדומיין.
2. השתמשו ב-SPF תקף אחד לכל דומיין מעטפת רלוונטי במסגרת המגבלות.
3. הפעילו ובדקו DKIM במקום שנתמך.
4. פרסמו מדיניות ניטור כגון v=DMARC1; p=none; rua=mailto:....
5. חקרו דוחות לצד לוגים ומידע על המקורות.
6. תקנו שגיאות אימות ובדקו התאמה למקורות לגיטימיים.
7. בחנו p=quarantine והשפעותיה.
8. המשיכו לבדוק נתונים וזרימות חיוניות.
9. בחנו p=reject עם בדיקות ותוכנית התאוששות.

סיכום: הגדרת DMARC באופן מסודר

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

בעשרות או מאות דומיינים סביבת ניהול אחידה עשויה לעזור. TrekMail יכולה להציע דומיינים אישיים, תיבות IMAP, catch-all, העברה, העתקת דואר ו-SMTP משלכם או מנוהל לפי התוכנית. IMAP מעתיק הודעות נתמכות; מעבר MX ונתוני יישומים אחרים דורשים טיפול נפרד. השוו עלויות ומגבלות לסביבה שלכם.

זו הדרך המעשית להבין איך להגדיר DMARC: לבדוק תחילה, לבחון התאמה ולהעריך מדיניות בעזרת יותר מדוחות בלבד.