דוא"ל מהדומיין שלכם

הבוט יכול לכתוב ללקוחות שלכם בדוא"ל — מכתובת בדומיין שלכם, למשל noreply@example.com. את המכתב עצמו שולח השרת שלנו. בגלל זה, לפני השליחה הראשונה צריך להוסיף פעם אחת שלוש רשומות ל־DNS של הדומיין. להלן: למה זה נחוץ, מה בדיוק מוסיפים ומה קורה אחר כך.

למה בלי רשומות DNS המכתבים לא מגיעים

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

הדרך היחידה של המקבל להבחין בין השניים היא לשאול את הדומיין עצמו: «האם השולח הזה באמת פועל בשמך?» את התשובה אתם מפרסמים ב־DNS של הדומיין שלכם, כי DNS הוא המקום היחיד שרק אתם שולטים בו — ולכן היחיד שהמקבל מאמין לו.

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

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

שלוש הרשומות ומה כל אחת עושה

DKIM — חתימה שמוכיחה אותנטיות

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

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

SPF — אילו שרתים רשאים לשלוח בשמכם

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

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

DMARC — מה המקבל צריך לעשות כשהבדיקות נכשלות

DKIM ו־SPF עונים על השאלה «האם המכתב אמיתי». DMARC עונה על הבאה: מה לעשות אם לא. זו ההוראה שלכם למקבל — לא לעשות כלום ורק לשלוח דוח, לשלוח לספאם, או לדחות. בנוסף DMARC היא הכתובת שאליה מקבלים שולחים דוחות מרוכזים על דואר בשמכם, כולל ניסיונות זיוף של אחרים.

התחילו במדיניות הרכה ביותר — «דוחות בלבד». להחמיר כדאי מאוחר יותר, כשווידאתם שכל השולחים הלגיטימיים שלכם (הנהלת חשבונות, CRM, ניוזלטרים, הבוט הזה) עוברים את הבדיקות. מדיניות מחמירה שהופעלה מוקדם מדי מתחילה לחתוך את הדואר שלכם עצמכם.

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

אילו רשומות להוסיף

קודם כול הוסיפו את הדומיין בממשק: מדור Email ← «Sending domains» ← כפתור «Add domain». בחלון שלושה שדות: הדומיין עצמו (למשל shop.example.com), החלק המקומי של הכתובת (מה שלפני @, בדרך כלל noreply) ושם השולח שהנמען רואה במקום כתובת. לאחר השמירה יופיעו על המסך רשומות ה־DNS שלכם.

כל השלוש הן רשומות מסוג TXT ב־DNS של הדומיין. מוסיפים אותן היכן שאתם מנהלים את הדומיין: בממשק הרשם או אצל ספק ה־DNS.

הערכים שלהלן מוצגים על דוגמת example.com — הציבו את הדומיין שלכם. הערכים המדויקים לדומיין שלכם מוצגים בכרטיס הדומיין בממשק — העתיקו משם, ובמיוחד DKIM: הערך שלו מכיל את המפתח הציבורי שלכם, לכל דומיין אחר, ואי אפשר לקחת אותו מהתיעוד.

על המסך כל רשומה מפוצלת לשני שדות נפרדים — «Host» ו־«Value» — לכל אחד כפתור «Copy» משלו. העתיקו אותם אחד־אחד לשדות המתאימים אצל ספק ה־DNS: שני החלקים אינם נדבקים כמקשה אחת.

שני דברים שבהם נכשלים לרוב:

• ממשקים רבים מוסיפים את הדומיין לשם הרשומה בעצמם. אם בשדה השם כבר כתוב «.example.com», הזינו רק mybot._domainkey ולא את השם המלא — אחרת ייצא mybot._domainkey.example.com.example.com.
• ערך ה־DKIM ארוך ואסור שיכיל מעברי שורה או רווחים בתוך המפתח. העתיקו אותו בכפתור ולא בגרירת עכבר.

אם לדומיין כבר יש רשומת SPF

לדומיין יכולה להיות רק רשומת SPF אחת. אם אתם כבר שולחים דואר דרך האחסון, CRM או שירות דיוור אחר — הרשומה קיימת. אל תוסיפו שנייה — הוסיפו לרשומה הקיימת include נוסף, לפני ה־~all המסיים:

v=spf1 include:spf.yourprovider.co.il include:esp.getmybot.dev ~all

שתי רשומות SPF בדומיין הן אותה שגיאה כמו אף אחת: הבדיקה לא עוברת, כי המקבל לא יודע לאיזו משתיהן להאמין.

שימו לב: «כיסוי» דרך רשומה של מישהו אחר אינו מספיק. גם אם הספק הנוכחי שלכם כולל אותנו ב־SPF שלו, ה־include שלנו חייב להופיע ברשומה שלכם ישירות — הסיבה מופיעה להלן בפרק על אימות הדומיין.

למה ב־SPF דווקא include ולא כתובת IP

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

include:esp.getmybot.dev הוא הפניה לרשימת שרתי השליחה שלנו, שאנחנו מתחזקים. היום מאחורי השם הזה עומד שרת ממסר אחד. מחר הם עשויים להתרבות, לעבור או להתחלף. כשזה יקרה נעדכן את הרשימה אצלנו — והרשומה שלכם תמשיך לעבוד בלי שתיגעו בכלום. זו כל המשמעות: הכתובת משתנה במקום אחד ולא ב־DNS של כל לקוח.

כתובת IP שנרשמה ידנית פשוט תחדל להתאים למציאות באותו רגע. המכתבים יתחילו להיכשל ב־SPF בלי שום התראה — בלי שגיאה בממשק ובלי הודעה. תגלו זאת מלקוחות ש«לא קיבלו כלום».

כתבו בדיוק include:esp.getmybot.dev ואל תוסיפו לזה דבר.

אימות הדומיין

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

הבדיקה חורגת מ«הרשומה קיימת»:

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

include של אחרים לא נחשב

include:esp.getmybot.dev חייב להופיע ברשומת ה־SPF שלכם עצמכם. אם ה־SPF שלכם כולל ספק צד שלישי שהרשומה שלו כוללת אותנו, האימות לא יקבל זאת: הפלטפורמה אינה פורשת שרשראות include של אחרים. הסיבה פשוטה — כך התשובה לשאלה «האם דווקא הדומיין הזה הרשה לנו» נשארת חד־משמעית.

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

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

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

מצב הדומיין נראה בכרטיס: «Pending verification», «Verified» או «Not verified». כל עוד הדומיין אינו מאומת, מופיעה בכרטיס גם האזהרה «Sending from this domain is disabled until it is verified.»

התוצאה אינה סתם «נכשל». לכל אחת משלוש הרשומות יש על המסך מצב משלה — «Passing», «Not passing» או «Not checked yet» — ושורה משלה שמסבירה מה לא בסדר.

עבור SPF המסך מבחין בין שני מצבים, וזו ההבחנה החשובה ביותר בכל התהליך:

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

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

אם האימות לא עובר:

1. קראו איזו משלוש הרשומות מסומנת «Not passing» ומה כתוב בהסבר שלה, ופעלו לפיו.
2. ודאו שהרשומות אכן פורסמו — ממשקים רבים דורשים ללחוץ בנפרד «החל שינויים».
3. בדקו את שם הרשומה מפני דומיין כפול (ראו למעלה).
4. ודאו שרשומת SPF היא אחת בלבד ושה־include שלנו נמצא בתוך אותה רשומה.
5. המתינו ובדקו שוב: ייתכן שהשינוי טרם התפשט.

עד לאימות השליחה לא עובדת — וזו כוונה

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

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

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

הסרות, תלונות וכשלי מסירה

שלושה כללים שמפתיעים את מי שלא ידע עליהם מראש.

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

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

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

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

כשלים זמניים (תיבה מלאה, שרת שאינו זמין כרגע) אינם סוגרים את הכתובת — השליחה נמשכת.

למה «פתיחות» נמוכות מהמציאות

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

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

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

אם דרוש מדד מעורבות אמין — הביטו ב**«Link clicks». קליק על קישור הוא פעולה אמיתית של אדם אמיתי; איש לא מבצע אותה עבורו מראש. גם «Delivered», «Unsubscribes», «Complaints» ו־«Bounces»** נספרים במדויק: עליהם מדווחים שרתי דואר, לא תמונה בתוך מכתב. כל אלה נמצאים בבלוק «Sending stats» באותו מסך Email.

מה הלאה

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