Το SPF στην πράξη: καταγραφή όλων των αποστολέων

Ενότητα 4: Παραδοσιμότητα: SPF, DKIM και DMARC στην πράξη · Χρόνος ανάγνωσης: 12 λεπτά

Στόχος μαθήματος: Μετά από αυτό το μάθημα θα μπορείτε να εντοπίζετε όλες τις υπηρεσίες που στέλνουν mail εκ μέρους του domain σας, να τις εντάσσετε σε ένα ενιαίο SPF-record, να μετράτε αναδρομικά τις αναζητήσεις μέχρι το όριο των δέκα, και να επιλέγετε συνειδητά ανάμεσα σε ~all και -all.

Βασικές έννοιες: απογραφή αποστολέων, envelope-αποστολέας (Return-Path), ένα SPF-record, include, redirect, όριο 10 αναζητήσεων DNS (RFC 7208 παράγραφος 4.6.4), κενές αναζητήσεις (void lookups, το πολύ 2), αναδρομική μέτρηση, permerror, flattening, SPF για subdomains, SPF σε domain που δεν στέλνει mail, ~all και -all

Μια σύντομη υπενθύμιση

Ένα SPF-record είναι ένα TXT-record στο domain σας που ξεκινά με v=spf1 και απαριθμεί ποιοι servers επιτρέπεται να στέλνουν mail εκ μέρους του domain σας. Η δομή, οι χαρακτήρες + - ~ ? και τα τρία πιο γνωστά λάθη (δύο records, +all, πάνω από δέκα αναζητήσεις) περιγράφονται στο μάθημα 4.3 του μαθήματος DNS. Διαβάστε το πρώτα αν το SPF είναι καινούργιο για εσάς. Αυτό το μάθημα ασχολείται με το δύσκολο κομμάτι: στην πράξη σχεδόν κανείς δεν γνωρίζει ακριβώς ποιος στέλνει mail εκ μέρους του domain του.

Βήμα 1: η απογραφή

Το SPF λειτουργεί μόνο αν περιλαμβάνει όλους τους αποστολείς. Αν ξεχάσετε έναν, το mail του θα καταλήγει στα spam ή θα απορρίπτεται μόλις αυστηροποιήσετε το DMARC. Ελέγξτε λοιπόν αυτή τη λίστα. Σε μια μέσου μεγέθους μικρή επιχείρηση θα βρείτε γρήγορα πέντε ή έξι:

Δύο καλοί τρόποι για να τους εντοπίσετε:

1. Ανάγνωση κεφαλίδων. Στείλτε από κάθε σύστημα ένα mail στον εαυτό σας (ένα τιμολόγιο, μια επαναφορά κωδικού, ένα δοκιμαστικό newsletter) και δείτε στις κεφαλίδες τα Return-Path και Authentication-Results (μάθημα 1.5). Εκεί θα δείτε μέσω ποιου domain και ποιου server στάλθηκε.
2. Αναφορές DMARC. Ρυθμίστε το DMARC σε p=none με μια διεύθυνση αναφοράς (μάθημα 4.4). Μετά από λίγες εβδομάδες θα δείτε στις αναφορές (μάθημα 4.5) κάθε server που έστειλε mail εκ μέρους του domain σας, ακόμη και αυτόν που είχατε ξεχάσει. Αυτή είναι η πιο αξιόπιστη απογραφή.

Δεν ανήκει κάθε υπηρεσία στο SPF σας

Εδώ γίνεται συχνά το λάθος. Το SPF εξετάζει τον envelope-αποστολέα (το Return-Path), όχι τη διεύθυνση Από. Πολλές υπηρεσίες newsletter και αποστολής στέλνουν με Return-Path στο δικό τους domain, για παράδειγμα bounce-123@mail.mailer.example. Ο παραλήπτης ελέγχει τότε το SPF-record του mailer.example, όχι το δικό σας. Ένα include αυτής της υπηρεσίας στο δικό σας record τότε δεν κάνει τίποτα, εκτός από το να κοστίζει μία αναζήτηση.

Αυτό που χρειάζεται όντως η υπηρεσία αυτή για να περάσει το DMARC είναι μια υπογραφή DKIM με το δικό σας domain (μάθημα 4.3), ή ένα δικό σας subdomain Return-Path (για παράδειγμα bounce.example.com ως CNAME προς την υπηρεσία). Διαβάστε λοιπόν στο εγχειρίδιο της υπηρεσίας τι ζητά. Αν λέει «βάλτε include: στο SPF σας», κάντε το. Αν λέει μόνο «δημιουργήστε αυτά τα CNAME-records για το DKIM και το domain για bounces», τότε δεν χρειάζεται τίποτα στο κύριο record σας. Η ενότητα 7 επεκτείνεται περισσότερο σε αυτό.

Βήμα 2: ένα record, και σωστή μέτρηση

Όλοι οι αποστολείς μπαίνουν σε ένα record. Ας υποθέσουμε ότι η απογραφή σας δίνει το εξής: τον mail server της εταιρείας hosting σας, το Microsoft 365 για μερικούς υπαλλήλους, το λογιστικό σας πρόγραμμα και ένα helpdesk. Τότε το record γίνεται για παράδειγμα:

example.com.  3600  IN  TXT  "v=spf1 a mx include:spf.hosting.example include:spf.protection.outlook.com include:_spf.boekhoud.example include:mail.helpdesk.example ~all"

Πόσες αναζητήσεις είναι αυτό; Μετρήστε κάθε a, mx, include, exists, ptr και redirect, και μετρήστε στη συνέχεια και όλα όσα περιέχονται στα records πίσω από κάθε include:

Στο 11 ο παραλήπτης επιστρέφει permerror: ολόκληρο το SPF-record δεν μετράει πλέον, για κανέναν αποστολέα. Το mail από τον δικό σας mail server λοιπόν αξιολογείται χειρότερα επειδή το helpdesk κοστίζει τρεις αναζητήσεις. Και το ύπουλο είναι ότι το record σας μπορεί σήμερα να είναι 9 και αύριο 11, χωρίς να αλλάξετε εσείς κάτι, επειδή μια υπηρεσία επεκτείνει το δικό της record.

Επιπλέον: το πολύ δύο κενές αναζητήσεις

Το RFC 7208 αναφέρει επίσης τα void lookups: αναζητήσεις που δεν αποδίδουν τίποτα (το όνομα δεν υπάρχει, ή δεν έχει record SPF ή διεύθυνσης). Περισσότερες από δύο από αυτές οδηγούν επίσης σε permerror. Αυτό συμβαίνει κυρίως με παλιά includes υπηρεσιών που δεν χρησιμοποιείτε πια και που έχουν αφαιρέσει το record τους, ή με ένα a: προς έναν server που δεν υπάρχει πλέον. Κάντε λοιπόν εκκαθάριση.

Βήμα 3: επιστροφή κάτω από το δέκα

Αν βρίσκεστε πάνω από το δέκα, υπάρχουν τέσσερις λύσεις, από την καλύτερη προς τη λιγότερο καλή:

1. Αφαιρέστε ό,τι δεν χρειάζεται. Υπηρεσίες που δεν χρησιμοποιείτε πια. Υπηρεσίες που στέλνουν με δικό τους Return-Path (δείτε παραπάνω) και επομένως δεν ανήκουν στο SPF σας. a αν ο ιστότοπός σας δεν στέλνει ο ίδιος mail. mx αν το MX σας δείχνει σε υπηρεσία που ήδη βρίσκεται στο record σας μέσω include.
2. Χρησιμοποιήστε ένα subdomain. Αφήστε μια υπηρεσία να στέλνει από το nieuws.example.com ή το factuur.example.com. Αυτό το subdomain αποκτά δικό του SPF-record μόνο με εκείνη την υπηρεσία, και δεν προσμετράται στο δέκα του κύριου domain σας. Η ευθυγράμμιση στο DMARC (μάθημα 4.4) λειτουργεί εξ ορισμού και για subdomains.
3. Χρησιμοποιήστε ip4: και ip6: για τους δικούς σας σταθερούς servers. Αυτά δεν κοστίζουν καμία αναζήτηση. Κάντε το μόνο για διευθύνσεις που διαχειρίζεστε εσείς και που δεν αλλάζουν.
4. Flattening (αντικατάσταση όλων των includes με τις IP-διευθύνσεις που βρίσκονται από πίσω τους αυτή τη στιγμή). Αυτό φέρνει τον αριθμό στο 0, αλλά το record δεν ισχύει πλέον μόλις μια υπηρεσία αλλάξει τις διευθύνσεις της, και οι μεγάλες υπηρεσίες το κάνουν αυτό τακτικά. Κάντε το μόνο με εργαλείο που το ενημερώνει αυτόματα, και καλύτερα καθόλου.

redirect ή include;

Το redirect= λέει: χρησιμοποιήστε το SPF-record εκείνου του άλλου domain αντί για αυτό το record. Κοστίζει μία αναζήτηση, όπως ακριβώς ένα include. Είναι χρήσιμο αν έχετε πολλά domains που πρέπει να έχουν ακριβώς την ίδια πολιτική: v=spf1 redirect=_spf.example.com σε κάθε domain, και το πραγματικό record σε ένα μέρος. Ένα record με redirect= δεν επιτρέπεται να έχει all, γιατί τότε το redirect αγνοείται. Το Gmail το χρησιμοποιεί το ίδιο: το gmail.com έχει v=spf1 redirect=_spf.google.com.

Βήμα 4: ~all ή -all;

Η συμβουλή αυτού του μαθήματος, ίδια με το μάθημα DNS:

• Ξεκινήστε με ~all (softfail). Το mail από έναν server που δεν βρίσκεται στο record σας θεωρείται ύποπτο, αλλά συνήθως δεν απορρίπτεται αμέσως. Αν ξεχάσετε έναν αποστολέα, η ζημιά είναι περιορισμένη.
• Προχωρήστε σε -all (fail) όταν είστε σίγουροι ότι όλοι οι αποστολείς βρίσκονται στο record, για παράδειγμα αφού έχετε δει για λίγες εβδομάδες τις αναφορές DMARC και δεν υπάρχουν πια άγνωστες πηγές.

Με το DMARC στη σχέση, η διαφορά είναι μικρότερη από ό,τι συχνά νομίζεται. Το DMARC αποφασίζει με βάση το «το SPF ή το DKIM πέρασε και είναι ευθυγραμμισμένο». Ένα softfail είναι για το DMARC απλώς «δεν πέρασε». Η πραγματική προστασία προέρχεται λοιπόν από μια αυστηρή πολιτική DMARC, όχι από το -all. Ορισμένοι παραλήπτες απορρίπτουν ήδη στο -all πριν καν γίνει η αξιολόγηση DMARC: αυτός είναι ένας λόγος να επιλέξετε το -all μόνο όταν το record σας είναι πραγματικά πλήρες.

Ένα domain που δεν στέλνει ποτέ mail

Έχετε domains που δεν στέλνουν ποτέ mail (ένα παλιό όνομα μάρκας, ένα domain λάθους πληκτρολόγησης); Προστατέψτε τα τότε από κατάχρηση με:

example.org.         IN  TXT  "v=spf1 -all"
_dmarc.example.org.  IN  TXT  "v=DMARC1; p=reject"
example.org.         IN  MX   0 .

Εδώ το -all είναι αμέσως σωστό: δεν υπάρχει κανείς που επιτρέπεται να στέλνει mail. Η τελευταία γραμμή είναι ένα null MX (RFC 7505): «αυτό το domain δεν δέχεται mail». Το example.com ίδιο έχει ρυθμιστεί ακριβώς έτσι.

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

Σε ένα πακέτο hosting του WebOké υπάρχει εξ ορισμού v=spf1 a mx include:webawere.nl ~all. Αν προσθέσετε μια υπηρεσία, προσαρμόζετε αυτό το record (στο DirectAdmin: DNS Management, το μολύβι πίσω από το SPF-record, πεδίο Include Domain: στο Το WebOké μου: ο βοηθός SPF στην καρτέλα DNS). Αφήστε το include:webawere.nl όπως είναι όσο το mail ή ο ιστότοπός σας περνά μέσα από αυτούς τους servers. Σε άλλους παρόχους το προεπιλεγμένο include ονομάζεται διαφορετικά, αλλά η αρχή είναι ίδια: προσθέστε, μη δημιουργείτε δεύτερο record.

Σύνοψη

• Φτιάξτε πρώτα μια απογραφή όλων των αποστολέων: οι αναφορές DMARC και οι κεφαλίδες βοηθούν σε αυτό.
• Μια υπηρεσία με δικό της Return-Path δεν ανήκει στο SPF σας: χρειάζεται DKIM με το δικό σας domain.
• Μετρήστε αναδρομικά: κάθε include, a, mx, exists, ptr και redirect, ακόμη και μέσα σε includes. Πάνω από το δέκα, ή περισσότερες από δύο κενές αναζητήσεις, σημαίνει permerror.
• Επιστρέψτε κάτω από το δέκα με εκκαθάριση και χρήση subdomains: flattening μόνο με αυτόματη συντήρηση.
• Ξεκινήστε με ~all, προχωρήστε σε -all όταν είστε σίγουροι. Domains που δεν στέλνουν ποτέ mail: -all, DMARC reject και null MX.

Κουίζ

Άσκηση

Άσκηση Z4.2: Αναδρομική καταμέτρηση του SPF του τομέα σας. Συμπληρώστε το δικό σας domain (ή το sidn.nl αν δεν έχετε δικό σας domain). Μετρήστε πρώτα μόνοι σας πόσες αναζητήσεις DNS κοστίζει το SPF-record, συμπεριλαμβανομένων όσων βρίσκονται μέσα στα includes, και συμπληρώστε τον αριθμό, μαζί με το τέλος του record (~all, -all, ?all ή +all). Το πρόγραμμα κάνει τη μέτρηση live, συμπεριλαμβανομένων των κενών αναζητήσεων, και δείχνει το δέντρο.

Άσκηση O4.2: Η απογραφή των αποστολέων σας. Φτιάξτε με τον πίνακα αυτού του μαθήματος μια λίστα όλων των συστημάτων που στέλνουν mail εκ μέρους του domain σας. Σημειώστε για κάθε ένα: μέσω ποιου server ή υπηρεσίας, αν πρέπει να βρίσκεται στο SPF σας (δικό του Return-Path ή όχι), και αν υπογράφει DKIM με το δικό σας domain. Στείλτε από τουλάχιστον δύο συστήματα ένα δοκιμαστικό mail στον εαυτό σας και σημειώστε από τις κεφαλίδες το domain του Return-Path και το domain του DKIM (d=).

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

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

• Δωρεάν μάθημα DNS 4.3: SPF: ποιος επιτρέπεται να στέλνει email εκ μέρους του domain σας;
• Εγχειρίδιο DirectAdmin 5.7: SPF ρύθμιση και συμπλήρωση
• Πώς λειτουργεί η εγγραφή SPF στο DNS;
• Προσθήκη ή αλλαγή εγγραφής SPF στο DirectAdmin
• Εγχειρίδιο WebOké 5.5: DNS βοηθήματα: MX, SPF, DMARC, CAA και SRV
• RFC 7208 (SPF), παράγραφος 4.6.4 (όρια) και 6.1 (redirect): RFC 7505 (null MX)