איך להגדיר DMARC בלי לחסום מיילים לגיטימיים

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

איך DMARC עובד יחד עם SPF ו-DKIM

SPF בודק אם כתובת ה-IP ששלחה את המייל מורשית לפי הדומיין ב-Envelope From (השדה הטכני שהשרתים מדברים בו ביניהם). DKIM בודק חתימה קריפטוגרפית שמוכיחה שהתוכן לא שונה בדרך. DMARC בא ומוסיף תנאי שלישי: הדומיין שמופיע לנמען בשדה From חייב להיות "מיושר" (aligned) עם הדומיין שעבר את בדיקת ה-SPF או ה-DKIM. בלי ההתאמה הזו, תוקף יכול לשלוח מייל עם SPF תקין מדומיין אחר לגמרי, אבל להציג לנמען כתובת From מזויפת של המותג שלך.

לפני DMARC: לוודא ש-SPF ו-DKIM באמת עוברים

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

בניית רשומת ה-TXT של DMARC שלב אחר שלב

רשומת DMARC יושבת תמיד תחת _dmarc.yourdomain.com, לא בדומיין הראשי, מסוג רשומת TXT. הרשומה הראשונה שכדאי לפרסם היא רשומת תצפית — היא לא חוסמת כלום, רק אוספת דוחות:

כתובת ה-rua חייבת להיות תיבה שאתה בודק בפועל, או שירות ניתוח DMARC — בלעדיה אתה עיוור לגמרי למה שקורה. תגיות נוספות שכדאי להכיר: adkim ו-aspf קובעות יישור קשיח (s) או רפוי (r), ו-sp קובעת מדיניות נפרדת לתתי-דומיינים.

קריאת דוחות RUA בלי להסתבך

הדוחות מגיעים כקובצי XML מרוכזים (בדרך כלל פעם ביום מכל שרת מקבל גדול), ובעצמם הם לא נוחים לקריאה ידנית. מה שחשוב לחפש בהם: כל מקור שליחה (IP או שירות) שמופיע כ-fail ב-SPF או ב-DKIM. במקרים רבים זה לא ניסיון זיוף אלא פלטפורמה לגיטימית — פלטפורמת e-commerce ששולחת אישורי הזמנה בשם הדומיין שלך בלי שהוגדרה כראוי ב-SPF, או תוסף וורדפרס ששולח דרך wp_mail() ישירות משרת האחסון. הדוחות הם בדיוק הכלי שחושף את אלה לפני שעוברים למדיניות חוסמת.

מסלול ההסלמה: מ-p=none ל-quarantine ועד reject

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

1. p=none — תצפית בלבד, שלב חובה שממנו מתחילים תמיד.
2. p=quarantine; pct=25 — מתחילים להעביר חלק קטן מהתעבורה הכושלת לספאם, לא לחסום לגמרי, ובודקים שהדוחות עדיין נקיים.
3. p=quarantine; pct=100 — כל המייל הכושל עובר לספאם אצל הנמען.
4. p=reject — שרתי הקבלה דוחים לגמרי מיילים שלא עוברים יישור. השלב הסופי, רק אחרי שאין עוד שולחים לא-מיושרים בדוחות.

טעויות Alignment שגורמות לכישלון DMARC

• יישור קשיח מדי מוקדם מדי — adkim=s ו-aspf=s דורשים התאמה מדויקת של תת-הדומיין. אם ה-ESP חותם עםmail.yourdomain.com וה-From הוא yourdomain.com, יישור קשיח ייכשל — יישור רפוי (r) בדרך כלל בטוח יותר להתחלה.
• שכחת תתי-דומיינים — בלי sp מפורש, תתי-דומיינים יורשים את מדיניות הדומיין הראשי, מה שיכול להפתיע כשיש שרתי בדיקה או סביבות staging שממשיכים לשלוח מיילים.
• פלטפורמות e-commerce ו-SMTP של אחסון — Shopify, WooCommerce על וורדפרס, ופלטפורמות ישראליות כמו Grow שולחות מיילים טרנזקציוניים בשם הדומיין שלכם לרוב בלי שהוגדר SPF/DKIM נכון מולן — זו הסיבה השכיחה ביותר לדוחות fail לא צפויים.

רגולציה בישראל: DMARC לא פוטר מחוק התקשורת

DMARC פותר בעיית אימות טכני, אבל לא פוטר משמירה על תיקון 40 לחוק התקשורת (בזק ושידורים) — מייל שיווקי לנמען בישראל עדיין חייב הסכמה מפורשת מראש (opt-in), את המילה "פרסומת" בתחילת שורת הנושא, פרטי יצירת קשר ברורים של השולח, ואפשרות הסרה פשוטה. הגדרת SPF/DKIM/DMARC נכונה משפרת את הסיכוי שהמייל בכלל יגיע לתיבה — אבל היא לא תחליף לעמידה בדרישות החוק.