האימיילים מגיעים לספאם? תהליך לאיתור שורש הבעיה

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

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

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

"ספאם" הוא תסמין, לא שורש הבעיה

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

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

סף השולח בתפוצה רחבה שאי אפשר לבטל

לפני האבחון חשוב להבין את המגרש. לאחר שחוצים את הסף המשוער של Google, ‏5,000 הודעות לחשבונות Gmail אישיים בחלון יחיד של 24 שעות, מסווגים לצמיתות כ-"שולח בתפוצה רחבה". גם אם הנפח יורד, התקן המחמיר נשאר ואין הליך ערעור.

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

תהליך אבחון של 15 דקות לאימיילים שמגיעים לספאם

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

שלב 1: אימות, משולש הברזל, 5 דקות

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

1. SPF (Sender Policy Framework)

הבדיקה: האם כתובת ה-IP ששולחת בפועל תואמת לכתובות שברשומת DNS TXT של הדומיין?

מצב הכשל: מגבלת 10 הבדיקות. לרשומות SPF תקרה של 10 בדיקות DNS. אם מפעילים include: עבור Google Workspace, Outlook, Mailchimp, Zendesk וה-CRM, אפשר לחרוג ממנה. התוצאה היא PermError, והמקבל רואה את כל הרשומה כלא תקינה. זו אחת הסיבות המרכזיות לספאם.

תיקון: בדקו מנגנוני include: והסירו שירותים שאינם בשימוש. להסבר מלא ראו הגדרת רשומת SPF.

2. DKIM (DomainKeys Identified Mail)

הבדיקה: האם החתימה הקריפטוגרפית בדואר היוצא תקינה ושלמה?

מצבי הכשל:

• אורך מפתח: Google דורשת לפחות 1024 ביט וממליצה מאוד על 2048 ביט. מפתחות 512 ביט ישנים הם סיכון אבטחה ואות שלילי למסירה.
• אי התאמת selector: אם DNS מפרסם מפתח תחת s=selector1 אך השרת חותם עם s=selector1-2026, אימות DKIM נכשל בשקט וההודעה נראית לא חתומה.

3. DMARC (אוכף המדיניות)

הבדיקה: האם פרסמתם רשומת DNS של DMARC עם לפחות p=none?

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

התאמת DMARC פירושה שהדומיין בכתובת "From" הגלויה חייב להתאים לדומיין שעבר SPF או DKIM. בשליחה דרך ספק כמו Mailchimp, ‏Return-Path מצביע לרוב אל mailchimp.com לטיפול בהחזרות. SPF עובר, אך התאמת SPF נכשלת כי mailchimp.com אינו תואם ל-yourcompany.com.

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

שלב 2: מוניטין, סף 0.3%, ‏5 דקות

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

כלל 0.3%: בדקו את שיעור התלונות. מעל 0.3%, כלומר רק 3 תלונות לכל 1,000 הודעות, נכנסים לאזור הענישה ו-Google עשויה להאט דואר שיווקי או לשלוח אותו לספאם.

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

מלכודת "מכנה תיבת הדואר" של Yahoo

Yahoo מחשבת שיעור ספאם אחרת מ-Google: המכנה הוא מסירה לתיבה, לא כלל הנפח שנשלח. לכן זה מסוכן:

1. אתם שולחים 1,000 הודעות לכתובות Yahoo.
2. 900 מגיעות לספאם ורק 100 לתיבה.
3. אדם 1 מתוך אותם 100 לוחץ "דיווח כספאם".
4. שיעור תלונות: 1 / 100 = 1.0%, יותר מפי שלושה מהסף הבטוח.

בחישוב של Yahoo מגיעים לענישה מהר מהצפוי, והספאם הנוסף מאיץ את הנזק.

שלב 3: היגיינה טכנית ותוכן, 5 דקות

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

1. FCrDNS (Forward-Confirmed Reverse DNS)

כל IP שולח צריך רשומת PTR שנפתרת לשם מארח, ושם המארח צריך להיפתר בחזרה לאותו IP. האישור הדו כיווני מוכיח שליטה בתשתית.

בדיקה: הפעילו dig -x <your-sending-IP> ואמתו את התוצאה.

כשל: אם ה-IP נפתר אל NXDOMAIN או אל שם כללי כמו ip-192-168-1-1.cloudprovider.com, שרתי דואר עשויים לראות בכם מארח פרוץ או זמני.

2. RFC 8058: הסרה בלחיצה אחת

מאז יוני 2024, Google ו-Yahoo דורשות כותרת הסרה קריאת מכונה בלחיצה אחת בכל דואר שיווקי. הכותרות חייבות לכלול את שתי השורות:

List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://yourdomain.com/unsubscribe...>

בלעדיהן כפתור "הסרה" לא יופיע ליד שם השולח ב-Gmail. משתמשים ילחצו "דיווח כספאם" ויפגעו ב-מוניטין שולח האימייל. המפרט המלא נמצא ב-IETF RFC 8058.

3. מוניטין קישורים

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

• URIBL/SURBL: קישור לדומיין חסום, כמו כתובת שותפים מפוקפקת, אתר WordPress פרוץ או דומיין שפג תוקפו ומציג מודעות, עלול לחסום את כל ההודעה.
• מקצרים ציבוריים: אל תשתמשו ב-bit.ly או tinyurl. שולחי ספאם מנצלים אותם, ולכן מסננים מענישים קישורים מקוצרים כברירת מחדל.

חקירת כותרות: קריאת האמת

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

תרחיש A: כשל התאמה

ההודעה עברה SPF ו-DKIM מבחינה טכנית אך נכשלה ב-DMARC כי הדומיינים לא תאמו:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sendgrid.net;
  spf=pass (sendgrid.net designates 167.89.x.x as permitted);
  dmarc=fail header.from=yourcompany.com

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

תרחיש B: פגיעת מוניטין של Microsoft

הכותרות של Microsoft מפורטות יותר. חפשו את X-Forefront-Antispam-Report:

X-Forefront-Antispam-Report: ... SCL:5 ... CAT:SPM ...

ערך SCL:9 מצביע כנראה על חסימה קשיחה של ה-IP. ‏SCL:5 מציין מסנן תוכן או מוניטין.

טבלת תיקון מהירה

לאחר שאיתרתם את שורש הבעיה, יישמו את התיקון המתאים מהטבלה.

הפסיקו להיאבק ב-DNS ותנו ל-TrekMail לטפל בתשתית

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

TrekMail מפשט את מערך התשתית כדי שתוכלו להתמקד בשליחה:

• אשף SPF/DKIM/DMARC: יוצר את רשומות DNS המדויקות הנדרשות. העתיקו אותן לרשם וסיימתם.
• SMTP מנוהל, Starter ב-$3.50/mo: אנחנו מטפלים במוניטין IP, בכותרות ובחימום, ואתם בכתיבה.
• BYO SMTP: מעדיפים Amazon SES או SendGrid? ‏TrekMail משתלב בהם ומחבר את הממשק שלנו לתשתית הספק.
• חימום דומיין: בדומיין חדש אנו מעלים את הנפח בהדרגה במשך שבועות כדי לבנות מוניטין חיובי.
• העברת SRS: העבירו דואר בין דומיינים בלי לשבור SPF. קראו את מדריך Sender Rewriting Scheme.

אם הבעיה עולה לעסק כסף, התוכניות מתחילות ב-Free ($0, בלי כרטיס) ומגיעות ל-Agency ($23.25/mo) לניהול 100+ דומיינים של לקוחות מלוח אחד. כל תוכנית בתשלום כוללת ניסיון 14-day.

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

נסו את TrekMail בחינם והסירו את כאב הראש של DNS.