Email: domæner, DNS & afsendelse

Før WeZend sender email i dit navn, beviser du, at du ejer domænet. Det er dét, der holder din mail ude af spam-mappen — indbakkeudbydere stoler på mail, der er kryptografisk bundet til et verificeret domæne.

1. Tilføj dit domæne

Åbn Indstillinger → Email-domæner i dashboardet og tilføj det domæne, du sender fra (fx mail.ditfirma.dk). API-ækvivalenten:

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.ditfirma.dk" }'

Svaret lister præcis de DNS-records, du skal oprette: en SPF-record (hvilke servere må sende for dig), en DKIM-nøgle (en signatur modtagere verificerer) og en DMARC-politik (hvad modtagere skal gøre, når en besked fejler de to første).

2. Opret DNS-records

Kopiér hver record ind hos din DNS-udbyder præcis som vist. DNS-ændringer kan tage fra minutter til et par timer om at slå igennem.

3. Verificér

Klik Verificér i dashboardet eller kald POST /v1/account/email-domains/:id/verify — platformen kører live DNS-opslag på alle tre records, gemmer resultatet og returnerer det:

Det er et DNS-tjek, og DNS er kun halvdelen af spørgsmålet. Det kan ikke se, om udgående post faktisk bliver signeret, så læs det som "recordsene er publiceret", ikke "DKIM virker". POST /v1/account/email-domains/:id/check-signing er den ærlige bekræftelse: den ser på en rigtig signatur. Kør den, før I strammer DMARC — de to præsenteret som ét grønt flueben er præcis sådan, et domæne kan stå som "verificeret", mens den leverede post slet ikke bærer DKIM.

DMARC har selv to endpoints ud over DNS-recorden. POST /v1/account/email-domains/:id/dmarc tager en aggregeret (rua) rapport som { xml } og parser den til et pass/fail-alignment-overblik, så I kan se hvem der sender som jeres domæne, og hvad der fejler; GET på samme sti returnerer de seneste rapporter og en rollup. GET /v1/account/email-domains/:id/dmarc/readiness svarer på det spørgsmål, der betyder noget, før I går til p=quarantine, målt på de samme fire kriterier som platformen holder sit eget domæne til: mindst 14 dages rapporter, mindst 3 rapporterende organisationer, alignment på 99% eller bedre, og ingen ikke-alignet kilde over 5 beskeder i vinduet. Den returnerer de fejlende årsager, ikke bare en dom. Og PUT /v1/account/email-domains/:id/bimi med { logo_url } sætter eller fjerner BIMI-logoet, når DMARC håndhæver. Et helt nyt domæne har intet omdømme, så POST /v1/account/email-domains/:id/warmup med { "action": "start" } sætter det på en 21-dages rampe: mens den kører, holdes marketing-mail ud over dagens loft tilbage i stedet for at blive sendt, og pause, resume og stop gør, hvad de siger. Transaktionel post er ikke en del af 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 skal begge passere, før status bliver verified; DMARC anbefales, men blokerer ikke.

checks indeholder én post per record, så et fejlet tjek fortæller dig, hvad du skal rette, i stedet for at vise et bart rødt kryds:

• ok — den pågældende records boolean.
• reason — en stabil maskinkode. Forgren på den i dit eget værktøj; ordlyden i hint er ikke en del af kontrakten.
• hint — én linje menneskeligt sprog til den, der styrer DNS'en. null ved et bestået tjek, med én undtagelse (se DMARC nedenfor).
• detail — den værdi, tjekket faldt på: den selector der faktisk blev fundet, det SPF-include der mangler, den host der ikke har nogen record. null når det ikke er relevant.
• selector — kun DKIM: den selector WeZend signerer med, så du kan navngive den i din egen grænseflade. policy — kun DMARC: den parsede p=-værdi, en af none, quarantine eller reject.

At køre Verificér igen er altid sikkert. Har du set et rødt DKIM-kryds på en record, du ved er publiceret korrekt, så kør det igen — verificeringen gav tidligere falsk negativ på DKIM for alle domæner, fordi WeZends managed key-host er publiceret som en TXT-record, mens health-tjekket kun slog A og CNAME op.

Reason-koder

• ok — recorden findes og er korrekt.
• esp_target_unresolved — den her ligger hos WeZend, ikke hos dig. Vores eget SPF-include eller managed-DKIM-key-host resolver ikke, så ingen record du publicerer, kan passere endnu. detail navngiver hosten. Send ikke domæneejeren ind i DNS'en over det her — kontakt support og oplys hosten.
• no_spf_record — domænet har slet ingen v=spf1-TXT-record.
• missing_include — der findes en SPF-record, men den indeholder ikke WeZends include (detail). Tilføj det til den record, du allerede har; publicér ikke en anden SPF-record.
• not_published — DKIM: intet på <selector>._domainkey.<domæne>. detail er den host, der blev slået op.
• wrong_cname_target — DKIM: der findes en CNAME på den rigtige host, men den peger et andet sted hen. detail er den host, den skal pege på.
• wrong_selector — DKIM: domænet publicerer faktisk en gyldig DKIM-nøgle, men under en anden selector. detail er den selector, der blev fundet.
• no_record — DMARC: ingen v=DMARC1-TXT-record på _dmarc.<domæne>.

Tilfældet med den forkerte selector

Det er den fejl, virkelige kunder rammer. DNS'en ser rigtig ud, SPF og DMARC passerer, DKIM er rød — og årsagen er, at den publicerede nøgle tilhører nogen andre. En mailboks-udbyder havde allerede sat DKIM op under sin egen selector, typisk smtp._domainkey eller default._domainkey, og den record blev taget for den, WeZend bad om.

WeZend signerer med sin egen selector (zc1 som standard) og har ingen anden udbyders private nøgle, så en fremmed selector kan aldrig tælle som bestået. Publicér også <selector>._domainkey-CNAME'en fra trin 2. Den anden udbyders record kan blive stående — de to sameksisterer, og at fjerne den ville ødelægge den mail, du sender gennem den udbyder.

DMARC-håndhævelse, mens DKIM fejler

Et DMARC-tjek, der passerer, returnerer stadig et hint, når politikken er p=quarantine eller p=reject og DKIM fejler. Den kombination er dét, der reelt lægger din mail i spam-mappen: du har fortalt modtagerne, at de skal sætte alt, der fejler autentificering, i karantæne eller afvise det — og DKIM fejler. Hold DMARC på p=none, indtil DKIM verificerer, og stram så op.

4. Send

Når domænet er verificeret, er email blot endnu en kanal på det endpoint, du allerede bruger:

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": "hej@mail.ditfirma.dk",
    "subject": "Velkommen!",
    "html": "<h1>Hej</h1><p>Tak fordi du tilmeldte dig.</p>"
  }'

Åbninger og kliks trackes automatisk (tracking-pixel og omskrevne links), bounces og klager føder suppressionslisten, og dit afsenderomdømme overvåges løbende — se Deliverability.