E-mailuri din formularul de contact care ajung la spam — Remediere expeditor server web (2026)

Publicat 2026-07-08

Date din 2026-06-29 · metodologie v7. Date agregate din recensământul a 261 milioane de domenii clasificate. Consultați cum clasificăm.

E-mailurile din formularul de contact și cele de pe site ajung la spam deoarece serverul dvs. web le trimite neautentificate — fără autorizare SPF, fără semnătură DKIM. Soluția fiabilă este rutarea acelui e-mail prin SMTP autentificat, nu includerea serverului pe lista albă. 46.4% din cele 261,086,232 domenii clasificate în recensământul Defaults.Exposed (date din 2026-06-29) nu publică niciun record SPF.

Ordinea de remediere contează, iar cele mai multe tutoriale o inversează. Rulați o scanare gratuită pentru a vedea ce publică efectiv domeniul dvs.; rutați e-mailul site-ului prin SMTP autentificat (furnizorul dvs. de cutii poștale sau un serviciu tranzacțional de e-mail) astfel încât să obțină o semnătură DKIM reală; reparați adresa From a formularului; și adăugați IP-ul serverului la SPF doar ca ultimă soluție.

De ce ajung e-mailurile de pe site-ul meu la spam?

Din cauza cine le trimite cu adevărat. Când un vizitator trimite formularul dvs. de contact, e-mailul nu este trimis de furnizorul dvs. de e-mail — serverul web îl generează singur, de obicei prin PHP mail(). Din perspectiva receptorului, acel mesaj:

vine de la un IP pe care înregistrarea dvs. SPF nu îl autorizează (SPF-ul dvs. acoperă furnizorul de e-mail, nu gazda web);
nu poartă nicio semnătură DKIM, deci nimic nu îl leagă criptografic de domeniul dvs.;
pleacă adesea de la un IP de găzduire partajată a cărui reputație este stabilită de sutele de site-uri ale altor persoane.

E-mailul neautentificat de la un IP cu reputație mixtă este exact ceea ce filtrele de spam sunt concepute să prindă — Gmail și Outlook văd un server aleatoriu care pretinde că este dvs. Linia de bază generală este sumbră: 46.4% din domenii nu publică niciun SPF, iar doar 10.59% (27,640,987 din 261,086,232 domenii clasificate, recensământ din 2026-06-29) aplică o politică DMARC.

De ce afectează aceasta în special site-urile WordPress?

WordPress trimite tot e-mailul său — notificări de formulare, resetări de parolă, confirmări de comandă — printr-o singură funcție, wp_mail(), care în mod implicit împachetează PHP mail() pe serverul web. Fiecare site WordPress care nu a fost reconfigurat deliberat este un expeditor neautentificat din start. Plugin-urile de formulare (Contact Form 7, WPForms, Gravity Forms) transmit toate e-mailul aceleași funcții: pare o problemă de plugin, dar este o problemă de transport.

Soluția nu este un plugin de formulare diferit, ci un plugin SMTP (WP Mail SMTP și echivalentele sale), care redirecționează tot ce trimite wp_mail() printr-un cont de e-mail real, autentificat — infrastructura pe care SPF-ul dvs. o autorizează deja, cu o semnătură DKIM atașată.

Ce metodă de trimitere ar trebui să folosească site-ul?

Metodă de trimitere	SPF	DKIM	Supraviețuiește migrarea gazdei?	Verdict
PHP `mail()` / `wp_mail()` implicit de pe serverul web	eșuează	niciunul	n/a — stricat peste tot	problema, nu o opțiune
SMTP autentificat prin furnizorul de cutii poștale (Google Workspace, Microsoft 365 etc.)	trece	semnat	da — independent de găzduire	soluția pentru majoritatea site-urilor
Serviciu tranzacțional de e-mail (SES, Postmark, Brevo etc.) cu domeniul dvs. verificat	trece	semnat	da	soluția la volum (e-commerce, formulare mari)
IP-ul serverului web adăugat la înregistrarea dvs. SPF	trece (numai SPF)	niciunul	nu — se strică silențios când IP-ul se schimbă	doar ultimă soluție — vezi mai jos

Pentru câteva notificări pe zi, SMTP prin cutia poștală pe care o plătiți deja este calea cea mai scurtă; la volum real, un serviciu tranzacțional este construit pentru asta. Ambele vă oferă DKIM — scurtătura de includere pe lista albă a IP-ului nu o face niciodată.

Cum remediez livrabilitatea e-mailurilor din formularul de contact?

Rulați scanarea gratuită la defaults.exposed înainte de a atinge orice. Arată ce SPF, DKIM și DMARC publică efectiv domeniul dvs. — fie că reparați transportul formularului, un record lipsă sau ambele. Niciun SPF deloc? Începeți cu cum să reparați SPF.
Creați o identitate SMTP dedicată pentru site — de ex. [email protected] la furnizorul dvs. de cutii poștale, sau un domeniu de trimitere verificat într-un serviciu tranzacțional. Folosiți o parolă de aplicație sau cheie API pe care o puteți revoca, nu parola de cutie poștală a unei persoane.
Rutați e-mailul site-ului prin ea. WordPress: instalați un plugin SMTP și îndreptați-l spre acel cont. Alte stive: configurați expeditorul cadrului în loc de mail() local.
Reparați adresa From (anti-tiparul de mai jos): From trebuie să fie propriul dvs. domeniu; vizitatorul merge în Reply-To.
Dacă expeditorul este un serviciu tranzacțional, adăugați înregistrările sale DKIM (de obicei o pereche de CNAME-uri) astfel încât e-mailul să fie semnat cu domeniul dvs. — pașii DNS oglindesc instrucțiunile de configurare SPF.
Trimiteți o testare și re-scanați. Antetele ar trebui să arate spf=pass și dkim=pass pentru domeniul dvs.; apoi rezolvați orice altceva semnalează scanarea prin reparați SPF și reparați DKIM.

De ce trimite formularul „de la” adresa de e-mail a vizitatorului?

Cea mai frecventă greșeală auto-provocată în configurarea formularelor, și multe plugin-uri obișnuiau să o facă implicit: notificarea sosește De la: adresa vizitatorului, astfel încât să puteți răspunde. Pare convenabil și este o falsificare. Serverul dvs. nu are dreptul să trimită e-mail ca [email protected] — eșuează SPF și DKIM pentru gmail.com, iar politica DMARC a Gmail le spune receptorilor să îl trimită la junk sau să îl respingă. Soluția nu costă nimic:

From: o adresă la propriul dvs. domeniu (identitatea SMTP de la pasul 2)
Reply-To: adresa vizitatorului — răspunsul ajunge direct la ei

Fiecare plugin de formulare principal suportă asta; sunt două câmpuri în setările de notificare.

De ce să nu adaug pur și simplu IP-ul serverului la înregistrarea mea SPF?

Este soluția la care ajung primele cele mai multe fire din forumuri, și este ultima soluție dintr-un motiv. Adăugarea ip4:<server> (sau un mecanism a pentru gazda dvs. web) la SPF face ca verificarea brută să treacă — dar:

Pe găzduire partajată autorizează persoane străine. IP-ul aparține serverului, nu dvs.; fiecare alt site de pe acel server poate acum trimite e-mail cu SPF trecut ca domeniul dvs.
Se strică silențios. Gazdele migrează servere și rotesc IP-urile fără să vă spună; SPF-ul dvs. continuă să autorizeze o adresă pe care ați lăsat-o cu luni în urmă.
Nu vă oferă niciun DKIM. SPF singur se strică sub forwarding și nu vă poate duce spre aplicarea DMARC la fel cum o poate face o semnătură.

Rezervați această rută pentru cazul cu adevărat constrâns: un server dedicat cu un IP static pe care îl controlați și o aplicație care nu poate vorbi SMTP — și combinați-o cu semnarea DKIM pe server dacă puteți.

SPF verifică adresa pe care formularul meu o pune în „From”?

Nu — și asta deraiează jumătate din diagnosticele DIY. Receptorii evaluează SPF față de domeniul Return-Path (RFC5321.MailFrom), nu antetul From. Serverele web imprimă adesea propriul hostname pe Return-Path, deci înregistrarea dvs. SPF nu a fost consultată deloc — receptorul a verificat SPF pentru srv0421.examplehost.com. SMTP autentificat rezolvă și asta: Return-Path devine domeniul dvs., deci pasul SPF contează în cele din urmă pentru dvs. Este și motivul pentru care DKIM contează — alinierea DMARC are nevoie de un pass legat de domeniul din From, iar o semnătură DKIM călătorește cu mesajul.

Întrebări frecvente

Va repara un plugin SMTP și e-mailurile de resetare a parolei și WooCommerce? Da. Pe WordPress totul curge prin wp_mail(), deci redirecționarea lui repară notificările de formulare, resetările de parolă și e-mailurile de comandă dintr-o singură mișcare.

Am în continuare nevoie de înregistrări SPF și DKIM dacă folosesc un plugin SMTP? Da — plugin-ul schimbă care infrastructură trimite e-mailul dvs.; înregistrările sunt cele care o autorizează. Dacă domeniul dvs. se numără printre cei 46.4% din 261,086,232 domenii clasificate fără niciun record SPF (recensământ, 2026-06-29), SMTP autentificat singur nu vă va salva. Lista de verificare pentru e-mail al domeniului nou acoperă setul complet de înregistrări.

E-mailurile formularului meu trec SPF dar tot eșuează DMARC — de ce? Aproape întotdeauna este anti-tiparul de falsificare From de mai sus, sau SPF trecând pentru domeniul Return-Path al gazdei mai degrabă decât al dvs. Reparați From/Reply-To mai întâi; dacă tot eșuează, piesa lipsă este o semnătură DKIM aliniată — consultați „Semnătură DKIM nevalidă”. Dacă și instrumentele SaaS din afara site-ului eșuează, ghidul SPF eșuând pentru SaaS acoperă ordinea de remediere.

Merită tot efortul pentru un formular de contact cu trafic redus? Formularul este de obicei locul unde intră banii — o solicitare ratată este un client pe care nu l-ați știut că l-ați pierdut. Iar soluția este gratuită; bariera este să știți că serverul web a fost mereu expeditorul neautentificat.

Trimiteți proprietarului raportul

Dacă sunteți dezvoltatorul sau contractorul care rezolvă asta: odată ce testul trece, re-rulați scanarea gratuită și trimiteți raportul clasificat proprietarului site-ului — o dovadă datată, în limbaj simplu, că domeniul se autentifică corect, și artefactul de care vor avea nevoie la următoarea reînnoire a asigurării cibernetice sau chestionarul de securitate al clienților. Dacă sunteți proprietarul care citește asta deoarece solicitările au încetat să mai ajungă: trimiteți această pagină și raportul dvs. de scanare celui care gestionează site-ul — o muncă de o după-amiază cu un înainte-și-după pe care vi le pot arăta.

Verificați domeniul → · SPF eșuând pentru instrumentele dvs. SaaS? → · Reparați SPF → · Cum clasificăm → · Doar date agregate. Date stocate și procesate în UE.