Το SPF Σταμάτησε να Λειτουργεί Μετά την Αλλαγή Παρόχου Email — Η Λύση Μετεγκατάστασης (2026)

Δημοσιεύτηκε 2026-07-08

Στοιχεία από 2026-06-29 · μεθοδολογία v7. Συγκεντρωτικά δεδομένα απογραφής από 261 εκατομμύρια βαθμολογημένα domains. Δείτε πώς βαθμολογούμε.

Το SPF σπάει συνήθως μετά από αλλαγή παρόχου email επειδή η εγγραφή του νέου παρόχου προστέθηκε δίπλα στην παλιά. Δύο εγγραφές v=spf1 αποτελούν μόνιμο σφάλμα — το SPF ακυρώνεται εντελώς. 1,013,416 domains — περίπου ένα στα 138 από αυτά που επιχειρούν SPF — βρίσκονται σε αυτή την κατάσταση, σύμφωνα με την απογραφή Defaults.Exposed 261 εκατομμυρίων domains. Συγχωνεύστε τα σε μία.

Η διόρθωση διαρκεί περίπου δέκα λεπτά: σαρώστε το domain για να δείτε ακριβώς τι άφησε πίσω η μετεγκατάσταση, λιστάρετε κάθε εγγραφή SPF στους authoritative nameservers σας, συγχωνεύστε τα σε μία εγγραφή που περιλαμβάνει μόνο τον νέο πάροχό σας και επαληθεύστε με dig. Αυτός ο οδηγός εξηγεί κάθε βήμα, καθώς και τους ελέγχους DKIM και nameserver που οι περισσότερες μετεγκαταστάσεις ξεχνούν.

Γιατί έσπασε το SPF αμέσως μετά τη μετεγκατάσταση;

Επειδή ο οδηγός εγκατάστασης του νέου παρόχου έλεγε «προσθέστε αυτή την εγγραφή TXT» — και το κάνατε, δίπλα στην παλιά. Αυτό ακριβώς δεν επιτρέπει το πρότυπο SPF. Το RFC 7208 (§3.2, αποτέλεσμα σφάλματος σύμφωνα με §4.5) επιτρέπει ακριβώς μία εγγραφή v=spf1 ανά domain· ένας παραλήπτης που βρει δύο ή περισσότερες πρέπει να επιστρέψει PermError αντί να μαντέψει ποια είναι αυθεντική. PermError σημαίνει ότι το SPF ακυρώνεται: όχι η παλιά εγγραφή, όχι η νέα, καθόλου SPF.

Και δεν σταματά εκεί. Το DMARC αντιμετωπίζει ένα PermError ως αποτυχία στο σκέλος SPF, οπότε το email σας εξαρτάται πλέον αποκλειστικά από το DKIM. Αν το DKIM του νέου παρόχου δεν έχει ρυθμιστεί ακόμα — συνηθισμένο κατά τη διάρκεια μετεγκατάστασης — στέλνετε αδιαπίστευτα ακριβώς τη στιγμή που αλλάξατε υποδομή, που είναι η στιγμή που οι παραλήπτες σας εξετάζουν πιο προσεκτικά.

Αυτή είναι η αντιγραφή-επικόλληση που ακυρώνει την προστασία όταν αλλάζετε παρόχους, και δεν είναι σπάνια: 1,013,416 domains δημοσιεύουν δύο ή περισσότερες εγγραφές SPF αυτή τη στιγμή — περίπου ένα στα 138 από τον πληθυσμό 139 εκατομμυρίων που επιχειρεί SPF, σύμφωνα με την απογραφή Defaults.Exposed 261 εκατομμυρίων domains (δεδομένα από 2026-06-29). Τα πλήρη στοιχεία για την παγίδα δύο εγγραφών έχουν δική τους αναφορά· αυτή η σελίδα είναι η διαδικαστική λύση.

Τι άφησε πίσω η μετεγκατάσταση;

Πέντε υπολείμματα προκαλούν σχεδόν κάθε αποτυχία SPF μετά από μετεγκατάσταση. Ελέγξτε τα με αυτή τη σειρά:

Τι έμεινε πίσω	Τι βλέπετε	Η λύση
Η παλιά εγγραφή SPF, ακόμα στο DNS δίπλα στη νέα (δύο εγγραφές `v=spf1`)	Τα εργαλεία ελέγχου αναφέρουν “πολλαπλές εγγραφές SPF” ή PermError· το SPF σταματά να λειτουργεί εντελώς	Συγχωνεύστε σε μία εγγραφή, διαγράψτε τις υπόλοιπες — βήματα παρακάτω
Το `include:` του παλιού παρόχου μέσα στη μία εγγραφή σας	Το SPF λειτουργεί, αλλά σπαταλάτε DNS lookups και οι παλιοί διακομιστές του παρόχου μπορούν να στείλουν ως εσείς	Αφαιρέστε το αφού ολοκληρωθεί η μεταφορά των μηνυμάτων από το παλιό σύστημα
Το `include:` του νέου παρόχου δεν προστέθηκε ποτέ	Το email από τον νέο πάροχο αποτυγχάνει SPF στους παραλήπτες	Προσθέστε το στην υπάρχουσα μοναδική εγγραφή — ποτέ ως νέα εγγραφή
Οι DKIM selectors δεν δημιουργήθηκαν για τον νέο πάροχο	`dkim=fail` ή υπογραφές από το default domain του παρόχου· το DMARC δεν έχει δεύτερο σκέλος	Δημοσιεύστε τους νέους selectors — βήμα 6 παρακάτω
Η εγγραφή ενημερώθηκε μόνο στους παλιούς nameservers	Διαφορετικές απαντήσεις ανάλογα με τον ερωτώμενο· διακοπτόμενες αποτυχίες	Διορθώστε τη ζώνη στους authoritative nameservers· επαληθεύστε και τα δύο σύνολα κατά τη μεταφορά

Πώς το διορθώνω; Η λίστα ελέγχου μετεγκατάστασης

Εκτελέστε πρώτα τη δωρεάν σάρωση στο defaults.exposed. Διαβάζει το live DNS σας και σας λέει αν έχετε πολλαπλές εγγραφές SPF, ένα λείπον include ή ένα κενό DKIM — διαγνώστε πριν αγγίξετε οτιδήποτε.
Λιστάρετε κάθε εγγραφή SPF στους authoritative nameservers. dig +short NS yourdomain.com, στη συνέχεια dig +short TXT yourdomain.com @<nameserver> σε έναν από αυτούς. Μετρήστε τα strings που ξεκινούν με v=spf1. Ο μόνος ασφαλής αριθμός είναι 1.
Συγχωνεύστε σε μία εγγραφή. Μία εγγραφή, που ξεκινά με v=spf1, περιέχοντας το include του νέου παρόχου σας και κάθε άλλον αποστολέα που εξακολουθείτε να χρησιμοποιείτε (εργαλείο τιμολόγησης, CRM, πλατφόρμα newsletter), με ένα τελικό -all ή ~all. Παράδειγμα — παλιό Google Workspace, νέο Microsoft 365, κατά τη διάρκεια αποστράγγισης:
```
Before:  "v=spf1 include:_spf.google.com ~all"
         "v=spf1 include:spf.protection.outlook.com -all"

After:   "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
Later:   "v=spf1 include:spf.protection.outlook.com -all"
```
Τιμές παρόχων και ιδιαιτερότητες πινάκων DNS υπάρχουν στους οδηγούς εγκατάστασης για Google Workspace και Microsoft 365.
Διαγράψτε τις επιπλέον εγγραφές. Η συγχώνευση χωρίς διαγραφή δεν διορθώνει τίποτα — το PermError προκύπτει από τον αριθμό.
Κρατήστε το include του παλιού παρόχου μόνο ενόσω το παλιό σύστημα αποστέλλει — προγραμματισμένες αναφορές, παλιός σύνδεσμος CRM, ξεχασμένο γραμματοκιβώτιο. Μόλις τελειώσει η αποστράγγιση, αφαιρέστε το: ένα ξεπερασμένο include αφήνει την παλιά υποδομή να στέλνει ως εσείς, και κάθε include κοστίζει DNS lookups έναντι του αυστηρού ορίου 10 του SPF — τουλάχιστον 797,263 domains έχουν ακυρώσει το SPF τους υπερβαίνοντας αυτό το όριο (απογραφή, 2026-06-29).
Ρυθμίστε το DKIM του νέου παρόχου — και μην διαγράψετε ακόμα τους παλιούς selectors. Νέοι selectors υπογράφουν νέα μηνύματα· παλιοί selectors πρέπει να παραμείνουν δημοσιευμένοι μέχρι να παραδοθεί κάθε μήνυμα που υπεγράφη με αυτούς και να επιλυθούν τυχόν προωθήσεις. Πλήρης οδηγός στο Αποτυχία DKIM μετά αλλαγή εργαλείου email.
Αν αλλάξατε και nameservers, ελέγξτε και τα δύο. Οι μετεγκαταστάσεις DNS συχνά συνοδεύουν τις μετεγκαταστάσεις email. Εκτελέστε ερώτηση απευθείας στο παλιό και νέο σύνολο NS (dig TXT yourdomain.com @old-ns και @new-ns) — μέχρι να ολοκληρωθεί πλήρως η μεταφορά delegation στον registrar, ορισμένοι παραλήπτες ακόμα ρωτούν τους παλιούς servers, οπότε η διορθωμένη εγγραφή πρέπει να υπάρχει σε οποιοδήποτε σύνολο απαντά.
Εκτελέστε ξανά τη σάρωση και επιβεβαιώστε ότι το SPF εμφανίζει μία μόνο έγκυρη εγγραφή με pass.

Ποιο domain ελέγχει πραγματικά το SPF;

Οι παραλήπτες αξιολογούν το SPF έναντι του domain Return-Path (RFC5321.MailFrom) — της διεύθυνσης αναπήδησης — όχι της κεφαλίδας From που βλέπουν οι παραλήπτες σας. Μετά από μετεγκατάσταση αυτό έχει σημασία δύο φορές: ο νέος πάροχός σας μπορεί να χρησιμοποιεί το δικό του domain αναπήδησης μέχρι να διαμορφώσετε ένα προσαρμοσμένο, και το SPF που «περνά» σε domain που δεν είναι δικό σας δεν θα ευθυγραμμιστεί για το DMARC. Η λύση για αυτό είναι το DKIM του νέου παρόχου, υπογεγραμμένο με το domain σας.

Μετεγκατάσταση και rebranding ταυτόχρονα;

Αλλάξατε και το domain μαζί με τον πάροχο; Αντιμετωπίστε τα ως δύο ξεχωριστές εργασίες. Το νέο domain χρειάζεται το πλήρες σύνολο — SPF, DKIM, DMARC — από την πρώτη μέρα· χρησιμοποιήστε τη λίστα ελέγχου email για νέο domain. Το παλιό domain παραμένει πιστοποιημένο για όσο διαρκεί η κίνηση προώθησης ή απάντησης μέσα από αυτό, και κλειδώνεται ρητά (δεν εγκαταλείπεται απλά) μόλις σταματήσει να χρησιμοποιείται. Ένα παλιό domain με ξεπερασμένο, μισοχαλασμένο SPF είναι στόχος spoofing που φέρει το παλιό σας όνομα.

Συχνές ερωτήσεις

Μπορώ να διατηρήσω δύο εγγραφές SPF κατά τη διάρκεια της μετεγκατάστασης; Όχι. Δεν υπάρχει περίοδος χάριτος στο πρότυπο — δύο εγγραφές v=spf1 αποτελούν PermError από τη στιγμή που υπάρχει η δεύτερη, και 1,013,416 domains βρίσκονται σε αυτή την κατάσταση σύμφωνα με την απογραφή (2026-06-29). Το ασφαλές μοτίβο μετεγκατάστασης είναι μία εγγραφή που φέρει τα includes και των δύο παρόχων κατά τη διάρκεια της επικάλυψης.

Πόσο καιρό πρέπει να κρατήσω το include του παλιού παρόχου; Μέχρι τίποτα να μην αποστέλλεται μέσω του παλιού παρόχου — συνήθως για τη διάρκεια του παράθυρου επικάλυψης, μέρες έως μερικές εβδομάδες. Παρακολουθήστε το Return-Path οτιδήποτε εξακολουθεί να φτάνει μέσω του παλιού συστήματος· όταν σταματήσει αυτή η κίνηση, αφαιρέστε το include και ελέγξτε ξανά τον αριθμό των lookups σας.

Γιατί ένα εργαλείο ελέγχου εξακολουθεί να εμφανίζει την παλιά εγγραφή μου αφού το διόρθωσα; Η προσωρινή αποθήκευση DNS τηρεί το TTL της εγγραφής, και αν άλλαξαν οι nameservers σας, ορισμένοι resolvers ακόμα ρωτούν το παλιό σύνολο. Επαληθεύστε απευθείας στους authoritative nameservers με dig TXT yourdomain.com @<ns> — αν η απάντηση είναι σωστή εκεί, η διόρθωση έγινε και οι κρυφές μνήμες θα ανανεωθούν. Αν είναι λανθασμένη σε ένα σύνολο NS, ανατρέξτε στο «Δεν βρέθηκε εγγραφή SPF» — οι πραγματικές αιτίες.

Χρειάζεται να αλλάξω το DMARC όταν αλλάξω πάροχο; Συνήθως όχι την ίδια την εγγραφή — ορίζει το mailbox αναφορών και την πολιτική σας, όχι τον πάροχό σας. Αλλά τα αποτελέσματα DMARC εξαρτώνται από το SPF και το DKIM που μόλις μετεγκαταστάθηκαν: αναμένετε μια πτώση στις αναφορές κατά τη μεταφορά και επιβεβαιώστε ότι και τα δύο σκέλη περνούν πριν αυστηροποιήσετε την πολιτική. Ξεκινήστε από το διόρθωση SPF αν η σάρωση εμφανίζει ότι το σκέλος SPF εξακολουθεί να αποτυγχάνει.

Στείλτε στον ιδιοκτήτη την αναφορά

Αν κάνετε αυτή τη μετεγκατάσταση για έναν πελάτη, τελειώστε με αποδείξεις. Εκτελέστε ξανά τη δωρεάν σάρωση μόλις η συγχώνευση είναι live και προωθήστε τη βαθμολογημένη αναφορά στον ιδιοκτήτη της επιχείρησης: SPF, DKIM και DMARC που περνούν στον νέο πάροχο, σε απλή γλώσσα, με ημερομηνία. Αυτό είναι το τεκμήριο που αρχειοθετούν για την ανανέωση ασφάλισης στον κυβερνοχώρο και για το επόμενο ερωτηματολόγιο ασφάλειας προμηθευτή — απόδειξη ότι η μετεγκατάσταση άφησε το domain με καλύτερη πιστοποίηση από ό,τι ξεκίνησε.

Ελέγξτε το domain σας → · Αποτυχία DKIM μετά αλλαγή εργαλείου email → · «Δεν βρέθηκε εγγραφή SPF» — οι πραγματικές αιτίες → · Πώς βαθμολογούμε → · Μόνο συγκεντρωτικά δεδομένα. Δεδομένα αποθηκευμένα και επεξεργασμένα στην ΕΕ.