Defaults.Exposed › Remedieri › Guides

DKIM trece dar DMARC eșuează: Capcana semnăturii implicite gappssmtp.com / onmicrosoft.com (2026)

Publicat 2026-07-08

Date din 2026-06-29 · metodologie v7. Date agregate din recensământul a 261 milioane de domenii clasificate. Consultați cum clasificăm.

E-mailul dvs. trece DKIM cu semnătura implicită a furnizorului — d= terminând în gappssmtp.com (Google Workspace) sau onmicrosoft.com (Microsoft 365) — dar acel domeniu nu se potrivește cu domeniul dvs. From, deci DMARC nu obține un pass aliniat. Activați semnarea cu domeniu personalizat pentru a o remedia. Din 12,145,313 domenii care autorizează serverele de e-mail ale Google, doar 18.5% aplică DMARC, conform recensământului Defaults.Exposed al 261,086,232 de domenii clasificate.

Remedierea este una dintre cele mai curate din autentificarea e-mailului: activați semnarea DKIM cu domeniu personalizat. Pe Google Workspace acesta este ecranul „Authenticate email” al consolei de administrare — generați cheia, publicați o înregistrare TXT, porniți-o. Pe Microsoft 365 este pagina DKIM a portalului Defender — publicați două CNAMEs de selector, activați. Douăzeci de minute de lucru și DMARC obține în final pass-ul aliniat pentru care a așteptat.

De ce trece DKIM dar eșuează totuși DMARC?

Deoarece DMARC nu întreabă „există o semnătură DKIM validă?” — întreabă „există o semnătură DKIM validă pentru domeniul din antetul From?” A doua condiție se numește aliniere și este întregul scop al DMARC: dovedind că domeniul pe care îl vede destinatarul este domeniul care a semnat.

Implicit, Google Workspace semnează e-mailul cu un domeniu precum yourdomain-com.20230601.gappssmtp.com (data stamp variază per domeniu) și Microsoft 365 semnează cu yourtenant.onmicrosoft.com. Ambele semnături sunt criptografic valide — verificatoarele DKIM spun pass — dar domeniul d= aparține Google sau Microsoft, nu dvs. Chiar și sub alinierea relaxată a DMARC, care cere doar potrivirea domeniilor organizaționale, gappssmtp.com nu este yourdomain.com. Nicio potrivire, niciun pass aliniat și dacă SPF nu se aliniază nici el (adesea nu poate — receptorii evaluează SPF față de domeniul Return-Path, nu antetul From, și redirecționarea îl strică complet), DMARC eșuează.

Aceasta este capcana definitorie a valorilor implicite ale furnizorilor: valoarea implicită vă oferă livrabilitate, nu protecție — alinierea este tura lipsă a cheii. Recensământul arată câți expeditori se opresc la valoarea implicită: din cele 12,145,313 domenii care autorizează serverele de e-mail ale Google prin _spf.google.com (din 138,927,207 publicatori SPF la nivel mondial), doar 18.5% aplică DMARC. Tabloul Microsoft are aceeași formă: 10,205,070 domenii autorizează spf.protection.outlook.com, 85.0% poartă înregistrarea SPF strictă pe care instalarea M365 le-o dă — și doar 21.7% aplică DMARC. Comparație completă în tabelul de clasament SPF al furnizorilor de e-mail.

Capcana este invizibilă în utilizarea de zi cu zi: e-mailul se livrează, testele de inbox arată bine, nimic nu dă erori — până când publicați o politică DMARC și propriul dvs. e-mail începe să o eșueze. Scanarea gratuită evidențiază exact acest decalaj.

Cum detectez capcana semnăturii implicite în Authentication-Results?

Deschideți un mesaj pe care l-ați trimis (la o căsuță poștală Gmail sau Outlook), vizualizați sursa originală/brută și găsiți antetul Authentication-Results. Indicatorul este un DKIM pass cu d= greșit — un exemplu primit de Gmail arată astfel:

Authentication-Results: mx.google.com;
       dkim=pass [email protected];
       spf=pass smtp.mailfrom=yourdomain.com;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

Citiți-l ca trei întrebări:

Pe e-mailul primit de Microsoft, aceeași poveste apare ca dkim=pass (signature was verified) header.d=yourtenant.onmicrosoft.com alături de compauth=fail — tipar acoperit în ghidul de respingere Outlook.

Dacă antetul dvs. arată în schimb atât dkim=pass cât și spf=pass cu un eșec DMARC, vă aflați în cazul mai larg al alinierii — ghidul DMARC eșuează dar SPF și DKIM trec parcurge alinierea relaxată față de strictă în detaliu.

Cum activez semnarea DKIM cu domeniu personalizat?

1. Rulați scanarea gratuită la defaults.exposed înainte de a atinge orice. Arată dacă domeniul dvs. are DKIM aliniat, care este de fapt politica dvs. DMARC și dacă altceva (SPF, sintaxa înregistrării DMARC) vă va bloca totuși după această reparație — astfel faceți întreaga muncă o dată.
2. Identificați cu ce implicit semnați. Verificați header.d= în Authentication-Results ca mai sus: gappssmtp.com înseamnă valoarea implicită Google Workspace, onmicrosoft.com înseamnă valoarea implicită Microsoft 365.
3. Google Workspace: generați și publicați propria cheie. În consola de administrare mergeți la Apps → Google Workspace → Gmail → Authenticate email, selectați domeniul și faceți clic pe Generate New Record (2048 de biți dacă gazda DNS nu poate stoca). Publicați înregistrarea TXT pe care o dă la google._domainkey.yourdomain.com, așteptați DNS (până la 48 de ore), apoi — pasul pe care oamenii îl ratează — faceți clic pe Start authentication. Generarea înregistrării nu face nimic până nu activați semnarea. Ghid complet: configurați DKIM pe Google Workspace.
4. Microsoft 365: publicați cele două CNAMEs ale selectorului și activați. În portalul Defender mergeți la Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM, selectați domeniul personalizat și creați cheile. Publicați ambele CNAMEs — selector1._domainkey și selector2._domainkey, pointând la țintele pe care vi le arată Microsoft (copiați țintele exacte din portal — domeniile activate înainte de mai 2025 se termină în .onmicrosoft.com al chiriașului; cele mai noi se termină în .dkim.mail.microsoft) — apoi activați semnarea. Două selectoare nu este opțional: Microsoft rotește cheile între ele. Ghid complet: configurați DKIM pe Microsoft 365.
5. Verificați noua semnătură. Trimiteți un mesaj proaspăt la o căsuță poștală externă și re-verificați Authentication-Results: dkim=pass ar trebui să arate acum header.d=yourdomain.com. Dacă panoul DNS a adăugat automat zona la ținta CNAME sau a denaturat valoarea TXT lungă, semnătura nu va comuta — particularitățile panoului, nu furnizorul, cauzează cele mai multe eșecuri aici.
6. Re-scanați și folosiți pass-ul aliniat undeva. Confirmați că scanarea arată DKIM aliniat, apoi folosiți-l: o politică DMARC la p=none nu protejează nimic. Dintre toate 261,086,232 domenii clasificate, doar 10.59% aplică DMARC (date din 2026-06-29) — DKIM aliniat este ceea ce face aplicarea sigur de ajustat. Începeți la cum să corectați DMARC.

Va strica activarea DKIM personalizat ceva?

Nu — aceasta este reparația rară din autentificarea e-mailului cu practic nicio rază de explozie: e-mailul care a ieșit cu semnătura implicită pur și simplu iese cu una mai bună, iar furnizorul continuă să gestioneze cheile (Microsoft rotește automat între cele două selectoare). Modul real de eșec este a face jumătate de treabă — publicând TXT-ul Google dar fără a face clic pe Start authentication sau publicând un selector M365 în loc de ambele. Și nu ștergeți înregistrările DNS mai târziu „pentru ordine”; semnarea se oprește în momentul în care cheia dispare.

O notă de domeniu: aceasta repară e-mailul trimis prin Google sau Microsoft. Instrumentele de newsletter și CRM-urile semnează și ele cu valorile lor implicite și fiecare are nevoie de DKIM cu domeniu personalizat activat — acel tipar și regulile expeditorului de masă Gmail care îl cer acum sunt acoperite în ghidul 550-5.7.26.

Întrebări frecvente

DKIM arată „pass” pe fiecare instrument de testare — de ce trebuie remediat ceva? Deoarece instrumentele răspund la o întrebare mai restrânsă decât DMARC. Semnătura este validă — dar este a gappssmtp.com sau onmicrosoft.com, nu a dvs., deci nu contează pentru alinierea DMARC. De aceea atât de mulți expeditori se opresc la valoarea implicită: din 12,145,313 domenii care autorizează Google, doar 18.5% aplică DMARC (date din 2026-06-29).

Alinierea DMARC relaxată permite trecerea semnăturii implicite? Nu. Alinierea relaxată slăbește doar potrivirea la domeniile organizaționale — mail.yourdomain.com se aliniază cu yourdomain.com. Domeniul organizațional al semnăturii implicite este gappssmtp.com sau onmicrosoft.com, care nu împărtășește nimic cu al dvs. Niciun mod de aliniere nu salvează un d= terț.

Semnătura gappssmtp.com / onmicrosoft.com este rea? Ar trebui s-o elimin? Nu este rea — asigură că e-mailul dvs. poartă o oarecare semnătură validă, ceea ce ajută la filtrarea spam. Pur și simplu nu este a dvs. Nu o eliminați; o înlocuiți activând semnarea cu domeniu personalizat.

Domeniul meu este pe Microsoft 365 cu SPF strict — sunt deja protejat? Probabil nu: acea înregistrare strictă este valoarea implicită M365 care își face treaba. Din 10,205,070 domenii care autorizează spf.protection.outlook.com, 85.0% au SPF strict dar doar 21.7% aplică DMARC (date din 2026-06-29). SPF se strică și la redirecționare, deoarece este evaluat față de Return-Path mai degrabă decât față de antetul From — DKIM aliniat este piciorul care supraviețuiește, ceea ce este exact de ce această reparație contează.

Cât timp durează reparația? Munca în consolă este de minute per furnizor. DNS este așteptarea: Google spune să permiteți până la 48 de ore înainte de a porni autentificarea; CNAMEs-urile Microsoft sunt de obicei live în câteva ore. Bugetați o zi de lucru de la cap la coadă, majoritatea din ea așteptând.

Trimiteți proprietarului raportul

Dacă reparați asta pentru un client sau angajatorul dvs., încheiați cu dovezi. Re-rulați scanarea gratuită odată ce noua semnătură este live și trimiteți raportul clasificat proprietarului afacerii: datat, limbaj simplu, arătând DKIM aliniat cu domeniul lor. Acesta este artefactul pentru reînnoirea asigurării cibernetice și pentru următorul chestionar de securitate al furnizorilor — dovada că domeniul se autentifică ca el însuși, nu ca un sub-chiriaș al gappssmtp.com.

Verificați gratuit alinierea DKIM

Vedeți dacă e-mailul dvs. semnează ca propriul domeniu — și exact ce trebuie corectat — privat și numai pentru proprietar.

Verificați domeniul → · DMARC eșuează dar SPF și DKIM trec → · Corectați DKIM → · Configurați DKIM pe Google Workspace → · Doar date agregate. Date stocate și procesate în UE.