מוניטין דומיין בדוא״ל: אבחון ותהליך התאוששות

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

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

מהו באמת מוניטין דומיין בדוא"ל

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

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

נמענים עשויים לצבור אותות מדומיין השורש ומתת-הדומיינים, אבל המשקל אינו אחיד בכל מצב. אם marketing.example.com נכנס לרשימת חסימה, גם הודעות מ-ceo@example.com עלולות להיפגע. תת-דומיינים מספקים הפרדה מסוימת, לא הגנה מובטחת.

סף השיא וסיווג שנשאר בתוקף

כאשר Google מסווגת דומיין כשולח בנפח גבוה, בסביבות 5,000 הודעות ביום לחשבונות Gmail אישיים, הסיווג נשאר לפי המדיניות שפורסמה והפחתת הנפח אינה מבטלת אותו אוטומטית. הדרישות הרלוונטיות כוללות הסרה בלחיצה אחת להודעות שיווקיות מתאימות ופרסום מדיניות DMARC. אין פירוש הדבר שחובה להשתמש תמיד ב-p=quarantine או ב-p=reject. בדקו את התיעוד העדכני של Google; לספקים אחרים יש הגדרות משלהם.

אם הנפח היומי ל-Gmail נשאר מתחת ל~100 הודעות ביום, Postmaster Tools עשוי להציג "No Data". הדבר תלוי בכיסוי הנתונים ובספים הנוכחיים. השלימו את התמונה בעזרת בדיקות seed מבוקרות, ניתוח החזרות ונתוני מסירה אמיתיים, בלי להתייחס לבדיקת seed כייצוג מלא של כל הנמענים.

4 גורמים מרכזיים לבעיות במוניטין דומיין

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

1. סיכון התלונות ב-0.3%

סימון הודעות כספאם בידי משתמשים הוא אות שלילי משמעותי. Google ו-Yahoo מפרסמות ספים לתוכניות שולחים מסוימות. בשיעור של 0.3%, כלומר 3 תלונות לכל 1,000 הודעות, הסיכון לסינון כספאם או לדחייה עולה, אך חסימה מיידית אינה מובטחת בכל מקרה. Google ממליצה להישאר מתחת ל-0.1%. התייחסו ל-0.3% כאל סף סיכון עליון ולא כיעד, ואמתו את ההגדרה העדכנית אצל כל ספק.

לעיתים מתארים את החישוב של Yahoo כמבוסס על הודעות שהגיעו לתיבת הדואר הנכנס. מאחר שההגדרה והמכנה עשויים להשתנות, בדקו את התיעוד העדכני ב-Yahoo Sender Hub.

תרחיש: אתם שולחים 1,000 הודעות. 900 מסוננות אוטומטית כספאם. 100 מגיעות לתיבת הדואר הנכנס. 1 מהנמענים מתלונן.
חישוב: 1 תלונה ÷ 100 הודעות בתיבה = שיעור תלונות של 1.0%.
תוצאה: השיעור הוא 3× מהסף שצוין, והבעיה עלולה להחמיר בתרחיש הזה.

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

2. אי-התאמה באימות (אות אפשרי להתחזות)

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

מצב נפוץ מתרחש עם ESP כמו Mailchimp או SendGrid. שולח המעטפה המשמש את SPF מצביע על mail.sendgrid.net, ואילו From מצביע על yourcompany.com. SPF עובר עבור ה-IP המורשה, אך התאמת DMARC דרך SPF נכשלת כי הדומיינים אינם תואמים. חתימת DKIM שמיושרת עם הדומיין שלכם עדיין יכולה להעביר DMARC.

Microsoft עשויה להחזיר 550 5.7.515, אך יש לקרוא את התשובה המלאה. הקוד עשוי להיות קשור לדרישות אימות או מדיניות בנפחי שליחה מסוימים, ולא רק לחסימת תוכן. אם האפשרות זמינה, הגדירו אימות דומיין מותאם אצל ה-ESP, המכונה לעיתים "Whitelabeling". ההגדרה יכולה להשתמש ב-Return-Path משלכם, וחשוב מכך, בחתימת DKIM מיושרת.

3. מגבלת 10 החיפושים של SPF (RFC 7208)

SPF אינו רשימה אינסופית. RFC 7208 §4.6.4 מגביל ל-10 את המנגנונים והמשנים שגורמים לחיפושי DNS בהערכת SPF. הוראות include של Google, Outlook, Zendesk, Mailchimp ומערכת CRM יכולות לצרוך חלק גדול מהמכסה. גם הוראות include: מקוננות נספרות כאשר הן גורמות לחיפושים נוספים.

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

4. Microsoft והסיכון של "Namespace Mining"

ריבוי החזרות קשיחות עשוי להיראות אצל Microsoft כניסיון לנחש כתובות או כרשימה בעייתית. הטווח 2-3% מובא כאן כאזהרה להמחשה, לא סף רשמי אוניברסלי שמפעיל חסימת IP מיידית. בין התשובות האפשריות 550 5.7.1 או הגבלה כמו 421 RP-001; קראו תמיד את התשובה המלאה.

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

מידע ייחודי לכל ספק

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

תהליך אבחון: בידוד נקודת הכשל

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

בדיקת תשתית במסוף

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

# Check SPF - count the includes, verify it ends in ~all or -all
dig txt yourdomain.com +short

# Check DMARC - p= should be quarantine or reject for live domains
dig txt _dmarc.yourdomain.com +short

# Check FCrDNS (Forward-Confirmed Reverse DNS)
# Step 1: Get the hostname from your sending IP
dig -x 1.2.3.4 +short
# Expected output: mail.yourdomain.com.

# Step 2: Verify the hostname resolves back to the same IP
dig mail.yourdomain.com +short
# Expected output: 1.2.3.4

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

ניתוח כותרות

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

אות שלילי: כשל התאמה

spf=pass smtp.mailfrom=sendgrid.net
dkim=pass header.d=sendgrid.net
dmarc=fail (p=reject) header.from=yourcompany.com

SPF ו-DKIM עברו מבחינה טכנית. DMARC נכשל כי אף אחד מהדומיינים לא היה מיושר עם yourcompany.com. זהו כשל ההתאמה שתואר לעיל, והוא עלול לפגוע במוניטין.

אות חיובי: התאמה תקינה

spf=pass smtp.mailfrom=em.yourcompany.com
dkim=pass header.d=yourcompany.com
dmarc=pass

תהליך התאוששות מסודר

אם Google Postmaster Tools מציג "Bad", שיפור עשוי להימשך, לדוגמה, 2-4 שבועות או יותר. זהו טווח לתכנון, לא מועד קבוע. שלושת השלבים הבאים מסייעים לארגן את העבודה כאשר הם מתאימים לגורם שאובחן; אין קיצור דרך מובטח או תהליך אוניברסלי.

שלב 1: בדיקת הרשימה

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

שלב 2: טיפול טכני

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

שלב 3: הגדלת נפח ליניארית

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

• יום 1: 50 הודעות
• יום 2: 100 הודעות
• יום 3: 200 הודעות
• יום 4: 400 הודעות

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

תקינות התשתית: גורמים שקשה לזהות

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

מדיניות TLS

ספקים גדולים רבים מצפים לתמיכה עדכנית ב-TLS, אך הטיפול בחיבורי SMTP לא מוצפנים תלוי בהקשר ובמדיניות הנמען. הגדירו פרוטוקולים נתמכים, כגון TLS 1.2 ומעלה, לפי הדרישות העדכניות של הצדדים האחרים. לפי תצורת TrekMail המתוארת, הדבר מנוהל כברירת מחדל; בדקו את מצב השירות ואת הגדרת החשבון הנוכחיים.

שכנים בעייתיים ב-IP משותף

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

בנפח מעל 100k/חודש, IP ייעודי עשוי להתאים, אבל אינו תמיד טוב יותר ודורש יכולת תפעול וחימום. בנפח נמוך יותר, מאגר מנוהל היטב עשוי להתאים יותר. אפשרות BYO SMTP של TrekMail מאפשרת לחבר Amazon SES, SendGrid או Mailgun בהתאם לתוכנית הנוכחית. ניהול ה-IP והמוניטין שלו נותרים תלויים בספק שנבחר, אלא אם אתם מנהלים במפורש IP ייעודי.

התפקיד של TrekMail

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

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

TrekMail מתאר יכולות לדואר נכנס, כגון אחסון בתעריף קבוע, תיבות IMAP, ניתוב catch-all והעברה בצד השרת ללא תמחור לפי משתמש. לדואר יוצא אפשר לחבר ספק SMTP בהתאם לתוכנית ולאינטגרציה. אשף SPF/DKIM/DMARC עשוי לסייע בהצטרפות. אמתו זמינות, מגבלות ותוצאות DNS עדכניות לפני שליחה בסביבת ייצור.

לפי המקור, התוכניות מתחילות ב-$3.50 לחודש. מתוארים ניסיון של 14 ימים שדורש כרטיס ותוכנית Nano ללא כרטיס, עם 10 דומיינים ו-5 GB, שמוצגת כחינמית. מחיר, יכולות ותנאי הניסיון עשויים להשתנות, והביטוי "חינם תמיד" אינו הבטחה. ראו trekmail.net/pricing לפרטים העדכניים.

סיכום

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

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

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