Defaults.Exposed › Διορθώσεις › Guides
«SPF Record Not Found» — Αλλά Υπάρχει; Οι 5 Πραγματικές Αιτίες (2026)
Δημοσιεύτηκε 2026-07-08
Στοιχεία έως 2026-06-29 · μεθοδολογία v7. Αθροιστικά δεδομένα απογραφής σε 261 εκατομμύρια βαθμολογημένα domains. Δείτε πώς βαθμολογούμε.
Εάν ένας ελεγκτής αναφέρει «SPF record not found» αλλά είστε σίγουροι ότι έχετε δημοσιεύσει μία εγγραφή, συνήθως η εγγραφή είναι αόρατη και όχι απούσα: 1,013,416 domains — περίπου ένα στα 138 από αυτά που επιχειρούν SPF — δημοσιεύουν δύο ή περισσότερες εγγραφές SPF, ένα PermError (RFC 7208 §3.2) που πολλοί ελεγκτές αναφέρουν ως «not found», σύμφωνα με την απογραφή του Defaults.Exposed σε 261 εκατομμύρια domains.
Υπάρχουν πέντε πραγματικές αιτίες, όλες επιδιορθώσιμες σε μία συνεδρία: λανθασμένος host, διπλή εγγραφή, λανθασμένος τύπος DNS ή παραμορφωμένα εισαγωγικά, ασυνεπείς nameservers ή σύγκρουση μήκους/CNAME. Παρακάτω: η εξέταση 60 δευτερολέπτων για κάθε αιτία, με τη σειρά ελέγχου, και στη συνέχεια τα βήματα επιδιόρθωσης.
Είστε σίγουροι ότι η εγγραφή υπάρχει πραγματικά;
Ξεκινήστε με την πιο δυσάρεστη πιθανότητα, επειδή είναι η πιο συνηθισμένη: από τα 261,086,232 domains που βαθμολογήθηκαν στην απογραφή του Defaults.Exposed, 121,145,609 — 46.4% — δεν έχουν καμία εγγραφή SPF. Πολλές περιπτώσεις «αλλά το ρύθμισα» αποδεικνύεται ότι ήταν μια εγγραφή που προστέθηκε σε ένα staging zone ή σε έναν παλιό πάροχο DNS που δεν είναι πλέον authoritative. Ελέγξτε τον πάροχο DNS στον οποίο δείχνουν πραγματικά οι nameservers σας (συχνά όχι ο registrar σας) για εγγραφή TXT που αρχίζει με v=spf1. Εάν πραγματικά δεν υπάρχει, παραλείψτε την έρευνα και πηγαίνετε κατευθείαν στο διόρθωση εγγραφής SPF.
Πώς ελέγχετε σωστά μια εγγραφή SPF;
Οι διαδικτυακοί ελεγκτές κάνουν ερώτημα DNS μέσω του δικού τους caching resolver. Για να δείτε την αλήθεια, ρωτήστε τον authoritative nameserver του domain σας απευθείας:
# βρείτε τους authoritative nameservers
dig NS yourdomain.com +short
# ρωτήστε έναν απευθείας για εγγραφές TXT
dig TXT yourdomain.com @ns1.yourdnshost.com +short
Στα Windows: nslookup -type=TXT yourdomain.com ns1.yourdnshost.com.
Δύο κανόνες ερμηνείας. Πρώτον, μετρήστε τις γραμμές που αρχίζουν με v=spf1 — ο αριθμός έχει εξίσου σημασία με το περιεχόμενο. Δεύτερον, ελέγξτε ότι κάνατε ερώτημα στο σωστό όνομα: οι παραλήπτες αξιολογούν το SPF έναντι του domain στο Return-Path (RFC5321.MailFrom, η «διεύθυνση αποστολέα φακέλου») — όχι τη διεύθυνση From που βλέπουν οι παραλήπτες. Εάν το εργαλείο newsletter σας αναπηδά αλληλογραφία μέσω bounce.yourdomain.com, μια τέλεια εγγραφή στο apex δεν είναι η εγγραφή που αναζητούν οι παραλήπτες.
Ποιες είναι οι πέντε πραγματικές αιτίες;
| # | Αιτία | Η εξέταση 60 δευτερολέπτων | Η επιδιόρθωση |
|---|---|---|---|
| 1 | Εγγραφή στον λανθασμένο host (subdomain έναντι apex) | dig TXT στο ακριβές domain του Return-Path σας | Δημοσίευση στο όνομα που στέλνει πραγματικά |
| 2 | Δύο ή περισσότερες εγγραφές v=spf1 = PermError | dig TXT επιστρέφει 2+ γραμμές v=spf1 | Συγχώνευση σε ακριβώς μία εγγραφή |
| 3 | Δημοσιεύτηκε ως εγγραφή τύπου 99 ή παραμορφωμένα εισαγωγικά | Ελέγξτε τον τύπο εγγραφής και τυχόν ανεπιθύμητα εισαγωγικά | Επανα-δημοσίευση ως μία καθαρή εγγραφή TXT |
| 4 | Παλιές κρυφές μνήμες / ασυνεπείς nameservers | Κάντε ερώτημα σε κάθε NS απευθείας· συγκρίνετε απαντήσεις | Διορθώστε τον καθυστερημένο nameserver, περιμένετε το παλιό TTL |
| 5 | Διαχωρισμός >255 χαρακτήρων ή σύγκρουση CNAME | Ψάξτε για κατακερματισμένα τμήματα συμβολοσειρών ή CNAME στο ίδιο όνομα | Αφήστε τον πάροχο να διαχωρίσει σωστά τις συμβολοσειρές· μετακινήστε την εγγραφή από το CNAME’d όνομα |
Δεδομένα έως 2026-06-29.
1. Η εγγραφή βρίσκεται στον λανθασμένο host;
Το κλασικό: SPF προστέθηκε στο mail.yourdomain.com ενώ η αλληλογραφία ισχυρίζεται ότι προέρχεται από το yourdomain.com, ή αντίστροφα. Το SPF δεν κληρονομείται προς τα κάτω — μια εγγραφή στο apex δεν λέει τίποτα για τα subdomains, και αντίστροφα. Δημοσιεύστε στο ακριβές όνομα του Return-Path σας. Ένας προμηθευτής που στέλνει από το δικό του bounce subdomain χρειάζεται εγγραφή σε αυτό το subdomain — συνήθως ένα CNAME ή TXT που παρέχει ο προμηθευτής (ο οδηγός ρύθμισης SPF για GoDaddy δείχνει πού βρίσκονται αυτά τα πεδία).
2. Έχετε δύο εγγραφές SPF;
Η κύρια αιτία, και το πιο παραπλανητικό μήνυμα σφάλματος στον έλεγχο ταυτότητας email. Το RFC 7208 §3.2 είναι σαφές: ένα domain πρέπει να έχει ακριβώς μία εγγραφή SPF. Δύο ή περισσότερες αποτελούν PermError — οι παραλήπτες αντιμετωπίζουν το SPF σας ως άκυρο. Ορισμένοι ελεγκτές αναφέρουν αυτή την κατάσταση με ακρίβεια («βρέθηκαν πολλαπλές εγγραφές»)· άλλοι αναφέρουν το καθαρό αποτέλεσμα: δεν βρέθηκε έγκυρη εγγραφή SPF. Βλέπετε μια εγγραφή στον πίνακα σας και συμπεραίνετε ότι ο ελεγκτής είναι χαλασμένος. Δεν είναι — έχετε μία εγγραφή παραπάνω.
Η απογραφή βρήκε 1,013,416 domains με δύο ή περισσότερες εγγραφές SPF — περίπου ένα στα 138 domains που επιχειρούν SPF — κάθε ένα με το SPF αποτελεσματικά απενεργοποιημένο. Συνήθως συμβαίνει κατά την αλλαγή παρόχου: ο οδηγός ρύθμισης του νέου παρόχου προσθέτει μια νέα εγγραφή αντί να επεξεργαστεί την παλιά. Η επιδιόρθωση είναι συγχώνευση, ποτέ δεύτερη εγγραφή: συνδυάστε τα πάντα σε μία γραμμή v=spf1 … ~all και διαγράψτε τα υπόλοιπα. Η αναφορά δεδομένων μας δύο εγγραφές SPF ισοδυναμούν με καμία αναλύει πώς ένα εκατομμύριο domains κατέληξαν εδώ· εάν ξεκίνησε μετά από μετεγκατάσταση, δείτε το SPF σταμάτησε να λειτουργεί μετά την αλλαγή παρόχου. Κατά τη συγχώνευση, μην αντιγράφετε τυφλά κάθε include: — κάθε ένα κοστίζει αναζητήσεις DNS έναντι του σκληρού ορίου των 10 του SPF, αντικαθιστώντας το «not-found» με ένα PermError: πάρα πολλές αναζητήσεις DNS.
3. Δημοσιεύσατε λανθασμένο τύπο εγγραφής — ή το UI την κατέστρεψε;
Το πρώιμο SPF είχε τον δικό του τύπο εγγραφής DNS (τύπος 99, κυριολεκτικά ονομαζόμενος «SPF»). Καταργήθηκε: το RFC 7208 απαιτεί TXT, και οι παραλήπτες δεν κάνουν ερώτημα τύπου 99. Ορισμένοι πίνακες DNS εξακολουθούν να προσφέρουν «SPF» στο αναπτυσσόμενο μενού τύπου εγγραφής· επιλέξτε το και η εγγραφή σας είναι πραγματική, καλοσχηματισμένη και αόρατη. Ελέγξτε τη στήλη τύπου και επανα-δημοσιεύστε ως TXT.
Η πιο λεπτή παραλλαγή είναι τα εισαγωγικά. Η επικόλληση μιας τιμής που περιβάλλεται από εισαγωγικά σε ένα πεδίο που προσθέτει τα δικά του εισαγωγικά παράγει ""v=spf1 …"" — το οποίο δεν αρχίζει πλέον με v=spf1, οπότε για έναν ελεγκτή δεν υπάρχει. Η έξοδος dig σας δείχνει την αλήθεια· ο πίνακας DNS συχνά την κρύβει καλλυντικά.
4. Είναι πραγματικά «ακόμα σε propagation»;
«Δώστε του 24-48 ώρες για propagation» είναι η πιο συνταγογραφημένη συμβουλή στο DNS. Το propagation είναι απλώς η λήξη των cache: μόλις παρέλθει το TTL της εγγραφής (συνήθως 1 ώρα, σπανίως περισσότερο από 24), κάθε resolver μπορεί να δει τη νέα απάντηση. Ακόμα «not-found» μετά από 24 ώρες; Το propagation δεν είναι η αιτία.
Οι δύο πραγματικοί ένοχοι: αρνητική αποθήκευση — ένας resolver που σας αναζήτησε πριν προσθέσετε την εγγραφή αποθηκεύει την απάντηση «δεν υπάρχει τέτοια εγγραφή» έως ότου λήξει το αρνητικό TTL — και ασυνεπείς nameservers μετά από μετεγκατάσταση, όπου το domain εξακολουθεί να αναφέρει τους nameservers του παλιού παρόχου μαζί με τους νέους και οι μισοί στον κόσμο διαβάζουν μια zone που δεν επεξεργάζεστε πλέον. Κάντε ερώτημα σε κάθε αναφερόμενο nameserver απευθείας· εάν οι απαντήσεις διαφέρουν, το βρήκατε. Διορθώστε την ανάθεση NS του registrar ώστε μόνο ο πάροχος που επεξεργάζεστε πραγματικά να είναι authoritative.
5. Η εγγραφή είναι πολύ μακριά ή εμποδίζεται από CNAME;
Μια μεμονωμένη συμβολοσειρά σε εγγραφή TXT φτάνει μέχρι 255 χαρακτήρες. Μεγαλύτερες εγγραφές SPF είναι νόμιμες αλλά πρέπει να χωριστούν σε πολλαπλές εισαγωγικά-οριοθετημένες συμβολοσειρές εντός μίας εγγραφής — και οι διεπαφές παρόχων DNS χωρίζουν τακτικά λανθασμένα, περικόπτοντας την τιμή ή σπάζοντάς την στα μισά ενός μηχανισμού ώστε να μη μπορεί να αναλυθεί. Εάν η εγγραφή σας είναι μακριά, ελέγξτε την έξοδο dig για μια τιμή που τελειώνει απότομα.
Ξεχωριστά, το DNS απαγορεύει εγγραφή TXT σε ένα όνομα που έχει ήδη CNAME. Εάν το mail.yourdomain.com είναι CNAME στον πάροχό σας, δεν μπορείτε επίσης να τοποθετήσετε εκεί SPF — ορισμένοι πίνακες το αποδέχονται και στη συνέχεια εξυπηρετούν μόνο το CNAME. Τοποθετήστε την εγγραφή εκεί που δείχνει το CNAME (εάν το ελέγχετε) ή αναδιαρθρώστε έτσι ώστε το όνομα αποστολής να μην έχει CNAME. Οι πάροχοι με σωστό χειρισμό TXT κάνουν και τα δύο πιο εύκολα — δείτε τον οδηγό ρύθμισης SPF για Cloudflare.
Πώς το διορθώνετε, βήμα προς βήμα;
- Εκτελέστε τη δωρεάν σάρωση στο defaults.exposed — διαβάζει το ζωντανό DNS σας και σας λέει σε ποια από τις πέντε καταστάσεις βρίσκεστε, πριν αγγίξετε οτιδήποτε.
- Επιβεβαιώστε ποιοι nameservers είναι authoritative (
dig NS) και ότι συμφωνούν όλοι. - Κάντε ερώτημα TXT στον authoritative nameserver για το ακριβές domain Return-Path.
- Μετρήστε τις γραμμές
v=spf1: μηδέν → δημοσιεύστε μία· δύο ή περισσότερες → συγχωνεύστε σε μία. - Επαληθεύστε ότι ο τύπος είναι TXT, η τιμή αρχίζει ακριβώς με
v=spf1και δεν παρεισέφρησαν ανεπιθύμητα εισαγωγικά ή περικοπές. - Περιμένετε ένα TTL, και μετά εκτελέστε ξανά σάρωση για να επιβεβαιώσετε ότι επιλύεται σωστά παντού.
Συχνές ερωτήσεις
Γιατί ο ελεγκτής λέει «not found» ενώ μπορώ να δω την εγγραφή στον πίνακα DNS μου;
Συνήθως αιτία 2 ή 4: μια δεύτερη εγγραφή v=spf1 καθιστά και τις δύο άκυρες — ένα PermError που ορισμένα εργαλεία αναφέρουν ως «not-found», κατάσταση στην οποία βρίσκονται 1,013,416 domains από 2026-06-29 — ή ο πίνακάς σας δεν είναι το DNS που είναι πραγματικά authoritative.
Πόσο καιρό μέχρι οι ελεγκτές να δουν τη διόρθωσή μου; Ένα TTL — συνήθως μία ώρα, το πολύ 24. Πέρα από αυτό, το «propagation» δεν είναι η εξήγηση· ελέγξτε ξανά τις πέντε αιτίες, ξεκινώντας από τη συνέπεια των nameservers.
Πρέπει να χρησιμοποιήσω τον τύπο εγγραφής «SPF» που προσφέρει ο πίνακας DNS μου; Όχι. Ο τύπος 99 έχει καταργηθεί· το RFC 7208 απαιτεί μόνο TXT. Μια εγγραφή τύπου 99 είναι αόρατη στους σύγχρονους παραλήπτες.
Η εγγραφή βρέθηκε τώρα — γιατί το email μου εξακολουθεί να αποτυγχάνει στο SPF; Επειδή το SPF ελέγχεται έναντι του domain Return-Path, όχι της κεφαλίδας From, και η εγγραφή πρέπει να αναφέρει πραγματικά τους διακομιστές που στέλνουν για λογαριασμό σας. Το «found» είναι το πρώτο βήμα· ο οδηγός διόρθωσης SPF καλύπτει την επιτυχία.
Είναι πραγματικά τόσο συνηθισμένη η απουσία εγγραφής SPF; Ναι — 121,145,609 domains, 46.4% των 261,086,232 που βαθμολογήθηκαν στην απογραφή του Defaults.Exposed (έως 2026-06-29), δεν δημοσιεύουν καθόλου SPF. Το «not-found» είναι η προεπιλεγμένη κατάσταση του διαδικτύου.
Στείλτε στον ιδιοκτήτη την αναφορά
Μόλις η εγγραφή επιλύεται σωστά, εκτελέστε ξανά τη σάρωση και προωθήστε τη βαθμολογημένη αναφορά στον ιδιοκτήτη της επιχείρησης ή τον πελάτη του οποίου ανήκει αυτό το domain. Δείχνει, με απλή γλώσσα, τι ήταν χαλασμένο, τι διορθώσατε και πού βρίσκεται πλέον το domain — ακριβώς τα στοιχεία που θα τους ζητηθούν σε ανανεώσεις ασφάλισης κυβερνοχώρου και ερωτηματολόγια ασφάλειας προμηθευτών. Η αναφορά είναι η απόδειξη για την εργασία.
Ελέγξτε δωρεάν την εγγραφή SPF σας
Δείτε σε ποια από τις πέντε καταστάσεις «not-found» βρίσκεται το domain σας — ιδιωτικά και μόνο για τον ιδιοκτήτη.
Ελέγξτε το domain σας → · Διόρθωση SPF → · SPF σταμάτησε μετά την αλλαγή παρόχου → · Πώς βαθμολογούμε → · Μόνο αθροιστικά δεδομένα. Τα δεδομένα αποθηκεύονται και επεξεργάζονται στην ΕΕ.