E-post: domener, DNS & utsending

Før WeZend sender e-post i navnet ditt, beviser du at du eier domenet. Det er dette som holder e-posten din ute av søppelpostmappen — innboksleverandører stoler på e-post som er kryptografisk knyttet til et verifisert domene.

1. Legg til domenet ditt

I dashbordet åpner du Innstillinger → E-postdomener og legger til domenet du sender fra (for eksempel mail.dittfirma.no). API-ekvivalenten:

curl -X POST https://api.wezend.com/v1/account/email-domains \
  -H "X-API-Key: $WEZEND_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "domain": "mail.dittfirma.no" }'

Svaret lister nøyaktig de DNS-postene du skal opprette: en SPF-post (hvilke servere som kan sende for deg), en DKIM-nøkkel (en signatur mottakere verifiserer) og en DMARC-policy (hva mottakere skal gjøre når en melding feiler de to første).

2. Opprett DNS-postene

Kopier hver post inn hos DNS-leverandøren din nøyaktig som vist. DNS-endringer kan ta fra minutter til et par timer å slå igjennom.

3. Verifiser

Klikk Verifiser i dashbordet eller kall POST /v1/account/email-domains/:id/verify — plattformen kjører live DNS-oppslag på alle tre postene, lagrer resultatet og returnerer det:

Det er en DNS-sjekk, og DNS er bare halve spørsmålet. Den kan ikke se om utgående post faktisk signeres, så les den som "postene er publisert", ikke "DKIM virker". POST /v1/account/email-domains/:id/check-signing er den ærlige bekreftelsen: den ser på en ekte signatur. Kjør den før du strammer DMARC — de to presentert som ett grønt flueben er nettopp slik et domene kan stå som "verifisert" mens den leverte posten ikke bærer DKIM i det hele tatt.

DMARC har selv to endepunkter utover DNS-posten. POST /v1/account/email-domains/:id/dmarc tar en aggregert (rua) rapport som { xml } og tolker den til en pass/fail-alignment-oversikt, så du ser hvem som sender som domenet ditt og hva som feiler; GET på samme sti returnerer de siste rapportene og en rollup. GET /v1/account/email-domains/:id/dmarc/readiness svarer på spørsmålet som betyr noe før du går til p=quarantine, mot de samme fire kriteriene plattformen holder sitt eget domene til: minst 14 dagers rapporter, minst 3 rapporterende organisasjoner, alignment på 99% eller bedre, og ingen ujustert kilde over 5 meldinger i vinduet. Den returnerer de feilende årsakene, ikke bare en dom. Og PUT /v1/account/email-domains/:id/bimi med { logo_url } setter eller fjerner BIMI-logoen når DMARC håndhever. Et helt nytt domene har ingen omdømme, så POST /v1/account/email-domains/:id/warmup med { "action": "start" } setter det på en 21-dagers rampe: mens den er aktiv, holdes markedsførings-e-post utover dagens tak tilbake i stedet for å sendes, og pause, resume og stop gjør det de sier. Transaksjonell post er ikke en del av rampen.

{
  "spf_verified": true,
  "dkim_verified": false,
  "dmarc_verified": true,
  "status": "pending",
  "checks": {
    "spf":   { "ok": true,  "reason": "ok" },
    "dkim":  { "ok": false, "reason": "wrong_selector", "detail": "smtp", "selector": "zc1", "hint": "You published a valid DKIM key under the \"smtp\" selector — that's another provider's key (e.g. your mailbox host), not WeZend's. WeZend signs with the \"zc1\" selector, so add the \"zc1._domainkey\" CNAME shown above; the \"smtp\" one can stay, it's harmless." },
    "dmarc": { "ok": true,  "reason": "ok", "policy": "quarantine" }
  }
}

SPF og DKIM må begge passere før status blir verified; DMARC anbefales, men blokkerer ikke.

checks inneholder én oppføring per post, så en feilet sjekk forteller deg hva du skal rette i stedet for å vise et bart rødt kryss:

• ok — den postens boolean.
• reason — en stabil maskinkode. Forgren på den i dine egne verktøy; ordlyden i hint er ikke en del av kontrakten.
• hint — én linje menneskelig språk til den som styrer DNS-en. null ved en bestått sjekk, med ett unntak (se DMARC nedenfor).
• detail — verdien sjekken falt på: selektoren som faktisk ble funnet, SPF-includet som mangler, verten som ikke har noen post. null når det ikke er relevant.
• selector — kun DKIM: selektoren WeZend signerer med, slik at du kan navngi den i ditt eget grensesnitt. policy — kun DMARC: den tolkede p=-verdien, én av none, quarantine eller reject.

Å kjøre Verifiser igjen er alltid trygt. Har du sett et rødt DKIM-kryss på en post du vet er riktig publisert, kjør den igjen — verifiseringen ga tidligere falskt negativt på DKIM for alle domener, fordi WeZends forvaltede nøkkelvert publiseres som en TXT-post mens helsesjekken bare slo opp A og CNAME.

Reason-koder

• ok — posten finnes og er riktig.
• esp_target_unresolved — denne ligger hos WeZend, ikke hos deg. Vårt eget SPF-include eller forvaltede DKIM-nøkkelvert svarer ikke, så ingen post du publiserer kan passere ennå. detail navngir verten. Send ikke domeneeieren inn i DNS-en for dette — kontakt support og oppgi verten.
• no_spf_record — domenet har ingen v=spf1-TXT-post i det hele tatt.
• missing_include — en SPF-post finnes, men inneholder ikke WeZends include (detail). Legg det til i posten du allerede har; ikke publiser en andre SPF-post.
• not_published — DKIM: ingenting på <selector>._domainkey.<domene>. detail er verten som ble slått opp.
• wrong_cname_target — DKIM: en CNAME finnes på riktig vert, men peker et annet sted. detail er verten den må peke på.
• wrong_selector — DKIM: domenet publiserer riktignok en gyldig DKIM-nøkkel, men under en annen selektor. detail er selektoren som ble funnet.
• no_record — DMARC: ingen v=DMARC1-TXT-post på _dmarc.<domene>.

Tilfellet med feil selektor

Det er feilen virkelige kunder treffer. DNS-en ser riktig ut, SPF og DMARC passerer, DKIM er rød — og årsaken er at den publiserte nøkkelen tilhører noen andre. En e-postvert hadde allerede satt opp DKIM under sin egen selektor, typisk smtp._domainkey eller default._domainkey, og den posten ble tatt for den WeZend ba om.

WeZend signerer med sin egen selektor (zc1 som standard) og har ingen annen leverandørs private nøkkel, så en fremmed selektor kan aldri regnes som bestått. Publiser også <selector>._domainkey-CNAME-en fra trinn 2. Den andre leverandørens post kan bli stående — de to sameksisterer, og å fjerne den ville ødelegge e-posten du sender gjennom den leverandøren.

DMARC-håndheving mens DKIM feiler

En DMARC-sjekk som passerer, returnerer likevel et hint når policyen er p=quarantine eller p=reject og DKIM feiler. Den kombinasjonen er det som faktisk legger e-posten din i søppelposten: du har fortalt mottakerne at de skal sette alt som feiler autentiseringen i karantene eller avvise det — og DKIM feiler. Hold DMARC på p=none til DKIM verifiserer, og stram så inn.

4. Send

Når domenet er verifisert, er e-post bare enda en kanal på det endepunktet du allerede bruker:

curl -X POST https://api.wezend.com/v1/messages/send \
  -H "X-API-Key: $WEZEND_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "kunde@example.com",
    "channel": "email",
    "sender": "hei@mail.dittfirma.no",
    "subject": "Velkommen!",
    "html": "<h1>Hei</h1><p>Takk for at du registrerte deg.</p>"
  }'

Åpninger og klikk spores automatisk (en sporingspiksel og omskrevne lenker), bounces og klager mater sperrelisten, og avsenderomdømmet ditt overvåkes løpende — se Deliverability.