SPF:s gräns på 10 DNS-uppslag och hur ni håller er under den

Vad är en SPF-post?

SPF (Sender Policy Framework, RFC 7208) låter domänägaren publicera vilka servrar som får skicka e-post med domänen som kuvertavsändare, även kallad return path eller MAIL FROM. Mottagande servrar slår upp posten och jämför den med IP-adressen hos servern som ansluter.

Posten är en DNS-post av typen TXT direkt på domänen. Den börjar med v=spf1 och listar mekanismer som kontrolleras från vänster till höger. Den första som matchar avgör resultatet. En typisk post ser ut så här:

example.com. TXT "v=spf1 ip4:192.0.2.10 include:_spf.mailprovider.example mx -all"

Det får bara finnas en SPF-post per namn. Hittar mottagaren två TXT-poster som börjar med v=spf1 blir resultatet permerror. Varje sträng i en TXT-post får vara högst 255 tecken. En längre post delas upp i flera citerade strängar i samma TXT-post, och mottagaren slår ihop dem utan mellanslag.

Vilka SPF-mekanismer räknas mot gränsen?

RFC 7208 avsnitt 4.6.4 begränsar antalet termer som orsakar DNS-frågor till 10 per SPF-utvärdering. Följande räknas:

• include: varje include räknas som ett uppslag, och alla uppslag i den inkluderade posten räknas också.
• a: ett uppslag för A- eller AAAA-posten för det angivna namnet.
• mx: ett uppslag för MX-posterna. Adressuppslagen för varje MX-värd har en egen gräns på 10 per mx-mekanism.
• ptr: räknas som ett uppslag och bör inte användas alls.
• exists: ett uppslag.
• redirect: modifieraren redirect räknas som ett uppslag, och målpostens uppslag räknas också.

Mekanismerna ip4, ip6 och all kräver inga DNS-frågor och räknas därför inte. Modifieraren exp utvärderas bara efter fail och räknas inte heller mot gränsen.

Hur räknas nästlade include?

Gränsen gäller hela utvärderingen, inte bara er egen post. Om ni inkluderar en leverantör vars post i sin tur har tre include kostar den enda include-termen fyra uppslag. Stora leverantörer använder ofta flera nivåer, så en post med bara fyra eller fem include kan ändå passera 10.

Leverantörerna kan dessutom ändra sina poster när som helst. En post som låg på 9 uppslag förra månaden kan ligga på 11 i dag utan att ni har ändrat något. Kontrollera det totala antalet regelbundet, inte bara när ni ändrar posten.

Vad är gränsen för tomma uppslag?

Samma avsnitt i RFC 7208 inför en andra gräns. Ett tomt uppslag (void lookup) är en DNS-fråga som inte ger något svar, antingen NXDOMAIN eller ett tomt svar. Mottagare bör tillåta högst 2 tomma uppslag per utvärdering och därefter ge permerror.

Tomma uppslag kommer oftast från include- eller a-termer som pekar på namn som inte längre finns, till exempel en gammal leverantör eller en borttagen server. Tar ni bort inaktuella termer minskar både antalet tomma uppslag och det totala antalet uppslag.

Vad händer när SPF ger permerror?

Permerror betyder att posten inte kunde utvärderas korrekt. För många uppslag, för många tomma uppslag, två SPF-poster eller ett syntaxfel leder alla dit. Två poster eller ett syntaxfel gör att SPF slutar fungera för alla avsändare. Vid för många uppslag avbryts utvärderingen när gränsen nås, så alla avsändare som matchas efter den punkten får permerror, och vissa mottagare underkänner hela posten. Räkna inte med att tidiga träffar räddar er.

För DMARC räknas bara ett SPF-pass med en domän som är i linje. Permerror är inget pass, så DMARC hänger då helt på DKIM. Meddelanden med en giltig DKIM-signatur i linje passerar fortfarande DMARC. Meddelanden utan en sådan underkänns, och med p=quarantine eller p=reject kan de hamna i skräpposten eller avvisas.

Hur minskar jag antalet SPF-uppslag?

• Ta bort avsändare ni inte längre använder. Gamla nyhetsbrevsverktyg, CRM-system och testtjänster är vanliga rester.
• Ersätt a och mx med ip4 eller ip6 där ni själva styr adresserna och de sällan ändras, till exempel er egen e-postserver.
• Flytta avsändare till underdomäner. En marknadsföringsplattform kan skicka från news.example.com med en egen SPF-post, som har en egen gräns på 10.
• Förlita er på DKIM för avsändare som signerar med er domän. Signerar en tjänst med en DKIM-nyckel i linje kan DMARC passera utan att tjänsten finns i er SPF-post.
• Använd aldrig ptr. RFC 7208 avråder från den. Den är långsam, opålitlig och kostar uppslag.

Vissa tjänster erbjuder så kallad SPF-flattening: varje include byts ut mot de IP-adresser som leverantören använder just nu. Det minskar antalet uppslag, men leverantörer byter adresser utan förvarning. Om posten inte uppdateras automatiskt börjar legitim e-post att underkännas. Använder ni flattening, se till att posten hålls uppdaterad automatiskt och att ni får ett larm när den ändras.

DMARC Visions kostnadsfria kontroll av SPF-poster körs i webbläsaren och varnar för risk att överskrida gränsen innan ni publicerar posten.

Ska jag använda ~all eller -all?

Mekanismen all i slutet avgör vad som händer med servrar som inte finns med. -all ger fail, ~all ger softfail och ?all ger ett neutralt resultat, medan +all låter alla servrar på internet passera. Ingen av dem påverkar antalet uppslag.

-all är målet. Det är det tydligaste besked en domän kan ge: bara de listade servrarna skickar för den. ~all är ett rimligt steg medan ni fortfarande letar upp alla era avsändare, men det överlåter beslutet till varje mottagare, och därför markerar e-postsäkerhetskontrollen det som något som behöver åtgärdas. Använd aldrig +all eller ?all.

Gå över till -all när era DMARC-rapporter visar att alla legitima avsändare passerar, och helst när de avsändarna också signerar med DKIM i linje med er domän. Vissa mottagare avvisar vid SPF-fail innan de tittar på DKIM, och vidarebefordrad e-post är det som oftast drabbas.