E-post: domäner, DNS & utskick

Innan WeZend skickar e-post i ditt namn bevisar du att du äger domänen. Det är detta som håller din e-post borta från skräppostmappen — inkorgsleverantörer litar på e-post som är kryptografiskt knuten till en verifierad domän.

1. Lägg till din domän

I dashboarden öppnar du Inställningar → E-postdomäner och lägger till domänen du skickar från (till exempel mail.dittforetag.se). API-motsvarigheten:

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.dittforetag.se" }'

Svaret listar exakt de DNS-poster du ska skapa: en SPF-post (vilka servrar som får skicka för dig), en DKIM-nyckel (en signatur mottagare verifierar) och en DMARC-policy (vad mottagare ska göra när ett meddelande misslyckas med de två första).

2. Skapa DNS-posterna

Kopiera varje post till din DNS-leverantör exakt som visat. DNS-ändringar kan ta från minuter till några timmar att slå igenom.

3. Verifiera

Klicka Verifiera i dashboarden eller anropa POST /v1/account/email-domains/:id/verify — plattformen kör live DNS-uppslag på alla tre posterna, sparar resultatet och returnerar det:

Det är en DNS-kontroll, och DNS är bara halva frågan. Den kan inte se om utgående post faktiskt signeras, så läs den som "posterna är publicerade", inte "DKIM fungerar". POST /v1/account/email-domains/:id/check-signing är den ärliga bekräftelsen: den tittar på en riktig signatur. Kör den innan du skärper DMARC — de två presenterade som en enda grön bock är precis så en domän kan stå som "verifierad" medan den levererade posten inte bär DKIM alls.

DMARC har själv två endpoints utöver DNS-posten. POST /v1/account/email-domains/:id/dmarc tar en aggregerad (rua) rapport som { xml } och tolkar den till en pass/fail-alignment-översikt, så du ser vem som sänder som din domän och vad som misslyckas; GET på samma sökväg returnerar de senaste rapporterna och en rollup. GET /v1/account/email-domains/:id/dmarc/readiness svarar på frågan som betyder något innan du går till p=quarantine, mot samma fyra kriterier som plattformen håller sin egen domän till: minst 14 dagars rapporter, minst 3 rapporterande organisationer, alignment på 99% eller bättre, och ingen ojusterad källa över 5 meddelanden i fönstret. Den returnerar de felande skälen, inte bara ett utslag. Och PUT /v1/account/email-domains/:id/bimi med { logo_url } sätter eller tar bort BIMI-logotypen när DMARC tillämpas. En helt ny domän har inget rykte, så POST /v1/account/email-domains/:id/warmup med { "action": "start" } sätter den på en 21-dagars ramp: medan den är aktiv hålls marknadsförings-e-post utöver dagens tak tillbaka i stället för att skickas, och pause, resume och stop gör vad de säger. Transaktionell post ingår inte i 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 och DKIM måste båda passera innan status blir verified; DMARC rekommenderas men blockerar inte.

checks innehåller en post per DNS-post, så en misslyckad kontroll talar om vad du ska rätta i stället för att visa ett naket rött kryss:

• ok — den postens boolean.
• reason — en stabil maskinkod. Förgrena på den i dina egna verktyg; ordalydelsen i hint är inte en del av kontraktet.
• hint — en rad mänskligt språk till den som sköter DNS:en. null vid en godkänd kontroll, med ett undantag (se DMARC nedan).
• detail — det värde kontrollen föll på: selektorn som faktiskt hittades, SPF-includet som saknas, värden som inte har någon post. null när det inte är tillämpligt.
• selector — endast DKIM: den selektor WeZend signerar med, så att du kan namnge den i ditt eget gränssnitt. policy — endast DMARC: det tolkade p=-värdet, ett av none, quarantine eller reject.

Att köra Verifiera igen är alltid säkert. Har du sett ett rött DKIM-kryss på en post som du vet är korrekt publicerad, kör den igen — verifieringen gav tidigare falskt negativt på DKIM för alla domäner, eftersom WeZends hanterade nyckelvärd publiceras som en TXT-post medan hälsokontrollen bara slog upp A och CNAME.

Reason-koder

• ok — posten finns och är korrekt.
• esp_target_unresolved — den här ligger hos WeZend, inte hos dig. Vårt eget SPF-include eller hanterade DKIM-nyckelvärd svarar inte, så ingen post du publicerar kan passera ännu. detail namnger värden. Skicka inte domänägaren in i DNS:en för det här — kontakta supporten och ange värden.
• no_spf_record — domänen har ingen v=spf1-TXT-post alls.
• missing_include — en SPF-post finns men innehåller inte WeZends include (detail). Lägg till det i posten du redan har; publicera inte en andra SPF-post.
• not_published — DKIM: inget på <selector>._domainkey.<domän>. detail är värden som slogs upp.
• wrong_cname_target — DKIM: en CNAME finns på rätt värd men pekar någon annanstans. detail är värden den måste peka på.
• wrong_selector — DKIM: domänen publicerar visserligen en giltig DKIM-nyckel, men under en annan selektor. detail är selektorn som hittades.
• no_record — DMARC: ingen v=DMARC1-TXT-post på _dmarc.<domän>.

Fallet med fel selektor

Det är det fel verkliga kunder råkar ut för. DNS:en ser rätt ut, SPF och DMARC passerar, DKIM är rött — och orsaken är att den publicerade nyckeln tillhör någon annan. En e-postvärd hade redan satt upp DKIM under sin egen selektor, vanligen smtp._domainkey eller default._domainkey, och den posten togs för den WeZend bad om.

WeZend signerar med sin egen selektor (zc1 som standard) och har ingen annan leverantörs privata nyckel, så en främmande selektor kan aldrig räknas som godkänd. Publicera även <selector>._domainkey-CNAME:n från steg 2. Den andra leverantörens post kan stå kvar — de två samexisterar, och att ta bort den skulle sabotera den e-post du skickar via den leverantören.

DMARC-tillämpning medan DKIM misslyckas

En DMARC-kontroll som passerar returnerar ändå ett hint när policyn är p=quarantine eller p=reject och DKIM misslyckas. Den kombinationen är det som faktiskt lägger din e-post i skräpposten: du har talat om för mottagarna att de ska sätta allt som misslyckas med autentiseringen i karantän eller avvisa det — och DKIM misslyckas. Håll DMARC på p=none till DKIM verifierar, och skärp sedan.

4. Skicka

När domänen är verifierad är e-post bara ännu en kanal på samma endpoint du redan använder:

curl -X POST https://api.wezend.com/v1/messages/send \
  -H "X-API-Key: $WEZEND_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "kund@example.com",
    "channel": "email",
    "sender": "hej@mail.dittforetag.se",
    "subject": "Välkommen!",
    "html": "<h1>Hej</h1><p>Tack för att du registrerade dig.</p>"
  }'

Öppningar och klick spåras automatiskt (en spårningspixel och omskrivna länkar), studsar och klagomål matar spärrlistan, och ditt avsändarrykte övervakas löpande — se Deliverability.