Defaults.Exposed › Fikser › Guides

Kontaktskjema-e-poster havner i søppel — Fiksingen av nettserver-avsenderen (2026)

Publisert 2026-07-08

Tall per 2026-06-29 · metodikk v7. Samlet sensusdata for 261 millioner graderte domener. Se hvordan vi graderer.

Kontaktskjema- og nettside-e-poster havner i søppel fordi nettserveren din sender dem uautentisert — ingen SPF-autorisasjon, ingen DKIM-signatur. Den pålitelige fiksen er å rute e-posten gjennom autentisert SMTP, ikke å hviteliste serveren. 46.4% av de 261,086,232 domenene gradert i Defaults.Exposed-sensus (data per 2026-06-29) publiserer ingen SPF-post overhodet.

Fiksrekkefølgen betyr noe og de fleste veiledninger gjør det baklengs. Kjør en gratis skanning for å se hva domenet faktisk publiserer; rut nettstedets e-post gjennom autentisert SMTP (e-postleverandøren din eller en transaksjons-e-posttjeneste) slik at den får en ekte DKIM-signatur; fiks skjemaets Fra-adresse; og legg bare til serverens IP i SPF som siste utvei.

Hvorfor havner e-poster fra nettstedet mitt i søppel?

På grunn av hvem som faktisk sender dem. Når en besøkende sender inn kontaktskjemaet ditt, sendes ikke e-posten av e-postleverandøren din — nettserveren genererer den selv, vanligvis via PHPs mail(). Fra mottakersiden er den meldingen:

• kommer fra en IP som SPF-posten din ikke autoriserer (SPF-en din dekker e-postleverandøren din, ikke nettvertfirmaet ditt);
• bærer ingen DKIM-signatur, slik at ingenting kryptografisk knytter den til domenet ditt;
• sendes ofte fra en delt hosting-IP hvis omdømme er satt av hundrevis av fremmedes nettsteder.

Uautentisert e-post fra en IP med blandet omdømme er nøyaktig det spamfilteret eksisterer for å fange — Gmail og Outlook ser en tilfeldig server som hevder å være deg. Det bredere grunnlaget er trist: 46.4% av domener publiserer ingen SPF overhodet, og bare 10.59% (27,640,987 av 261,086,232 graderte domener, sensus per 2026-06-29) håndhever en DMARC-policy.

Hvorfor rammer dette WordPress-nettsteder spesielt?

WordPress sender all e-posten sin — skjema-varsler, passordtilbakestillinger, ordrebekreftelser — gjennom én funksjon, wp_mail(), som som standard pakker inn PHPs mail() på nettserveren. Hvert WordPress-nettsted som ikke er bevisst rekonfigurert er en uautentisert avsender ut av esken. Skjema-programtillegg (Contact Form 7, WPForms, Gravity Forms) sender alle e-post til den samme funksjonen: det ser ut som et programtilleggsproblem men er et transportproblem.

Fiksen er ikke et annet skjema-programtillegg men et SMTP-programtillegg (WP Mail SMTP og tilsvarende), som omruter alt wp_mail() sender gjennom en ekte, autentisert e-postkonto — infrastruktur SPF-en din allerede autoriserer, med en DKIM-signatur vedlagt.

Hvilken sendemetode bør nettstedet bruke?

For noen få varsler om dagen er SMTP gjennom postkassen du allerede betaler for den korteste veien; ved reelt volum er en transaksjonstjeneste bygget for det. Begge gir deg DKIM — IP-hvitelisting-snarveien gjør det aldri.

Hvordan fikser jeg leverbarhet for kontaktskjema-e-post?

1. Kjør den gratis skanningen på defaults.exposed før du rører noe. Den viser hva SPF, DKIM og DMARC domenet faktisk publiserer — enten du fikser skjemaets transport, en manglende post, eller begge deler. Ingen SPF overhodet? Start med hvordan fikser du SPF.
2. Opprett en dedikert SMTP-identitet for nettstedet — f.eks. [email protected] hos e-postleverandøren din, eller et verifisert sendingsdomene i en transaksjonstjeneste. Bruk et apppassord eller API-nøkkel du kan tilbakekalle, ikke en persons postkassepassord.
3. Rut nettstedets e-post gjennom det. WordPress: installer et SMTP-programtillegg og pek det mot den kontoen. Andre stakker: konfigurer rammeverkets e-postsender i stedet for lokal mail().
4. Fiks Fra-adressen (antimønsteret nedenfor): Fra må være ditt eget domene; den besøkende legges i Svar-til.
5. Hvis avsenderen er en transaksjonstjeneste, legg til dens DKIM-poster (vanligvis et par CNAME-er) slik at e-post signeres med domenet ditt — DNS-trinnene speiler gjennomgangene for SPF-oppsett.
6. Send en testinnsending og skann på nytt. Overskrifter skal vise spf=pass og dkim=pass for ditt domene; rydd deretter opp alt annet skanningen flagger via fiks SPF og fiks DKIM.

Hvorfor sender skjemaet «fra» den besøkendes e-postadresse?

Den vanligste selvpåførte feilen i skjemakonfigurering, og mange programtillegg pleide å gjøre det som standard: varselet ankommer Fra: den besøkendes adresse, slik at du kan trykke svar. Det føles praktisk, og det er forfalskning. Serveren din har ingen rett til å sende e-post som [email protected] — det feiler SPF og DKIM for gmail.com, og Gmails DMARC-policy forteller mottakere å søppelkategorisere eller avvise det. Fiksen koster ingenting:

• Fra: en adresse på ditt eget domene (SMTP-identiteten fra trinn 2)
• Svar-til: den besøkendes adresse — svaret går fortsatt direkte til dem

Alle vanlige skjema-programtillegg støtter dette; det er to felt i varselinnstillingene.

Hvorfor ikke bare legge til serverens IP i SPF-posten min?

Det er fiksen de fleste forumtråder griper etter først, og det er reserven av en grunn. Å legge til ip4:<server> (eller en a-mekanisme for nettvertfirmaet ditt) i SPF får den rå sjekken til å bestå — men:

• På delt hosting autoriserer det fremmede. IP-en tilhører serveren, ikke deg; hvert annet nettsted på den serveren kan nå sende SPF-beståenede e-post som domenet ditt.
• Det bryter stille. Vertsfirmaer migrerer servere og roterer IP-er uten å fortelle deg; SPF-en din autoriserer fortsatt en adresse du forlot for måneder siden.
• Det gir deg ingen DKIM. SPF alene bryter ved videresending og kan ikke bære deg mot DMARC-håndhevelse slik en signatur kan.

Reserver denne veien for det genuint begrensede tilfellet: en dedikert server med en statisk IP du kontrollerer og en applikasjon som ikke kan kommunisere SMTP — og par det med DKIM-signering på serveren hvis du kan.

Sjekker SPF i det hele tatt adressen skjemaet legger inn i «Fra»?

Nei — og dette snubler halvparten av DIY-diagnosene. Mottakere evaluerer SPF mot Return-Path (RFC5321.MailFrom)-domenet, ikke Fra-overskriften. Nettservere stempler ofte sitt eget vertsnavn på Return-Path, slik at SPF-posten din aldri ble konsultert i det hele tatt — mottakeren sjekket SPF for srv0421.examplehost.com. Autentisert SMTP fikser dette også: Return-Path blir domenet ditt, slik at SPF-bestått endelig teller for deg. Det er også grunnen til at DKIM er viktig — DMARC-justering trenger et bestått som er knyttet til domenet i Fra, og en DKIM-signatur reiser med meldingen.

Ofte stilte spørsmål

Vil et SMTP-programtillegg fikse passordtilbakestilling og WooCommerce-e-poster også? Ja. På WordPress flyter alt gjennom wp_mail(), slik at omruting av det fikser skjema-varsler, passordtilbakestillinger og bestillings-e-poster i én operasjon.

Trenger jeg fortsatt SPF- og DKIM-poster hvis jeg bruker et SMTP-programtillegg? Ja — programtillegget endrer hvilken infrastruktur som sender e-posten din; postene er det som autoriserer det. Hvis domenet ditt er blant de 46.4% av 261,086,232 graderte domener uten SPF-post (sensus, 2026-06-29), vil autentisert SMTP alene ikke redde deg. Kontrollisten for ny-domene-e-post dekker det fullstendige postsettet.

Skjema-e-postene mine består SPF men feiler fortsatt DMARC — hvorfor? Nesten alltid Fra-forfalskning-antimønsteret ovenfor, eller SPF som består for vertens Return-Path-domene i stedet for ditt. Fiks Fra/Svar-til først; hvis det fortsatt feiler, er det manglende stykket en justert DKIM-signatur — se «DKIM-signatur ikke gyldig». Hvis SaaS-verktøy utover nettstedet også feiler, dekker veiledningen for SPF som feiler for SaaS fiksrekkefølgen.

Er det verdt alt dette for et lavtrafikkert kontaktskjema? Skjemaet er vanligvis der pengene kommer inn — en savnet henvendelse er en kunde du aldri visste du mistet. Og fiksen er gratis; barrieren er å vite at nettserveren var den uautentiserte avsenderen hele tiden.

Send eieren rapporten

Hvis du er utvikleren eller konsulenten som fikser dette: når testinnsendingen består, kjør den gratis skanningen på nytt og videresend den graderte rapporten til nettstedets eier — en datert, klartspråklig oversikt over at domenet autentiserer korrekt, og artefakten de trenger for neste fornyelse av cyberforsikring eller kundesikkerhetsspørreskjema. Hvis du er eieren som leser dette fordi henvendelser sluttet å ankomme: send denne siden og skannerapporten din til hvem som helst som driver nettstedet ditt — en ettermiddags-jobb med en før-og-etter de kan vise deg.

Sjekk domenet ditt → · SPF feiler for SaaS-verktøyene dine? → · Fiks SPF → · Hvordan vi graderer → · Kun aggregerte data. Data lagret og behandlet i EU.