Kontaktformulär-e-post hamnar i skräppost — webbserver-avsändarfixen (2026)

Publicerad 2026-07-08

Siffror från 2026-06-29 · metodik v7. Aggregerade censusdata över 261 miljoner graderade domäner. Se hur vi graderar.

Kontaktformulär- och webbplats-e-post hamnar i skräppost eftersom din webbserver skickar dem oautentiserat — ingen SPF-auktorisering, ingen DKIM-signatur. Den pålitliga fixen är att dirigera den e-posten via autentiserad SMTP, inte vitlista servern. 46.4% av de 261,086,232 domänerna graderade i Defaults.Exposed-censuset (data per 2026-06-29) publicerar ingen SPF-post alls.

Fixordningen spelar roll och de flesta handledningar gör det bakvänt. Kör en kostnadsfri sökning för att se vad din domän faktiskt publicerar; dirigera webbplatsens e-post via autentiserad SMTP (din postlådeleverantör eller en transaktionell e-posttjänst) så att den får en riktig DKIM-signatur; åtgärda formulärets From-adress; och lägg bara till serverns IP i SPF som en sista utväg.

Varför hamnar e-post från min webbplats i skräppost?

På grund av vem som egentligen skickar dem. När en besökare skickar in ditt kontaktformulär skickas e-posten inte av din e-postleverantör — webbservern genererar den själv, vanligtvis via PHP:s mail(). Från mottagarsidan är det meddelandet:

från en IP som din SPF-post inte auktoriserar (din SPF täcker din e-postleverantör, inte din webbvärd);
bär ingen DKIM-signatur, så inget kryptografiskt binder det till din domän;
lämnar ofta från en delad värd-IP vars rykte sätts av hundratals okänds webbplatser.

Oautentiserad e-post från en IP med blandat rykte är exakt vad skräppostfilter finns till för att fånga — Gmail och Outlook ser en slumpmässig server som påstår sig vara du. Den bredare baslinjen är dyster: 46.4% av domänerna publicerar ingen SPF alls, och bara 10.59% (27,640,987 av 261,086,232 graderade domäner, censuset per 2026-06-29) tillämpar en DMARC-policy.

Varför drabbar detta WordPress-webbplatser i synnerhet?

WordPress skickar all sin e-post — formuläraviseringar, lösenordsåterställningar, orderbekräftelser — via en funktion, wp_mail(), som som standard omsluter PHP mail() på webbservern. Varje WordPress-webbplats som inte medvetet konfigurerats om är en oautentiserad avsändare direkt ur lådan. Formulär-plugins (Contact Form 7, WPForms, Gravity Forms) överlämnar alla e-post till samma funktion: det ser ut som ett plugin-problem men är ett transport-problem.

Fixen är inte ett annat formulär-plugin utan ett SMTP-plugin (WP Mail SMTP och dess motsvarigheter), som dirigerar om allt wp_mail() skickar via ett riktigt, autentiserat e-postkonto — infrastruktur som din SPF redan auktoriserar, med en DKIM-signatur bifogad.

Vilken sändningsmetod ska webbplatsen använda?

Sändningsmetod	SPF	DKIM	Överlever en värdmigration?	Dom
PHP `mail()` / standard `wp_mail()` från webboxen	misslyckas	ingen	n/a — trasig överallt	problemet, inte ett alternativ
Autentiserad SMTP via din postlådeleverantör (Google Workspace, Microsoft 365, etc.)	godkänns	signerat	ja — oberoende av värdtjänst	fixen för de flesta webbplatser
Transaktionell e-posttjänst (SES, Postmark, Brevo, etc.) med din domän verifierad	godkänns	signerat	ja	fixen vid volym (e-handel, stora formulär)
Webbserverns IP tillagd i din SPF-post	godkänns (enbart SPF)	ingen	nej — slutar fungera tyst när IP:n ändras	bara som sista utväg — se nedan

För ett par aviseringar per dag är SMTP via postlådan du redan betalar för den kortaste vägen; vid verklig volym är en transaktionell tjänst byggd för det. Båda ger dig DKIM — IP-vitlistningsgenvägen gör det aldrig.

Hur åtgärdar jag leveransbarhet för kontaktformulär-e-post?

Kör den kostnadsfria sökningen på defaults.exposed innan du rör något. Den visar vilken SPF, DKIM och DMARC din domän faktiskt publicerar — om du åtgärdar formulärets transport, en saknad post eller båda. Ingen SPF alls? Börja med hur man åtgärdar SPF.
Skapa en dedikerad SMTP-identitet för webbplatsen — t.ex. [email protected] hos din postlådeleverantör, eller en verifierad sändande domän i en transaktionell tjänst. Använd ett applösenord eller API-nyckel du kan återkalla, inte en persons postlådelösenord.
Dirigera webbplatsens e-post via den. WordPress: installera ett SMTP-plugin och peka det mot det kontot. Andra stackar: konfigurera ramverkets mejlare istället för lokal mail().
Åtgärda From-adressen (antimönstret nedan): From måste vara din egna domän; besökaren läggs i Reply-To.
Om avsändaren är en transaktionell tjänst, lägg till dess DKIM-poster (vanligtvis ett par CNAMEs) så att e-post signeras med din domän — DNS-stegen speglar SPF-konfigurationsgenomgångarna.
Skicka en testinlämning och scanna om. Rubriker bör visa spf=pass och dkim=pass för din domän; åtgärda sedan allt annat som sökningen flaggar via åtgärda SPF och åtgärda DKIM.

Varför skickar formuläret “från” besökarens e-postadress?

Det vanligaste egeninfliktade såret i formulärkonfigurering, och många plugins brukade göra det som standard: aviseringen kommer From: besökarens adress, så du kan trycka på svara. Det känns bekvämt, och det är förfalskning. Din server har ingen rätt att skicka e-post som [email protected] — det misslyckas med SPF och DKIM för gmail.com, och Gmails DMARC-policy ber mottagare att skräppost-sortera eller avvisa det. Fixen kostar ingenting:

From: en adress på din egna domän (SMTP-identiteten från steg 2)
Reply-To: besökarens adress — svar går fortfarande direkt till dem

Varje vanlig formulär-plugin stöder detta; det är två fält i aviseringsinställningarna.

Varför inte bara lägga till serverns IP i min SPF-post?

Det är fixen de flesta forum-trådar snabbt fastnar vid, och det är en sista utväg av en anledning. Att lägga till ip4:<server> (eller en a-mekanism för din webbvärd) i SPF gör att råkontroll godkänns — men:

På delad värdtjänst auktoriserar det obekanta. IP:n tillhör boxen, inte dig; alla andra webbplatser på den servern kan nu skicka SPF-godkänd e-post som din domän.
Det slutar fungera tyst. Värdar migrerar servrar och roterar IP:er utan att berätta för dig; din SPF fortsätter auktorisera en adress du lämnade för månader sedan.
Det ger dig ingen DKIM. SPF ensam slutar fungera under vidarebefordring och kan inte föra dig mot DMARC-tillämpning på samma sätt som en signatur kan.

Reservera denna väg för det genuint begränsade fallet: en dedikerad server med en statisk IP du kontrollerar och ett program som inte kan tala SMTP — och para det med DKIM-signering på boxen om du kan.

Kontrollerar SPF ens adressen mitt formulär sätter i “From”?

Nej — och detta snavar upp hälften av hemmagjorda diagnoser. Mottagare utvärderar SPF mot Return-Path (RFC5321.MailFrom)-domänen, inte From-rubriken. Webbservrar stämplar ofta sitt egna värdnamn på Return-Path, så din SPF-post rådfrågades aldrig alls — mottagaren kontrollerade SPF för srv0421.examplehost.com. Autentiserad SMTP åtgärdar detta också: Return-Path blir din domän, så SPF-godkännandet slutligen räknas för dig. Det är också varför DKIM spelar roll — DMARC-anpassning behöver ett godkännande knutet till domänen i From, och en DKIM-signatur följer med meddelandet.

Vanliga frågor

Kommer ett SMTP-plugin att åtgärda lösenordsåterställnings- och WooCommerce-e-post också? Ja. På WordPress flödar allt via wp_mail(), så att dirigera om det åtgärdar formuläraviseringar, lösenordsåterställningar och beställnings-e-post i ett svep.

Behöver jag fortfarande SPF- och DKIM-poster om jag använder ett SMTP-plugin? Ja — plugin-et ändrar vilken infrastruktur som skickar din e-post; posterna är det som auktoriserar den. Om din domän hör till de 46.4% av 261,086,232 graderade domäner utan SPF-post (censuset, 2026-06-29), räcker inte autentiserad SMTP ensam. Checklistan för ny domän-e-post täcker den fullständiga postuppsättningen.

Min formulär-e-post godkänns med SPF men misslyckas fortfarande med DMARC — varför? Nästan alltid From-förfalskningsantimönstret ovan, eller SPF som godkänns för värdens Return-Path-domän snarare än din. Åtgärda From/Reply-To först; om det fortfarande misslyckas är den saknade pusselbiten en anpassad DKIM-signatur — se “DKIM-signatur inte giltig”. Om SaaS-verktyg bortom webbplatsen också misslyckas täcker guiden SPF-misslyckas-för-SaaS fixordningen.

Är det värt allt detta för ett lågtrafikerat kontaktformulär? Formuläret är vanligtvis där pengarna kommer in — en missad förfrågan är en kund du aldrig visste att du förlorade. Och fixen är gratis; hindret är att veta att webbservern var den oautentiserade avsändaren hela tiden.

Skicka ägaren rapporten

Om du är utvecklaren eller konsulten som åtgärdar detta: när testinlämningen godkänns, kör om den kostnadsfria sökningen och vidarebefordra den graderade rapporten till webbplatsens ägare — ett daterat, klarspråkigt protokoll om att domänen autentiserar korrekt, och den artefakt de behöver vid nästa cyberförsäkringsförnyelse eller kundsäkerhetsenkät. Om du är ägaren som läser detta för att förfrågningar slutade anlända: skicka den här sidan och din sökrapport till den som driver din webbplats — ett eftermiddagsarbete med ett före-och-efter de kan visa dig.

Kontrollera din domän → · SPF misslyckas för dina SaaS-verktyg? → · Åtgärda SPF → · Hur vi graderar → · Enbart aggregerade data. Data lagras och behandlas inom EU.