Η μετάβαση στο DNS: MX, SPF, DKIM και DMARC

Ενότητα 4: Μετακόμιση του email · Χρόνος ανάγνωσης: 12 λεπτά

Μαθησιακός στόχος: Μετά από αυτό το μάθημα θα μπορείτε να σχεδιάσετε και να εκτελέσετε την αλλαγή DNS για το email με τη σωστή σειρά, ώστε να μη χαθεί κανένα μήνυμα, το εξερχόμενο email σας να μην καταλήγει στα ανεπιθύμητα και το Outlook να μη συνεχίζει κρυφά να επικοινωνεί με τον παλιό πάροχο.

Βασικές έννοιες: TTL, αλλαγή MX, SPF (μία εγγραφή), selector DKIM, DMARC (p=none, rua), autodiscover, autoconfig, εγγραφή επαλήθευσης, αποδεκτό domain

Πέντε εγγραφές, μία στιγμή

Για το email στο δικό σας domain υπάρχουν μερικές εγγραφές στο DNS που μαζί καθορίζουν αν φτάνει η αλληλογραφία και αν το email σας είναι αξιόπιστο:

Σε μια μετακόμιση αλλάζει σχεδόν όλο αυτό. Η τέχνη βρίσκεται στη σειρά. Αν αλλάξετε το MX ενώ το SPF και το DKIM ισχύουν ακόμη μόνο για το Microsoft, τότε το email σας θα φτάνει μεν, αλλά το email που στέλνετε θα καταλήγει στα ανεπιθύμητα. Αν αλλάξετε πρώτα το SPF, τότε το Microsoft δεν θα μπορεί πλέον να στέλνει σωστά εκ μέρους σας τις ημέρες πριν.

Αυτό το μάθημα αφορά τη σειρά. Πώς ακριβώς λειτουργεί κάθε εγγραφή, το διαβάζετε στο μάθημα DNS (μαθήματα 4.1 έως 4.5).

Βήμα 1, δύο ημέρες πριν: μείωση του TTL και αντίγραφο ασφαλείας

Κάθε εγγραφή DNS έχει ένα TTL (time to live): πόσο καιρό επιτρέπεται σε άλλους servers να θυμούνται την απάντηση. Αν το TTL του MX σας είναι 86400 δευτερόλεπτα (μία ημέρα), τότε ορισμένοι servers θα συνεχίσουν να στέλνουν στον παλιό server έως και μία ημέρα μετά την αλλαγή.

Γι' αυτό μειώστε τουλάχιστον έναν παλιό κύκλο TTL πριν, το TTL του MX, του SPF και του autodiscover σε 300 ή 3600 δευτερόλεπτα. Με TTL μιας ημέρας, το κάνετε δηλαδή τουλάχιστον μία ημέρα νωρίτερα· δύο ημέρες είναι άνετο περιθώριο. Παράλληλα, φτιάξτε ένα αντίγραφο ασφαλείας της ζώνης DNS σας, ή σημειώστε όλες τις τρέχουσες εγγραφές. Έτσι μπορείτε πάντα να επιστρέψετε πίσω.

Η Bakkerij De Korrel βλέπει:

example.com.            3600  IN  MX   0 example-com.mail.protection.outlook.com.
example.com.            3600  IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"
selector1._domainkey    3600  IN  CNAME selector1-example-com._domainkey.korrel.onmicrosoft.com.
selector2._domainkey    3600  IN  CNAME selector2-example-com._domainkey.korrel.onmicrosoft.com.
_dmarc.example.com.     3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
autodiscover            3600  IN  CNAME autodiscover.outlook.com.
example.com.            3600  IN  TXT  "MS=ms12345678"

Το TTL είναι ήδη 3600 (μία ώρα). Θέτουν το MX και το SPF στο 300.

Βήμα 2, πριν την αλλαγή: ετοιμάστε το DKIM και το SPF για τον νέο πάροχο

Τις εγγραφές που δεν χαλάνε τίποτα, τις τοποθετείτε ήδη εκ των προτέρων:

• DKIM του νέου παρόχου. Ο νέος πάροχος δίνει έναν selector και ένα κλειδί, για παράδειγμα x._domainkey με μια εγγραφή TXT v=DKIM1; k=rsa; p=.... Επειδή ο selector ονομάζεται διαφορετικά από αυτόν του Microsoft (selector1 και selector2), συνυπάρχουν άνετα δίπλα δίπλα. Κάθε παραλήπτης κοιτάζει μόνο τον selector που αναφέρεται στην υπογραφή του email.
• Επέκταση του SPF, όχι αντικατάσταση. Επιτρέπεται μόνο μία εγγραφή SPF. Προσθέστε τον νέο πάροχο στην ίδια εγγραφή, ώστε κατά τις ημέρες μετάβασης να μπορούν να στέλνουν και οι δύο:

"v=spf1 include:spf.protection.outlook.com include:spf.mailaanbieder.example ~all"

Η αρτοποιία είχε -all. Κατά τη διάρκεια της μετάβασης επιλέγουν προσωρινά ~all (softfail): αν λείπει κάποιος server, το email θεωρείται ύποπτο μάλλον παρά απορρίπτεται. Αυτό ακολουθεί τον εμπειρικό κανόνα: ~all όταν δεν είστε απόλυτα σίγουροι, -all όταν γνωρίζετε με βεβαιότητα ότι όλοι οι αποστολείς περιλαμβάνονται.

Μην ξεχάσετε τους άλλους αποστολείς από τη λίστα σας στο μάθημα 4.1: το ηλεκτρονικό κατάστημα, την υπηρεσία ενημερωτικών δελτίων, τη λογιστική. Αυτοί παραμένουν στην εγγραφή SPF.

Βήμα 3, η στιγμή της αλλαγής: MX και autodiscover

Τη συμφωνημένη στιγμή, αφού έχει ολοκληρωθεί το πρώτο αντίγραφο των γραμματοκιβωτίων (μάθημα 4.2):

1. Αντικαταστήστε τις εγγραφές MX με αυτές του νέου παρόχου. Αφαιρέστε το παλιό MX· μην το αφήσετε ως «εφεδρικό» με υψηλότερη προτεραιότητα, γιατί τότε θα φτάνει email στον παλιό πάροχο όποτε ο νέος είναι λίγο αργός.
2. Προσαρμόστε το autodiscover. Το Outlook αναζητά τις ρυθμίσεις του μέσω autodiscover.example.com. Αν αυτό εξακολουθεί να δείχνει στο autodiscover.outlook.com, το Outlook θα συνεχίσει να προσπαθεί να συνδεθεί στο Microsoft, ακόμη και αν προσθέσετε νέο λογαριασμό. Αφαιρέστε το ή αφήστε το να δείχνει σε αυτό που ορίζει ο νέος σας πάροχος. Ορισμένοι πάροχοι χρησιμοποιούν αντ' αυτού autoconfig.example.com (Thunderbird) ή εγγραφές SRV όπως _imaps._tcp και _submission._tcp (RFC 6186).
3. Εκτελέστε ένα δεύτερο αντίγραφο των γραμματοκιβωτίων, ώστε να συμπεριληφθεί το email των τελευταίων ωρών.

Υπάρχει μια έκπληξη στο Microsoft 365 που αιφνιδιάζει πολλούς. Όσο το example.com παραμένει στο περιβάλλον Microsoft 365 ως αποδεκτό domain, το Microsoft παραδίδει εσωτερικά το email μεταξύ χρηστών του ίδιου περιβάλλοντος, χωρίς να ελέγχει το MX. Αν ένας συνάδελφος που εξακολουθεί να εργάζεται στο Outlook στο Microsoft στείλει email σε άλλον συνάδελφο, αυτό το email θα καταλήξει στο παλιό γραμματοκιβώτιο. Γι' αυτό μεταβαίνετε όλοι οι υπάλληλοι την ίδια ημέρα και αφαιρείτε το domain από το περιβάλλον Microsoft μετά την περίοδο μετάβασης.

Βήμα 4, DMARC: παρακολούθηση κατά τη μετάβαση

Το DMARC λέει στους παραλήπτες τι να κάνουν αν ένα email δεν περνά τον έλεγχο SPF ή DKIM, και σας στέλνει αναφορές. Η αρτοποιία είχε p=quarantine. Αυτό είναι καλό, αλλά επικίνδυνο κατά τη διάρκεια μιας αλλαγής: αν το DKIM στον νέο πάροχο δεν είναι ακόμη ενεργό, το δικό τους email θα καταλήγει στα ανεπιθύμητα των πελατών.

Η ασφαλής προσέγγιση:

• Αν δεν έχετε ακόμη DMARC, ξεκινήστε με p=none και μια διεύθυνση rua. Τότε δεν γίνεται τίποτα με το email σας, αλλά λαμβάνετε αναφορές.
• Αν έχετε ήδη quarantine ή reject, ελέγξτε πριν την αλλαγή με ένα δοκιμαστικό email ότι το DKIM του νέου παρόχου λειτουργεί (η κεφαλίδα ενός ληφθέντος email δείχνει dkim=pass με d=example.com). Αν έχετε αμφιβολίες, θέστε προσωρινά p=none και παρακολουθήστε τις αναφορές για μερικές εβδομάδες.
• Μετά, αυστηροποιήστε βήμα βήμα: none, μετά quarantine, μετά ενδεχομένως reject. Σύμφωνα με το νέο πρότυπο DMARC (RFC 9989), μπορείτε στη φάση δοκιμής να χρησιμοποιήσετε επίσης t=y· η παλιά ετικέτα pct καταργείται.

Βήμα 5, μετά από μερικές εβδομάδες: καθαρισμός

Αν όλα λειτουργούν καλά για μερικές εβδομάδες, καθαρίζετε τις παλιές εγγραφές:

• το παλιό include από το SPF (και ενδεχομένως επιστροφή στο -all)·
• τις παλιές εγγραφές DKIM (selector1 και selector2)·
• την εγγραφή επαλήθευσης MS=ms... και τυχόν άλλες εγγραφές για το Microsoft, όπως enterpriseregistration και lyncdiscover αν τις είχατε·
• το TTL πίσω σε μια κανονική τιμή, όπως 3600·
• το domain από το παλιό περιβάλλον Microsoft ή Google.

Αν αφήσετε το παλιό include, ο παλιός πάροχος θα μπορεί να στέλνει email εκ μέρους του domain σας για χρόνια ακόμη. Αυτό είναι μια ανοιχτή πόρτα.

Στην πράξη: έτσι φαίνεται σε έναν πάροχο

Στο Το WebOké μου, στην καρτέλα DNS υπάρχει η κάρτα Ρυθμίσεις email. Αυτή εμφανίζει το MX, το SPF και το DMARC με μια έγχρωμη κουκκίδα, και πάνω δεξιά ποιον πάροχο email αναγνωρίζει από το MX σας. Με το Γρήγορη ρύθμιση ορίζετε με ένα κλικ τις εγγραφές για έναν πάροχο, και η κίτρινη ειδοποίηση προειδοποιεί ότι οι υπάρχουσες εγγραφές MX και SPF θα αντικατασταθούν. Γι' αυτό φτιάξτε πρώτα ένα αντίγραφο ασφαλείας DNS και ελέγξτε κατόπιν αν η εγγραφή SPF εξακολουθεί να περιλαμβάνει τους άλλους αποστολείς σας. Στη σελίδα προϊόντος ενός πακέτου hosting υπάρχει η κάρτα Set E-mail, η οποία δείχνει ανά εγγραφή αν είναι Σωστό, Προσοχή, Λανθασμένο ή Δεν βρέθηκε και δίνει την τιμή με ένα κουμπί αντιγραφής. Αν το DNS βρίσκεται σε άλλον πάροχο, μεταφέρετε εκεί αυτές τις τιμές. Άλλοι πάροχοι και πίνακες DNS έχουν παρόμοιες επισκοπήσεις· οι ίδιες οι εγγραφές είναι παντού ίδιες.

Σύνοψη

• Μειώστε το TTL τουλάχιστον έναν παλιό κύκλο TTL πριν και φτιάξτε ένα αντίγραφο ασφαλείας της ζώνης DNS σας.
• Ετοιμάστε το DKIM του νέου παρόχου και μια διευρυμένη εγγραφή SPF (μία εγγραφή, και οι δύο πάροχοι) ήδη πριν την αλλαγή.
• Αλλάξτε το MX και το autodiscover ταυτόχρονα, και μεταβείτε όλοι οι υπάλληλοι την ίδια ημέρα· διαφορετικά το Microsoft εξακολουθεί να παραδίδει το εσωτερικό email στα παλιά γραμματοκιβώτια.
• Μην κάνετε το DMARC κατά τη μετάβαση αυστηρότερο από ό,τι γνωρίζετε με βεβαιότητα· αν δεν έχετε DMARC, ξεκινήστε με p=none και αναφορές.
• Μετά από μερικές εβδομάδες καθαρίστε το παλιό include, τις εγγραφές DKIM, τις εγγραφές επαλήθευσης και το domain από το παλιό περιβάλλον.

Κουίζ

Άσκηση

Άσκηση A4.3: Οι εγγραφές email σας με μια ματιά. Συμπληρώστε το domain σας και τον selector DKIM του (νέου) παρόχου σας. Το πρόγραμμα ελέγχει αν το MX δείχνει στον πάροχό σας, αν υπάρχει ακριβώς μία εγγραφή SPF, αν το κλειδί DKIM υπάρχει σε αυτόν τον selector και αν υπάρχει ακριβώς μία εγγραφή DMARC. Μετρά επίσης το TTL του MX σας στον αρμόδιο nameserver: για μια προγραμματισμένη αλλαγή αυτό πρέπει να είναι 3600 ή χαμηλότερο.

Άσκηση E4.3: Το σενάριο αλλαγής σας. Γράψτε για το δικό σας domain το σενάριο από αυτό το μάθημα: ανά βήμα την ημερομηνία και ώρα, τις εγγραφές πριν και μετά (παλιό και νέο SPF ως μία γραμμή), ποιος το κάνει, και τι ελέγχετε μετά από κάθε βήμα.

Περαιτέρω ανάγνωση

Τα βήματα σε αυτά τα άρθρα ισχύουν για τις υπηρεσίες του WebOké· σε άλλους παρόχους η διαδικασία είναι παρόμοια.

• Εγχειρίδιο WebOké 6.7: Η κάρτα Ρύθμιση email (MX, SPF, DKIM, DMARC)
• Εγχειρίδιο WebOké 5.6: Γρήγορη ρύθμιση email στο DNS
• Εγχειρίδιο WebOké 5.7: Επαναφορά DNS και δημιουργία backup DNS
• Εγχειρίδιο DirectAdmin 10.4: Μετά τη μετακόμιση: εγγραφές MX και οι συσκευές σας
• Δωρεάν μάθημα DNS 4.3: SPF: ποιος επιτρέπεται να στέλνει email εκ μέρους του domain σας;
• Δωρεάν μάθημα DNS 4.4: DKIM: η υπογραφή κάτω από το email σας
• Δωρεάν μάθημα DNS 4.5: DMARC: τι πρέπει να κάνουν οι παραλήπτες με ψεύτικα emails
• Δωρεάν μάθημα DNS 6.3: Το DNS κατά τη διάρκεια μιας μεταφοράς
• RFC 7208 (SPF), RFC 6376 (DKIM), RFC 9989 (DMARC), RFC 6186 (εγγραφές SRV για προγράμματα email)