Un mensaje puede mostrar el nombre de una empresa familiar y al mismo tiempo utilizar una dirección de correo electrónico completamente diferente. También puede mostrar la dirección de su empresa mientras el servicio de envío autentica sólo su propio dominio. Comprensión DMARC comienza por separar esas identidades.
DMARC significa autenticación, informes y conformidad de mensajes basados en dominio. Evalúa el uso autenticado del dominio en la dirección De del mensaje y conecta ese resultado con la política publicada del propietario del dominio. Es una evaluación a nivel de dominio, no un veredicto sobre la persona, la solicitud o el archivo adjunto.
Encuentre la dirección detrás del nombre del remitente
Supongamos que una aplicación de correo muestra este remitente ficticio:
Cuentas de ejemplo < notices@shop.example.com >Cuentas de ejemplo es el nombre para mostrar. avisos es la parte anterior a la arroba. shop.example.com es el dominio en la dirección De, llamado Dominio de autor en DMARC .
Es posible que la vista compacta de la aplicación de correo muestre solo el nombre para mostrar. Abra los detalles del remitente o el mensaje original para identificar la dirección real. Un logotipo, un nombre y una línea de asunto reconocible no establecen esa relación de dominio.
Los ejemplos de esta guía suponen un mensaje normal y bien formado con un dominio de autor. Los campos De mal formados o ambiguos requieren su propio manejo de formato de mensaje; no invente una identidad preferida a partir de lo que muestre una aplicación de correo.
Mantenga las otras direcciones en sus roles adecuados.
Un correo electrónico tiene una conversación de entrega SMTP , así como los encabezados y el cuerpo que las personas leen. La identidad de devolución del sobre admite el manejo del estado de entrega y normalmente es la identidad evaluada por SPF para correo ordinario. Puede diferir de De.
A firma DKIM proporciona otro dominio en su valor d=. Un mensaje puede tener varias firmas, cada una con su propio dominio y resultado. Responder a es diferente nuevamente: influye hacia dónde se dirige una respuesta, no qué dominio de autor evalúa DMARC .
| Artículo | Pregunta que ayuda a responder |
|---|---|
| Del dominio | ¿Qué dominio de autor reclamado se está evaluando? |
| Identidad del sobre | ¿Qué dominio se está evaluando para la autorización SPF ordinaria? |
| DKIM d= domain | ¿Qué dominio está asociado con esta firma? |
| Responder a | ¿Hacia dónde se dirige una respuesta? |
| Nombre para mostrar | ¿Qué nombre se presenta al lector? |
Estos campos pueden diferir legítimamente. La tarea es comprender sus relaciones en lugar de exigir que todas las direcciones mostradas sean idénticas.
Comprender la relación llamada alineación
SPF puede pasar por el dominio de sobre de un servicio de envío. DKIM puede verificar una firma del dominio de firma de ese servicio. Luego, DMARC pregunta si una identidad autenticada pasajera se alinea con el dominio del autor.
Estricto alineación requiere una coincidencia exacta de dominio. La alineación relajada utiliza la relación organización-dominio aplicable. No determine ese límite simplemente tomando las dos últimas etiquetas y no trate dos marcas de apariencia similar como dominios alineados.
Para aprobar DMARC a nivel de mensaje, al menos una ruta SPF o DKIM calificada debe aprobarse y alinearse. Una firma de paso de un dominio no relacionado no puede proporcionar esa ruta simplemente porque la empresa posee una cuenta con el servicio.
Sigue dos mensajes ficticios.
El siguiente es un ejemplo de enseñanza sintético, no un mensaje de cliente capturado o redactado. Supongamos que se encuentra la política DMARC aplicable y que los resultados indicados provienen de un sistema receptor confiable.
Ambos mensajes tienen From en shop.example.com . Sus identidades difieren de la siguiente manera:
| Observación | Mensaje A | Mensaje B |
|---|---|---|
| SPF | Pase para returns.example.net | Pase para returns.example.net |
| DKIM | Pase con d=shop.example.com | Pasar con d=dispatch.example.org |
| Camino de paso alineado | Coincidencias DKIM desde exactamente | Ninguna identidad pasajera se alinea |
| Validación DMARC | Aprobar | Fallar |
El mensaje A tiene una ruta DKIM que coincide exactamente. No es necesario cambiar el nombre de su identidad SPF separada para que se pase ese resultado DMARC a nivel de mensaje.
El mensaje B autentica dominios no relacionados con su dominio De. Por lo tanto, dos pasadas sin procesar no producen ningún camino alineado. Si se trata de un remitente autorizado que necesita reparación, siga las instrucciones guía de solución de problemas de alineación. Esa investigación es diferente a decidir que cada mensaje con este patrón es malicioso.
Separar el resultado de lo que hace el receptor
El propietario de un dominio publica la política DMARC en DNS con un nombre _dmarc aplicable. La póliza expresa la valoración del propietario sobre el mal uso. No configura la identidad de firma de una aplicación ni determina la acción final de cada receptor.
Los receptores también evalúan información fuera de DMARC . En consecuencia, un pase no promete ubicación en la bandeja de entrada y un fallo no establece de forma independiente un ataque bloqueado. El guía de selección de políticas explica cómo el uso real de un dominio afecta la decisión del propietario.
Los informes pueden ayudar al propietario a investigar cómo aparece su dominio en el correo observado. Los informes son comentarios de los receptores participantes, no un libro de contabilidad completo de cada mensaje enviado. Mantenga las observaciones reportadas separadas de la autorización comercial y los resultados finales de la entrega.
Leer un resultado aprobado sin sobreleerlo
Utilice los resultados de autenticación producidos por el límite de recepción de confianza relevante. Un remitente puede insertar un encabezado que reclame un pase; la existencia de ese texto no lo hace confiable.
Incluso un pase genuinamente alineado tiene límites. Una cuenta autorizada comprometida puede enviar correo autenticado. Un dominio no relacionado puede autenticar sus propios mensajes mientras presenta un nombre para mostrar engañoso. DMARC no inspecciona la veracidad de una factura ni aprueba una instrucción de pago.
La explicación útil es específica: este mensaje recibido tenía un dominio autenticado de paso que cumplía la relación requerida con su dominio De. Ésa es una valiosa señal de identidad. Mantenga junto a ella la protección de la cuenta, la evaluación del contenido y la verificación independiente de solicitudes confidenciales.
Para la implementación, continúe con crear y verificar un registro DMARC. Para la propiedad entre aplicaciones, utilice el inventario del remitente. Ambas cosas se vuelven más fáciles una vez que queda claro el dominio real que se está evaluando.
Traza un resultado en cinco líneas
Utilice esta breve hoja de trabajo cuando un mensaje se describa como "autenticado". Comience con la dirección, no con el nombre de la empresa que aparece al lado.
- De: escriba el dominio después de @ en la dirección De actual.
- Evidencia: utilice los resultados confiables del sistema receptor. Registre el dominio SPF y cada dominio DKIM d= que pasa por separado.
- Relación: compare cada identidad pasajera con De bajo el modo estricto o relajado aplicable. El nombre de una cuenta de proveedor no coincide con un dominio.
- Resultado: con una política aplicable y sin errores DNS sin resolver, una ruta de paso alineada es suficiente. Si no hay ninguno, el mensaje falla DMARC . Ninguna política descubierta significa que DMARC no se aplica; un error de consulta DNS requerido no es simplemente un paso o un fracaso.
- Significado: registre el resultado de la identidad por separado de la entrega y si es seguro actuar sobre la solicitud.
Para el mensaje A anterior, la explicación es: " DKIM aprobado para shop.example.com , que coincide exactamente con From; esto proporciona un pase DMARC ". No es: “La factura está aprobada”.
Compruebe el Pasos de procesamiento DMARC y el Límite de confianza Authentication-Results para estas distinciones.