SPF-fout oplossen: foutcodes, oorzaken en DNS-herstel

Uw e-mail is teruggestuurd. In de headers staat spf=fail. U kijkt tegen een 550 5.7.1 of 550 5.7.26 aan, terwijl een klant wacht op een antwoord dat nooit is aangekomen.

Een SPF-fout is geen inhoudsprobleem. Het is een DNS-authenticatiefout. De ontvangende mailserver controleerde uw SPF-record, zag dat het verzendende IP-adres niet op de lijst met toegestane adressen stond en weigerde het bericht voordat het ooit een spammap bereikte.

Sinds februari 2024 kunnen Google en Yahoo niet-geauthenticeerde e-mail op protocolniveau weigeren in plaats van die alleen als verdacht te markeren. Deze gids verklaart de specifieke foutcode die u ziet, laat zien waar u het geweigerde IP-adres in de headers vindt en behandelt de drie DNS-oplossingen die het overgrote deel van de SPF-fouten verhelpen. U hoeft niet te gissen: begin meteen met de passende oplossing.

Als u voor het eerst e-mail op uw domein instelt, zorg dan voor een juiste basisconfiguratie van DNS voordat u fouten gaat onderzoeken. SPF-problemen komen vaak voort uit een onvolledige eerste configuratie.

Wat is een SPF-fout?

Een SPF-fout ontstaat wanneer een ontvangende mailserver het Sender Policy Framework-record van uw domein beoordeelt en vaststelt dat het verzendende IP-adres niet als toegestaan is vermeld. SPF wordt als DNS TXT-record op uw domein gepubliceerd en vermeldt elk IP-adres en elke maildienst die namens u e-mail mag verzenden. Als de controle mislukt, weigert de server het bericht direct (hard fail) of accepteert deze het als verdacht (soft fail). In beide gevallen telt uw DMARC-beleid dit als een mislukte controle.

SPF controleert de envelope sender: het MAIL FROM-adres dat tijdens de SMTP-handshake wordt uitgewisseld, niet de herkenbare "From"-header die uw ontvanger ziet. Dat verschil is belangrijk wanneer u de fout opspoort.

Lees de foutcode voordat u iets wijzigt

Verschillende mailservers geven verschillende SMTP-codes terug voor een SPF-fout. De foutcode vertelt wat de ontvanger heeft besloten en waarom. Als u een 550 5.7.26 hetzelfde behandelt als een algemene 550 5.7.1, verliest u tijd bij de diagnose. Koppel de code aan de oorzaak voordat u ook maar één DNS-record aanraakt.

Stap 1: vind het geweigerde IP-adres in uw headers

Gis niet welk IP-adres de SPF-fout veroorzaakte. Open de ruwe headers van het teruggestuurde bericht of van de bounce-melding en zoek naar Authentication-Results. Deze header geeft het precieze IP-adres dat de ontvanger heeft beoordeeld en de genomen beslissing.

Authentication-Results: mx.google.com;
   spf=fail (google.com: domain of team@example.com does not designate
   192.0.2.55 as permitted sender)

Twee forensische gegevens staan daar direct: het verzendende IP-adres (192.0.2.55) en het gecontroleerde domein (example.com). Bepaal nu wie eigenaar is van dat IP-adres:

• Een SaaS-tool die u onlangs hebt toegevoegd? (HubSpot, Zendesk, Shopify)
• Uw webserver? (WordPress, cPanel)
• Een mailforwarder? (Zie het gedeelte over de forwardingval hieronder)

Controleer vervolgens uw huidige SPF-record met een snelle lookup:

dig +short txt yourdomain.com | grep spf

Als u meer dan één regel ziet die begint met v=spf1, hebt u al een van de problemen gevonden.

Stap 2: de drie meest voorkomende oplossingen voor SPF-fouten

De meeste SPF-fouten hebben een van drie hoofdoorzaken: een ontbrekende include voor een leverancier, een dubbel record of overschrijding van de limiet van 10 DNS-lookups. Kies de oplossing die past bij wat u in stap 1 hebt gevonden.

Oplossing 1: de ontbrekende include (leverancier ontbreekt)

U hebt een nieuwe e-mailtool toegevoegd - HelpScout, HubSpot, Zendesk of transactionele e-mail van Shopify - maar uw DNS niet bijgewerkt. De dienst verzendt namens u vanaf een IP-adres dat u niet hebt toegestaan. Dit is een zeer gebruikelijke oorzaak van een SPF-fout nadat een nieuwe leverancier is toegevoegd.

Record dat faalt:

v=spf1 include:spf.trekmail.net -all

Record dat slaagt (na toevoeging van HelpScout):

v=spf1 include:spf.trekmail.net include:helpscoutemail.com -all

Zoek de vereiste SPF-include van uw leverancier in de documentatie. Voeg deze toe aan uw bestaande SPF TXT-record en maak geen nieuw record. Elke dienst waarmee u verzendt, moet worden vermeld.

Oplossing 2: het dubbele record (fatale syntaxisfout)

U mag maar één SPF-record per domein hebben. Als u voor een nieuwe tool een tweede TXT-record toevoegt in plaats van dit met het bestaande record samen te voegen, zien ontvangers twee tegenstrijdige beleidsregels en verklaren ze beide ongeldig. Het resultaat is een PermError: een harde SPF-fout voor elke e-mail vanaf uw domein, ook voor mail die daarvoor probleemloos werd afgeleverd.

Onjuist - twee afzonderlijke records:

v=spf1 include:spf.trekmail.net -all
v=spf1 include:_spf.google.com -all

Juist - samengevoegd tot één record:

v=spf1 include:spf.trekmail.net include:_spf.google.com -all

Log in bij uw DNS-provider, verwijder alle SPF TXT-records op één na en voeg alles samen op één regel. Een PermError door een dubbel record veroorzaakt voor alle afzenders ongemerkt een SPF-fout totdat u dit herstelt.

Oplossing 3: de limiet van 10 lookups (architectuurfout)

RFC 7208 beperkt de SPF-beoordeling tot 10 DNS-lookups. Dit voorkomt dat servers als vector voor DNS-versterking worden gebruikt. Mechanismen zoals include, a en mx tellen elk mee voor de limiet. Geneste includes, waarbij uw leverancier het record van een andere leverancier opneemt, tellen ook mee.

Bij meer dan 10 lookups krijgt u PermError. SPF faalt dan voor iedereen. Controleer het huidige aantal lookups door uw record te volgen:

dig +short txt yourdomain.com

Tel handmatig elk mechanisme include, a en mx en volg daarna de geneste includes voor elke leverancier. Als u boven de limiet zit, zijn er twee heldere benaderingen:

1. Verdeel afzenders over subdomeinen. Verplaats marketingtools met een hoog volume naar marketing.yourdomain.com. Dat subdomein krijgt een eigen nieuwe limiet van 10 lookups, volledig gescheiden van het record van uw hoofddomein.
2. Maak uw record vlak. Vervang ketens met include door de daadwerkelijke IP-adressen waarnaar ze verwijzen, met mechanismen als ip4: of ip6:. Deze tellen niet als lookup. Nadeel: u moet het record handmatig bijwerken wanneer leveranciers IP-adressen wijzigen.

Nog een valkuil is de limiet voor lege lookups. Als meer dan twee lookups in uw keten NXDOMAIN teruggeven - bijvoorbeeld door een typefout zoals include:spf.gogle.com - wordt uw record volgens RFC 7208 §11.1 ongeldig. Eén typefout ergens in de geneste includes van leveranciers kan de volledige SPF-beoordeling laten mislukken.

De forwardingval: waarom SPF faalt bij legitieme mail

De volgende SPF-fout heeft niets met uw DNS-configuratie te maken. U verzendt een e-mail naar een alumni-adres (alice@university.edu), dat automatisch doorstuurt naar Gmail (alice@gmail.com). Gmail ziet de e-mail aankomen vanaf het server-IP van de universiteit. Uw SPF-record staat dat IP-adres niet toe. De SPF-controle faalt, hoewel u alles juist hebt gedaan.

Het pad: uw server → server van universiteit → Gmail. De controle: Gmail beoordeelt de laatste stap. U kunt forwardingfouten niet met SPF oplossen, omdat SPF alleen het oorspronkelijke verzendende IP-adres toestaat. Zodra een forwarder tussenbeide komt, werkt de IP-controle niet meer.

De juiste oplossing is DKIM. DKIM ondertekent de berichtinhoud en headers cryptografisch. De forwarder wijzigt de inhoud doorgaans niet, zodat de DKIM-handtekening de relaystap overleeft. Zelfs als SPF faalt, kan een geldige DKIM-handtekening uw bericht onder DMARC geldig houden.

Als u forwarding op infrastructuurniveau uitvoert en SPF-compatibele herschrijvingen wilt, is het nuttig om het Sender Rewriting Scheme (SRS) te begrijpen. Daarmee kunnen forwarders de envelope sender herschrijven, zodat SPF op de eindbestemming slaagt. Voor bredere afleverproblemen met forwarding behandelt de gids voor het instellen en herstellen van e-mailforwarding het volledige diagnosetraject.

Controleer de oplossing voordat u verdergaat

Wacht na het bijwerken van uw DNS-record op propagatie. Bij de meeste providers duurt dit doorgaans 5 tot 30 minuten, maar in sommige uitzonderingen kan het enkele uren duren. Controleer daarna of de oplossing werkelijk is doorgevoerd voordat u het werk als voltooid beschouwt.

Verzend een testmail naar een Gmail-adres en open de ruwe headers. Zoek naar Authentication-Results. U wilt dit zien:

Authentication-Results: mx.google.com;
   spf=pass (google.com: domain of team@example.com designates
   192.0.2.55 as permitted sender)

Als u nog steeds spf=fail of spf=softfail ziet, is de oplossing nog niet gepropageerd of bevat uw record nog een probleem. Vergelijk het IP-adres in de headers met uw bijgewerkte record. Ze moeten overeenkomen.

U kunt het record ook rechtstreeks controleren:

dig +short txt yourdomain.com

Bevestig dat er precies één record is dat begint met v=spf1, dat al uw verzenddiensten zijn opgenomen en dat het record eindigt met -all (hard fail) of ~all (soft fail).

SPF beheren voor meerdere domeinen

Voor één domein is SPF-beheer een eenmalige taak. Voeg uw includes toe, voeg dubbele records samen en herstel het aantal lookups. Maar als u e-mail beheert voor 10, 50 of 500 domeinen, elk met een eigen SPF-record en een eigen verzameling SaaS-leveranciers, wordt het handmatig onderzoeken van elke SPF-fout een aanzienlijke operationele last.

De beheerde SMTP van TrekMail - beschikbaar vanaf Starter voor $3.50/maand - beperkt dit tot één include per domein. TrekMail verzorgt IP-rotatie, controle op bounces, DKIM-uitlijning en de onderliggende afleverinfrastructuur. Bureaus met het Agency-abonnement ($23.25/maand) kunnen één gestandaardiseerd DNS-sjabloon op alle klantdomeinen toepassen, in plaats van SPF-fouten in honderden afzonderlijke records na te lopen.

Start een gratis proefperiode van 14 dagen als u beheerde aflevering in de praktijk wilt bekijken.

SPF-fout: de korte versie

Een SPF-fout betekent dat de ontvangende server uw DNS heeft gecontroleerd, zag dat het verzendende IP-adres niet was vermeld en uw beleid heeft toegepast. Hard fail (-all) betekent weigering. Soft fail (~all) betekent de spammap. PermError betekent dat uw record ongeldig is en SPF voor elke afzender faalt totdat u het record zelf herstelt.

Werk de oplossingen in deze volgorde af:

1. Zoek het geweigerde IP-adres in de header Authentication-Results
2. Voeg de ontbrekende include van de leverancier toe als een nieuwe dienst de SPF-fout veroorzaakte
3. Voeg dubbele SPF-records samen tot één record
4. Breng het aantal DNS-lookups onder 10 of verdeel afzenders met een hoog volume over subdomeinen
5. Als SPF faalt bij doorgestuurde mail, implementeer dan DKIM. SPF overleeft een relaystap niet

Pas eerst de juiste oplossing toe, controleer die via de headers en rond het werk af.