Το email καταλήγει στα spam μετά τη μετακίνηση στο Cloudflare: λίστα ελέγχου για να επανέλθουν τα email στα 'Εισερχόμενα'

Αφού μεταφέρατε τον ιστότοπο σε νέο hosting και μεταφέρατε το DNS στο Cloudflare, τα ειδοποιητικά email — επιβεβαιώσεις εγγραφής, ειδοποιήσεις, επαναφορές κωδικού πρόσβασης — άρχισαν ξαφνικά να προσγειώνονται στα "Spam". Πριν από τη μετακόμιση, όλα έφταναν στο "Inbox". Σας ακούγεται οικείο; Ας αναλύσουμε βήμα προς βήμα γιατί συμβαίνει αυτό και πώς να το διορθώσετε — αυτή είναι μια έτοιμη λίστα ελέγχου που μπορεί να ολοκληρωθεί σε 20-30 λεπτά.

Γιατί Συμβαίνει Αυτό

Στις περισσότερες περιπτώσεις, ο λόγος είναι ένας: κατά την εισαγωγή ζώνης στο Cloudflare, οι εγγραφές ελέγχου ταυτότητας email μεταφέρονται "όπως ήταν" — μαζί με τον παλιό host. Η αυτόματη εισαγωγή DNS (και οι βοηθοί AI που όλο και περισσότερο βοηθούν στη μετανάστευση) μεταφέρουν εγγραφές "ένα προς ένα" και δεν επανασυνθέτουν το SPF για τον νέο αποστολέα. Ο ιστότοπος λειτουργεί εξωτερικά, αλλά το email σπάει σιωπηλά — τα email αποστέλλονται αλλά προσγειώνονται στα spam, και κανείς δεν το παρατηρεί για εβδομάδες.

Ένα κλασικό παράδειγμα: το κύριο SPF παραμένει v=spf1 include:_spf.old-hoster.com ~all, παρόλο που τα email αποστέλλονται πλέον στην πραγματικότητα από διαφορετική υπηρεσία — Amazon SES, Resend, SendGrid, ή Postmark. Ο τομέας "επιτρέπει" τον παλιό host, αλλά όχι τον πραγματικό αποστολέα. Το Gmail βλέπει SPF: fail ή softfail και στέλνει το email στα spam, ακόμα κι αν το περιεχόμενο είναι απολύτως νόμιμο.

Βήμα 1. Διάγνωση (Μην Μαντεύετε)

• Στείλτε ένα δοκιμαστικό email στο mail-tester.com — η υπηρεσία παρέχει μια διεύθυνση μιας χρήσης και εμφανίζει μια αναφορά με βαθμολογία στα 10 και ανάλυση κάθε εγγραφής.
• Στο Gmail, ανοίξτε το email → κάντε κλικ στο μενού "⋮" → "Εμφάνιση πρωτοτύπου." Βρείτε τρεις γραμμές: SPF, DKIM, DMARC. Και οι τρεις πρέπει να είναι PASS.

Εάν τουλάχιστον μία είναι fail / softfail — το πρόβλημα είναι με το DNS, όχι με το περιεχόμενο του email. Συνεχίστε με τη λίστα ελέγχου.

Βήμα 2. Λίστα Ελέγχου Εγγραφών DNS

Όλα διορθώνονται στο Cloudflare → DNS → Records:

• SPF (κύριος τομέας). Πρέπει να εξουσιοδοτεί τον ΠΡΑΓΜΑΤΙΚΟ αποστολέα. Για Amazon SES / Resend, είναι v=spf1 include:amazonses.com ~all. ⚠️ Μπορεί να υπάρχει μόνο μία εγγραφή v=spf1 ανά τομέα — εάν υπάρχουν δύο, και οι δύο γίνονται άκυρες. Εάν τα email αποστέλλονται τόσο μέσω εξωτερικής υπηρεσίας όσο και από το γραμματοκιβώτιό σας — συνδυάστε τα όλα σε μία γραμμή χρησιμοποιώντας include:.
• DKIM. Πρέπει να υπάρχει μια εγγραφή επιλογέα (π.χ., resend._domainkey). Αυτή είναι μια κρυπτογραφική υπογραφή που χρησιμοποιεί η υπηρεσία αλληλογραφίας για να επιβεβαιώσει ότι το email προέρχεται γνήσια από εσάς και δεν έχει πλαστογραφηθεί.
• DMARC. Εγγραφή _dmarc. Για έναν νέο τομέα, είναι εντάξει να ξεκινήσετε με p=none (μόνο παρακολούθηση). μετά την "προθέρμανση", αυξήστε την σε p=quarantine.
• MX και return-path. Πρέπει να δείχνουν στον πάροχο αποστολής/λήψης σας, όχι στον παλιό host.
• PTR (αντίστροφη εγγραφή, rDNS). Σχετικό μόνο εάν στέλνετε email από τον δικό σας διακομιστή SMTP — η αντίστροφη εγγραφή της IP πρέπει να ταιριάζει με το όνομα του διακομιστή.
• Αφαιρέστε τα παλιά σκουπίδια του host. Ένα σπασμένο κύριο MX, ένας ξεπερασμένος παλιός επιλογέας DKIM, επιπλέον include: στο SPF — μια κοινή αιτία που ξεχνιέται μετά τη μετανάστευση.

Ο κύριος κανόνας: μετά από ΟΠΟΙΑΔΗΠΟΤΕ μεταφορά DNS, εκτελέστε έναν έλεγχο αλληλογραφίας ξεχωριστά. Η εισαγωγή ζώνης αντιγράφει τις εγγραφές "όπως ήταν", και "όπως ήταν" είναι η διαμόρφωση του παλιού παρόχου.

Βήμα 3. Εάν τα Email ΕΧΟΥΝ Ήδη Πάει στα Spam

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

• Μεταβείτε στο Google Mail (Gmail), ανοίξτε ένα email από τον φάκελο "Spam" → κάντε κλικ στο κουμπί "Όχι spam". Αυτό είναι το ισχυρότερο σήμα σε επίπεδο λογαριασμού: το Gmail θα αναθεωρήσει την φήμη του αποστολέα γρηγορότερα και θα αρχίσει να τοποθετεί τα email του στο "Inbox".
• Ζητήστε από τους πρώτους παραλήπτες να κάνουν το ίδιο — μερικές σημάνσεις "Όχι spam" από πραγματικούς ανθρώπους θα επιταχύνουν σημαντικά τη διαδικασία.

Βήμα 4. Λάβετε Υπόψη τον Παράγοντα "Νέος Τομέας"

Εάν ο τομέας καταχωρήθηκε πρόσφατα, του λείπει ακόμα ιστορικό και φήμη. Ακόμα και με τέλεια διαμορφωμένα SPF, DKIM και DMARC, ορισμένα email μπορεί αρχικά να καταλήγουν στα spam — και αυτό είναι αναμενόμενο· δεν αφορά πλέον το DNS.

• Προθερμάνετε τον τομέα: ξεκινήστε με μικρούς όγκους αποστολής και αυξήστε σταδιακά, όχι "χίλια email την πρώτη μέρα".
• Παρακολουθήστε παράπονα και απεγγραφές — απότομες αυξήσεις βλάπτουν τη φήμη.
• Οι σημάνσεις "Όχι spam" από πραγματικούς παραλήπτες σε αυτό το στάδιο προθερμαίνουν τον τομέα ταχύτερα.

Διορθώνετε το DNS μία φορά, και στη συνέχεια η φήμη χτίζεται με τον όγκο και τη συμπεριφορά των παραληπτών.

Βήμα 5. Ελέγξτε το Αποτέλεσμα

• Επαναλάβετε τον έλεγχο στο mail-tester.com → στοχεύστε στο 10/10.
• Στις κεφαλίδες των email (Gmail → "Εμφάνιση πρωτοτύπου"): SPF: PASS, DKIM: PASS, DMARC: PASS.
• Ένα δοκιμαστικό email φτάνει στο "Inbox," όχι στο "Spam."

Συμπέρασμα

Τα email που πηγαίνουν στα spam μετά τη μετανάστευση σχεδόν ποτέ δεν είναι "μαγεία", αλλά μάλλον το SPF που μεταφέρθηκε από τον παλιό host, το οποίο δεν εξουσιοδοτεί τον νέο αποστολέα (μια κοινή παρενέργεια της αυτόματης και AI μετανάστευσης DNS στο Cloudflare). Ο αλγόριθμος θεραπείας: επανασύνθεση του SPF για τον πραγματικό αποστολέα → έλεγχος DKIM, DMARC, MX → καθαρισμός παλιών σκουπιδιών του host → δοκιμή στο mail-tester → εάν τα email έχουν ήδη πάει στα spam, σημάνετε "Όχι spam" χειροκίνητα → για νέο τομέα, προσθέστε προθέρμανση. Ακολουθήστε αυτή τη λίστα ελέγχου μία φορά — και τα email θα επιστρέφουν σταθερά στο "Inbox".