DMARC. Steg för steg.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) är den oförhandlingsbara förutsättningen för BIMI. En domän med p=none kommer aldrig att visa en logotyp i Gmail eller Apple Mail, oavsett hur perfekt SVG-filen är konfigurerad. Denna guide täcker hela vägen från initial driftsättning till full tillämpning.

Förutsättningar

Innan du skapar en DMARC-post, bekräfta att följande redan är på plats:

1. SPF-post — En TXT-post på din apex-domän som specificerar vilka e-postservrar som är behöriga att skicka för din räkning. Exempel: v=spf1 include:_spf.google.com -all
2. DKIM-post — En publik nyckel publicerad i DNS som mottagande servrar använder för att verifiera dina e-postsignaturer. Din e-postleverantör genererar denna.
3. DNS-åtkomst — Skrivrättigheter till din domäns DNS-zon (Cloudflare, Route 53, GoDaddy, eller din registrars kontrollpanel).

DMARC kräver att minst en av SPF eller DKIM är korrekt konfigurerad och justerad med From:-domänen innan den fungerar.

Steg 1: Skapa en övervakningspost (p=none)

Börja med en policy för enbart övervakning. Denna registrerar autentiseringsfel utan att påverka e-postleveransen.

_dmarc.yourdomain.com  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; pct=100"

Taggreferens:

| Tagg | Obligatorisk | Beskrivning | |---|---|---| | v=DMARC1 | Ja | Protokollversion. Måste komma först. | | p=none | Ja | Policy: endast övervakning, ingen åtgärd vidtas. | | rua=mailto: | Rekommenderat | E-postadress för aggregerade rapporter. | | pct=100 | Valfritt | Procentandel av e-post som omfattas av policyn (standard: 100). |

Publicera denna post och vänta 48–72 timmar för DNS-propagering.

Steg 2: Läs dina aggregerade rapporter

Aggregerade rapporter (RUA) anländer som XML-bilagor, vanligtvis en gång per dag per sändningskälla. De visar:

• Vilka IP-adresser som skickade e-post som hävdade din domän
• Om SPF och DKIM godkändes eller underkändes
• Hur många meddelanden som skickades från varje källa

Vad du ska leta efter: Alla legitima sändningstjänster (din ESP, CRM, ärendehanteringssystem, marknadsföringsplattform) som misslyckas med SPF- eller DKIM-justering måste åtgärdas innan du går vidare till tillämpning. Att gå till p=reject med olösta justeringsfel kommer att orsaka att legitim e-post blockeras.

Vanliga källor som kräver separat DKIM/SPF-konfiguration: Mailchimp, Salesforce, HubSpot, Zendesk, SendGrid, Google Workspace, Microsoft 365.

Steg 3: Gå till p=quarantine

När alla legitima sändningskällor passerar autentisering, uppdatera policyn för att sätta misslyckade meddelanden i karantän:

_dmarc.yourdomain.com  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=25"

Börja med pct=25 för att tillämpa karantänpolicyn på endast 25% av misslyckade meddelanden. Övervaka i en till två veckor. Om ingen legitim e-post sätts i karantän, öka till pct=100.

Steg 4: Gå till p=reject

Full tillämpning. Oautentiserade meddelanden avvisas direkt och levereras aldrig.

_dmarc.yourdomain.com  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100"

Detta är minimikravet för BIMI. Gmail och Apple Mail kommer inte att bearbeta din BIMI-post om inte din domän har p=quarantine eller p=reject med pct=100. En policy på p=none är osynlig för BIMI — logotypen kommer aldrig att visas oavsett hur korrekt resten av konfigurationen är.

Varför p=none blockerar BIMI

BIMI-specifikationen kräver att brevlådeleverantörer verifierar att den sändande domänen har en tillämpad DMARC-policy innan logotypen visas. Resonemanget: en logotyp är en förtroendesignal. Att visa en logotyp för en domän som inte har tillämpat antispoofing-kontroller skulle tillåta angripare att visa verifierade logotyper på nätfiske-e-post. p=none ger ingen tillämpning, så leverantörer vägrar att respektera BIMI-posten.

Justering: Detaljen de flesta guider hoppar över

DMARC godkänns endast när den autentiserade domänen justeras med From:-huvuddomänen. Det finns två justeringslägen:

• Avslappnad (standard): Den organisatoriska domänen måste matcha. mail.example.com justeras med example.com.
• Strikt: Den exakta domänen måste matcha. mail.example.com justeras inte med example.com.

För BIMI, använd avslappnad justering (adkim=r; aspf=r) om du inte har ett specifikt skäl för strikt. Strikt justering orsakar fel för underdomäner och tredjepartstjänster för sändning.

Komplett postreferens

_dmarc.yourdomain.com  IN  TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:[email protected]; pct=100"

| Tagg | Värde | Betydelse | |---|---|---| | p=reject | Avvisa | Blockera oautentiserad e-post | | sp=reject | Avvisa | Tillämpa samma policy på underdomäner | | adkim=s | Strikt | DKIM-justering måste vara exakt | | aspf=s | Strikt | SPF-justering måste vara exakt | | rua= | E-post | Destination för aggregerade rapporter | | pct=100 | 100% | Tillämpa på all e-post |

Nästa steg

När din domän når p=reject:

1. Generera din BIMI SVG — Använd makeBIMI™ för att producera en W3C SVG Tiny P/S-kompatibel logotypfil. Gratis, inget konto krävs.
2. Kör en DMARC-granskning — Verktyget makeBIMI Domain Audit verifierar din DMARC-, SPF- och BIMI-poststatus i realtid.
3. Skaffa ett certifikat — För Gmail-logovisning krävs ett VMC eller CMC. veriBIMI℠ förmedlar hela certifikatprocessen, inklusive hantering av DMARC-tillämpning, SVG-förberedelse och CA-ansökan.