Stop dobbeltbetaling: Erstat SendGrid med Microsoft 365 HVE

I betaler måske for SendGrid/Mailgun, mens jeres systemmails i praksis kun går til medarbejdere og få faste eksterne modtagere. Samtidig står der ofte et gammelt SMTP-relay eller en on-prem Exchange og “holder dampen oppe” til scannere og ERP. Med Microsoft 365 High Volume Email (HVE) kan I flytte den trafik ind i Exchange Online og få færre afsendere, færre fejl og enklere styring. Målet er konkret: opsig unødvendige SMTP-tjenester og luk de relays, der giver drift og sikkerhed hovedpine.

• Kortlæg afsendere (ERP, løn, scannere, alarmer) og flyt dem til ét endpoint: smtp-hve.office365.com (TLS påkrævet).
• Skær ned på SPF/DKIM-kompleksitet: færre tredjeparts-afsendere gør det lettere at håndhæve DMARC stramt.
• Brug HVE til “system-mails”: designet til intern LOB-trafik, ikke til marketing/bulk mod eksterne lister.
• Planlæg legacy uden panik: Basic Authentication understøttes på HVE-endpointet frem til september 2028 (til scannere/ældre apps).
• Undgå driftsoverraskelser: test 10MB mail-størrelsesgrænsen og 1 minuts TCP-timeout, før I skifter i produktion.

Hvorfor Microsoft 365 High Volume Email giver mening til systemmails

HVE er lavet til applikationer og enheder, der skal sende mange systemmails uden at belaste brugerpostkasser. Microsoft gjorde løsningen Generally Available (GA) 31. marts 2026, så I kan basere drift på den i stedet for preview-løsninger og hjemmelavede relays (kilde: Microsoft Tech Community, 2026).

For en typisk SMB handler gevinsten sjældent om “flere mails”. Den handler om at konsolidere afsendelse og få styr på governance:

• Én standard for TLS og afsenderidentitet.
• Færre steder at fejlsøge, når fakturaer eller adgangskoder ikke bliver leveret.
• En mere kontrolleret SPF/DKIM/DMARC-opsætning, fordi I reducerer antallet af udbydere, der må sende på vegne af jeres domæne.

Sådan ved I, om HVE kan erstatte SendGrid i jeres setup

Brug denne beslutningsregel: Hvis jeres systemmails primært går internt (medarbejdere) og kun sekundært til et begrænset antal eksterne (fx kunder der får faktura/ordrebekræftelse), så er HVE ofte relevant. Hvis I sender store kampagner eller høj volumen til mange eksterne modtagere, skal I kigge mod Azure-løsninger.

HVE’s hårde grænser, I skal designe efter

• Interne modtagere: op til 100.000 pr. dag pr. tenant (kilde: Microsoft Learn, 2026).
• Eksterne modtagere: 2.000 pr. dag (kilde: Microsoft Learn, 2026). Brug det som et stopskilt for “marketing/bulk”.
• Mailstørrelse: 10MB (kilde: C7 Solutions, 2026).
• TCP-timeout: 1 minut (kilde: C7 Solutions, 2026). Langsomme LOB-apps skal optimeres eller sende i mindre batches.
• Endpoint: smtp-hve.office365.com, port 587, TLS kræves (kilde: Microsoft Learn, 2026).
• Legacy: Basic Authentication understøttes på HVE-endpointet frem til september 2028 (kilde: Microsoft Exchange Blog, 2026).

Mikro “Før → Efter” #1
Før: En scanner sender via et on-prem SMTP-relay med åbne firewall-regler og ingen central kontrol.
Efter: Scanneren sender via HVE med TLS til Exchange Online. I kan dokumentere afsendervejen og lukke en server, der ellers kræver patching og overvågning.

Hvordan vælger I mellem HVE og Azure Communication Services

Hold det simpelt: HVE er til interne LOB- og driftsmails. Azure Communication Services (ACS) giver jer en anden model til eksterne masseudsendelser og kundekommunikation, hvor 2.000 eksterne modtagere/dag hurtigt bliver en stopper (kilde: Office 365 IT Pros, 2026).

Behov	Vælg HVE	Vælg ACS
IT-driftsmails, alarmer, ERP- og scanner-mails	Ja	Kun hvis I har særlige krav til ekstern skala
Mange eksterne modtagere (kampagner, marketing, store kundelister)	Nej (2.000 eksterne/dag er en hård grænse)	Ja
Stram domænekontrol og færre afsendere i SPF/DKIM/DMARC	Ja (konsoliderer systemmail i M365)	Afhænger af jeres domæneopsætning
Store vedhæftninger	Nej (10MB grænse)	Typisk bedre egnet end HVE til tung ekstern kommunikation

Tjekliste: Migrér fra SendGrid/SMTP-relay til Exchange Online SMTP relay med HVE

1. Lav et afsender-inventar (1 time): List alle systemer/enheder der sender mail. Notér: afsenderadresse, antal mails/dag, interne/eksterne modtagere, vedhæftninger, og om systemet kan TLS/OAuth.
2. Segmentér trafik:
   • Interne beskeder (adgangskoder, workflows, notifikationer) → HVE-kandidat.
   • Eksterne transaktionsmails (faktura, ordrebekræftelse) → HVE kun hvis I holder jer under 2.000 eksterne/dag.
   • Marketing/bulk → ikke HVE. Brug separat løsning (fx ACS) for at undgå limit- og deliverability-problemer.
3. Test mod HVE’s begrænsninger:
   • Send 10–20 realistiske mails med største vedhæftning: fejler noget over 10MB?
   • Simulér langsom app: rammer I 1 minuts timeout?
4. Plan for autentificering:
   • Kan systemet OAuth? Prioritér modern auth først.
   • Kan det kun Basic Auth? Brug HVE som bro, men sæt en udløbsdato før september 2028.
5. Stram domænepolitik: Når I udfaser tredjeparts-afsendere, ryd op i SPF og dokumentér DKIM/DMARC. Færre “include:” gør fejlfinding og håndhævelse lettere (kilde: CISA, 2026).
6. Cutover i batches: Flyt ét system ad gangen. Mål fejlrate, leveringshastighed og supporthenvendelser før næste batch.

Mikro “Før → Efter” #2
Før: SPF-recorden har mange tredjeparts-“includes”, og DMARC kan ikke sættes stramt uden at noget knækker.
Efter: I reducerer antallet af afsendere til få kontrollerede kilder (HVE + evt. én ekstern mailmotor). DMARC kan håndhæves mere konsekvent, og I bruger mindre tid på “hvem sender egentlig for os?”.

Fejl der koster driftstid, når I skifter til M365 HVE

1) ERP-fakturaer med store PDF’er

10MB-grænsen er lav nok til at nogle fakturaer, rapporter eller zip-filer fejler. Fix det praktisk: komprimér PDF’er, flyt tunge bilag til SharePoint-link, eller send bilag via anden kanal og lad mailen være en notifikation.

2) Apps der sender langsomt

1 minuts TCP-timeout betyder, at “send 5.000 mails i én session” kan gå galt i ældre kode. Ret det ved at sende i mindre batches, genbruge forbindelser korrekt, og indføre retry/backoff.

3) Forkert forventning til ekstern volumen

2.000 eksterne modtagere/dag er ikke en anbefaling. Det er en grænse. Hvis jeres forretning kræver mere til eksterne, så design med en separat mailmotor, så jeres interne systemmails ikke rammes af throttling.

FAQ om Microsoft 365 High Volume Email (HVE)

Hvad er Microsoft 365 High Volume Email?

En Exchange Online-funktion til at sende systemmails i høj volumen via et dedikeret SMTP-endpoint, uden at bruge almindelige brugerpostkasser til afsendelse (kilde: Microsoft Tech Community, 2026).

Kan HVE erstatte SendGrid?

Ja, for mange SMB-scenarier med interne systemmails og begrænset ekstern transaktionsmail. Hvis I sender kampagner eller har behov for høj ekstern volumen, så brug en løsning målrettet ekstern kommunikation (fx ACS) og hold HVE til drift/LOB.

Hvad er grænsen for mails i M365 HVE?

Tommelfingerregel: HVE er “stor nok” til intern trafik og “for lille” til ekstern bulk. Microsoft angiver op til 100.000 interne modtagere/dag og 2.000 eksterne modtagere/dag pr. tenant (Microsoft Learn, 2026).

Understøtter HVE eksterne modtagere?

Ja, men med en fast grænse på 2.000 eksterne modtagere pr. dag (Microsoft Learn, 2026). Planlæg jeres løsning, så eksterne kundelister ikke ligger på HVE, hvis I kan ramme loftet.

Hvordan opsættes HVE i Exchange Online rent praktisk?

Designreglen er enkel: brug endpointet smtp-hve.office365.com på port 587, og kræv TLS (Microsoft Learn, 2026). Start med én applikation i test, log fejl og justér batch-størrelser før I flytter næste afsender.

Kan vi blive på Basic Auth til scannere og gamle ERP-systemer?

På HVE-endpointet understøttes Basic Authentication frem til september 2028 (Microsoft Exchange Blog, 2026). Brug perioden til at udskifte/modernisere – og begræns risikoen imens med segmentering, stærke passwords og overvågning.

Hvordan påvirker HVE SPF/DKIM/DMARC?

HVE hjælper indirekte, fordi I kan fjerne tredjeparts-afsendere fra SPF og reducere antallet af systemer, der må sende på vegne af domænet. Færre afsendere gør DMARC-håndhævelse enklere og mindsker risikoen for domæne-spoofing (CISA, 2026). Hvis I har en stram DMARC-politik (fx p=reject), så test hver applikation efter migrering og hold øje med rapporter, før I slukker den gamle afsender.

Sådan kommer I i gang uden at forstyrre driften

1. Kortlæg alle systemafsendere og klassificér dem (intern, ekstern transaktion, bulk).
2. Vælg målaritektur: HVE til interne/LOB; separat løsning til ekstern bulk, hvis I kan ramme 2.000/dag.
3. Lav en testpakke pr. system: største vedhæftning, langsomste scenarie, og 20–50 realistiske modtagere.
4. Migrér i batches og mål fejlrate (timeouts, 10MB-fejl, autentificeringsfejl) før næste batch.
5. Ryd op i domæneopsætning: fjern gamle SPF-includes, dokumentér hvem der må sende, og stram DMARC gradvist.
6. Planlæg Basic Auth-udfasning med en intern deadline før september 2028 og en udskiftningsliste for legacy-enheder.

Relevante genveje, hvis I vil samle mere af driften i Microsoft: /microsoft-365 og /it-sikkerhed.

Kilder: Microsoft Tech Community (2026), Microsoft Learn (2026), Microsoft Exchange Blog (2026), C7 Solutions (2026), Office 365 IT Pros (2026), CISA (2026).