# DMARC från p=none till p=reject på 30 dagar Kanonisk URL: https://brew.new/sv/blog/dmarc-p-none-to-reject-in-30-days Författare: Thomas Park Publicerad: 2026-10-04 Uppdaterad: 2026-10-04 DMARC är en TXT-post på `_dmarc.` som talar om för mottagande servrar vad de ska göra med mejl som har din domän i From-headern men varken klarar SPF eller DKIM med alignment, och vart rapporterna ska skickas. `p=none` begär bara rapporter, `p=quarantine` ber mottagande servrar att behandla mejl som inte klarar kontrollen som misstänkta, och `p=reject` ber dem att avvisa sådana mejl. Gmail, Yahoo och Microsoft godtar `p=none` från storskaliga avsändare, så många domäner publicerar det och stannar där. De får rapporter om dem som förfalskar domänen men stoppar dem inte. Red Sifts analys av 73,3 miljoner domäner, som citerades i [april 2026](https://redsift.com/blog/email-authentication-bespinlabs-redsift), visade att 14,9 % hade någon DMARC-policy alls och att 2,5 % tillämpade `p=reject`. EasyDMARC, en annan DMARC-leverantör, [rapporterade 2025](https://easydmarc.com/blog/dmarc-adoption-across-fortune-500-and-inc-5000-the-growing-divide/) att 62,7 % av de Fortune 500-företag som hade DMARC använde `p=reject`, jämfört med 15,2 % av företagen på Inc. 5000. Här är en plan på 30 dagar fram till `p=reject`, post för post, för en domän som skickar från medarbetarnas e-post, en eller två ESP:er, ett kundtjänstverktyg och ett faktureringsverktyg. Trettio dagar passar för en underdomän som används för utskick. En domän som dina medarbetare använder för vardaglig e-post behöver längre tid. ## Det viktigaste i korthet - Publicera `v=DMARC1; p=none; rua=mailto:...` dag 1. Utan `rua` får mottagande servrar inte skicka aggregerade rapporter. - Varje legitim avsändare måste klara SPF eller DKIM med alignment mot din From-domän. För de flesta verktyg innebär det DKIM-signering med din domän. - Håll SPF på högst 10 termer som kräver DNS-uppslag, nästlade includes medräknade, annars får all din e-post `permerror`. - Gå över till `p=quarantine` dag 15 och `p=reject` dag 22, i båda fallen efter en vecka med rena rapporter. För en domän som medarbetarna använder för vardaglig e-post rekommenderar RFC 9989 en månad i vart och ett av de två första stegen. - RFC 9989 (maj 2026) klassar `pct` som historisk. Hoppa över upptrappningen med `pct=10` och `pct=50`. - BIMI kräver `p=quarantine` eller `p=reject` på organisationsdomänen, ingen `sp=none`, en logotyp i SVG Tiny PS och, för Gmail, ett VMC eller CMC. ## Det här ändrades i DMARC 2026 I maj 2026 ersatte IETF RFC 7489, ett informativt dokument (Informational) från 2015, med DMARCbis: [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), en Proposed Standard som också ersätter RFC 9091, plus [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) för aggregerad rapportering. Tre ändringar spelar roll här: - **`pct` är historisk.** Enligt bilaga A.6 tillämpades taggen ”oftast inte korrekt, om inte det angivna värdet var antingen 0 eller 100”. - **`t=y` ersätter `pct=0`.** Mottagande servrar tillämpar en nivå under din policy, så `p=reject; t=y` fungerar som quarantine. Det är en testflagga. - **`np` är ny.** Den gäller underdomäner som inte finns i DNS, och äldre mottagande servrar måste ignorera den. Dessutom ersätts Public Suffix List av en sökning uppåt i DNS-trädet (DNS tree walk) när organisationsdomänen ska fastställas. ## De tre posterna som DMARC bygger på DMARC godkänns när SPF eller DKIM godkänns **och** den godkända domänen stämmer överens med From-domänen, så kallad alignment. Det räcker att en av dem godkänns med alignment. ### SPF och gränsen på 10 uppslag SPF anger vilka servrar som får skicka e-post för kuvertdomänen (domänen i `MAIL FROM`, även kallad returadress eller return-path), den enda identitet som DMARC använder, inte HELO. [RFC 7208, avsnitt 4.6.4](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4) begränsar termerna som kräver DNS-uppslag till 10: `include`, `a`, `mx`, `ptr`, `exists` och `redirect`, räknat genom varje nästlad include. `ip4`, `ip6` och `all` räknas inte. Över gränsen blir resultatet `permerror`. Avsnittet tillåter också högst två ”void lookups” (tomma uppslag), oftast en include för ett värdnamn som inte längre finns. ```dns example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.helpdesk.example include:mail.billing.example ~all" ``` Det förbrukar 4 uppslag innan du har räknat det som varje leverantör nästlar, så slå upp varje led med `dig +short TXT ` hela vägen ned. För att hålla dig inom gränsen på 10 kan du ta bort verktyg som inte längre används eller ge varje ESP en egen underdomän för returadressen, till exempel `bounce.example.com`, med en egen budget på 10. Microsofts [guide för att konfigurera SPF](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) rekommenderar att posten avslutas med `-all` på domäner som också använder DKIM och DMARC. Många ESP:er använder som standard en egen domän för returadressen, och den stämmer inte överens med din. Konfigurera en egen returadress eller förlita dig på DKIM. ### DKIM: nycklar på 2048 bitar, selektorer och rotation DKIM signerar varje meddelande med en domän, `d=`, och en selektor, `s=`; den mottagande servern hämtar nyckeln från `._domainkey.`. Ett verktyg som signerar med `d=vendor-mail.example` klarar DKIM men inte DMARC. Enligt [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html) måste den som signerar använda RSA-nycklar på minst 1024 bitar och bör använda 2048. [Googles riktlinjer för avsändare](https://support.google.com/mail/answer/81126) säger samma sak för utskick till personliga Gmail-konton. En nyckel på 2048 bitar överskrider gränsen på 255 tecken för en TXT-sträng, så den läggs in som flera strängar inom citattecken i en och samma post, något som de flesta DNS-leverantörer delar upp åt dig. ```dns s202610._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1x..." "...remainder-of-the-2048-bit-key...IDAQAB" ) ``` Ge varje system som skickar e-post en egen selektor och återanvänd aldrig ett namn. Ett datum, som `s202610`, gör historiken lätt att följa. Enligt M3AAWG:s [rekommendationer för nyckelrotation](https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf) ska nycklarna roteras minst var sjätte månad: 1. Publicera den nya selektorn och låt den spridas. 2. Byt signeringen till den nya nyckeln. 3. Behåll den gamla publika nyckeln i DNS i 7–30 dagar, så att mejl som är på väg fortfarande kan verifieras. 4. Pensionera den gamla selektorn med ett tomt `p=`. Radera den inte. ### Alignment: relaxed eller strict RFC 9989 definierar två lägen: | Läge | Tagg | Godkänd SPF-/DKIM-domän | From-domän | Stämmer överens? | |---|---|---|---|---| | Relaxed (standard) | `aspf=r`, `adkim=r` | `bounce.example.com` | `mail.example.com` | Ja, samma organisationsdomän | | Strict | `aspf=s`, `adkim=s` | `bounce.example.com` | `mail.example.com` | Nej, namnen måste vara identiska | | Oavsett läge | | `vendor.example.net` | `example.com` | Nej | RFC 9989 konstaterar att ”nästan alla domänägare har funnit att relaxed alignment räcker”. Utelämna `aspf` och `adkim`. Med strict alignment för SPF klarar den vanliga returadressen på en underdomän inte längre kontrollen. ## Planen på 30 dagar ![En tidslinje för DMARC på 30 dagar i fyra steg: dag 1–7 på p=none med rua-rapportering, dag 8–14 för att åtgärda avsändare, dag 15 på p=quarantine, dag 22 på p=reject och sedan BIMI från dag 30, med den exakta TXT-posten för varje steg.](/images/blog/dmarc-p-none-to-reject-in-30-days-timeline.png) *Posten för varje steg. Gå vidare först efter en vecka med rena rapporter.* | Dagar | Policy | Det här gör du | Villkor för att gå vidare | |---|---|---|---| | 1–7 | `p=none` | Publicera med `rua`, lista varje källa | 7 dagar med rapporter från Google, Yahoo och Microsoft | | 8–14 | `p=none` | Åtgärda DKIM och SPF, pensionera avsändare som inte används | Varje legitim källa klarar SPF eller DKIM med alignment | | 15–21 | `p=quarantine` | Håll utkik efter legitima mejl som hamnar i karantän | 7 dagar utan att någon legitim källa underkänns | | 22–30 | `p=reject` | Fortsätt läsa rapporterna, lägg till `np=reject` | Stabilt i en vecka | | 30+ | `p=reject` | Börja med BIMI | Certifikatet är utfärdat | Om vecka 2 visar en källa som ingen kan åtgärda, stanna på `p=none`. Att avvisa dina egna fakturor är värre än att tillämpa policyn sent. ### Dag 1–7: publicera p=none med rapportering ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com" ``` Rapporterna är gzip-komprimerad XML, minst en gång per dygn från varje mottagande server, så låt `rua` peka på en tjänst som bearbetar rapporter, inte på en person. Om adressen ligger på en annan organisationsdomän ska mottagande servrar enligt RFC 9990 ignorera den, om inte `example.com._report._dmarc.` godkänner den. Rapporttjänsterna publicerar den posten själva; för dina egna domäner lägger du till den själv. Publicera exakt en DMARC-post. Om automatiska konfigurationsguider lämnar två `v=DMARC1`-poster på `_dmarc.example.com` kastar mottagande servrar båda. Hoppa över `ruf`. RFC 9989 påpekar att mottagande system som värnar om integriteten maskerar felrapporter kraftigt eller inte skickar dem alls, och de vanliga frågorna i Microsofts [meddelande till avsändare med stora volymer](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) säger att Microsoft skickar `rua`-rapporter och inte har några planer på att skicka `ruf`. ### Så läser du en aggregerad rapport RFC 9990 beskriver XML-rapporter som skickas ”dagligen (eller oftare)”, en per policydomän. Här är en post, bearbetad utifrån exemplet i RFC:n: ```xml 192.0.2.123 123 none fail fail bounces.vendor.example example.com vendor.example abc123 pass bounces.vendor.example pass ``` I `policy_evaluated` är `dkim` och `spf` resultat för **alignment**, och `disposition` är det som den mottagande servern gjorde. `auth_results` innehåller de råa resultaten och deras domäner. Här godkänns båda för `vendor.example`, så båda underkänns för alignment: en leverantör som skickar i ditt namn utan att signera i ditt namn. Aktivera DKIM med din egen domän eller domänautentisering hos leverantören. ### Dag 1–7: hitta de okända avsändarna Gruppera efter `source_ip`, `envelope_from` och DKIM-värdena `domain` plus `selector`, sortera efter `count` och dela in resultaten så här: | Mönster i rapporten | Trolig orsak | Åtgärd | |---|---|---| | DKIM eller SPF godkänns med alignment | Korrekt konfigurerat | Ingen | | DKIM och SPF godkänns för leverantörens domäner | SaaS-verktyg som använder sin egen identitet | Aktivera DKIM med din egen domän | | DKIM godkänns med alignment, SPF underkänns, IP-adress hos en e-postleverantör eller en e-postlista | Vidarebefordran eller en e-postlista | Oftast ingen. DKIM med alignment klarar vidarebefordran | | Ingen DKIM, SPF underkänns, IP-adresser som inte går att härleda | Förfalskning (spoofing) | Ingen. Det är det här som `p=reject` stoppar | För att ta reda på vem en IP-adress tillhör kör du `dig -x 192.0.2.123 +short` och tittar på selektorn, som ofta innehåller leverantörens namn. Fråga sedan ekonomiavdelningen, supporten och säljteamet vad som skickar e-post i företagets namn: fakturering, kundtjänstverktyg, kalenderinbjudningar, skannrar på kontoret. Vidarebefordrade mejl och mejl via e-postlistor kommer att underkännas på sätt som du inte kan åtgärda, och Googles [vanliga frågor för avsändare](https://support.google.com/mail/answer/14229414) kräver inte alignment för dem, så låt dem inte hålla tillbaka planen. ### Dag 8–14: åtgärda varje legitim källa Börja med det högsta värdet för `count` och arbeta dig nedåt: 1. **Medarbetarnas e-post** (Google Workspace, Microsoft 365). Aktivera DKIM i administratörskonsolen, med 2048 bitar där det går, och kontrollera att leverantörens include finns med i SPF. 2. **ESP:er och marknadsföringsverktyg.** Konfigurera domänautentisering så att de signerar med din `d=`, plus en egen returadress om det erbjuds. 3. **Kundtjänst, fakturering, CRM.** Samma sak som för ESP:er. Om ett verktyg inte kan signera med din domän, använd en underdomän som det kan signera för, eller verktygets egen domän. 4. **Verktyg som inte används längre.** Ta bort deras includes och selektorer. Räkna SPF-uppslagen igen efteråt. ### Dag 15: p=quarantine ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com" ``` Karantän innebär oftast att mejlet hamnar i skräpposten. Håll utkik efter legitima källor med `quarantine` som disposition. Vill du öva först ber `p=quarantine; t=y` mottagande servrar som följer RFC 9989 att tillämpa `none`, men RFC:n är bara några månader gammal och alla mottagande servrar respekterar inte `t` än. ### Dag 22: p=reject ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc-reports@example.com" ``` Mottagande servrar som respekterar `p=reject` avvisar underkända mejl redan under SMTP-sessionen, men RFC 9989 säger att de ska sätta mejlet i karantän när policyn är deras enda underlag, så en del hamnar i skräpposten. Samma RFC säger att en domän med `p=reject` ”INTE FÅR förlita sig enbart på SPF” och måste signera med DKIM, eftersom vidarebefordran förstör SPF men inte DKIM. Bekräfta först att varje källa har DKIM med alignment. Behåll `rua` för alltid. Nästa kvartals nya verktyg dyker upp i dina rapporter innan det dyker upp i supportkön. ### När du bör förlänga planen Enligt RFC 9989, avsnitt 7.4, ”BÖR INTE” domäner vars användare skriver till e-postlistor publicera `p=reject`, och de som ändå gör det bör först ligga ”minst en månad” på `p=none` och ”en lika lång period” på `p=quarantine`. Det gäller de flesta företags huvuddomäner, så ge där vart och ett av de två första stegen en månad. En underdomän som bara används av din ESP har ingen trafik från e-postlistor och kan hålla takten på 30 dagar. ### Policy för underdomäner: sp= och np= `p` gäller domänen och dess underdomäner. `sp` åsidosätter den för befintliga underdomäner, `np` för underdomäner som inte finns. En underdomän med en egen post använder den, och RFC 9989 ignorerar då `sp`. En dedikerad underdomän för utskick som `mail.example.com`, som används av en enda ESP med verifierad SPF och DKIM, kan publicera `p=reject` från dag ett. `p=none; sp=reject` på huvuddomänen skyddar underdomänerna medan du gör klart själva huvuddomänen, men blockerar BIMI. Parkerade domäner bör publicera `v=spf1 -all`, enligt Microsofts guide för SPF, plus `v=DMARC1; p=reject;` på `_dmarc`. ## Dag 30 och framåt: BIMI BIMI visar din logotyp bredvid autentiserade mejl i inkorgar som stöder standarden: | Krav | Detalj | Källa | |---|---|---| | DMARC-policy | `p=quarantine` eller `p=reject` på organisationsdomänen och From-domänen | BIMI-utkastet | | Policy för underdomäner | Om `sp` är publicerad, inte `none` | BIMI-utkastet | | Procentandel | Quarantine får inte ha `pct` under 100 | BIMI-utkastet | | Logotyp | SVG Tiny PS: `baseProfile="tiny-ps"`, `version="1.2"`, en ``, inga skript eller externa referenser, inga `x=` eller `y=` på rotelementet | BIMI Group | | Certifikat | Gmail kräver ett VMC (registrerat varumärke, bock) eller ett CMC (inget registrerat varumärke, ingen bock) | Google | [BIMI-utkastet](https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/) är i version 14 (maj 2026) och fortfarande ett Internet-Draft som är skrivet mot RFC 7489, därav `pct`. Utelämna `pct` och sätt inte `t=y`. Regeln om organisationsdomänen fångar avsändare på underdomäner: med `mail.example.com` på `p=reject` och `example.com` på `p=none` får mottagande servrar inte visa logotypen, så huvuddomänen måste också gå igenom hela planen. [BIMI Groups riktlinjer för SVG](https://bimigroup.org/creating-bimi-svg-logo-files/) rekommenderar en kvadratisk, centrerad logotyp på enfärgad bakgrund, under 32 KB. Google [lade till stöd för CMC i september 2024](https://workspaceupdates.googleblog.com/2024/09/gmail-additional-bimi-protections.html). Posten, enligt [BIMI Groups implementeringsguide](https://bimigroup.org/implementation-guide/): ```dns default._bimi.example.com. 3600 IN TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem" ``` Det tar månader att registrera ett varumärke, så börja med eventuellt VMC-arbete redan nu. ## Det här kräver Gmail, Yahoo och Microsoft Ingen av de tre kräver en tillämpad policy, bara en DMARC-post och alignment. | | Gmail | Yahoo | Outlook.com | |---|---|---|---| | Tröskel | Nära 5 000 per dag till personliga Gmail-konton, per primär domän, permanent när den väl har nåtts | Storskaliga avsändare, inget antal anges | Över 5 000 per dag till outlook.com, hotmail.com och live.com, per From-domän | | SPF och DKIM | Båda | Båda | Båda måste godkännas | | DMARC | Post krävs, `p=none` godtas | Minst `p=none`, `rua` rekommenderas starkt | Minst `p=none` | | Alignment | SPF eller DKIM | SPF eller DKIM, relaxed räcker | SPF eller DKIM | | Vid fel | Tillfälliga och permanenta avvisningar sedan november 2025 | Anges inte | `550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.` | Källor: [Googles riktlinjer för avsändare](https://support.google.com/mail/answer/81126) och [vanliga frågor](https://support.google.com/mail/answer/14229414), [Yahoos bästa praxis för avsändare](https://senders.yahooinc.com/best-practices/) samt Microsofts [meddelande från april 2025](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) och [supportsida om 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com). Microsoft började tillämpa kraven den 5 maj 2025, efter att en uppdatering den 29 april hade ändrat åtgärden från att flytta mejlen till skräpposten till att avvisa dem. Googles vanliga frågor säger att alignment för både SPF och DKIM ”så småningom kommer att bli ett krav för avsändare”, så se till att båda har alignment redan vecka 2. Om avregistrering och spamfrekvens kan du läsa i [vad som fortfarande gäller när en agent skickar dina mejl](/sv/blog/agent-email-deliverability) och i vår [guide om leveransbarhet](/sv/blog/email-deliverability). ## DMARC på en avsändardomän i Brew [Domänkonfigurationen](https://docs.brew.new/get-started/verify-your-sending-domain) i Brew ber om: - **DKIM**, en TXT-post på en `._domainkey`-selektor under din avsändardomän. Obligatorisk. - **SPF**, en MX-post och en TXT-post på `send.<your sending domain>`, returadressen för Brew. Obligatorisk. - **DMARC**, en TXT-post på `_dmarc.<your sending domain>`. Valfri, men rekommenderas. - En **CNAME**-post för klickspårning, bara om du har en egen underdomän för spårning. Domänen kan skicka så snart SPF och DKIM är verifierade, och Brew föreslår ett DMARC-värde som passar: ```dns ; dedicated sending subdomain, e.g. mail.example.com _dmarc.mail.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@mail.example.com" ; apex domain, or a domain Brew can't prove is dedicated _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com" ``` En dedikerad underdomän får `p=reject` eftersom ingenting skickas från den innan SPF och DKIM för Brew är verifierade. En huvuddomän får `p=none` eftersom dina andra verktyg troligen också skickar i dess namn, så följ planen ovan. Alignment förblir relaxed eftersom returadressen `send.<domain>` bara stämmer överens med From-domänen i relaxed-läget. Brew läser den aktuella posten på `_dmarc.<sending domain>` när domänen läggs till, när den verifieras och vid varje ny kontroll. **Domäner** visar resultatet, liksom `get_domain_health` via MCP och `GET /v1/domains/{domainId}/health`: - **`dmarc_missing`**, en varning med den exakta post som ska läggas till. - **`dmarc_invalid`**, när det finns två DMARC-poster på namnet, eller en felaktig version, policy eller dubblerade taggar. Den anger vilken post som ska raderas. - **Verifierad**, när exakt en giltig post har hittats. Den automatiska DNS-konfigurationen skriver bara DMARC när det inte finns någon post, så den skapar aldrig en dubblett. Kontrollen görs på avsändardomänen, inte på domänen ovanför, så ge varje underdomän för utskick en egen post, även den för [transaktionsmejl](/sv/blog/transactional-emails) om du delar upp de två som dokumentationen rekommenderar. Det är i din rapporttjänst för `rua` som du läser rapporterna och bestämmer när det är dags att gå över till reject. ## Vanliga frågor ### Hur länge ska jag ligga kvar på p=none innan jag går över till quarantine? Tills en hel veckas rapporter visar att varje legitim källa klarar SPF eller DKIM med alignment, oftast en till två veckor för en underdomän för utskick. För en domän som medarbetarna använder för vardaglig e-post rekommenderar RFC 9989 minst en månad. Två år på `p=none` utan att någon läser rapporterna är inte värt något. ### Är DMARC-taggen pct föråldrad? Ja. RFC 9989 klassar `pct` som ”historisk” och ersätter de enda tillförlitliga värdena med `t`: `t=y` fungerar som `pct=0` och `t=n` som `pct=100`. Äldre mottagande servrar kan fortfarande läsa `pct`, men tillämpade aldrig mellanliggande värden konsekvent, så ta hela steg. ### Blockerar p=reject mina vidarebefordrade mejl? Vanlig vidarebefordran förstör oftast SPF men inte DKIM, så DKIM med alignment godkänns fortfarande. E-postlistor som ändrar ämnesraden eller sidfoten förstör DKIM, och vissa skriver om From-headern för att kompensera. DKIM med alignment överallt är ditt bästa skydd. ### Kräver Gmail och Yahoo p=reject? Nej. Båda kräver att storskaliga avsändare publicerar DMARC och godtar `p=none`, liksom Microsoft för över 5 000 meddelanden per dag till Outlook.com. En tillämpad policy stoppar förfalskning och krävs för BIMI, men ingen av de tre kräver den. ### Behöver jag ett VMC för BIMI? För Gmail behöver du antingen ett VMC, som kräver ett registrerat varumärke och visar en bock, eller ett CMC, som visar logotypen utan bock. Enligt [BIMI Group](https://bimigroup.org/understanding-bimi-certificate-types/) visar några leverantörer, bland annat Yahoo och Fastmail, även egendeklarerade logotyper utan certifikat.