הגדרת אימות דומיין תיכשל אם פסיק לא יהיה במקום, או שיתווסף ל-DNS תו מיותר. כתוצאה: אימות הדומיין יכשל ותתקבל חסימה או פגיעה בעבירוּת.
אל תעשו את הטעויות האלה. סיפורי לקוחות
תוכן עניינים
האזנה לפודקאסט
סינדרום התחת הגדול והשמיכה הקטנה
הגדרת אימות דומיין במערכות המדוורות הוא מבחינתי “סף הכניסה לעבירוּת”. זה הצעד הראשון שמדוורים יכולים לעשות כדי לקחת על עצמם את הבעלות על ה-reputation שלהם. עבירוּת נשענת על כמה עמודי תווך כששלושת העיקריים הם ה-reputation של כתובת ה- IP (הכוונה לכתובות ה-IP של שרתי הדיוור שלרוב המדוורים הן כתובות שיתופיות ולכן אין למדוורים שליטה עליהן), ה-reputation של הדומיין (הדומיין, לרבות ה-reputation של סיומת ה-TLD של הדומיין, ה-reputation של רשם הדומיינים), ה-reputation של התוכן והקישורים שמצורפים לדיוור (אל דומיינים חיצוניים) ועוד כמה וכמה גורמים משפיעים.
אני כותב מערכות מדוורות ולא רק “מערכת דיוור”, כי כמעט בכל עסק יש לאימייל כמה וכמה תפקידים. אימיילים עסקיים ישלחו משירות כגון Microsoft 365 או Google Workspace ואימיילים שיווקיים ישלחו ממערכת דיוור. אך פעמים רבות יש לאימייל תפקידים נוספים טרנזקציוניים (כגון אישור הזמנה, איפוס סיסמה, דיוור של מייל הצטרפות לרשימת דיוור) ואימיילים תפעוליים (כגון דוחות וחשבוניות).
אני קורא לזה “סינדרום התחת הגדול והשמיכה הקטנה”, כי פעמים רבות קיים קונפליקט בין מחלקות או חטיבות שונות תחת אותו הדומיין.
אני כיעוץ עבירוּת חייב לוודא שכל צורכי האימייל של הארגון יבואו לידי ביטוי ללא הפרעה. בשל שיקולי ניהול reputation השאיפה היא לא לשים את כל ה-reputation תחת הדומיין הראשי. הפרקטיקה הרווחת היא לנהל פעילויות דיוור שונות (email streams) תחת תת דומיינים (sub-domain). מהדומיין הראשי ישלחו האימיילים העסקיים (365, GWS) וינוהלו תת דומיינים נפרדים עבור פעילויות הדיוור שונות (טרנזקציוני, תפעולי, שיווקי).
אנו לא רוצים שפעילות דיוור שיווקית (קמפיינים, ניוזלטרים וכו’) תפריע לפעילות טרנזקציונית, או שפעילות תפעולית תפריע לפעילות טרנזקציונית. ההפרדה תכלול הפעלה של שרתי דיוור נפרדים לחלוטין עבור סוגי הדיוורים השונים ולא רק הפרדה לתתי דומיינים. ניתן להשתמש בתת דומיינים תחת דומיין ראשי ללא הגבלה (וזה לא עולה יותר).
ראו הרחבה במאמרים: הדברים הקטנים המשפיעים על domain reputation וגם החשיבות של הפרדת דיוורים
סיבה חשובה נוספת ליצור הפרדות דיוור קשורה במגבלות ה-lookup (מספר הקריאות אל ה-DNS על מנת לפענח את הרשומה) של רשומת SPF לאימות הדומיין. מגבלת ה-lookups היא עד 10 lookups. ניתן לראות בדוגמא כי אימות Google Workspace על ידי הוספת include:_spf.google.com דורשת ארבעה lookups לתוך ה-DNS. אימות כל המקורות שבדוגמא זו יוצרת 7 Lookups.
DNS = תשתית קריטית
שכיח לראות טעויות באימות הדומיין שיוצרת overflow על ה-SPF וחריגה ממגבלת ה-lookups (עד 10) מה שעשוי ליצור בעיות בחלק מרשומות האימות, עשוי לפתח בעיות עבירוּת וחסימות כי לא כל המקורות מקבלים אימות.
ראו הרחבה במאמר: רשומת SPF וגם חשיבות ה-DNS לפעילות אימייל תקינה.
DNS הוא תשתית קריטית בכל עסק ובוודאי לפעילות תקינה של אימייל והגדרות שגויות יכולות ליצור בעיות עבירוּת. מספיק שפסיק או תו לא במקומם.
הגדרת אימות דומיין מבוצעת על ידי הטמעת רשומות ב-DNS של הדומיין. ה-DNS הוא מנגנון קריטי לפעילות כל מה שקשור בדומיין ובשירותים הקשורים בדומיין, לרבות אימייל. ישנם סוגים שונים של שרתי DNS והם נבדלים ביכולות שלהם, באופן בו מוטמעות הרשומות, בנוחות התפעול ובתפוצתם ויכולות השרידות שלהם (המידע מופץ ומשתכפל בחוות שרתים רבות סביב העולם). רשמי הדומיינים מציעים בעת רישום הדומיין שירות DNS ועסקים רבים מאוד ממשיכים לנהל את ה-DNS אצל רשם הדומיינים. בעיני זו טעות ותמיד עדיף להפריד את ה-DNS מרשם הדומיינים או את ה-DNS מהאתר (קשה או לא ניתן לעשות זאת ב-WIX למשל).
כדי להפריד בין רשם הדומיינים ל-DNS, לאחר רישום אתר (או אם יש לכם כבר דומיין) היכנסו לפאנל הניהול ברשם הדומיינים וחפשו היכן משנים את “שרתי השם” (Name Servers). פיתחו חשבון ב-Cloudflare (שרת ה-DNS המהיר בעולם. יש לו שתי נקודות אירוח בישראל ועוד רבות מאוד סביב לעולם) והעבירו את הדומיין לניהול ב-Cloudflare.
בשלב הזה תקבלו שתי רשומות כדי להטמיע ברשם הדומיינים במקום השרתים הקיימים. צרו גיבוי של ה-Zone (הרשומות הקיימות) ב-DNS הישן לגיבוי. העברת ה-DNS שואבת את הרשומות מהשרת הישן. לא כל הרשומות נדרשות ושכיח שרשמי דומיינים דוחפים רשומות מיותרות ל-DNS שרלוונטיות לשירות שלהן אך לא יהיו פעילות או אף יזיקו לאחר המעבר. לכן כדאי לדעת מה שעושים ולדעת לבקש סיוע מקצועי בעת הצורך.
אנשים חושבים שאימייל זה קל כי כל אחד יודע לשלוח אימייל… אבל מאחורי הקלעים זה עולם ומלאו שהבסיס שלו הוא טכנולוגי ודורש הבנה והתעמקות בקוצו של יוד.
האזנה לפודקאסט
מדוור ענק, טעות קטנה, חסימה גדולה
לקוח גדול שאני מלווה מספר חודשים מנהל תשתית דיוור פנימית (שרתי MTA עצמאיים) ומדוור כמה מיליוני אימיילים ביום. על דעת עצמו וללא סיוע מתאים הלקוח ביצע מעבר בין שירותי DNS בשיטת copy paste. ה-DNS היה מוגדר מצוין בשירות הקודם והכל עבד כמו שצריך בהקשר של ה- DNS עד המעבר אל שרת Route53 ה-DNS של Amazon. ואז הדברים התחילו להשתבש. הלקוח פנה אלי ותיאר סיטואציה של חסימות של כתובות IP ב-Spamhaus. בדיקת החסימה התגלתה כ-CSS המצביעה על שרתים שלא מוגדרים נכון.
מה קרה?
כל שרת DNS מתנהג אחרת. שרת Route53 של אמזון דורש ברשומות TXT למשל לשרשר רשומות ארוכות. כך קרה שה- DKIM שהוגדר באורך 2048 נשבר ואימות הדומיין שלהם נכשל, מה שהוביל בווליום שהם שולחים לחסימה קריטית של כל השרתים המדוורים. כמו כן לא הוגדר PTR (reverse DNS) על הכתובות לאחר המעבר ל-DNS החדש, וזו בהחלט סיבה לחסימה.
מה אפשר היה לעשות אחרת כדי למנוע את הבעיה שנוצרה?
במעבר DNS או ביצוע שינויים ב-DNS (שפעמים רבות יש אליו גישה ליותר מידי אנשים) כדאי לבדוק את אימות הדומיינים מחדש ולוודא שההגדרות תקינות לפני שחוזרים לדוור (אם יש אוטומציות לעצור אותן זמנית בעת המעבר). זו פעולה שכדאי לעשות תקופתית בדיוק מאותה סיבה. בדיקה יכולה להתבצע על ידי שליחת אימייל לשירות כגון ratemy.email שמחזיר דוח של מצב האימות.
אימות דומיינים באימייל העסקי
לקוחות רבים שמשתמשים ב-Google Workspace פונים אלי עם בעיה – אימיילים שלהם שולחים מגיעים לספאם אפילו כשהם מתכתבים לכאורה “בתוך הארגון” עם יוזרים אחרים בדומיין העסקי.
מה קרה?
בחלק גדול מהמקרים האלה הסיבה לכך נובעת משימוש באימייל העסקי לצרכי דיוורים שיווקיים באופן כזה שפוגע בדומיין .זה שכיח בקרב מי שעושים cold email. אך פעמים רבות הבעיה נובעת מכך שאימות הדומיין לא השולם. ב-Google Workspace וב- Microsoft 365 אימות הדומיין לא מבוצע אוטומטית לאחר הוספת הדומיין לשירות האימייל ובשני השירותים אינה מוסיפה רשומות DKIM לאימות הדומיין (ב-365 מתווסף SPF וב-GWS מתווסף SPF רק אם הדומיין רשום ב-Google שהיא בעצמה רשם דומיינים).
מה אפשר היה לעשות אחרת כדי למנוע את הבעיה שנוצרה?
במסך ה-Admin בחלונית העליונה (רלוונטי גם ל-GWS וגם ל-365) חפשו DKIM במסך האימות ושם תראו את הסטטוס של האימות. בדוגמא שבתמונה מתוך google Workspace אפשר לראות שהסטטוס הוא: “לא מתבצע אימות אימייל”. כלומר הדומיין אינו מאומת עם רשומת DKIM.
לכן ניצור את הרשומה ב-DNS של הדומיין. זו רשומות TXT המורכבת משני חלקים: החלק הראשון הוא המפריד (S= Selector) של הדומיין במקרה הזה google._domainkey שצריך לרשום או להדביק ב-name ברשומת ה-TXT ב-DNS והחלק השני הוא מפתח ה-DKIM הציבורי שאותו יש להדביק בחלונית השנייה. לשים לב לא להשמיט אף תו ולוודא שאין רווחים (למה Google לא שמו כפתור copy? היה יכול לחסוך טעויות).
באופן דומה ב-Microsoft 365 מחפשים באפליקציית admin בחלונית העליונה DKIM, מגיעים לרשימה של דומיינים המוגדרים במערכת מסמנים את הדומיין ומזיזים את הכפתור. יתקבלו שתי רשומות CNAME שיש להקים ב-DNS של הדומיין.
הטמעת SPF ב-365 וב-GWS נעשית באמצעות רשומת TXT. שימו לב לא לעשות טעות שרבים עושים ולהוסיף כמה רשומות SPF על אותו דומיין. מותר רק רשומה אחת וכאמור מספר ה-lookups יכול להיות עד 10.
אם יש לכם רשומות SPF נוספות תחת הדומיין צריך לאחד אותן לרשומה אחת, כמודגם בתמונה למטה.
*** Microsoft 365 SPF (TXT record)
v=spf1 include:spf.protection.outlook.com -all
*** Google Workspace SPF (TXT record)
v=spf1 include:_spf.google.com ~all
*** Example of inclusing Google Workspace and one other service
v=spf1 include:_spf.google.com include:spf.sendinblue.com ~all
למה DMARC?
DMARC אינו פרוטוקול לאימות דומיין וניתן לשלוח אימיילים גם ללא DMARC. מערכות דיוור רבות דורשות מהלקוח להציב רשומת DMARC חסרת משמעות ב-DNS שלא תשפר ללקוח את העבירות. ראיתי גם מקרים שהרשומה אינה מדווחת ונמצאת במצב אכיפה כגון reject או quarantine מה שעשוי אף להוביל לחסימה של מיילים.
יישום DMARC באמצעות כלי יאפשר לנטר את הדוחות, לזהות תשתיות דיוור שדורשות טיפול ולהתקדם באבולוציה של אימות DMARC על למצב אכיפה בו אפשר לצפות לשיפור בעבירוּת. זו אבולוציה של לפחות 3 חודשים, כחודש בכל שלב.
דוגמא לרשומה חסרת משמעות:
format: TXT record
Host: _dmarc.domain.co.il
Value: v=DMARC1; p=none; adkim=r; aspf=r
כלי הטמעה וניטור DMARC נפוצים
| שם הכלי | הערות |
| easydmarc | value for money |
| Uriports | value for money |
| dmarcdigests | value for money |
| dmarcly | |
| dmarcian | |
| kdmarc | |
| dmarcanalyzer | |
| dmarcreport |
ראו הרחבה במאמר על רשומת DMARC
אני סלע יפה, מומחה אימייל מרקטינג ועבירוּת אימיילים. אני מזמין אותך לפגישת יעוץ ראשונית של 1/2 שעה ללא עלות בנושא עבירוּת אימיילים ואסטרטגיית אימייל מרקטינג. book an email deliverability discovery call.
לקריאה נוספת
Sella Yoffe
Email Deliverability & Email Marketing Expert
Helping global email senders, startups, digital agencies, and ESPs with email deliverability, email authentication (SPF, DKIM, DMARC, BIMI), and email & content strategy
Podcast creator & Blogger @ CRM.BUZZ & EmailGeeks.Show
