Så integrerar du Ungapped säkert i din IT‑miljö – från DNS till dataskydd

Integrera Ungapped säkert utan att tappa fart

När marknadsavdelningen behöver skicka målinriktade kampanjer, välkomstserier och nyhetsbrev i stor skala, ställs krav på snabb lansering, hög leveransbarhet och detaljerad spårning av mottagarbeteende. För IT-chefen och dataskyddsombudet innebär samma projekt ett komplext pussel av domänautentisering, nätverkssäkerhet, identitetshantering och efterlevnad av dataskyddsförordningen. Att integrera en marknadsplattform som Ungapped kräver därför en strukturerad strategi där marknadens behov översätts till tydliga tekniska och juridiska krav – utan att varken hastighet eller säkerhet offras.

En fullständig integration berör långt mer än att bara öppna ett konto och börja skicka e-post. Domäner och DNS-poster måste konfigureras för SPF, DKIM och DMARC så att mottagande servrar kan autentisera avsändaren och skydda mot spoofing. Spårningsdomäner och eventuellt dedikerade IP-adresser påverkar både rykte och mätbarhet. Nätverket behöver säkras med utgående kontroller, TLS-kryptering och eventuellt IP-tillitslistor, medan åtkomst till plattformen helst styrs via SSO och rollbaserade behörigheter. API:er och webhooks kräver design för säkerhet, återförsök och integration med SIEM eller logganalysverktyg. Dataskyddsaspekter som rättslig grund, dataminimering, lagringstider och incidenthantering måste dokumenteras i avtal och rutiner. Slutligen ska driftsäkerhet säkras genom redundanta vägar, tydliga SLA:er och koppling till automationsplattformar som kan hantera köer och fel.

Den här guiden ger dig konkreta svar på dessa frågor och visar hur du bygger en integration som uppfyller både marknadens behov av hastighet och IT:s krav på säkerhet och kontroll. Du får:

• Tydliga definitioner av grundbegrepp som SPF, DKIM, DMARC, spårnings-CNAME och dedikerad IP, förklarade på klar svenska
• En steg-för-steg-plan för DNS-konfiguration, policyutrullning, nätverkssäkring, loggning och dataskydd
• Checklistor för varje fas som hjälper dig säkerställa att inget viktigt steg missas
• KPI:er som kopplar tekniska mått som auth-alignment, API-latens och webhook-fördröjning till affärsnytta som leveransgrad och klagomålsfrekvens

Grundbegrepp och målarkitektur för säker leverans

För att förstå vad som ska integreras behöver vi först klargöra kärnkomponenterna i en trygg Ungapped-integration. I centrum står avsändarautentisering, där plattformen skickar e-post för din organisations räkning och mottagande servrar måste kunna verifiera att utskicket är legitimt. Detta görs genom tre kompletterande mekanismer: SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) och DMARC (Domain-based Message Authentication, Reporting and Conformance). SPF listar vilka IP-adresser som får skicka e-post från din domän och kontrolleras mot MAIL FROM-adressen. DKIM signerar varje meddelande digitalt med en privat nyckel och mottagaren verifierar signaturen mot en offentlig nyckel publicerad i DNS. DMARC bygger vidare på SPF och DKIM genom att kräva att minst en av dem lyckas autentisera och att avsändardomänen i From-fältet stämmer överens med den domän som autentiserades (detta kallas alignment). DMARC låter dig också ange en policy för hur mottagaren ska hantera meddelanden som misslyckas med autentiseringen – antingen leverera ändå (p=none), karantän (p=quarantine) eller avvisa (p=reject).

Utöver autentisering måste du bestämma hur spårning ska hanteras. När mottagare klickar på länkar i utskicket omdirigeras de vanligtvis via en spårningsdomän för att logga händelsen. Denna domän konfigureras som en CNAME-post i DNS som pekar på plattformens infrastruktur. Om du använder en subdomän för spårning (till exempel track.dindomän.se) isoleras ryktet för utskick från din huvuddomän. Vissa organisationer väljer också dedikerad IP-adress för att ha full kontroll över avsändarryktet och undvika att dela IP-rykte med andra kunder på plattformen. Dedikerad IP kräver dock planerad uppvärmning (gradvis ökning av volym) och kontinuerlig övervakning för att undvika blacklistning.

Slutligen behöver du säkerställa att åtkomst till plattformen sker säkert och spårbart. API:er och webhooks ska autentiseras med token eller signaturer, och användaråtkomst ska helst styras via SSO (Single Sign-On) med SAML för att centralisera identitetshantering och minska antalet lösenord. Rollbaserad åtkomst (RBAC) ser till att marknadspersonal, utvecklare och administratörer bara får de behörigheter de faktiskt behöver. Tabellen nedan sammanfattar de centrala komponenterna:

För fördjupning om hur DMARC samspelar med SPF och DKIM och hur du kan övervaka autentiseringsresultat rekommenderas Microsofts stegvisa vägledning för DMARC-införande i moderna miljöer, som täcker allt från grundläggande DNS-konfiguration till tolkning av aggregerade och forensiska rapporter.

DNS och avsändarautentisering steg för steg

När grundkomponenterna är kartlagda är nästa steg att faktiskt konfigurera DNS-posterna i rätt ordning. Rekommenderad arbetsgång är att börja med SPF och DKIM, sedan lägga till DMARC i monitoring-läge (p=none) för att samla data, och slutligen trappa upp policyn gradvis till quarantine och reject när autentiseringen är stabil. Här är en praktisk ordning att följa:

1. Bestäm vilken eller vilka underdomäner som ska användas för utskick (till exempel newsletter.dindomän.se) och spårning (track.dindomän.se).
2. Lägg till SPF-post för utskicksdomänen som inkluderar plattformens SPF-definition (till exempel ”v=spf1 include:_spf.ungapped.com ~all”).
3. Generera DKIM-nyckelpar i plattformen och publicera den offentliga nyckeln som en TXT-post i DNS (till exempel ungapped._domainkey.newsletter.dindomän.se).
4. Skapa en DMARC-post för basdomänen (eller underdomänen om du vill ha separata policyer) med p=none och rapportadresser (rua och ruf) så att du börjar få aggregerade och forensiska rapporter.
5. Konfigurera spårnings-CNAME så att track.dindomän.se pekar på plattformens spårningsserver (till exempel track.ungapped.com).
6. Övervaka DMARC-rapporter i några veckor för att identifiera alla legitima källor som skickar e-post från din domän och säkerställ att de autentiserar korrekt.
7. När autentiseringsgraden är hög (över 95 % lyckat SPF- eller DKIM-alignment), ändra DMARC-policyn till p=quarantine och fortsätt övervaka.
8. Efter ytterligare en period med stabil autentisering, uppdatera till p=reject för att avvisa meddelanden som misslyckas med autentiseringen.

Det är viktigt att inte hoppa direkt till p=reject, eftersom det kan leda till att legitim e-post från tredje part (till exempel externa system som skickar för din räkning) blockeras om de inte autentiserar korrekt. En gradvis policyresa med övervakning ger dig tid att identifiera och åtgärda problem innan du genomdriver full avvisning. En detaljerad guide för denna övergång finns i Redsifts omfattande DMARC-implementeringsguide, som beskriver en sexstegsprocess från audit till kontinuerlig övervakning.

Om din organisation skickar stora volymer eller har särskilda krav på avsändarrykte kan en dedikerad IP-adress vara motiverad. Dedikerad IP ger full kontroll över ryktet eftersom ingen annan kund på plattformen delar samma IP, men den kommer också med ansvar. En ny IP har inget rykte alls och måste värmas upp genom att gradvis öka utskicksvolymen över flera veckor – börja med några tusen meddelanden om dagen till engagerade mottagare och öka långsamt. Segmentera mottagarna så att de mest engagerade får mejl först, vilket bygger positivt rykte snabbare. Om volymen är ojämn (till exempel kampanjer bara vissa veckor) kan dedikerad IP vara svår att underhålla, eftersom långa perioder utan utskick kan leda till att ryktet försvagas.

Slutligen måste du säkerställa att konfigurationen uppfyller kraven från stora mottagare. Både Google och Yahoo har uppdaterat sina riktlinjer för bulkavsändare (över 5 000 meddelanden per dag till Gmail- eller Yahoo-adresser). Dessa krav inkluderar giltigt SPF och DKIM, DMARC-policy på basdomänen, korrekt forward- och reverse-DNS för IP-adresser, samt enkel avregistreringsmekanism (List-Unsubscribe-header och helst one-click unsubscribe). Säkerställ att de tekniska förutsättningarna är på plats både i er DNS-miljö och att ni följer Googles uppdaterade riktlinjer för e-postavsändare, som specificerar autentisering, TLS, och krav på avregistrering.

Nätverk, åtkomst och identitet i er miljö

När DNS och autentisering är klart måste du säkra nätverksanslutningarna mellan din miljö och Ungapped som en extern SaaS-plattform. Eftersom plattformen är molnbaserad sker kommunikationen över internet, men det finns flera åtgärder som höjer säkerheten och prestandan. Utgående egress-kontroll innebär att ni konfigurerar brandväggar så att bara godkända destinationer och portar tillåts – typiskt HTTPS (port 443) till plattformens API-endpoints och SMTP (port 587 eller 25) om ni skickar via plattformens SMTP-relay. TLS-kryptering ska alltid användas för både API-anrop och e-postöverföring för att skydda data i transit. Om plattformen erbjuder IP-tillitslistor kan ni begränsa inkommande webhook-trafik till endast kända IP-block, vilket minskar risken för förfalskade händelser.

För prestanda och tillgänglighet kan SD-WAN (Software-Defined Wide Area Network) hjälpa till att styra trafik intelligent över several internetuppkopplingar och prioritera kritisk trafik som API-anrop och webhook-leveranser. SD-WAN kan också mäta latens och paketverlust kontinuerligt och växla över till en backup-koppling om primär väg försämras. Om ni vill fördjupa er i hur SD-WAN kan stärka säkerheten och prestandan till SaaS-tjänster, se vår artikel om säker och optimerad uppkoppling till SaaS-tjänster med SD-WAN.

Åtkomst till plattformen bör styras centralt via SSO med SAML-federation mot er befintliga Identity Provider (IdP), till exempel Azure AD, Okta eller ADFS. Detta ger flera fördelar: användare loggar in med sitt vanliga företagskonto och behöver inte hantera ett separat lösenord, onboarding och offboarding sker automatiskt när konton skapas eller tas bort i IdP, och ni kan framtvinga multifaktorautentisering (MFA) centralt. Inom plattformen ska rollbaserad åtkomst (RBAC) konfigureras så att marknadsförare kan skapa och skicka kampanjer, analytiker kan visa rapporter men inte redigera, och administratörer kan hantera domäner och integrationsinställningar. Webhook-mottagare bör placeras bakom en lastbalanserare och Web Application Firewall (WAF) för att hantera hög last vid stora kampanjer och skydda mot skadlig trafik. Webhook-hanterare ska designas med idempotens i åtanke – samma händelse kan skickas flera gånger vid återförsök, och hanteraren måste kunna identifiera dubbletter. En kö- eller meddelandebaserad arkitektur (till exempel RabbitMQ, Azure Service Bus eller AWS SQS) gör det möjligt att buffra händelser och hantera dem asynkront, vilket minskar risken för tappade meddelanden vid toppar eller tillfälliga fel.

Loggning, webhooks och koppling till SIEM som driver rätt KPI:er

För att få insyn i utskickens beteende och kunna agera på problem i realtid behöver relevanta händelser loggas och skickas vidare till er SIEM-lösning (Security Information and Event Management) eller logganalysverktyg. Vilka händelser är viktiga att logga? Grunden är leveransstatus för varje meddelande: lyckad leverans (delivered), permanent studs (hard bounce), tillfällig studs (soft bounce), blockering av mottagare (blocked) och klagomål (complaint/feedback loop). Dessa händelser ger information om leveransbarhet och rykte. Utöver det kan beteendehändelser vara värdefulla för marknadsföring och analys: öppningar (open), klick (click) och avregistreringar (unsubscribe). Alla dessa händelser ska kopplas till en unik meddelande-ID och kampanj-ID så att de kan spåras och analyseras i sammanhang.

Webhook-design ska prioritera säkerhet och tillförlitlighet. Plattformen ska signera varje webhook-anrop med en hemlig nyckel (HMAC-signatur) som mottagaren verifierar innan händelsen behandlas. Detta förhindrar att obehöriga kan skicka förfalskade händelser. Om webhook-mottagaren inte svarar eller returnerar ett felmeddelande ska plattformen försöka igen automatiskt med exponentiell backoff – till exempel efter 1 minut, 5 minuter, 15 minuter och så vidare. Efter ett visst antal misslyckade försök ska händelsen placeras i en dead-letter queue (DLQ) för manuell granskning så att den inte försvinner helt. Inom mottagaren ska händelser mappas till SIEM-fält enligt er befintliga struktur, till exempel:

1. event_type (delivered, bounce, complaint, etc.)
2. timestamp (ISO 8601-format med tidszon)
3. message_id (unik identifierare för meddelandet)
4. campaign_id (kampanj eller utskicksserie)
5. recipient_email (mottagaradress, krypterad eller hashad om känslig)
6. status_detail (felkod eller beskrivning vid bounce/block)
7. source_ip (plattformens IP för verifiering)

SIEM-larm ska konfigureras för att varna om avvikelser, till exempel plötslig ökning av bounce-frekvens (kan indikera dålig listkvalitet eller blockeringar), ovanligt många klagomål (risk för rykteskada eller blacklistning), eller upprepad autentiseringsfel i DMARC-rapporter (möjlig spoofing-attack). Dessa larm möjliggör snabb åtgärd innan problemen påverkar ryktet eller efterlevnaden allvarligt.

För att mäta framgång behöver ni ett KPI-ramverk som kopplar tekniska mått till affärsnytta. Här är ett förslag på centrala KPI:er och vad de berättar:

Genom att spåra dessa KPI:er över tid kan ni identifiera trender och ingripa proaktivt. För en bredare checklista kring leveransbarhet och hantering av bounces och klagomål, se Twilios praktiska sammanställning av bästa praxis för e-post marknadsföring 2025, som täcker allt från listhygien till optimala tidpunkter för utskick.

Dataskydd, rättslig grund och hållbar utskickshygien

GDPR ställer tydliga krav på hur personuppgifter får behandlas i samband med e-postmarknadsföring och nyhetsbrev. Innan något utskick sker måste organisationen kunna peka på en rättslig grund för behandlingen av e-postadresser och annan persondata. De vanligaste grunderna är samtycke och berättigat intresse. Samtycke innebär att mottagaren aktivt har gett sitt godkännande för att ta emot marknadsföring, vanligtvis genom att kryssa i en ruta eller fylla i ett formulär. Samtycke måste vara frivilligt, specifikt, informerat och otvetydigt, och kan när som helst återkallas. För offentliga myndigheter är samtycke sällan lämpligt som grund, eftersom relationen mellan myndighet och medborgare inte är jämbördig – det finns en otydlig maktbalans som gör det svårt att avgöra om samtycket är verkligt frivilligt. I sådana fall är berättigat intresse ofta en mer adekvat grund, förutsatt att myndighetens intresse av att informera väger tyngre än individens integritetsskydd och att mottagaren har fått tydlig information och möjlighet att invända.

Oavsett vilken rättslig grund som används har mottagaren alltid en absolut rätt att invända mot direktmarknadsföring. När en invändning görs får personuppgifterna inte längre behandlas för det ändamålet. Detta krav gäller även när rättslig grund är berättigat intresse – invändningen måste respekteras omedelbart. Praktiskt innebär det att varje utskick måste innehålla en enkel och tydlig avregistreringsmekanism, helst en one-click unsubscribe-länk som mottagaren kan använda utan att behöva logga in eller fylla i formulär. Tekniskt implementeras detta ofta genom List-Unsubscribe-header i e-postmeddelandets metadata, som Gmail och andra klienter kan visa som en ”Avregistrera”-knapp direkt i inkorgen. Integritetsskyddsmyndigheten (IMY) har tydlig vägledning om samtycke som rättslig grund enligt GDPR och vad som krävs för att samtycke ska vara giltigt. För information om hur mottagare kan utöva sina rättigheter, se IMY:s förklaring av hur man avregistrerar sig från nyhetsbrev.

För att säkerställa god datahygien och efterlevnad i praktiken, följ denna checklista:

• Dataminimering: Samla bara in de fält som är nödvändiga för utskicket – namn och e-postadress är ofta tillräckligt.
• Lagringstid: Definiera hur länge uppgifter ska lagras och radera dem automatiskt när syftet är uppfyllt eller samtycke återkallas.
• Behörigheter: Begränsa åtkomst till kontaktlistor till de medarbetare som faktiskt behöver dem för sina arbetsuppgifter.
• Incidentprocess: Ha en dokumenterad rutin för hur personuppgiftsincidenter (dataläckor) ska hanteras, rapporteras till IMY inom 72 timmar vid behov, och kommuniceras till berörda.
• Personuppgiftsbiträdesavtal (PuB): Säkerställ att ett skriftligt avtal finns med plattformsleverantören som personuppgiftsbiträde, där ansvar och säkerhetsåtgärder specificeras.
• Informationsskyldighet: Se till att mottagare får tydlig information om vilka uppgifter som behandlas, varför, hur länge, och hur de kan utöva sina rättigheter (access, rättelse, radering, begränsning, dataportabilitet).

Hållbar utskickshygien innebär också att regelbundet rensa listor från inaktiva kontakter, hålla bounce-hantering aktiv så att ogiltiga adresser tas bort automatiskt, och respektera avregistreringar omedelbart. En lista med hög engagemang (många öppningar och klick) ger bättre leveransbarhet än en stor lista med låg aktivitet. Det är bättre att skicka till 10 000 engagerade mottagare än till 50 000 där majoriteten aldrig öppnar mejlen – de senare skadar ryktet och ökar risken för klagomål.

Tillgänglighet, redundans och driftbarhet i produktion

När integrationen är live måste den vara driftsäker och redundant för att hantera hög belastning, nätverksproblem och eventuella avbrott i plattformen. Hög tillgänglighet för e-postutskick börjar med DNS-redundans – se till att DNS-servrar för era domäner är geografiskt distribuerade och att TTL-värden (Time To Live) är balanserade mellan snabb uppdatering och motståndskraft mot DNS-tjänststörningar. För nätverksvägar bör ni ha minst två oberoende internetuppkopplingar från olika operatörer så att trafik kan växla om primär väg faller bort. SD-WAN kan automatisera denna växling och övervaka länkhälsa kontinuerligt.

Övervakning av utskicksflödet ska inkludera både tekniska mått (API-tillgänglighet, svarstider, webhook-latens) och affärsmått (antal skickade meddelanden, leveransgrad, bounce-frekvens). Konfigurera larm som varnar om API-latens överstiger tröskelvärden, webhook-fördröjningar blir ovanligt långa, eller om bounce-frekvensen ökar plötsligt. Kvoter och hastighetsbegränsningar (rate limits) på API-nivå hjälper till att förhindra att en felaktig integration överbelastar systemet – konfigurera dessa tillsammans med leverantören och ha en strategi för backoff och återförsök när kvoter nås.

SLA-frågor att ställa till leverantören inkluderar garanterad tillgänglighet (till exempel 99,9 % uptime), maximal API-latens under normal belastning, hur länge det tar att leverera webhook-händelser, och vilka maintenance-fönster som planeras. Fråga också om hur incidenter eskaleras och kommuniceras – finns det en statusida ni kan prenumerera på, och vad är förväntad svarstid vid kritiska fel? Ha en plan för hur er organisation hanterar planerade maintenance-fönster (kan ni schemalägga utskick runt dem?) och oplanerade avbrott (finns backup-lösning eller kan utskick köas och skickas senare?).

För robusta flöden mellan system bör ni koppla utskick till en central automationsplattform som kan hantera arbetsflöden, köer och återförsök över flera tjänster. En sådan plattform kan till exempel ta emot händelser från CRM, filtrera och berika data, anropa Ungapped-API för att skapa utskick, ta emot webhooks med resultat, och uppdatera CRM eller datawarehouse. Genom att ha tydliga dead-letter-strategier och loggar kan ni spåra varje meddelande genom hela flödet och felsöka när något går fel. För vägledning om hur ni bygger en robust automationsplattform som kopplar system och arbetsflöden, se vår fördjupande artikel som täcker arkitekturmönster, köhantering och felhantering.

Så väljer ni väg mellan Ungapped med dedikerad IP och egen SMTP

När grunderna är på plats kan det vara aktuellt att överväga om ni ska fortsätta använda Ungappeds delade infrastruktur, uppgradera till dedikerad IP inom plattformen, eller till och med bygga en egen SMTP-lösning. Valet beror på era krav på kontroll, volym, spårbarhet och tillgängliga resurser. Tabellen nedan jämför alternativen:

Egen SMTP-server kan vara motiverad i vissa fall, till exempel om ni har mycket stora volymer (miljontals meddelanden per dag), extremt känsliga datakrav som inte tillåter tredje parts molntjänster, eller behov av helt anpassade protokoll och headers. Men att driva egen SMTP kommer med betydande risker och åtaganden: ni ansvarar helt för avsändarrykte och måste proaktivt övervaka blacklistor, hantera feedback loops från stora mottagare (Gmail, Yahoo, Outlook), säkerställa redundans och skalbarhet, samt underhålla säkerhetspatchar och konfiguration. En felkonfigurerad eller dåligt övervakad SMTP-server kan snabbt hamna på blacklistor och göra all utgående e-post obrukbar. Dessutom måste ni bygga eller köpa in egna verktyg för spårning, analys och rapportering – funktioner som redan finns inbyggda i en plattform som Ungapped.

Rekommendationen för de flesta svenska organisationer är att börja med delad IP inom plattformen och övergå till dedikerad IP om volymerna växer över 50 000–100 000 meddelanden per månad eller om ni behöver full kontroll över ryktet för en specifik domän. Egen SMTP-lösning bör endast övervägas om ni har dedikerad e-postinfrastrukturpersonal, mycket höga volymer, eller juridiska krav som omöjliggör molnbaserade lösningar. För att förstå de krav som måste uppfyllas oavsett val av lösning, se Klaviyos sammanfattning av kravbilden för stora avsändare enligt Google och Yahoo 2024, som täcker autentisering, avregistrering och klagomålströsklar.

Gör planen delbar och beslutsbar i er organisation

För att integrationen ska bli framgångsrik behöver marknad, IT och dataskydd arbeta tillsammans från start. Samla teamet och skapa ett beslutspaket som innehåller en enkel arkitekturskiss över hur komponenter kopplas ihop (DNS, API, webhooks, SIEM), en konkret DNS-plan med alla poster som ska läggas till och i vilken ordning, dokumenterade åtkomstrutiner för SSO och RBAC, samt ett KPI-dashboard som visar både tekniska och affärsmässiga mått i realtid. Detta paket gör det lätt för ledningen att fatta beslut baserat på faktiska förutsättningar och kostnader, och ger driftteamet en tydlig färdplan att följa.

Starta litet med en pilotdomän eller en begränsad målgrupp, till exempel ett internt nyhetsbrev eller en enskild kampanj till en mindre segment. Mät kontinuerligt mot de KPI:er ni definierat – leveransgrad, bounce-frekvens, DMARC-alignment, API-latens – och justera konfigurationen baserat på resultaten. När piloten är stabil och alla inblandade team är nöjda, rulla ut stegvis till fler domäner, större listor och fler affärsflöden. Dokumentera lärdomar längs vägen och uppdatera rutiner och checklistor baserat på vad ni upptäcker. Slutligen, säkra tydligt ägarskap för drift och efterlevnad. Vem ansvarar för att övervaka DMARC-rapporter varje vecka? Vem hanterar eskaleringar vid incidenter? Vem ser till att biträdesavtal förnyas och att nya medarbetare får rätt behörigheter? Genom att etablera dessa roller tidigt säkerställer ni att integrationen förblir trygg och efterlevs även när verksamheten växer och behoven förändras.