Marco de políticas del remitente (SPF)
El registro del Marco de políticas del remitente (SPF) se creó como una forma de evitar la falsificación de la dirección del remitente. Es un estándar abierto que actúa como una forma de autenticación de correo electrónico. Excepto que, en lugar de impedir que ciertos correos electrónicos lleguen a su bandeja de entrada, evita que se envíen correos electrónicos no autorizados en su nombre.
Al implementar un registro SPF, puede especificar qué servidores pueden enviar correos electrónicos en nombre de su dominio. Esto ayuda a prevenir la suplantación de dominio. Y como propietario del dominio, publica su política y el servidor receptor verificará (según la política) para verificar su validez.
Ejemplo de registro SPF
{
"Status": 0,
"TC": false,
"RD": true,
"RA": true,
"AD": true,
"CD": false,
"Question": [
{
"name": "zerobounce.net.",
"type": 99
}
],
"Answer": [
{
"name": "zerobounce.net.",
"type": 99,
"TTL": 299,
"data": "\"v=spf1 ip4:185.25.156.0/24 include:_spf.google.com include:mail.zendesk.com include:spf.tapfiliate.com -all\""
}
]
}
¿Cómo configuro mi registro SPF?
Puedes usar el Generador de registros SPF ZeroBounce para configurar rápidamente el tuyo.
Una vez que haya creado su registro SPF, deberá agregarlo a sus registros DNS. Sus registros DNS pueden ser administrados por su empresa de alojamiento, en sus propios servidores o en un proveedor externo.
TXT (TYPE 16) o SPF (TYPE 99) Tipos de registros en DNS
Tenga en cuenta: SPF (TYPE 99) ahora está obsoleto
Cuando se introdujo el estándar, su registro SPF se almacenó como un registro TXT (TYPE 16). En 2005, se introdujo un nuevo estándar, SPF (TYPE 99). Originalmente, SPF se creó para reemplazar el registro TXT original. Sin embargo, los servidores de correo volvieron al registro TXT original y SPF (TIPO 99) quedó obsoleto.
Ahora, aunque SPF (TYPE 99) es obsoleto, se recomienda tener los registros presentes. Si su cadena de autenticación contiene TYPE 99 y TYPE 16, se lo considerará "compatible con SPF". Si solo tiene TYPE 16, se lo considerará "Cumple".
Llaves de dominio (dkim)
DomainKeys es un protocolo de autenticación de correo electrónico obsoleto desarrollado por Yahoo. Fue creado para verificar la integridad del mensaje del nombre de dominio de cualquier remitente.
DomainKeys fue reemplazado por el método de autenticación de correo electrónico de Correo Identificado de DomainKeys (DKIM). A pesar de que este estándar está reemplazado, muchos servidores de correo (antiguos y nuevos) aún lo usan, y si tiene la opción, debe implementarlo.
¿Cómo funcionan DomainKeys?
Como propietario del dominio, generaría 2 claves; uno privado y uno público, para firmar todos los correos electrónicos salientes de su servidor de correo. La clave pública sigue el siguiente formato:
{
"Status": 0,
"TC": false,
"RD": true,
"RA": true,
"AD": true,
"CD": false,
"Question": [
{
"name": "zb._domainkey.zerobounce.net.",
"type": 16
}
],
"Answer": [
{
"name": "zb._domainkey.zerobounce.net.",
"type": 16,
"TTL": 299,
"data": "\"v=DKIM1; k = rsa;
p = MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAjxHiM + LhOfpCTgqZCnmZgX8S0766oDeOx2XkVJqqxMQgCp4CNqzGBLMk / wc2wwWYAsSI5tSW6vSTigkYwA2Y73Ufhc4c1GGpp8oN / d + OJqTNHIqJO4fk7RvTryJbfG8IxFNKefTMMVdcVZcElqGNiflpC5PgbJmk9cNMVcAxiBgYNmg8ofmjIHX8MvbMr3tN / \ "\" A2XRacZtpvlukrHwJYnRzb1gK7W0l / 7 QEH / Ad8uIQa / fSaf9oWWnEk7caA7aKRMln / heayxP42XfXMfsBGXGN8ZkrPtevXkmECl21LYKwP + rlEtxS55vK5cgJjtFPI2ooAxRfkQlh1W9CediWXEzwIDAQAB \"
}
],
"Comment": "Response from 162.159.0.218."
}
Como puede ver en nuestro registro, la clave pública comienza con "P =" y nuestro método de encriptación se denota por "K =" . Suponiendo que su software de correo electrónico está habilitado para DomainKey, su clave privada se utiliza para generar una firma digital. Esto está incrustado en los encabezados de sus correos electrónicos. Para que su correo electrónico se entregue a la bandeja de entrada del destinatario, la clave pública y la firma digital deben coincidir.
¿Qué es un registro de política DomainKeys?
Cuando usa DomainKeys, puede publicar declaraciones de políticas en DNS que ayudan a los receptores de correo electrónico a comprender cómo deben tratar su correo electrónico. Hay tres declaraciones principales que se pueden publicar:
"t=y" - Which means that your email DomainKeys are in test mode.
"o=-" - All email from your domain is digitally signed.
"o=~" - Some email from your domain is digitally signed.
"n=*" - n stands for notes. Replace the * symbol, with any note you like
¿Cómo configurar un registro de política DKIM?
Para configurar su DomainKey, deberá habilitar esto a través de su software de correo electrónico. Esta característica generalmente está incorporada, pero para habilitarla como se describió anteriormente, tendrá que hacer el trabajo preliminar. Tenga en cuenta: si su software de correo electrónico carece de esta funcionalidad, puede ser el momento de cambiar a uno nuevo.
Si su software de correo electrónico requiere que las claves RSA se generen por separado, agregue la clave privada a sí mismo y la clave pública a su DNS.
Para generar sus claves privadas / públicas DKIM, puede usar nuestro asistente aquí: Generador DKIM .
Identificadores de correo electrónico: alineaciones de identidad SPF y DKIM
Los servidores de correo usan dos métodos diferentes para determinar SPF y DKIM : estricto y relajado . En el ejemplo a continuación, verá que la dirección FROM utiliza zerobounce.net como dominio. Esto se compara con "ruta de retorno (remitente envuelto)" para SPF o la "d =" etiqueta en la firma de dominio para DKIM .
Ejemplo de alineación de identificador de correo electrónico estricto SPF
A continuación se muestra un encabezado de muestra de un correo electrónico, preste atención al dominio resaltado en rojo .
Return-path: <mailtest@Zerobounce.net>
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
d=zerobounce.net; s=secure;
h=from;
bh=o3fu6xyRMvsfFmwnP6/SlW7vJ99RrE0ChDczpE+HayQ=;
b=ODihl0g56Upldz3ETsFkFlY5EyPNJecpftbJxQHaBzHVOOzqpr0NaJTEBZ3aOLOR0
piHemvHGHtVtEM0jH0RUJ2MG22gEuUnXA8No6mqgJEs47P/9APKG45SVy7O1XNpK7
2dzD8iGgb4aguGwvYMO1lrsv+I7Wtj0J+Ev98b4Xg=
Received: from [168.144.32.46] (VPS9517.ad3.softcom.biz [168.144.32.46])
by mail.zerobounce.net with SMTP;
Sun, 8 Jul 2020 23:53:06 -0400
Subject: Your Email Authentication Results!
Date: Sun, 08 Jul 2020 23:53:06 -0400
From: "ZeroBounce" <mailtest@Zerobounce.net>
Si las dos secciones resaltadas en rojo coincidir exactamente, se considera que es Cumplimiento estricto de SPF .
Ejemplo de alineación de identificador de correo electrónico estricto de DKIM
A continuación se muestra un encabezado de muestra de un correo electrónico. Presta atención al dominio resaltado en rojo .
Return-path: <mailtest@zerobounce.net>
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
d=Zerobounce.net; s=secure;
h=from;
bh=o3fu6xyRMvsfFmwnP6/SlW7vJ99RrE0ChDczpE+HayQ=;
b=ODihl0g56Upldz3ETsFkFlY5EyPNJecpftbJxQHaBzHVOOzqpr0NaJTEBZ3aOLOR0
piHemvHGHtVtEM0jH0RUJ2MG22gEuUnXA8No6mqgJEs47P/9APKG45SVy7O1XNpK7
2dzD8iGgb4aguGwvYMO1lrsv+I7Wtj0J+Ev98b4Xg=
Received: from [168.144.32.46] (VPS9517.ad3.softcom.biz [168.144.32.46])
by mail.zerobounce.net with SMTP;
Sun, 8 Jul 2020 23:53:06 -0400
Subject: Your Email Authentication Results!
Date: Sun, 08 Jul 2020 23:53:06 -0400
From: "ZeroBounce" <mailtest@Zerobounce.net>
Si las dos secciones resaltadas en rojo coincidir exactamente, se considera que es Cumplimiento estricto de DKIM .
Ejemplo de alineación de identificador de correo electrónico relajado de SPF
A continuación se muestra un encabezado de muestra de un correo electrónico. Presta atención al dominio resaltado en naranja .
Return-path: <mailtest@amazing.zerobounce.net>
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
d=zerobounce.net; s=secure;
h=from;
bh=o3fu6xyRMvsfFmwnP6/SlW7vJ99RrE0ChDczpE+HayQ=;
b=ODihl0g56Upldz3ETsFkFlY5EyPNJecpftbJxQHaBzHVOOzqpr0NaJTEBZ3aOLOR0
piHemvHGHtVtEM0jH0RUJ2MG22gEuUnXA8No6mqgJEs47P/9APKG45SVy7O1XNpK7
2dzD8iGgb4aguGwvYMO1lrsv+I7Wtj0J+Ev98b4Xg=
Received: from [168.144.32.46] (VPS9517.ad3.softcom.biz [168.144.32.46])
by mail.zerobounce.net with SMTP;
Sun, 8 Jul 2020 23:53:06 -0400
Subject: Your Email Authentication Results
Date: Sun, 08 Jul 2020 23:53:06 -0400
From: "ZeroBounce" <mailtest@awesome.zerobounce.net>
Si las dos secciones resaltadas en naranja los subdominios no coinciden, esto se considera Cumplimiento relajado de SPF
DKIM Relaxed Email Identifier Alignment Example
A continuación se muestra un encabezado de muestra de un correo electrónico. Presta atención al dominio resaltado en naranja .
Return-path: Firma DKIM: v = 1; a = rsa-sha256; c = simple / simple; d =amazing.zerobounce.net; s = seguro; h = de; bh = o3fu6xyRMvsfFmwnP6 / SlW7vJ99RrE0ChDczpE + HayQ =; b = ODihl0g56Upldz3ETsFkFlY5EyPNJecpftbJxQHaBzHVOOzqpr0NaJTEBZ3aOLOR0 piHemvHGHtVtEM0jH0RUJ2MG22gEuUnXA8No6mqgJEs47P / 9 APKG45SVy7O1XNpK7 2 dzD8iGgb4aguGwvYMO1lrsv + I7Wtj0J + Ev98b4Xg = Recibido: de [168.144.32.46] (VPS9517.ad3.softcom.biz [168.144.32.46]) por mail.zerobounce.net con SMTP; Dom, 8 julio 2020 23:53: 06 - 0400 Asunto: Fecha de resultados de autenticación de correo electrónico: Dom, 08 julio 2020 23:53: 06 - 0400 De: "ZeroBounce" <mailtest@awesome.zerobounce.net>
Si las dos secciones resaltadas en naranja coincidir exactamente, se considera que es Cumplimiento relajado de DKIM .
Ejemplo de alineación de identificador de correo electrónico no alineado SPF
A continuación se muestra un encabezado de muestra de un correo electrónico. Presta atención al dominio resaltado en azul .
Return-path: <mailtest@ejemplo.com>
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
d=zerobounce.net; s=secure;
h=from;
bh=o3fu6xyRMvsfFmwnP6/SlW7vJ99RrE0ChDczpE+HayQ=;
b=ODihl0g56Upldz3ETsFkFlY5EyPNJecpftbJxQHaBzHVOOzqpr0NaJTEBZ3aOLOR0
piHemvHGHtVtEM0jH0RUJ2MG22gEuUnXA8No6mqgJEs47P/9APKG45SVy7O1XNpK7
2dzD8iGgb4aguGwvYMO1lrsv+I7Wtj0J+Ev98b4Xg=
Received: from [168.144.32.46] (VPS9517.ad3.softcom.biz [168.144.32.46])
by mail.zerobounce.net with SMTP;
Sun, 8 Jul 2020 23:53:06 -0400
Subject: Your Email Authentication Results
Date: Sun, 08 Jul 2020 23:53:06 -0400
From: "ZeroBounce" <mailtest@Zerobounce.net>
Si las dos secciones resaltadas en azul los dominios no coinciden, esto se considera Cumplimiento no alineado de SPF .
Ejemplo de alineación de identificador de correo electrónico no alineado DKIM
A continuación se muestra un encabezado de muestra de un correo electrónico. Presta atención al dominio resaltado en azul .
Return-path: Firma DKIM: v = 1; a = rsa-sha256; c = simple / simple; d =ejemplo.com; s = seguro; h = de; bh = o3fu6xyRMvsfFmwnP6 / SlW7vJ99RrE0ChDczpE + HayQ =; b = ODihl0g56Upldz3ETsFkFlY5EyPNJecpftbJxQHaBzHVOOzqpr0NaJTEBZ3aOLOR0 piHemvHGHtVtEM0jH0RUJ2MG22gEuUnXA8No6mqgJEs47P / 9 APKG45SVy7O1XNpK7 2 dzD8iGgb4aguGwvYMO1lrsv + I7Wtj0J + Ev98b4Xg = Recibido: de [168.144.32.46] (VPS9517.ad3.softcom.biz [168.144.32.46]) por mail.zerobounce.net con SMTP; Dom, 8 julio 2020 23:53: 06 - 0400 Asunto: Fecha de resultados de autenticación de correo electrónico: Dom, 08 julio 2020 23:53: 06 - 0400 De: "ZeroBounce" <mailtest@Zerobounce.net>
Si las dos secciones resaltadas en azul coincidir exactamente, se considera que es Cumplimiento no alineado de DKIM .
¿Se necesita DMARC?
Entonces, ¿por qué estamos mencionando DMARC?
DMARC (Autenticación, informe y conformidad de mensajes basados en el dominio) incluye etiquetas opcionales, que ayudarán a los servidores de correo a validar sus mensajes a un estándar más alto. ADKIM y ASPF son las etiquetas que representan el modo de alineación para DKIM y SPF. Pueden tener dos valores: "r" para relajado y "s" por estricto Consulte las tablas a continuación para ver los escenarios de aprobación / falla:
Alineamiento relajado
- Dominio 'MailFrom'
- Encabezado 'De' Dominio
- RESULTADO
- mail.example.com
- mail.example.com
- PASAR
- mail.example.com
- ejemplo.com
- PASAR
- ejemplo.mail.com
- ejemplo.com
- FALLAR
Alineamiento estricto
- Dominio 'MailFrom'
- Encabezado 'De' Dominio
- RESULTADO
- mail.example.com
- mail.example.com
- PASAR
- mail.example.com
- ejemplo.com
- FALLAR
- ejemplo.mail.com
- ejemplo.com
- FALLAR
Cómo configurar tus contactos de abuso
La Cámara de Compensación de Abusos de la Red ( http://www.abuse.net ejecuta y mantiene una base de datos de contactos de abuso. Aquí, el propietario de un dominio puede registrar su información de contacto de correo electrónico de abuso. Si una persona recibe correos electrónicos abusivos, de acoso o de SPAM, puede acceder a la base de datos y encontrar la dirección adecuada de los contactos de abuso del dominio infractor.
¿Cómo agrego mi dominio a la base de datos para que las personas puedan alertarme de cualquier abuso?
Email " update@abuse.net "con la línea de asunto de" Por favor agregue mis contactos ", luego en el cuerpo del correo electrónico incluya la siguiente información.
Para un solo contacto de abuso:
Nombredominio.com: abuse@example.comPara contactos de abuso múltiple:
Nombredominio.org: abuse@example.com postmaster@example.netEntonces envíalo. Visite el sitio web para obtener información de contacto de abuso actualizada a las pocas horas de enviar el correo electrónico.
¿Cómo busco el contacto de abuso para un dominio del que estoy sufriendo abuso?
Siéntase libre de usar la herramienta de búsqueda Abuse.net: Abuse.net Búsqueda de contactos
Cómo configurar sus prácticas de firma de dominio de autor (HISTORIC)
¿Qué es ADSP?
Las prácticas de firma de dominio de autor (ADSP), es una extensión opcional utilizada en la autenticación DKIM. ADSP se desarrolló para evitar que un remitente malintencionado se distorsione como el autor legítimo de un correo electrónico.
ADSP fue aprobado como estándar RFC 5617 en agosto 2009, pero declarado "Histórico" en noviembre 2013.
Actualmente, hay tres posibles prácticas de firma saliente:
- Grabar
- Explicación
- desconocido
- Se firmarán algunos, todos o la mayoría de los correos electrónicos. Tratado de la misma manera que no se define un registro
- Todos
- Todos y cada uno de los correos electrónicos del dominio están firmados.
- descarte
- Todo el correo enviado desde este dominio se firmará, y si la firma no es válida o falta, se le solicita al servidor receptor que deje el mensaje
Si el registro está configurado con " todos "o" descartable ", entonces el campo DE debe originarse en sus servidores de correo. Si utiliza algo como Gmail o Outlook para enviar correo, su política ADSP DKIM se establecerá en" desconocido ".
Entonces, ¿cuál es la diferencia entre "todos" y "descartables"? Si la política está marcada como "todos", entonces el servidor de correo receptor podría tratar el correo electrónico como sospechoso y asignar un puntaje de spam más alto. Si el registro está marcado como "descartable", el servidor de correo electrónico receptor descartará el mensaje si el dominio no lo ha firmado correctamente.
Cómo configurar una política ADSP
- Configura tu DKIM: Cómo configurar su firma DKIM .
- Publique un tipo de registro de recursos TXT de DNS para su dominio en el siguiente formato:
- Por ejemplo, "user@blogs.domain.com" tendría una clave similar a esta:
_adsp._domainkey.blogs.domain.com - Pero, más comúnmente, la mayoría de los propietarios de dominios tienen correos electrónicos como "users@domain.com" y se verá así.
_adsp._domainkey.domain.com
Dependiendo de la política que desee aplicar, puede establecer el registro en "dkim = all", "dkim = descartable" o "dkim = desconocido" .
Registros PTR (búsquedas inversas de DNS)
La búsqueda inversa de DNS o la resolución inversa de DNS (rDNS) se conocen más comúnmente como registros PTR. Básicamente, asignan una dirección IP a un dominio / host. Es el reverso del registro A en IPv4 y el registro AAAA en IPv6.
Entonces, si son como registros A (pero a la inversa) ¿por qué son importantes? Los registros PTR son utilizados por los filtros SPAM. Por lo general, los spammers envían correos electrónicos con nombres de dominio falsificados. Sin embargo, es posible que no tengan el registro PTR correcto configurado en DNS. Si este es el caso, el destinatario no puede recibir los correos electrónicos.
¿Por qué debería evitar el uso de registros genéricos de RPP?
Los PTR genéricos son registros utilizados por la mayoría de las empresas de hosting. Usan lo que parece ser una cadena aleatoria, una secuencia alfanumérica o un patrón repetitivo. Algo similar a 123-123-123-123 .your.isp.com.
Muchos filtros de spam buscarán su registro PTR para determinar si coincide con una de las muchas cadenas genéricas conocidas. Si no ha establecido su registro PTR y en su lugar confía en el proporcionado por su empresa de alojamiento, corre el riesgo de ser marcado por el filtro de spam. Para evitar esto, su registro PTR debe ser único y, por lo general, adoptar la forma de "mail.domain.com".
Tenga en cuenta que solo sus servidores de correo salientes o la última dirección IP de envío ( LSIP ) deben tener un registro de RPD de rDNS. Sin embargo, recomendamos configurar un registro PTR para todos los registros MX e IP que tenga.
¿Qué es LSIP y por qué es importante?
Última dirección IP de envío ( LSIP ) se refiere a la última dirección IP para "manejar" y enviar su correo electrónico a su destinatario. Es importante que configure un registro rDNS para este dominio, y que esta IP sea la misma IP utilizada en la verificación de ID de remitente y SPF.
¿Cómo configuro mi registro PTR exclusivo?
En primer lugar, deberá ponerse en contacto con su ISP para configurar su registro PTR. Esto es algo que harán de forma gratuita, pero deberá iniciar la solicitud. En segundo lugar, si el dominio de su servidor es similar a mail.exampledomain.com, deberá solicitar a su ISP que configure el registro rPTR. Para hacer esto, deberá proporcionarles la dirección IP de su servidor.
Firmas DKIM (correo identificado de DomainKeys)
DomainKeys Identified Mail ( DKIM ) es un método de autenticación creado para detectar la suplantación de identidad del correo electrónico. Permite que el servidor de correo receptor verifique que el correo electrónico que recibió ha sido enviado por el propietario del dominio. Lo hace adjuntando una firma digital a cada correo electrónico saliente, que está vinculado a un nombre de dominio específico. El sistema receptor lo verifica con la clave pública en DNS.
Ejemplo de una firma DKIM
DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=secure;
c=relaxed/simple; q=dns/txt; t=1117574938; x=1118006938;
h=from:to:subject:date:keywords:keywords;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR
La siguiente tabla analiza la firma DKIM presentada anteriormente.
- v versión
- un algoritmo de firma
- re dominio
- s selector
- c algoritmo (s) de canonicalización para encabezado y cuerpo
- q método de consulta predeterminado
- t marca de tiempo de la firma
- x expirar tiempo
- h campos de encabezado: lista de los que se han firmado
- bh picadillo corporal
- si firma de encabezados y cuerpo
¿Cómo configuro mi firma DKIM?
Una vez que haya configurado sus DomainKeys, configurará su firma DKIM en el software de su servidor de correo electrónico. La mayoría, si no todo, del software de correo electrónico moderno le permitirá habilitar las firmas DKIM y establecer configuraciones básicas.
Si su software de correo electrónico no incluye las capacidades de DKIM, le recomendamos cambiar a un paquete de software más moderno. Esto asegurará que tenga acceso a todos los estándares modernos de correo electrónico.
ID del remitente (SIDF) Histórico
El Id. Del remitente, también conocido como SPF2. 0 (Histórico), se creó originalmente para ampliar el protocolo SPF original. La intención era proporcionar una protección superior contra el phishing y la suplantación de dominio mediante la verificación de los remitentes de correo electrónico. Actualmente, Microsoft posee patentes de varios componentes dentro de la ID del remitente, y aún lo utiliza dentro de su servidor de Exchange.
La mayoría de los correos electrónicos no deseados o maliciosos contienen encabezados que fueron modificados para ocultar su identidad / punto de origen. El SPF y el ID del remitente son casi idénticos en sintaxis. Lo que sí difieren es en cómo el servidor de correo receptor busca el registro de autenticación del mensaje. El registro de autenticación es una línea de código implantada en su DNS, que aparece en los encabezados de sus mensajes de correo electrónico.
SPF examina el dominio desde la dirección de ruta de retorno del sobre (5321 -FROM), típicamente llamada dirección de rebote. La identificación del remitente examina la supuesta dirección responsable (PRA), conocida como 5322 -FROM, es decir, la dirección del remitente visible en el mensaje. Por lo tanto, la ID del remitente proporciona una mejor protección contra las estafas de phishing y la suplantación de dominios que mencionamos anteriormente.
El ID del remitente es casi idéntico al SPF, excepto que v = spf1 se reemplaza por uno de los siguientes:
- Método
- Explicación
- spf2. 0 / mdesde
- Verifique la dirección del remitente del sobre al igual que SPF.
- spf2. 0 / mfrom, pra o spf2. 0 / pra, mfrom
- verifique tanto el remitente del sobre como el PRA.
- spf2. 0 / pra
- verificar solo el PRA.
¿Cómo funciona la identificación del remitente?
- Envía un mensaje de correo electrónico.
- El servidor de correo electrónico del destinatario recibe su mensaje.
- El servidor de correo electrónico del destinatario verifica el registro SPF del dominio de envío y determina que es una coincidencia.
- Si la dirección IP y el registro SPF del servidor remitente coinciden, se entrega el correo.
Diagrama de cómo funciona la identificación del remitente

Ejemplo de registro DMARC
¿Qué es un registro DMARC y qué importancia tiene?
La autenticación, informes y conformidad de mensajes basados en dominio (DMARC) es un protocolo de autenticación de correo electrónico que tiene como objetivo detener o reducir el correo no deseado y los ataques de phishing. La especificación DMARC esencialmente extiende la autenticación de correo electrónico existente usando SPF o DKIM . Por lo tanto, los receptores de correo electrónico que hayan aplicado DMARC experimentarán una autenticación más constante.
Al igual que SPF, DMARC permite que el propietario del dominio publique su política y el servidor receptor puede verificar la validez del registro. Sin embargo, a diferencia de SPF, DMARC también incluye instrucciones sobre qué hacer con cualquier mensaje que falle la autenticación.
DMARC esencialmente extiende la funcionalidad de SPF y DomainKeys Identified Mail (DKIM). Permite al administrador de un dominio publicar una política en sus registros DNS. Luego, pueden especificar qué protocolo de autenticación (SPF, DKIM o ambos) se utiliza al enviar correos electrónicos desde ese dominio. Además, el administrador puede especificar un procedimiento de informe, Formato de informe de falla de autenticación (AFRF), para las acciones realizadas bajo esas políticas.
Ejemplo de registro DMARC
Aquí hay un ejemplo de un Registro DMARC usamos en www.zerobounce.net:
"v=DMARC1;p=none;pct=100;rua=mailto:email@domain.com;ruf=mailto:email@domain.com;"
El código de arriba en detalle
- Sintaxis
- Definición
- Ejemplo
- v
- Versión de protocolo
- v = DMARC1
- pct
- Porcentaje de mensajes sujetos a filtrado
- pct = 100
- ruf
- URI de informes para informes forenses
- ruf = authfail@zerobounce.net
- rua
- URI de informes para informes agregados
- rua = aggrep@zerobounce.net
- p
- Política para dominio organizacional
- p = cuarentena
- sp
- Política para subdominios de OD
- sp = rechazar
- adkim
- Modo de alineación de identificador para DKIM
- adkim = estricto
- aspf
- Modo de alineación de identificador para SPF
- aspf = relajado
Ahora es más probable que se pregunte, "¿Cómo configuro mi _DMARC Record?" Esa es la parte fácil. Puedes utilizar nuestro programa gratuito Herramienta de generador de registros DMARC .
Genere y pruebe su registro DMARC
Navega hacia nuestro Generador DMARC y comience completando el cuestionario. Después de crear su registro DMARC, recibirá instrucciones sobre cómo agregarlo a su DNS.