הגדרת DMARC: רשומות DNS, התאמה ובדיקת מדיניות

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

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

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

מה עושה הגדרת DMARC?

מפרסמים רשומת TXT בכתובת _dmarc.yourdomain.com כדי לבקש משרתי הקבלה טיפול מסוים בהודעות שאינן עומדות בדרישות DMARC. הצלחה דורשת מעבר של SPF או DKIM והתאמה של הדומיין המאומת לדומיין הגלוי בכותרת From.

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

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

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

רשומת ה-DNS הראשונה

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

את הדוגמה הבאה מפרסמים בשם המארח _dmarc. היא משתמשת בהתאמה מחמירה לבחירה, שאינה בהכרח ברירת המחדל המתאימה לכל סביבה:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100

אם התאמה מקלה מתאימה למבנה הדומיינים שלכם, אפשר לשנות את adkim=s ואת aspf=s. הדוגמה הבאה היא חלופה לקודמת, ולא רשומה נוספת לפרסום לצדה:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100

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

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

תגיות DMARC החשובות

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

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

התגית pct מתוארת ב-RFC 7489 כאמצעי לבקשת החלה מדורגת, אך תמיכת הנמענים ויישומם עשויים להשתנות. הערך 100 עם none אינו הופך ניטור לאכיפה. השיעור הוא בקשה, לא הבטחה לחלוקת הטיפול בפועל.

הגדרת DMARC שלב אחר שלב

בדקו SPF ו-DKIM, פרסמו מדיניות ניטור, בחנו דוחות והודעות אמיתיות ואז שקלו החמרת מדיניות. בדיקת DNS לבדה אינה מספיקה.

1. מפו את אירוח הדואר, ה-CRM, החיוב, התמיכה, הטפסים והשיווק שמשתמשים בדומיין שלכם.
2. בדקו SPF עבור דומייני שולח המעטפת ומקורות השליחה המורשים בפועל. אל תוסיפו כל שירות אוטומטית לאותה רשומה.
3. הפעילו DKIM בשירותים שתומכים בו ובדקו תוקף חתימה והתאמה, גם במסלולי העברה.
4. פרסמו מדיניות ניטור עם p=none.
5. בחנו דוחות למשל במשך 2 עד 4 שבועות כקו מנחה ראשוני. זרימות נדירות או תקופתיות עשויות לדרוש ניטור ארוך יותר או בדיקות ייעודיות.
6. שקלו p=quarantine לאחר בחינת זרימות לגיטימיות וסיכונים.
7. שקלו p=reject לאחר בדיקה מספקת של מקורות, ניסויים והכנת דרך חזרה.

בדיקות שימושיות משורת הפקודה:

dig TXT _dmarc.example.com +short

dig TXT example.com +short

dig TXT dkim._domainkey.example.com +short

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

; SPF
example.com.  IN TXT  "v=spf1 include:spf.trekmail.net include:_spf.google.com -all"

; DKIM
dkim._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

; DMARC
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100"

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

מתי DMARC עובר או נכשל?

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

בטבלה, ההתאמה מתייחסת למנגנון האימות שהצליח:

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

שלחתם מ-billing@example.com ולקוח העביר את ההודעה ל-Gmail. SPF עלול להיכשל עקב שינוי השרת, אך אם חתימת d=example.com נשארת תקפה עם ההתאמה הנדרשת, DMARC יכול לעבור.

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

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

מעבר מ-none ל-quarantine ול-reject

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

אפשרויות המדיניות המקובלות:

1. p=none: ללא בקשת הגבלה מכוח DMARC; ניטור וחקירה כשמידע זמין.
2. p=quarantine: בקשה להתייחס להודעות כחשודות, בלי הבטחה להעברה לתיקייה מסוימת.
3. p=reject: בקשת סירוב, בכפוף לאפשרות של חריגים מקומיים.

השלבים הבאים הם חלופות עוקבות. פרסמו מדיניות אחת בכל פעם והשאירו את הערות הדוגמה מחוץ לערך ה-TXT בפועל:

; Phase 1
v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100

; Phase 2
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100

; Phase 3
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100

sp= מאפשרת לציין מדיניות נורשת שונה לדומייני משנה. לפי RFC 7489, בעת שימוש במדיניות הדומיין הארגוני ובהיעדר sp, חלה המדיניות הראשית. רשומת DMARC ייעודית לדומיין המשנה עשויה לקבל קדימות; בדקו את גילוי המדיניות לכל דומיין.

טעויות נפוצות בהגדרת DMARC

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

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

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

סביבת ניהול משולבת עם TrekMail

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

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

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

רשימת בדיקה סופית להגדרת DMARC

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

1. מפו את מקורות השליחה המשתמשים בדומיין.
2. שמרו על רשומת SPF אחת לכל דומיין מעטפת רלוונטי ועל מגבלת עשרת המנגנונים והפרמטרים המשנים המחייבים DNS, כולל הערכה מקוננת.
3. הפעילו ובדקו DKIM במקום שנתמך.
4. התחילו בדרך כלל בפרסום מדיניות ניטור.
5. בחנו דוחות למשל במשך 2 עד 4 שבועות כקו מנחה ראשוני, ובדקו גם זרימות נדירות, חודשיות ורבעוניות.
6. שקלו quarantine לאחר בדיקת דואר לגיטימי.
7. שקלו reject עם בדיקות מספקות, ניטור ותוכנית התאוששות.

זהו תהליך ניהול מתמשך, לא משימה חד-פעמית לסימון.

TrekMail עשויה להציע מספר דומיינים, אחסון משותף, העברת IMAP ובדיקות DNS לפי התוכנית. בדקו את האפשרות החינמית ואת התנאים העדכניים ב-trekmail.net. לשליחה מנוהלת, עיינו בתוכניות.

המטרה היא לנהל סיכוני התחזות לדומיין ודחייה לא מכוונת של דואר לגיטימי. DMARC מסייע בכך, אך אינו מחליף את יתר ניהול הדואר.