Yhteydenottolomakkeen sähköpostit päätyvät roskapostiin — Web-palvelimen lähettäjän korjaus (2026)

Julkaistu 2026-07-08

Tiedot päivätty 2026-06-29 · metodologia v7. Koostettua väestönlaskentadataa 261 miljoonasta arvioidusta verkkotunnuksesta. Katso miten arvioimme.

Yhteydenottolomakkeen ja verkkosivuston sähköpostit päätyvät roskapostiin, koska web-palvelimesi lähettää ne todentamattomina — ilman SPF-valtuutusta, ilman DKIM-allekirjoitusta. Luotettava korjaus on reitittää kyseinen sähköposti todennetun SMTP:n kautta, ei sen palvelimen IP-osoitteen salliminen. 46.4% Defaults.Exposed-väestönlaskennan 261,086,232 verkkotunnuksesta (tiedot päivätty 2026-06-29) ei julkaise lainkaan SPF-tietuetta.

Korjausjärjestys on tärkeä, ja useimmat ohjeet saavat sen päinvastoin. Suorita ilmainen skannaus nähdäksesi, mitä verkkotunnuksesi todella julkaisee; reititä sivuston sähköposti todennetun SMTP:n kautta (sähköpostipalveluntarjoajasi tai transaktionaalinen sähköpostipalvelu), jotta se saa aidon DKIM-allekirjoituksen; korjaa lomakkeen From-osoite; ja lisää palvelimen IP-osoite SPF-tietueeseen vasta viimeisenä vaihtoehtona.

Miksi verkkosivustoni sähköpostit päätyvät roskapostiin?

Syy on kuka ne todella lähettää. Kun kävijä täyttää yhteydenottolomakkeesi, sähköpostia ei lähetä sähköpostipalveluntarjoajasi — web-palvelin tuottaa sen itse, yleensä PHP:n mail()-funktion kautta. Vastaanottajan näkökulmasta viesti:

tulee IP-osoitteesta, jota SPF-tietueesi ei valtuuta (SPF kattaa sähköpostipalveluntarjoajasi, ei web-isäntäsi);
ei sisällä DKIM-allekirjoitusta, joten mikään ei kryptografisesti sido sitä verkkotunnukseesi;
lähtee usein jaetun webhotelli-palvelimen IP-osoitteesta, jonka maineen määrittävät sadat muiden ihmisten sivustot.

Todentamaton sähköposti sekalaiselta maineeltaan vaihtelevalta IP-osoitteelta on juuri sitä, mitä roskapostisuodattimet on tarkoitettu havaitsemaan — Gmail ja Outlook näkevät satunnaisen palvelimen, joka väittää olevansa sinä. Laajempi perustaso on synkkä: 46.4% verkkotunnuksista ei julkaise lainkaan SPF-tietuetta, ja vain 10.59% (27,640,987 / 261,086,232 arvioidusta verkkotunnuksesta, väestönlaskenta päivätty 2026-06-29) pakottaa DMARC-käytännön.

Miksi tämä koskee erityisesti WordPress-sivustoja?

WordPress lähettää kaiken sähköpostinsa — lomakeilmoitukset, salasanan palautukset, tilausvahvistukset — yhden funktion, wp_mail():n, kautta, joka oletuksena käyttää PHP:n mail()-funktiota web-palvelimella. Jokainen WordPress-sivusto, jota ei ole tarkoituksellisesti uudelleenkonfiguroitu, on oletuksena todentamaton lähettäjä. Lomakkeliitännäiset (Contact Form 7, WPForms, Gravity Forms) kaikki välittävät sähköpostin samalle funktiolle: ongelman näyttää olevan liitännäisessä, mutta se on todellisuudessa kuljetusprotokollaan liittyvä ongelma.

Ratkaisu ei ole eri lomakkeliitännäinen, vaan SMTP-liitännäinen (WP Mail SMTP ja vastaavat), joka reitittää kaiken wp_mail():n lähettämän todennetun sähköpostitilin kautta — infrastruktuuri, jonka SPF jo valtuuttaa, ja johon liitetään DKIM-allekirjoitus.

Mitä lähetysmenetelmää sivuston tulisi käyttää?

Lähetysmenetelmä	SPF	DKIM	Säilyykö palvelimen vaihdon jälkeen?	Arvio
PHP `mail()` / oletusarvoinen `wp_mail()` web-palvelimelta	epäonnistuu	ei ole	ei sovellu — toimintahäiriö kaikkialla	ongelma, ei vaihtoehto
Todennettu SMTP sähköpostipalveluntarjoajan kautta (Google Workspace, Microsoft 365 jne.)	hyväksytty	allekirjoitettu	kyllä — riippumaton isännöinnistä	korjaus useimmille sivustoille
Transaktionaalinen sähköpostipalvelu (SES, Postmark, Brevo jne.) vahvistetulla verkkotunnuksella	hyväksytty	allekirjoitettu	kyllä	korjaus suurissa volyymeissa (verkkokauppa, isot lomakkeet)
Web-palvelimen IP lisätty SPF-tietueeseen	hyväksytty (vain SPF)	ei ole	ei — hajoaa äänettömästi kun IP vaihtuu	vararatkaisu vain — katso alla

Muutamalle ilmoitukselle päivässä SMTP jo maksamasi postilaatikon kautta on lyhin polku; suuressa volyymissa transaktionaalinen palvelu on siihen rakennettu. Molemmat antavat DKIM:n — IP-osoitteen sallimispikakorjaus ei koskaan anna.

Miten korjaan yhteydenottolomakkeen sähköpostin toimitettavuuden?

Suorita ilmainen skannaus osoitteessa defaults.exposed ennen kuin kosket mihinkään. Se näyttää, mitä SPF-, DKIM- ja DMARC-tietueita verkkotunnuksesi todella julkaisee — korjaatko lomakkeen kuljetusta, puuttuvaa tietuetta vai molempia. Ei lainkaan SPF:ää? Aloita SPF:n korjauksesta.
Luo sivustolle erillinen SMTP-identiteetti — esim. [email protected] sähköpostipalveluntarjoajallasi tai vahvistettuna lähetysdomeenina palveluna. Käytä sovellussalasanaa tai API-avainta, jonka voit peruuttaa, älä kenenkään henkilökohtaista postilaatikkosalasanaa.
Reititä sivuston sähköposti sen kautta. WordPress: asenna SMTP-liitännäinen ja ohjaa se kyseiselle tilille. Muut järjestelmät: konfiguroi kehyksen sähköpostinlähetin paikallisen mail():n sijaan.
Korjaa From-osoite (alla oleva sudenkuoppa): From-kentässä tulee olla oma verkkotunnuksesi; kävijä menee Reply-To-kenttään.
Jos lähettäjä on transaktionaalinen palvelu, lisää sen DKIM-tietueet (yleensä pari CNAME-tietuetta), jotta sähköposti allekirjoitetaan verkkotunnuksellasi — DNS-vaiheet peilaavat SPF:n asennusohjeita.
Lähetä testimäärittely ja skannaa uudelleen. Otsikoissa pitäisi näkyä spf=pass ja dkim=pass omalle verkkotunnuksellesi; korjaa sen jälkeen muut skannauksen havainnot SPF:n korjauksen ja DKIM:n korjauksen kautta.

Miksi lomake lähettää “from” kävijän sähköpostiosoitteesta?

Yleisin lomakekonfiguraation itselle aiheutettu ongelma, ja monet liitännäiset tekivät sen oletuksena aiemmin: ilmoitus saapuu Lähettäjä: kävijän osoite, jotta voit painaa vastausta. Se tuntuu kätevälle, ja se on väärentämistä. Palvelimellasi ei ole oikeutta lähettää sähköpostia [email protected]:n nimissä — se epäonnistuu gmail.comin SPF:ssä ja DKIM:ssä, ja Gmailin DMARC-käytäntö kehottaa vastaanottajia hylkäämään tai torjumaan sen. Korjaus ei maksa mitään:

From: osoite omassa verkkotunnuksessasi (SMTP-identiteetti vaiheesta 2)
Reply-To: kävijän osoite — vastaus menee silti suoraan heille

Jokainen yleinen lomakkeliitännäinen tukee tätä; se on kaksi kenttää ilmoitusasetuksissa.

Miksei lisätä palvelimen IP:tä SPF-tietueeseen?

Se on ensimmäinen korjaus, johon useimmat foorumiviestiketjut turvautuvat, ja se on vararatkaisu syystä. ip4:<palvelin>:n (tai web-isäntää varten a-mekanismin) lisääminen SPF:ään saa raakakokeen läpäisemään — mutta:

Jaetussa webhotellissa se valtuuttaa vieraat. IP kuuluu koneelle, ei sinulle; kaikki muut sivustot samalla palvelimella voivat nyt lähettää SPF:n läpäisevää sähköpostia verkkotunnuksesi nimissä.
Se hajoaa äänettömästi. Isännät siirtävät palvelimia ja vaihtavat IP:itä kertomatta sinulle; SPF jatkaa valtuuttamista osoitteelle, josta lähdit kuukausia sitten.
Se ei anna DKIM:iä. Pelkkä SPF hajoaa välityksessä, eikä se voi viedä sinua kohti DMARC:n täytäntöönpanoa samalla tavalla kuin allekirjoitus.

Varaa tämä reitti aidosti rajoitettuun tapaukseen: dedikoitu palvelin, jolla on staattinen, hallitsemasi IP, ja sovellus, joka ei osaa SMTP:tä — ja pari se DKIM-allekirjoitukseen palvelimella jos mahdollista.

Tarkistaako SPF edes From-kentän osoitteen?

Ei — ja tämä hämmentää puolet omatoimisista diagnooseista. Vastaanottajat arvioivat SPF:n Return-Path (RFC5321.MailFrom) -verkkotunnusta vastaan, ei From-otsikkoa. Web-palvelimet leimavat usein oman isäntänimensä Return-Path:iin, joten SPF-tietuettasi ei koskaan konsultoitu — vastaanottaja tarkisti SPF:n srv0421.examplehost.com:lle. Todennettu SMTP korjaa tämänkin: Return-Path:sta tulee verkkotunnuksesi, joten SPF-hyväksyntä lopulta lasketaan sinulle. Tästä syystä DKIM on tärkeä — DMARC-linjautuminen tarvitsee hyväksynnän, joka on sidottu From-kentän verkkotunnukseen, ja DKIM-allekirjoitus kulkee viestin mukana.

Usein kysytyt kysymykset

Korjaako SMTP-liitännäinen myös salasanan palautus- ja WooCommerce-sähköpostit? Kyllä. WordPressissä kaikki kulkee wp_mail():n kautta, joten sen uudelleenreititys korjaa lomakeilmoitukset, salasanan palautukset ja tilaussähköpostit yhdellä kertaa.

Tarvitsenko silti SPF- ja DKIM-tietueita, jos käytän SMTP-liitännäistä? Kyllä — liitännäinen muuttaa mitä infrastruktuuria sähköpostisi lähettää; tietueet ovat se, mikä valtuuttaa sen. Jos verkkotunnuksesi kuuluu 46.4%:iin 261,086,232 arvioidusta verkkotunnuksesta, joilla ei ole SPF-tietuetta (väestönlaskenta, 2026-06-29), todennettu SMTP yksin ei riitä. Uuden verkkotunnuksen sähköpostin tarkistuslista kattaa koko tietuejoukon.

Lomakkeen sähköpostit läpäisevät SPF:n mutta epäonnistuvat DMARC:ssa — miksi? Lähes aina kyse on yllä olevasta From-osoitteen väärinkäytöstä tai siitä, että SPF hyväksyy isännän Return-Path-verkkotunnuksen eikä omaasi. Korjaa From/Reply-To ensin; jos se epäonnistuu edelleen, puuttuva osa on linjautunut DKIM-allekirjoitus — katso “DKIM-allekirjoitus ei kelpaa”. Jos myös muut SaaS-työkalut epäonnistuvat, SaaS:ille epäonnistuvan SPF:n opas kattaa korjausjärjestyksen.

Onko tämä kaiken vaivan arvoinen pelkästä vähäisen liikenteen yhteydenottolomakkeesta? Lomake on yleensä se, mistä raha tulee — menetetty tiedustelu on asiakas, jonka menetit tietämättäsi. Ja korjaus on ilmainen; este on tietää, että web-palvelin oli todentamaton lähettäjä alusta asti.

Lähetä omistajalle raportti

Jos olet kehittäjä tai urakoitsija, joka korjaa tätä: kun testi läpäisee, suorita ilmainen skannaus uudelleen ja lähetä arvioitu raportti sivuston omistajalle — päivätty, selkokielinen tiedote siitä, että verkkotunnus todentaa asianmukaisesti, ja se artefakti, jota he tarvitsevat seuraavaa kybervakuutuksen uusimista tai asiakkaiden turvallisuuskyselyä varten. Jos olet omistaja, joka lukee tätä, koska tiedustelut lakkasivat saapumasta: lähetä tämä sivu ja skannauksesi raportti sille, joka ylläpitää verkkosivustoasi — yhden iltapäivän työ, josta saa näyttää ennen/jälkeen-vertailun.

Tarkista verkkotunnuksesi → · SPF epäonnistuu SaaS-työkaluillesi? → · Korjaa SPF → · Miten arvioimme → · Vain koostettua dataa. Data tallennettu ja käsitelty EU:ssa.