שאלות ותשובות בנושא אימייל מרקטינג ועבירוּת אימיילים

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

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

הסיבות שאימיילים מגיעים לספאם יכולות להיות טכניות כגון חוסר בהגדרות אימות (SPF/DKIM), או הגדרות לא מספקות או לא נכונות, מוניטין דומיין נמוך, כתובות IP חסומות של שפקי מערכות דיוור, תוכן שנראה “ספאמי”, דיווחי ספאם על ידי משתמשים, ירידה ב-Engagement (מעורבות) מצד הנמענים ועוד.

עבירוּת אימיילים (email deliverability) – בעברית קלה איך לדוור באימייל בלי להגיע אל הספאם או איך לצאת משם.

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

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

רבים מתבלבלים בין המונחים. deliverability שונה מ-delivery. מסירה” (Delivery) אומרת שהמייל התקבל על ידי השרת של הנמען בצד המקבל ולא חזר (Bounce). “עבירוּת” (Deliverability) היא השלב הבא והחשוב יותר – האם האימייל נחת ב-Inbox (תיבת הדואר הנכנס) או בתיבת הספאם? 

תקן DMARC הוא פרוטוקול שנועד להגנה על דומיינים ומותגים מפני התחזות (spoofing) ולניטור הפרוטוקולים לאימות הדומיין.

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

• מסמך RFC 9990 הוסיף לסכימת ה-XML שדות חדשים (בהם discovery_method, אינדיקציית מצב בדיקה ושדה generator).
• הפך דרישות פורמט מ”רצוי” ל”חובה”.
• ביטל את מגבלת הגודל בתגית rua.
• הפך את אימות יעדי הדיווח החיצוניים לחובה – כך שבלי רשומת ההרשאה החיצונית, דוחות לכלי ניטור חיצוני פשוט לא יישלחו.

ארבעה פעולות רצויות:

• להסיר את התגיות pct, rf ו-ri מהרשומה אם הן קיימות.
• לשקול הוספת np=reject לחסימת סאב-דומיינים לא קיימים.
• לוודא שכלי ניטור ה-DMARC שלכם תומך בסכימת הדוחות החדשה ושרשומת ההרשאה החיצונית במקומה.
• אם המדיניות שלכם היא reject על דומיין עם משתמשים ששולחים לרשימות דיוור (discussion lists) – לבחון מחדש את ההחלטה מול הדוחות המצטברים.

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

לא. ARC (RFC 8617) נשאר מסמך נפרד במעמד Experimental, והוא אינו חלק מהמנגנון הנורמטיבי של תקן ה-DMARC החדש. התקן מתמודד עם הבעיה אחרת: הוא מנחה שרתים מקבלים שלא לדחות הודעה רק בגלל מדיניות reject שפורסמה, אלא להפעיל שיקול דעת נוסף. שרת מקבל רשאי להשתמש ב-ARC כאחד הכלים לשיקול הדעת הזה, אבל זו החלטה מקומית שלו, מחוץ למוגדר בתקן.

פעולת Forwarding (העברה) שוברת את אימות הדומיין ומכשילה DMARC, כי ה-SPF נבדק מול כתובת ה-IP של השרת האחרון ששלח, וזו של שרת הביניים (שביצע את ההעברה) אינה מופיעה ברשומת ה-SPF של דומיין המקור.

התקן החדש אף מחדד שהבדיקה נעשית אך ורק מול זהות ה-MAIL FROM, ללא Fallback ל-HELO. ה-DKIM שורד Forwarding לרוב כל עוד לא נעשה שינוי לגוף ההודעה, אך נשבר כשהמתווך משנה את ההודעה (למשל אם מתווסף footer או disclaimer).

בתקן DMARC החדש הוגדר מצב בדיקה חדש באמצעות התגית t.

התגית t מחליפה את תגית PCT (אחוזים) שאינה תקפה עוד. t=y מאותת שהמדיניות כעת במצב בדיקה, והציפייה היא שהצד המקבל יחיל רמה אחת מתחת למוצהר (reject יטופל כ-quarantine, ו-quarantine כ-none). אין השפעה על מדיניות none, ואין השפעה על שליחת הדוחות.

ברירת המחדל t=n – אכיפה מלאה.

תגית np מגדירה מדיניות נפרדת לסאב-דומיינים שאינם קיימים (מחזירים NXDOMAIN). זו ההגנה הראשונית שכדאי להפעיל בתקן החדש: סאב-דומיין שלא קיים ב-DNS לא שולח אימייל לגיטימי, ולכן אפשר להגדיר np=reject כבר היום, גם אם הדומיין הראשי עדיין ב-p=none, בלי שום סיכון שאימייל אמיתי שלכם יפגע.

שלוש תגיות: pct (אכיפה הדרגתית באחוזים, שבפועל לא יושמה בעקביות), rf (פורמט דוחות כשל, שהיה מיותר כי קיים רק פורמט אחד) ו-ri (מרווח בין דוחות, שממילא זכה להתעלמות). אם הן קיימות ברשומה שלכם, שרתים מתעלמים מהן – אבל כדאי להסיר אותן.

DNS Tree Walk הוא האלגוריתם באמצעותו שרת מקבל מאתר את רשומת ה-DMARC ואת הדומיין הארגוני בתקן החדש.

במקום להסתמך על ה-Public Suffix List חיצונית, השרת שואל את ה-DNS ישירות: הוא מחפש רשומה בדומיין השולח, ואם לא מצא – מטפס במעלה ההיררכיה תווית אחר תווית, עד שמונה רמות. הרשומה הראשונה שנמצאת קובעת.

לא. אין דבר כזה DMARC2. במאי 2026 פורסם תקן DMARC מעודכן (שכונה בקהילה DMARCbis או DMARC2.0), אבל מזהה הגרסה ברשומה לא השתנה: רשומת DMARC ממשיכה להתחיל ב-v=DMARC1, ורשומות קיימות ממשיכות לעבוד ללא שינוי.

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

אין צורך בשינוי דחוף, אבל מומלץ לנקות תגיות ישנות בעדכון ה-DNS הבא.

הסיבה למהר ולעדכן את הרשומה היא התגית החדשה np – שמאפשר להגן מיד על סאב דומיינים לא קיימים (שאינם בשימוש). 

עיקרי השינויים בתקן DMARC החדש:

• התקן החדש קיבל מעמד Proposed Standard במסלול התקינה הרשמי של ה-IETF.
• החלפת ה-Public Suffix List באלגוריתם DNS Tree Walk.
• הוצאת שלוש תגיות משימוש (pct, rf, ri).
• הוספת שלוש תגיות חדשות (np, t, psd).
• הנחיות מפורשות לשרתים מקבלים לגבי אופן אכיפת מדיניות reject.

התקן החדש מורכב משלושה מסמכים שפורסמו במאי 2026:

RFC 9989 – הפרוטוקול עצמו.

RFC 9990 – דוחות מצטברים

RFC 9991 – דוחות כשל.

שלושתם יחד מתחליפים את RFC 7489 מ-2015 ואת RFC 9091.