DNS הוא הרבה יותר מסתם רכיב טכני - הוא הבסיס לניהול כל עסק אונליין. כל אימייל שמתקבל נבדק מול רשומות ב-DNS. טעויות בהגדרתו עלולות לגרום לבעיות עבירוּת ולמנוע מכם להגיע לתיבת האימייל של הנמענים. מהו DNS, מה תפקידו באימייל מרקטינג ואיך להגדיר ולתחזק אותו נכון?
תוכן עניינים
מהו DNS ולמה הוא חשוב כל כך לפעילות אימייל מרקטינג?
מערכת שמות המתחם, או DNS (ראשי תיבות של (Domain Name System היא מרכיב קריטי לתפקוד כל תשתית אינטרנט. לעיתים קרובות אולי בגלל היותו מרכיב טכני, ה-DNS ואופן ניהולו אינם מקבלים את תשומת הלב הראויה מצד מדוורים ובעלי אתרים וזה מקור לצרות.
במסגרת תהליכי ליווי לקוחות בנושא deliverability אני נתקל בהמון בעיות סביב ה-DNS. יש ל- DNS תפקיד קריטי לפעילות תקינה של אימייל מרקטינג ואימייל בכלל. ה- DNS שומר בתוכו את כל ההגדרות הדרושות לזיהוי, ניתוב, אימות ואבטחת תעבורת האימיילים.
מאוד שכיחות טעויות שונות בהגדרת ה-DNS ואופן התחזוקה שלו – ויש לכך השפעה ישירה על בעיות עבירוּת שקשורות ב-setup הטכני.
מהו DNS?
ה- DNS הוא שילוב של מאגר נתונים (נקרא Zone File) ונתב שמקשר בין שמות מתחם (דומיינים) למערכות שונות והגדרות הקשורות בהן.
ה-DNS מתרגם ומתווך בין מערכת שמבקשת לתשאל את המאגר ומנתבת את השאילתא אל הרשומה המתאימה במאגר הנתונים.
לדוגמא כשתרשמו בדפדפן crm.buzz או כל כתובת אתר אחרת, הדפדפן באמצעות ספק האינטרנט שלכם ייגש אל ה-DNS של הדומיין ויקבל את כתובת ה-IP של שרת האחסון של האתר. מערכות שונות יבקשו מכם להוסיף רשומה TXT ל-DNS לאימות הבעלות על הדומיין וכך הלאה. בצורה דומה שרתי דואר גם לפעילות אימייל מרקטינג. בכל אימייל שמתקבל ספקית האימייל בודקת רשומות ב-DNS כדי לאמת את הדומיין (רשומות SPF, DKIM), נוכחות של רשומת DMARC תקינה ומה הפוליסי שלה, ובדיקות של רשומות נוספות מול ה-DNS.
אלו רשומות ה-DNS הנפוצות שכדאי שתכירו
A Record (Address Record) – מקשרת שם דומיין לכתובת IP מסוג IPv4 ומצביעה בד”כ על כתובת ה-IP של השרת המארח את האתר שלכם. לדוגמא: 65.198.51.79
כתובת AAAA Record מקשרת בין דומיין אל כתובת IP מסוג IPV6 . לדוגמא: 2001:db8:85a3::8a2e:370:7334
CNAME Record (Canonical Name Record) מפנה דומיין אחד לאחר. בד”כ משתמשים בה להגדרות של סאב דומיינים. לא ניתן להשתמש ברשומת CNAME לדומיין הראשי אלא לתת דומיינים.
MX Record (Mail Exchange Record) מגדירה לאן יש לשלוח אימיילים שמיועדים לדומיין. אם יש כמה שרתי דואר משתמשים ב priority (עדיפות). ככל שהמספר הנמוך יותר העדיפות גבוהה יותר.
TXT Record (Text Record) – לרוב משמשת לאימותים ובמקרים רבים באמצעותה מגדירים רשומות SPF, DKIM ו-DMARC. במקרים מסוימים מערכות דיוור שונות מגדירות רשומות אלו באמצעות CNAME.
NS Record (Name Server Record) – מציין אילו שרתי DNS אחראים על הדומיין. לפעמים נרצה להגדיר שרתי NS לתת דומיינים כדי למשל לתת למערכת הדיוור לנהל את הסאב דומיין שממנו אנו מדוורים.
SOA Record (Start of Authority) – רשומה המשמשת לאבטחת DNS. מציינת את השרת הראשי, מנהל הדומיין וזמני הרענון.
PTR Record – ממפה כתובת IP לשם דומיין. רשומה זו חיונית לאימות שרתי דיוור באמצעות בדיקות DNS הפוכות: התאמה של IP אל שם הסאב דומיין של שרת ה-MTA והתאמה של שם השרת ל-IP.
רשומת SPF שקיימת ב-DNS יצאה משימוש ובמקומה יש להשתמש ברשומת TXT או CNAME בהתאם להגדרה שתקבלו ממערכת הדיוור שלכם.
ישנן רשומות נוספות אך הן פחות שכיחות.
למה כדאי להפריד בין ניהול DNS לרשם הדומיין?
כל רשם דומיינים מספק גם שירות DNS בסיסי ורבים מבעלי הדומיינים משאירים את ניהול ה-DNS אצל רשמי הדומיינים. כאמור, DNS הוא תשתית קריטית ובמקרים רבים ה-DNS ברשמי הדומיינים הוא מיושן, פחות מאובטח ופתח לצרות.
קרו מקרים של פריצות ואירועי אבטחה ברשמי דומיינים (כולל ברשמים בישראל) שלא פגעו ברישום הדומיין עצמו אך מנעו גישה לניהול ה-DNS. עוד סיבה טובה להפריד בין רשם הדומיינים ל-DNS.
לכל שירות DNS, כולל בשרתים המקצועיים, יש מגבלות והגדרות שונות. לדוגמה, שירות ה-DNS של Amazon אינו מאפשר רשומות TXT באורך רב, ולכן יש לשרשר אותן. רשומת DKIM באורך 2048 ביט למשל לא תועבר כראוי בעת מעבר מ-DNS אחר לשירות ה-DNS של Amazon, אם לא תתבצע התאמה מראש. כבר נתקלתי בלקוחות שביצעו מעבר כזה מבלי לבדוק, וגילו שכל שרתי הדיוור שלהם נכנסו לרשימות חסימה ב- Spamhaus.
שימוש ב-DNS של Cloudflare או Cloudns במקום בשרתי ה- DNS של רשם הדומיינים מספק יתרונות משמעותיים, בהם ביצועים מהירים יותר בזכות פריסה גלובלית, זמינות גבוהה עם יתירות (מאות שרתים ברחבי העולם) ומנגנונים למניעת השבתה, אבטחה מתקדמת הכוללת הגנה מפני מתקפות DDoS ותמיכה ב-DNSSEC. בנוסף, השירותים הללו מציעים ממשקי ניהול נוחים ופעולות מתקדמות נוספות.
רבים מאיתנו מחזיקים דומיינים רבים שרשמנו אך הם לא פעילים. בכל מקרה שהדומיינים משמשים לפעילות עסקית אני מציע להעביר את ניהול ה-DNS לשרת חיצוני כמו ב-Cloudflare. דומיינים שאינם פעילים אפשר להשאיר ברשם הדומיינים ולא לשכוח להגדיר אותם כ-parked domains כדי למנוע מספאמרים לדוור דרכם. עושים את זה על ידי הגדרת רשומת SPF שתמיד תיכשל ורשומת DMARC במצב reject.
ראו הרחבה במאמר על דומיינים חונים (parked domains)
לשרת ה-DNS של Cloudflare יש יתרונות נוספים:
ניתן לשתף את משתמשים אחרים בהרשאות מתאימות בחשבון מבלי לתת את שם המשתמש והסיסמה הראשיים. בנוסף, יש אפשרות לרשום הערה ותגית לגבי כל רשומה, מה שמקל על תיעוד ועוזר לנהל את הרשומות החיוניות ולא פחות חשוב את אלה שכבר לא רלוונטיות וכדאי למחוק מה-DNS. השירות של Cloudflare הוא הרבה מעבר ל-DNS. היא מספקת שירותי אבטחה, ביצועים וניהול תעבורה לאתרים ואפליקציות באמצעות רשת ענן גלובלית. אם ה-DNS שלכם מנוהל ב-Cloudflare תוכלו להפעיל שירות ניטור DMARC בסיסי ובחינם.
אבטחת DNS
DNSSEC (ראשי תיבות של Domain Name System Security Extensions) הוא הרחבה לפרוטוקול ה-DNS שמטרתה להגן על משתמשים מפני זיוף נתונים (כמו מתקפת DNS spoofing או cache poisoning), על ידי אימות קריפטוגרפי של המידע שמתקבל משרת ה-DNS. במקרה כזה צריך להגדיר רשומות DS ב-DNS בשילוב מידע מרשם הדומיינים. ההמלצה שלי להגדיר DNSEC לאחר העברת ה-DNS מרשם הדומיינים לניהול DNS חיצוני.
ה- DNS כבסיס לפרוטוקולי אימות האימיילים: SPF, DKIM, DMARC
בכל אימייל שנשלח ממערכת הדיוור או כל מערכת מדוורת בשם הדומיין, שרתי הדואר של הצד המקבל (ספקיות אימייל, שרתי אימייל ארגוניים וכדומה) יבצעו פניות אל ה-DNS של הדומיין ויבדקו את הרשומות לאימות הדומיין SPF, DKIM, DMARC.
פרוטוקול SPF (Sender Policy Framework) מאפשר להגדיר מקורות מאושרים מהם אימיילים נשלחים (sources) ברמת הדומיין השולח כגון כתובות IP, תחומי כתובות (רשתות), רשומות אחרות (A record, MX record, PTR record), , כתובות ורשתות של צדדי ג’ וכדומה.
הגדרת SPF נעשית באמצעות רשומת TXT או CNAME ב-DNS של הדומיין השולח, פרוטוקול SPF מאפשר להגדיר מקורות המורשים לשלוח בשם הדומיין. הוא גם מאפשר למנהל הדומיין להגדיר חוקים במקרה של אי התאמה (pass, fail, soft fail, neutral).
פרוטוקול DKIM (DomainKeys Identified Mail) הוא רשומת TXT (או CNAME) ב-DNS, המגדירה דומיינים האחראים על ההודעה מבחינת חתימת ההודעה ומצפינה מקטע מתוכן ההודעה (body).
הרשומה אינה משמשת רק לאימות דומיין אלא גם כאמצעי אבטחה המוודא שהודעת אימייל לא עברה שינוי בדרך בין מוען (השולח) לנמען (המקבל).
פרוטוקול DMARC – ראשי תיבות של Domain-based Message Authentication, Reporting & Conformance – אינו פרוטוקול לאימות דומיין ועד לכניסתן לתוקף של הדרישות החדשות של גוגל ויאהו בשנה שעברה, לא הייתה חובה להטמיע DMARC. זהו פרוטוקול שנועד להגן על דומיינים ומותגים, ולספק כלים לניטור והתאמה של הגדרות SPF ו.DKIM-
באמצעות מדיניות (policy) ברורה, ניתן להורות לספקיות אימייל כיצד להתייחס להודעות שנכשלות באימות SPF אוDKIM . למשל: לא לעשות כלום, לשלוח להסגר (quarantine) או לדחות את ההודעה (reject). המדיניות הזו מקלה על ספקיות האימייל להחליט במהירות כיצד לטפל בהודעות, מה שמייעל את הסינון ומפחית אצלן את עלויות התפעול.
בנוסף, DMARC מספק דוחות אגרגטיביים ופורנזיים מהצד המקבל, שמאפשרים לבעלי הדומיין כיצד מתקבלות הודעותיו. הדוחות כוללים מידע על מצב האימות (למשל: SPF תקף או לא) ועל התאמה בין כתובת השולח המוצהרת לבין זו שנבדקה בפועל (alignment).
היישום של שלושת הפרוטוקולים האלו בצורה מדויקת הוא תנאי סף לעבירוּת אימיילים. זה לא רק מגביר את האמון מצד ספקיות האימייל, אלא גם מצמצם את הסיכוי להתחזויות ומצמצם נזק במקרה של מתקפות פישינג (בתנאי ש-DMARC של הדומיין המדוור במצב אכיפה).
טעויות נפוצות בהגדרת DNS שמובילות לבעיות בעבירוּת
מעסקים קטנים ועד ארגונים גדולים נופלים בפח של הגדרות DNS חלקיות או שגויות. ניהול DNS סובל משתי בעיות קיצון:
בעסקים קטנים בד”כ יש גישה אל ה-DNS לפרינלסר חיצוני אחד או יותר אבל פעמים רבות אין גשיה לבעלי העסק. כבר נתקלתי בסוגיות שונות סביב זה החל מבעלי עסקים שאבדו גישה ל-DNS ואפילו סחיטה של ממש סביב מחלוקת עסקית שמנעה מבעלי העסק גישה ל-DNS.
לעיתים הדומיין נרשם על שם סוכונות דיגיטל ולא על שם בעלי העסק מה שפותח סט שלם של בעיות.
ראו הרחבה על טעויות בשמירה על נכסים דיגיטליים
בארגונים גדולים בד”כ יש בעיה אחרת – ליותר מידי אנשים יש גישה ל-DNS ואין תיעוד מספק של הפעולות שנעשו ומידת ההשפעה שלהן. מספיק שפסיק לא במקום או שמישהו מחק רשומה קריטית כדי ליצור בעיה באימות הדומיין.
מבחינת הגדרות שקשורות באימייל מרקטינג אלו הטעויות הנפוצות בהגדרות DNS:
- לא מבצעים הפרדה בין ניהול ה-DNS של הדומיין לבין רשם הדומיין (ראו הרחבה כאן).
- שימוש ברשומת SPF מסוג SPF שכבר לא נתמכת ולא ברשומת TXT או CNAME.
- הוספת מקורות שיוצרים יותר מידי DNS lookups כלומר, הפניה למקורות חיצוניים שיוצרים יותר מ-10 שאילתות ל-DNS, דבר שגורם לכישלון האימות. הפתרון לזה הוא צמצום מספר המקורות (include) ושימוש במאקרו ב-SPF או באמצעות שירות .SPF flattening (כלי ניטור ה-DMARC מציעים פתרונות כאלה).
- יצירת יותר מרשומת SPF אחת. בפועל מותר ליצור רק רשומה אחת פר דומיין. ניתן להגדיר רשומות SPF נפרדות לסאב דומיינים. אם צריכים להוסיף מקור שולח צריך לערוך את רשומת ה-SPF הקיימת וגם זה פתח לטעות למי שאינו מנוסה בכך ועשוי ליצור overflow בכמות השאילתות ל-DNS.
- רשומת DMARC: במערכות הדיוור בד”כ יציעו לכם להגדיר רשומה חסרת תועלת כדי לצאת ידי חובה, ללא RUA – רשומה שאינה כוללת כתובת אימייל לקבלת דוחות. בסופו של דבר המטרה של DMARC היא להגן על המותג והדומיין מפני התחזות (spoofing). כדי לעשות זאת צריך לעבוד עם כלי לפריסה וניטור DMARC, לעבור מסע DMARC תוך טיפול והגדרה של כל התשתיות המדוורות תחת הדומיין עד למצב אכיפה והמשך ניטור מתמיד. כלי ניטור DMARC מקצועי יציף בעיות אימות ב-SPF ו-DKIM בזמן אמת בכל מקרה שמישהו שינה הגדרות ב-DNS.
כלי הטמעה וניטור DMARC נפוצים
| שם הכלי | הערות |
| easydmarc | value for money |
| Uriports | value for money |
| dmarcdigests | value for money |
| dmarcly | |
| dmarcian | |
| kdmarc | |
| dmarcanalyzer | |
| dmarcreport |
מדוע DNS מהיר ומאובטח חשוב לאימייל מרקטינג?
DNS איטי או לא אמין יכול לעכב את פעולת אימות האימיילים, או במקרים גרועים יותר להוביל לכישלון בתהליך האימות. שרתי דואר של חברות כמו Gmail, Microsoft או Yahoo מבצעים בקשות DNS בזמן אמת כדי לבדוק את רשומות האימות של כל הודעת אימייל. אם הרשומות אינן זמינות או שהבקשות נכשלות עקב תגובה איטית מה- DNS קיים סיכון שהאימות יכשל. בנוסף, שרתי DNS הם יעד למתקפות DDOS (מניעת שירות) מה שגורם ל-DNS המותקף לחוסר זמינות רגעית או מתמשכת או לאיטיות. בעניין הזה אני פחות סומך על שרתי ה- DNS של רשמי הדומיינים.
מעבר לכך, שרת DNS שאינו מאובטח עלול להיות נתון להתקפות מסוג DNS hijacking אוcache poisoning. תוקף שמצליח להשתלט על רשומות הדומיין יכול לשנות את כתובת שרת הדואר (MX), לשלוח אימיילים מזויפים, או להפנות תעבורה לכתובות זדוניות. כל אלו מסכנים את הארגון ואת אמינותו, פוגעים במותג ועלולים ליצור נזק שיווקי ותדמיתי.
רשמי דומיניים בסיומת il (מקור איגוד האינטרנט הישראלי)
| שם הרשם וקישור לאתר | תומך DNSSEC |
| דרוביט רייד בע"מ (mynames) | + |
| דומיין דה נט טכנולוגיות בע"מ | + |
| LiveDNS | + |
| אינטרספייס בע"מ | + |
| סטאר תקשורת ויזמות בע"מ | + |
| בזק בינלאומי בע"מ | + |
| טריפל סי מחשוב בע"מ | + |
| קומיוניגל בע"מ (גלקום) | + |
| ג'ט סרבר קלאוד בע"מ | + |
| גורני אינטראקטיב בע"מ (BOX) | + |
| סקיורסט בע"מ | |
| Safenames Ltd | No |
| פוליגון בע"מ | No |
| Tucows Domains | + |
לכן, חשוב לבחור שירות DNS עם יכולות אבטחה גבוהות כגון הגנה נגד התקפות DDoS, תמיכה ב-DNSSEC (לא כל רשמי הדומיינים הישראלים תומכים ב-DNSEC) ועם מהירות תגובה גלובלית גבוהה. שימוש בשירותים כמו Cloudflare, AWS Route 53 או CloudDNS עדיפים על פני השארת ניהול ה-DNS של הדומיין בשירות ה-DNS הבסיסי שמקבלים ברשם הדומיינים.
ראיונות בפודקאסט עם מומחי אימייל מרקטינג בינלאומיים
האזנה לפודקאסט
פודקאסט ובלוג מובילים בעברית בנושאי אימייל מרקטינג (email marketing) ועבירוּת אימיילים (deliverability).
הגעתם אל הבלוג והפודקאסט המובילים והמעודכנים ביותר בעברית בתחום אימייל מרקטינג, עבירוּת אימיילים, שיווק ודאטה. כאן תמצאו שפע מאמרים מפורטים ופודקאסטים מקצועיים למתחילים ולמתקדמים, המכסים את התחום בצורה מעמיקה.
חלק מהפרקים כוללים ראיונות עם מומחי אימייל מרקטינג בינלאומיים מובילים, המשולבים בעברית.
אימייל מרקטינג הוא ערוץ ותיק, אך דווקא בגלל שהוא “הסבא” של המדיה הדיגיטלית, הוא לא תמיד זוכה לתשומת לב והמקצועיות הראויה. היום הולך ונהיה קשה יותר להגיע לאינבוקס. כדי להצליח באימייל מרקטינג, יש להתמקצע ולא להסתמך רק על הפלטפורמה (מערכת הדיוור) שתעשה את הכל.
בבלוג ובפודקאסט תמצאו מידע מקיף ועדכני בנושאים כמו אימייל מרקטינג, עבירוּת אימיילים, סקירות מערכות דיוור, אוטומציה שיווקית, שיווק באמצעות תוכן, אימייל מרקטינג לאיקומרס, טיפים לשיווק במייל, דיוור בסטארטאפים ועוד.
יוצר הפודקאסט והבלוג, סלע יפה, הוא מומחה בינלאומי לעבירוּת אימיילים ושיווק באימייל. הוא מסייע למדוורים גלובליים, סטארטאפים, סוכנויות אימייל ומערכות דיוור (ESPs) בנושאי עבירוּת אימיילים, אימות אימייל (SPF, DKIM, DMARC, BIMI) ואסטרטגיית אימייל.
A blog and podcast (in Hebrew) about email marketing, email deliverability, marketing, and data.
חלק שני של הריאיון המרתק עם Jakub Olexa, מנכ”ל מערכת הדיוור Mailkit ושרת הדיוור הטרנזקציוני Omnivery, ומהמומחים הבולטים לתופעת האינטראקציות הלא אנושיות.
מדובר בבוטים “טובים” שפותחים ומקליקים על אימיילים כדי להגן על פרטיות המשתמשים או על מנת לבצע סריקה של הקישורים שבתוך האימייל לצורכי אבטחה.
זה יוצר שיבוש בעולם האימייל מרקטינג – חלק גדול מהפתיחות וגם חלק מסוים מההקלקות שאתם רואים במערכת הדיוור שלכם הם נתונים מנופחים של פתיחות והקלקות שווא, בדיוק בגלל התופעה הזו של אינטראקציות לא אנושיות.
אני מתכוון לערוך את הפרק ולתרגם אותו לעברית ואפרסם את הפרק בליווי תרגום סימולטני לעברית בהמשך כאן ב-crm.buzz
בינתיים אני מפרסם כאן את הפרק באנגלית, בשני חלקים. השבוע יובא החלק ראשון ובשבוע הבא אביא את החלק השני.
השבוע אשתתף ב- Deliverability Summit (וועידת עבירוּת) באמסטרדם ביומיים מרוכזים של מינגלינג ולמידה עם המומחים המובילים בעולם, גם את Jakub אפגוש שם. הוועידה מתמקדת בניהול עבירוּת במערכות דיוור, ניהול שרתי דיוור, ויחסי הגומלין בין מערכות דיוור, הלקוחות של מערכות הדיוור, ספקיות האימייל והגופים הנלחמים בספאם.
אני מתכוון לערוך ראיונות בשטח ואשזור אותם בפרקים הבאים של הפודקאסט.
הכרטיסים לוועידה עצמה אזלו, אבל אפשר לצפות בשידור הסטרימינג מהוועידה אונליין ואף קיבלתי ממארגני הועידה קוד הנחה למי שמעוניין לרכוש כרטיס.
קוד הנחה: SELLA
אני סלע יפה, מומחה אימייל מרקטינג ועבירוּת אימיילים. אני מזמין אותך לפגישת יעוץ ראשונית של 1/2 שעה ללא עלות בנושא עבירוּת אימיילים ואסטרטגיית אימייל מרקטינג. book an email deliverability discovery call.
לקריאה נוספת
רשומות DNS המדריך המקוצר המלא, Cloudflare
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
