מגבלות שליחה וחימום דומיין: למה דומיינים חדשים נתקלים בסינון

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

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

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

על מה מגינות מגבלות השליחה

קודם כול, על המוניטין של הדומיין שלכם ושל תשתית השליחה המשותפת.

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

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

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

המגבלות בכל מסלול

אלה מכסות הבסיס של המסלולים, לא הבטחה למכסה הזמינה בפועל. הספירה נעשית לפי התאריך בשירות, ולא בחלון מתגלגל של 24 שעות. המכסה היומית נצרכת לפי מספר הנמענים, והמכסה הכוללת של החשבון משותפת לכל התיבות שלו: עשרים תיבות במסלול Starter לא יכולות לנצל כל אחת 1,000, כי המכסה הכוללת היא 6,000. הכתובות בשדות To, Cc ו־Bcc נספרות יחד, ולכן הודעה ל־120 אנשים חורגת מהמגבלה של Starter גם אם זו הודעה אחת. דומיין חדש כפוף למכסות מופחתות; Nano דורש שרת SMTP משלכם, והמספרים בטבלה לא כוללים שליחה דרך שרתי הפלטפורמה.

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

למה לחשבונות חדשים יש מכסות נמוכות יותר

בתקופת ניסיון, בחשבון שלא בוצע בו תשלום בעבר, מכסות ההגנה הבסיסיות הן 30 לתיבה ביום, 50 לחשבון, 10 נמענים בהודעה ו־15 שליחות SMTP בשעה. המכסה היומית נצרכת לפי מספר הנמענים; חימום של דומיין חדש עשוי להפחית אותה עוד. מחוץ לתקופת הניסיון ובסטטוסים אחרים חלים כללים שונים. תשלום שאושר בדרך כלל מסיר את מגבלת החשבון שלא שילם בעבר, אבל אינו מבטל את מגבלות המסלול, הדומיין ושאר הבדיקות.

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

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

מה קורה כשחורגים ממגבלת השליחה

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

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

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

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

חימום הדומיין

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

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

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

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

מה בודקים שרתי הדואר המקבלים

כמות ההודעות לבדה אינה מספיקה. בדקו גם את הסימנים הבאים:

שיעור התלונות. זהו מדד לסימון הודעות כספאם, כפי שמחשב אותו השירות המקבל. ההנחיות של Google לשולחים ממליצות לשמור על המדד ב־Postmaster Tools מתחת ל־0.1% ולהימנע מרמה של 0.3% ומעלה. הרמה האחרונה משקפת בערך שלוש תלונות לאלף במסגרת המדד הזה, ולא בהכרח מתוך כל ההודעות שנשלחו. אין להחיל את המספרים האלה ככלל אחיד על כל שירות דואר.

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

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

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

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

איך להישאר במסגרת מגבלות השליחה

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

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

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

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

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

שאלות נפוצות

מהן מגבלות השליחה היומיות?

מכסות הבסיס הן 200 לתיבה ו־400 לחשבון במסלול Nano; במסלול Starter הן 1,000 ו־6,000; ב־Pro הן 2,000 ו־15,000; וב־Agency הן 2,500 ו־40,000. מגבלת הנמענים להודעה נעה בין 50 ל־500 לפי המסלול. המכסה היומית נצרכת לפי מספר הנמענים; חימום הדומיין וסטטוס החשבון עשויים להפחית את המגבלה בפועל. Nano דורש שרת SMTP משלכם.

למה המכסות שלי נמוכות מאלה שמופיעות במסלול?

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

מה קורה כשמגיעים למגבלה?

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

אפשר להגדיל את המגבלות?

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

המגבלות חלות גם עם שרת SMTP משלי?

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

כמה זמן לוקח לחמם דומיין?

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

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

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

עצם החריגה מהמכסה פוגעת במוניטין?

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