הגדרת AWS SES לשליחת אימייל: DKIM, DMARC, טיפול בהחזרות

הגדרת AWS SES: מדוע הודעות נופלות לספאם

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

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

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

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

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

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

מה נותנת עבודה נכונה עם AWS: יכולת מסירה ומוניטין דומיין

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

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

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

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

מצבי שליחה: שער משותף, דומיין משלך או ערוץ ייעודי

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

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

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

שלבי יישום: מביקורת רשומות DNS ועד מסירת נהלים

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

1. ביקורת DNS והדואר הנוכחי. משווים SPF עם כל השולחים החיצוניים, MX, סלקטורי DKIM קיימים, TTL ותת-דומיינים. קובעים מי עוד שולח הודעות בשם הדומיין.
2. סכימת דומיינים ותצורת שליחה. ב-AWS SES מגדירים תת-דומיין לשליחה, אזור, מגבלה יומית של שליחה והתנהגות בעת חריגה. מפרידים זרמים טרנזקציוניים ושיווקיים כדי שהמוניטין של אחד לא ישקע את השני.
3. חתימת DKIM. מפרסמים מפתח ציבורי כרשומת CNAME, מפעילים חתימה, ומיד מכינים סלקטור שני לרוטציה – החלפה ללא השבתה.
4. SPF, MAIL FROM, DMARC טיוטתי. מגדירים תת-דומיין משלנו ליישור השולח, מפרסמים DMARC במצב ניטור עם דוחות: קודם אוספים סטטיסטיקה, לא חוסמים.
5. טיפול בסירובים ובתלונות. סירובים קשים מועברים מיד לרשימת חסימה, רכים – עם חזרות. אחרת שליחות לכתובות לא קיימות אוכלות את המוניטין במהירות.
6. בדיקת חתימה וניטור מסירה. הודעות בדיקה לתיבות חיצוניות, ניתוח כותרות ליישור DKIM ו-SPF, התראות לפי אחוז סירובים ותלונות.
7. מסירת נהלים. תיעוד: רוטציית מפתחות, הוספת שולחים ל-SPF, סדר החמרת DMARC וטיפול בתקריות.

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

מה נשאר לכם לאחר המסירה: רשומות, תצורות, נהלים

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

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

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

לקוח הגיע עם הודעות טרנזקציוניות: אישור הרשמה, איפוס סיסמה, קבלות. לתיבת הנכנסת נכנסו כ-62% מהשליחות, השאר שקעו בספאם ובלשונית 'מבצעים', ואחוז הסירובים עמד על 8% – את בסיס הכתובות לא ניקו שנים, וכל סירוב התמיכה טיפלה בו ידנית.

מה שינו בזרם

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

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

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

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

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

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

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

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

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

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

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

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

ספקות טכניים: מוניטין, מגבלות וטיפול בסירובים

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

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

איך להבין שהכתובת נכנסה לרשימה שחורה?

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

נמענים מתלוננים על ספאם — עד כמה זה קריטי?

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

מי מתחזק את רשומות האימות לאחר המסירה?

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

נדון במשימה: נחזור עם הערכה ותוכנית יישום

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

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

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

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