כיצד להגדיר את אזור DNS TXT עבור SPF, DKIM ו-DMARC וכיצד למנוע דחיית הודעות דואר אלקטרוני עסקיות על ידי Gmail - משלוח דואר נכשל

Administratorii de דוא"ל פרטי חמור לעסקים לעתים קרובות הוא מתמודד עם בעיות ואתגרים רבים. מהגלים של דואר זבל אשר חייב להיות חסום על ידי מסננים ספציפיים, אבטחת התכתבות בשרת הדואר האלקטרוני המקומי ובשרתים מרוחקים, תצורה si ניטור שירותי SMTP, POP, IMAPועוד המון המון פרטים אחרים תצורת SPF, DKIM ו-DMARC כדי לפעול לפי שיטות עבודה מומלצות לשליחת דואר אלקטרוני מאובטחת.

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

כדי שהודעות דואר אלקטרוני יישלחו משם דומיין, זה חייב להיות מתארח בשרת דואר אלקטרוני מוגדר כהלכה, ו שם דומיין שיכלול אזורי DNS עבור SPF, MX, DMARC SI DKIM מוגדר נכון במנהל DNS TXT של התחום.

במאמר של היום נתמקד בבעיה נפוצה למדי שרתי דואר אלקטרוני עסקיים פרטיים. לא ניתן לשלוח דואר אלקטרוני ל-Gmail, Yahoo! אוֹ iCloud.

הודעות שנשלחות אל @ Gmail.com נדחות באופן אוטומטי. "משלוח דואר נכשל: החזרת הודעה לשולח"

לאחרונה נתקלתי בבעיה ב דומיין דואר אלקטרוני של חברה, שממנו נשלחים באופן קבוע הודעות דואר אלקטרוני לחברות אחרות ולאנשים פרטיים, שלחלקם יש כתובות @ Gmail.com. כל ההודעות שנשלחו לחשבונות Gmail הוחזרו מיד לשולח. "משלוח דואר נכשל: החזרת הודעה לשולח".

הודעת שגיאה הוחזרה לשרת הדואר האלקטרוני ב- EXIM נראה ככה:

1nSeUV-0005zz-De ** reciver@gmail.com R=dnslookup T=remote_smtp H=gmail-smtp-in.l.google.com [142.x.x.27] X=TLS1.2:ECDHE-ECDSA-AES128-GCM-SHA256:128 CV=yes: SMTP error from remote mail server after pipelined end of data: 550-5.7.26 This message does not have authentication information or fails to\n550-5.7.26 pass authentication checks. To best protect our users from spam, the\n550-5.7.26 message has been blocked. Please visit\n550-5.7.26  https://support.google.com/mail/answer/81126#authentication for more\n550 5.7.26 information. d3-20020adff843000000b001f1d7bdaeb7si6107985wrq.510 - gsmtp

בתרחיש זה לא מדובר במשהו מאוד רציני, כגון כלול את שם הדומיין השולח או ה-IP השולח ברשימת דואר זבל גלובלי או o שגיאת תצורה גדולה של שירותי דואר אלקטרוני ב-server (EXIM).
למרות שאנשים רבים רואים הודעה זו מיד כשהם חושבים על דואר זבל או שגיאת תצורה של SMTP, הבעיה נוצרת על ידי האזור. DNS TXT של התחום. לרוב, DKIM אינו מוגדר באזור ה-DNS או אינו מועבר כהלכה במנהל ה-DNS של הדומיין. בעיה זו נתקלת לעתים קרובות על ידי המשתמשים בה CloudFlare כמנהל DNS ותשכח לעבור DNS TXT: mail._domainkey (DKIM), DMARC si SPF.

כפי שמספרת לנו הודעת הדחייה של Gmail, האותנטיות והאימות של דומיין השולח נכשלו. "להודעה זו אין פרטי אימות או לא מצליחה \ n550-5.7.26 לעבור בדיקות אימות." המשמעות היא שלדומיין אין DNS TXT מוגדר כדי להבטיח אמינות עבור שרת הדואר האלקטרוני של הנמען. Gmail, בסקריפט שלנו.

כאשר אנו מוסיפים דומיין אינטרנט עם שירות דואר אלקטרוני פעיל ב-cPanel או VestaCP, הקבצים באזור ה-DNS של אותו דומיין נוצרים אוטומטית. אזור DNS הכולל תצורת שירות דואר אלקטרוני: MX, SPF, DKIM, DMARC.
במצב בו אנו בוחרים את התחום להיות המנהל DNS CloudFlare, יש להעתיק את אזור ה-DNS של חשבון האירוח של הדומיין ל-CloudFlare על מנת שדומיין הדוא"ל יפעל כראוי. זו הייתה הבעיה בתרחיש לעיל. במנהל DNS של צד שלישי, רישום DKIM אינו קיים, למרות שהוא קיים במנהל ה-DNS של השרת המקומי.

מה זה DKIM ומדוע דוא"ל נדחה אם אין לנו תכונה זו בדומיין דוא"ל?

דואר מזוהה של DomainKeys (DKIM) הוא פתרון סטנדרטי לאימות דומיין דואר אלקטרוני המוסיף א חתימה דיגיטלית כל הודעה שנשלחה. שרתי היעד יכולים לבדוק באמצעות DKIM האם ההודעה מגיעה מתחום החוק של השולח ולא מתחום אחר המשתמש בזהות השולח כמסיכה. לכל הדעות, אם יש לך את הדומיין ABCDqwerty.com ללא DKIM, הודעות דוא"ל עשויות להישלח משרתים אחרים באמצעות שם הדומיין שלך. זה אם אתה רוצה גניבת זהות, מה שנקרא במונחים טכניים זיוף דוא"ל.
טכניקה נפוצה בעת שליחת הודעות דואר אלקטרוני דיוג si דואר זבל.

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

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

דוגמה ל-DKIM היא:

mail._domainkey: "v=DKIM1; k=rsa; p=MIGfMA0GCSqGfdSIb3DQEBAQUAA4GN ... ocqWffd4cwIDAQAB"

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

לאחר התקנה והגדרה של DKIM כהלכה DNS TXT מנהל, אפשר מאוד לפתור את הבעיה של הודעות שהוחזרו לחשבונות Gmail. לפחות עבור השגיאה "משלוח דואר נכשל":

"SMTP error משרת דואר מרוחק לאחר סיום הנתונים בצנרת: 550-5.7.26 להודעה זו אין פרטי אימות או לא מצליחה \ n550-5.7.26 לעבור בדיקות אימות. כדי להגן בצורה הטובה ביותר על המשתמשים שלנו מפני דואר זבל, ההודעה \ n550-5.7.26 נחסמה."

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

gmail (גוגל) אולי דוחה אוטומטית את כל ההודעות מגיע מתחומים שאין להם סמנטיקה דיגיטלית כזו של DKIM.

מהו SPF ומדוע הוא חשוב לשליחת דוא"ל מאובטחת?

בדיוק כמו DKIM, ו SPF מטרתו למנוע הודעות דיוג si זיוף דוא"ל. בדרך זו, ההודעות שנשלחו לא יסומנו עוד כדואר זבל.

מסגרת מדיניות שולח (SPF) היא שיטה סטנדרטית לאימות הדומיין שממנו נשלחות הודעות. ערכי SPF מוגדרים ל מנהל DNS של TXT של הדומיין שלך, והערך הזה יציין את שם הדומיין, ה-IP או הדומיינים המורשים לשלוח הודעות דואר אלקטרוני באמצעות שם הדומיין שלך או של הארגון שלך.

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

כמובן שהודעות עדיין יכולות להישלח בשמך משרתים אחרים, אך הן יסומנו כדואר זבל או יידחו אם השרת או שם הדומיין לא יצוינו בערך ה-SPF TXT של הדומיין שלך.

ערך SPF במנהל DNS נראה כך:

@ : "v=spf1 a mx ip4:x.x.x.x ?all"

כאשר "ip4" הוא IPv4 בשרת הדוא"ל שלך.

כיצד אוכל להגדיר SPF עבור מספר דומיינים?

אם ברצוננו לאשר לדומיינים אחרים לשלוח הודעות דואר אלקטרוני בשם הדומיין שלנו, נציין אותם עם הערך "include"ב-SPF TXT:

v=spf1 ip4:x.x.x.x include:example1.com include:example2.com ~all

המשמעות היא שניתן לשלוח הודעות דואר אלקטרוני גם משם הדומיין שלנו אל example1.com ו-example2.com.
זה רשומה מאוד שימושית אם יש לנו למשל אחד חנות מקוונת על הכתובת"example1.com", אבל אנחנו רוצים שההודעות מהחנות המקוונת ללקוחות ישאירו כתובת הדומיין של החברה, ההוויה הזו "example.com". ב SPF TXT עבור "example.com", לפי הצורך כדי לציין לצד IP ו-"include: example1.com". כדי שניתן יהיה לשלוח הודעות מטעם הארגון.

כיצד אוכל להגדיר SPF עבור IPv4 ו-IPv6?

יש לנו שרת דואר עם שניהם IPv4 ועם IPv6, חשוב מאוד ששני כתובות ה-IP יצוינו ב-SPF TXT.

v=spf1 ip4:196.255.100.26 ip6:2001:db8:8:4::2 ~all

לאחר מכן, אחרי ה-IP, ההנחיה "include"כדי להוסיף דומיינים המורשים למשלוח.

מה זה אומר "~all","-all"ו"+allמה-SPF?

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

~all : אם ההודעה מתקבלת מדומיין שאינו רשום ב-SPT TXT, ההודעות יתקבלו בשרת היעד, אך הן יסומנו כספאם או חשודות. הם יהיו כפופים למסנני האנטי-ספאם של שיטות עבודה טובות של ספק הנמען.

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

+all : נעשה בו שימוש נדיר מאוד ואינו מומלץ כלל, תג זה מאפשר לאחרים לשלוח הודעות דואר אלקטרוני בשמך או בשם הארגון שלך. רוב הספקים דוחים אוטומטית את כל הודעות הדואר האלקטרוני שמגיעות מדומיינים עם SPF TXT."+all". בדיוק בגלל שלא ניתן לאמת את האותנטיות של השולח, אלא לאחר בדיקת "כותרת אימייל".

סיכום: מה המשמעות של Sender Policy Framework (SPF)?

מאשר דרך אזור DNS TXT / SPF, כתובות IP ושמות דומיין שיכולים לשלוח הודעות דואר אלקטרוני מהדומיין או מהחברה שלך. זה גם מחיל את ההשלכות החלות על הודעות שנשלחות מדומיינים לא מורשים.

מה המשמעות של DMARC ומדוע זה חשוב לשרת האימייל שלך?

DMARC (דיווח והתאמה של אימות הודעות מבוסס דומיין) קשורה קשר הדוק לתקני מדיניות SPF si DKIM.
DMARC הוא א מערכת אימות נועד להגן שם הדומיין שלך או של החברה שלך, שיטות כגון זיוף דוא"ל ו הונאות דיוג.

באמצעות תקני הבקרה של Sender Policy Framework (SPF) ו-Domain Keys Identified Mail (DKIM), DMARC מוסיף תכונה חשובה מאוד. דיווחים.

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

רשומת DMARC ב-DNS TXT יכולה להיות:

V=DMARC1; rua=mailto:report-id@rep.example.com; ruf=mailto:account-email@for.example.com; p=none; sp=none; fo=0;

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

ניתן להגדיר תגי DMARC בהתאם למדיניות שנכפתה על ידך או על ידי הארגון שלך:

v - גרסה של פרוטוקול DMARC הקיים.
p - החל מדיניות זו כאשר לא ניתן לאמת את DMARC עבור הודעות דואר אלקטרוני. זה יכול לקבל את הערך: "none","quarantine"או"reject". משמש "none"כדי לקבל דיווחים על זרימת הודעות וסטטוס.
rua - זוהי רשימה של כתובות URL שעליהן ספקי האינטרנט יכולים לשלוח משוב בפורמט XML. אם נוסיף כאן את כתובת הדואר האלקטרוני, הקישור יהיה:rua=mailto:feedback@example.com".
ruf - רשימת כתובות האתרים שבהן ספקי האינטרנט יכולים לשלוח דיווחים על אירועי סייבר ופשעים שבוצעו בשם הארגון שלך. הכתובת תהיה:ruf=mailto:account-email@for.example.com
rf - פורמט דיווח על פשעי סייבר. ניתן לעצב אותו"afrf"או"iodef
pct - מורה לספק האינטרנט להחיל את מדיניות DMARC רק על אחוז מסוים של הודעות שנכשלו. לדוגמה, ייתכן שיש לנו:pct=50%"או מדיניות"quarantine"ו"reject". זה לעולם לא יתקבל".none
adkim - מציין "מצב יישור" עבור חתימות דיגיטליות של DKIM. המשמעות היא שההתאמה של החתימה הדיגיטלית של ערך DKIM עם הדומיין נבדקת. adkim יכולים לקבל את הערכים: r (Relaxed) או s (Strict).
aspf - באותו אופן כמו במקרה adkim "מצב יישור" מצוין עבור SPF ותומך באותם ערכים. r (Relaxed) או s (Strict).
sp - מדיניות זו חלה כדי לאפשר לתת-דומיינים שמקורם בדומיין הארגון להשתמש בערך DMARC של הדומיין. כך נמנע משימוש במדיניות נפרדת לכל תחום. זהו למעשה "תו כללי" עבור כל תת-הדומיינים.
ri - ערך זה מגדיר את המרווח שבו יתקבלו דוחות XML עבור DMARC. לרוב, דיווח עדיף על בסיס יומי.
fo - אפשרויות לדיווחי הונאה. "משפטי options". ייתכן שיש להם ערכים של "0" כדי לדווח על תקריות כאשר גם האימות SPF וגם DKIM נכשלים, או הערך "1" עבור התרחיש שבו ה-SPF או DKIM אינם קיימים או אינם עוברים את האימות.

לכן, כדי להבטיח שהודעות הדואר האלקטרוני שלך או של החברה שלך יגיעו לתיבת הדואר הנכנס שלך, עליך לשקול את שלושת הסטנדרטים הללו."שיטות עבודה מומלצות לשליחת אימיילים DKIM, SPF si DMARC. כל שלושת התקנים הללו הם DNS TXT ויכולים להיות adminממנהל ה-DNS של הדומיין.

נלהב מהטכנולוגיה, אני אוהב לבדוק ולכתוב הדרכות על מערכות הפעלה macOS, לינוקס, Windows, על אודות WordPress, WooCommerce והגדרת שרתי LEMP (Linux, NGINX, MySQL ו-PHP). אני כותב על StealthSettings.com מאז 2006, וכעבור כמה שנים התחלתי לכתוב ב- iHowTo.Tips הדרכות וחדשות על מכשירים במערכת האקולוגית. Apple: iPhone, אייפד, Apple צפה, HomePod, iMac, MacBook, AirPods ואביזרים.

השאירו תגובה