מסירת דואר ו-DNS

כתובת אימייל אמינה בדומיין עסקי

מאת Alexey Bulygin
הגדרות DNS ואמון לכתובת בדומיין עסקי

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

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

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

למה הכללים הוחמרו בשנים 2024-2026

הכללים הוחמרו ב-2024, כאשר Gmail ו-Yahoo הכריזו על אכיפה לשולחים בכמות גדולה. שולחים שמעבירים יותר מ-5,000 הודעות ביום לכתובות Gmail נדרשים כיום ל-DKIM מאומת, SPF תקין ומדיניות DMARC של p=none לפחות עם דוחות פעילים. Microsoft המשיכה ב-2025 עם בדיקות התאמה מחמירות יותר ב-p=quarantine.

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

שבעת הכללים במבט מהיר

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

  1. SPF, DKIM ו-DMARC מוגדרים ועוברים. אין חריגים ואין דחייה של DMARC. שלושתם מהיום הראשון.
  2. התאמת DMARC מתקיימת. הדומיין הגלוי בכותרת From צריך להתאים לדומיין שחותם ב-DKIM, ורצוי גם לדומיין SPF שב-Return-Path.
  3. שמות החלק המקומי פועלים לפי תבנית מתועדת. firstname.lastname היא הבטוחה ביותר; ערבוב תבניות פוגע במקצועיות.
  4. כתובות תפקיד הן כינויים. support@, sales@ ו-billing@ מפנות לתיבות של אנשים אמיתיים ואינן תיבות נפרדות.
  5. כתובת השחזור אינה Gmail אישי. שחזור מנהל משתמש בתיבה בתשלום אצל מארח אחר, עם מפתח חומרה לאימות דו שלבי 2FA.
  6. מפתחות DKIM נפרדים לכל שולח. כל שירות חיצוני שחותם בשם הדומיין צריך בורר DKIM משלו.
  7. דוחות DMARC נבדקים מדי חודש. דוחות מצטברים חושפים כל שולח לגיטימי וכל ניסיון התחזות; התעלמות מהם מבטלת את תועלת המדיניות.

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

כלל 1: שלישיית האימות חייבת לעבור

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

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

כלל 2: התאמת DMARC חייבת להתקיים

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

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

כאשר כתובת מתחילה להיכשל בהתאמה, דוח DMARC המצטבר הוא כלי האבחון. הדוחות מציגים כל IP שטען לשימוש בדומיין ב-24 השעות האחרונות, את תוצאות DKIM ו-SPF ואם ההתאמה התקיימה. שירות שמופיע עם d=mailgun.com אך From=yourdomain.com הוא הוכחה לכך שחתם בדומיין שלו במקום בשלכם. הגדירו את הבורר, והכשל אמור להיעלם בתוך שעות לאחר הפצת DNS.

כלל 3: שמות החלק המקומי חייבים להיות אחידים

אחידות בשם החלק המקומי מבדילה בעיני נמענים בין כתובת עסקית לכתובת חובבנית. firstname.lastname היא ברירת מחדל בטוחה שמתאימה גם מעבר ל-30 עובדים. שם פרטי בלבד עובד מתחת ל-30 אך נשבר כשמצטרף אדם שני עם אותו שם. ערבוב תבניות באותו דומיין הוא אות חובבני נפוץ במיוחד.

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

כלל 4: כתובות תפקיד הן כינויים, לא תיבות

כתובות תפקיד כמו support@, sales@, billing@ ו-hello@ צריכות להיות כינויים שמצביעים אל תיבות של אנשים אמיתיים, לא תיבות נפרדות שמישהו צריך לזכור לבדוק. זה ההבדל התפעולי בין כתובת שמתאימה לצמיחה לבין כתובת שמאבדת הודעות לקוח לאורך זמן. תיבות שאיש אינו פותח מתמלאות בדואר שלא נקרא.

לפי המכסות המוצגות כיום, TrekMail תומכת בכך ישירות: 30 כינויים לתיבה ב-Starter, ‏50 ב-Pro ו-100 ב-Agency. צוות של 10 אנשים ב-Pro יכול לארח 10 תיבות אמיתיות ועד 500 כתובות כינוי במחיר $96 לשנה. כל כינוי מפנה לאדם שמחזיק כעת בתפקיד, וכשהאחריות משתנה מפנים אותו מחדש בתוך 30 שניות ללא העברת תיבה.

כלל 5: כתובת השחזור אינה Gmail אישי

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

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

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

כיצד TrekMail מכסה את שבעת הכללים

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

הכללים התפעוליים, אחידות שמות, ניהול כינויים ומסלול שחזור, הם החלטות מדיניות ש-TrekMail יכולה לתמוך בהן אך לא לאכוף. לפי התוכניות הנוכחיות, Pro במחיר $10 לחודש כוללת 50 כינויים ו-10 כללי דואר לכל תיבה לקביעת ניתוב. Agency במחיר $29 לחודש מוסיפה עורך Sieve גולמי ללוגיקת שמירה וניתוב לצורכי ציות. עורך הכללים ב-Pro מכסה את רוב תבניות ההעברה ללא כתיבת Sieve. ליסודות ההתאמה ראו התאמת DMARC.

הצעדים הבאים

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

לפי התמחור הנוכחי, TrekMail Pro במחיר $96 לשנה מתאימה לרוב הצוותים הצומחים עם 50 כינויים, 10 כללי דואר לכל תיבה וגישה מלאה ל-API. בדקו תחילה את תהליך העבודה ב-Nano החינמית. הירשמו דרך trekmail.net/pricing. להקשר הרחב של אמינות, ראו כתובת אימייל מקצועית.

שתפו מאמר זה

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

התחברות ל-TrekMail

גישה ללוח הבקרה, לתיבות הדואר ול-DNS שלכם.

או

12 תווים הסיסמאות תואמות

או

דוא״ל האיפוס נשלח

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

בהמשך אתם מסכימים ל תנאי השימוש ול מדיניות הפרטיות של TrekMail.