Configuración DMARC
Es un estándar de autenticación de mensajes, informes y conformidad basado en dominios. Esto es implementado para garantizar que un correo electrónico legítimo sea autenticado correctamente en función a DKIM y SPF establecidos, que puedan bloquear alguna actividad fraudulenta que pareciera provenir de dominios bajo el control de la organización.
IMPORTANTE: A partir de febrero de 2024, tener configurado DMARC], al igual que SPF y DKIM, es un requisito para enviar emails hacia servidores Google y Yahoo.
Para configurar DMARC debe:
Realizar un registro del tipo TXT en el DNS del dominio a configurar:
_dmarc IN TXT “v=DMARC1; p=none; sp=none; rua=mailto:sudominio@danaconnect-dmarc.com; ruf=mailto:sudominio@danaconnect-dmarc.com; rf=afrf; pct=100; ri=86400”
1.1. Para configurar en modo monitoreo:
v=DMARC1; p=none; rua=mailto:cliente-rep@danaconnect-dmarc.com; ruf=mailto:cliente-for@danaconnect-dmarc.com; pct=100; adkim=r; sp=none; fo=1; ri=43200
1.2. Para configurar en modo cuarentena:
v=DMARC1; p=quarantine; rua=mailto:cliente-rep@danaconnect-dmarc.com; ruf=mailto:cliente-for@danaconnect-dmarc.com; pct=100; adkim=r; sp=quarantine; fo=1; ri=43200
2-. Además debe registrar el CNAME para la plataforma DANAConnect :
dana IN CNAME bounce.email-platform.com.
Tag= v=
Value DMARC1
Notes Mandatory. This must be the first supplied tag=value within the dmarc specific text and, while DMARC tag=value pairs are not case sensitive, this one must have the explicit upper-case value DMARC1.
Tag= p=
Value May take one of the following values:
none No specific advice is offered to the receiving MTA.
quarantine Advises the receiving MTA to treat any email that fails any DKIM and/or SPF checks as suspicious and perform additional checks or mark the mail as suspected SPAM or whatever local policy is in operation.
reject Advises the receiving MTA to reject any email that fails any DKIM and/or SPF checks.
Notes Mandatory and must be the second tag=value pair. Defines the policy the sending MTA advises the receiving MTA to follow.
Tag= sp=
Value Same values as for p= (reject, quarantine, none)
Notes Optional. If not present the p= policy is assumed to cover the domain.name and all its subdomains. If sp= is present it indicates the defined policy that applies to subdomains of the domain.name at which the DMARC RR was discovered and not the name itself (the domain.name in this case is covered by the p= tag=value pair). Thus, if the following DMARC RR is present: $ORIGIN example.com. … _dmarc IN TXT “v=DMARC1;p=reject;sp=quarantine” Then failed mail from user@example.com would be rejected but mail from user@a.example.com or user@b.a.example.com or user@anything.example.com would be quarantined.
Tag= adkim=
Value r (relaxed – default) or s (strict) mode
Notes Optional (if omitted defaults to adkim=r). In strict mode the sender domain name must exactly match the corresponding d=name (in the DKIM mail headers). In relaxed mode any subdomain of d=domain (in the mail headers) will also be accepted. Thus if d=example.com in the mail header then mail from user@example.com will pass from either adkim = r or adkim=s, however, mail from user@a.example.com will fail if adkim=s but pass if adkim=r.
Tag= aspf=
Value r (relaxed) or s (strict) mode
Notes Optional (if omitted defaults to aspf=r). In strict mode the domain.name in the MAIL FROM command (in SMTP) and the from: header (in the mail item) must match exactly. In relaxed mode any valid subdomain of domain.name is acceptable.
Tag= pct=
Value value from 0 to 100
Notes Optional. Defines the percentage of mail to which the DMARC policy applies. If omitted defaults to pct=100 (100%) – all mail is subject to DMARC processing. This parameter allows mail senders to experiment with a small percentage of mail being subject to DMARC action. Problems can be progressively eliminated from the system before turning DMARC on for all mail.
Tag= fo=
Value the following values:
0 Generate report to the sending MTA if all underlying checks failed. Thus, if only DKIM is used to secure mail and the DKIM check fails a report will be sent, if only SPF is used to secure mail and the SPF check fails a report will be sent. However, if both DKIM and SPF are used and, say, the SPF check fails but the DKIM check passes a report WILL NOT be sent.
1 Generate report to the sending MTA if any underlying check failed. Thus, if only DKIM is used to secure mail and the DKIM check fails a report will be sent, if only SPF is used to secure mail and the SPF check fails a report will be sent. However, if both DKIM and SPF are used and, say, the SPF check fails but the DKIM check passes a report WILL be sent.
d Generate a report if DKIM checks fail.
s Generate a report if SPF checks fail.
Notes reporting policy the sending MTA requests from the receiving MTA. Multiple options may be defined using colon ( separated values, for example, fo=0:s.
Tag= rf=
Value May take one or more of the following values:
afrf Message format for error reporting (Abuse Report format) is defined by RFC 5965.
iodef Message format for error reporting (Incident Object Description Exchange Format) is defined by RFC 5070.
Notes Optional (defaults to rf=afrf). Defines the reporting format the sending MTA requests from the receiving MTA.
Tag= ri=
Value Defines the time in seconds between reports requested from the receiving MTA
Notes Optional (if omitted defaults to ri=86400 – 24 hours). Defines the reporting interval in seconds. receivimg MTAs must be able to send daily (86400) reports and should be able to send hourly (3600) reports but on a best efforts basis. Implicitly anything less than 1 hour (3600) can be rounded up to 1 hour by the receiving MTA.
Tag= rua=
Value A comma delimited list of URI(s) to which aggregate mail reports should be sent
Notes Optional. If not present aggregate reports will not be sent from the receiving MTA. URIs must be of the format mailto:user@example.com (implicit in the draft RFC). Aggregate report format is defined in section 7.2 of the draft RFC. Where a mailto address is lies with the sending zone no additional configuration is required, however if the mailto address lies outside the sending zone an additional empty DMRC RR is required. Thus, if the email sending zone is example.net and the DMARC TXT RR contains the parameter rua=mailto:dmarc-admin@example.net this lies inside the sending zone and no additional configuration is required. If, however the email sending zone is example.net and the DMARC TXT RR in the zone file for example.net contains the parameter rua=mailto:dmarc-admin@example.com this lies outside the sending zone and the zone example.com must validate that it will accept reports for the example.net domain by having the following minimal DMARC TXT RR: # example.com zone file fragment $ORIGIN example.com. … # authorises the receiving of DMARC reports for example.net example.net._report._dmarc TXT “v=DMARC1”
Tag= ruf=
Value A comma delimited list of URI(s) to which detailed failure reports should be sent
Notes Optional. If not present detailed failure reports will not be sent from the receiving MTA. URIs must be of the format mailto:user@example.com (implicit in the draft RFC). Where a mailto address is lies with the sending zone no additional configuration is required, however if the mailto address lies outside the sending zone an additional empty DMRC RR is required.
Thus, if the email sending zone is example.net and the DMARC TXT RR contains the parameter rua=mailto:dmarc-admin@example.net this lies inside the sending zone and no additional configuration is required. If, however the email sending zone is example.net and the DMARC TXT RR in the zone file for example.net contains the parameter rua=mailto:dmarc-admin@example.com this lies outside the sending zone and the zone example.com must validate that it will accept reports for the example.net domain by having the following minimal DMARC TXT RR: # example.com zone file fragment $ORIGIN example.com. … # authorises the receiving of DMARC reports for example.net example.net._report._dmarc TXT “v=DMARC1”.
IMPORTANTE: A partir de febrero de 2024, tener configurado DMARC], al igual que SPF y DKIM, es un requisito para enviar emails hacia servidores Google y Yahoo.
Para configurar DMARC debe:
Realizar un registro del tipo TXT en el DNS del dominio a configurar:
_dmarc IN TXT “v=DMARC1; p=none; sp=none; rua=mailto:sudominio@danaconnect-dmarc.com; ruf=mailto:sudominio@danaconnect-dmarc.com; rf=afrf; pct=100; ri=86400”
1.1. Para configurar en modo monitoreo:
v=DMARC1; p=none; rua=mailto:cliente-rep@danaconnect-dmarc.com; ruf=mailto:cliente-for@danaconnect-dmarc.com; pct=100; adkim=r; sp=none; fo=1; ri=43200
1.2. Para configurar en modo cuarentena:
v=DMARC1; p=quarantine; rua=mailto:cliente-rep@danaconnect-dmarc.com; ruf=mailto:cliente-for@danaconnect-dmarc.com; pct=100; adkim=r; sp=quarantine; fo=1; ri=43200
2-. Además debe registrar el CNAME para la plataforma DANAConnect :
dana IN CNAME bounce.email-platform.com.
Tag=Value Parameters
Tag= v=
Value DMARC1
Notes Mandatory. This must be the first supplied tag=value within the dmarc specific text and, while DMARC tag=value pairs are not case sensitive, this one must have the explicit upper-case value DMARC1.
Tag= p=
Value May take one of the following values:
none No specific advice is offered to the receiving MTA.
quarantine Advises the receiving MTA to treat any email that fails any DKIM and/or SPF checks as suspicious and perform additional checks or mark the mail as suspected SPAM or whatever local policy is in operation.
reject Advises the receiving MTA to reject any email that fails any DKIM and/or SPF checks.
Notes Mandatory and must be the second tag=value pair. Defines the policy the sending MTA advises the receiving MTA to follow.
Tag= sp=
Value Same values as for p= (reject, quarantine, none)
Notes Optional. If not present the p= policy is assumed to cover the domain.name and all its subdomains. If sp= is present it indicates the defined policy that applies to subdomains of the domain.name at which the DMARC RR was discovered and not the name itself (the domain.name in this case is covered by the p= tag=value pair). Thus, if the following DMARC RR is present: $ORIGIN example.com. … _dmarc IN TXT “v=DMARC1;p=reject;sp=quarantine” Then failed mail from user@example.com would be rejected but mail from user@a.example.com or user@b.a.example.com or user@anything.example.com would be quarantined.
Tag= adkim=
Value r (relaxed – default) or s (strict) mode
Notes Optional (if omitted defaults to adkim=r). In strict mode the sender domain name must exactly match the corresponding d=name (in the DKIM mail headers). In relaxed mode any subdomain of d=domain (in the mail headers) will also be accepted. Thus if d=example.com in the mail header then mail from user@example.com will pass from either adkim = r or adkim=s, however, mail from user@a.example.com will fail if adkim=s but pass if adkim=r.
Tag= aspf=
Value r (relaxed) or s (strict) mode
Notes Optional (if omitted defaults to aspf=r). In strict mode the domain.name in the MAIL FROM command (in SMTP) and the from: header (in the mail item) must match exactly. In relaxed mode any valid subdomain of domain.name is acceptable.
Tag= pct=
Value value from 0 to 100
Notes Optional. Defines the percentage of mail to which the DMARC policy applies. If omitted defaults to pct=100 (100%) – all mail is subject to DMARC processing. This parameter allows mail senders to experiment with a small percentage of mail being subject to DMARC action. Problems can be progressively eliminated from the system before turning DMARC on for all mail.
Tag= fo=
Value the following values:
0 Generate report to the sending MTA if all underlying checks failed. Thus, if only DKIM is used to secure mail and the DKIM check fails a report will be sent, if only SPF is used to secure mail and the SPF check fails a report will be sent. However, if both DKIM and SPF are used and, say, the SPF check fails but the DKIM check passes a report WILL NOT be sent.
1 Generate report to the sending MTA if any underlying check failed. Thus, if only DKIM is used to secure mail and the DKIM check fails a report will be sent, if only SPF is used to secure mail and the SPF check fails a report will be sent. However, if both DKIM and SPF are used and, say, the SPF check fails but the DKIM check passes a report WILL be sent.
d Generate a report if DKIM checks fail.
s Generate a report if SPF checks fail.
Notes reporting policy the sending MTA requests from the receiving MTA. Multiple options may be defined using colon ( separated values, for example, fo=0:s.
Tag= rf=
Value May take one or more of the following values:
afrf Message format for error reporting (Abuse Report format) is defined by RFC 5965.
iodef Message format for error reporting (Incident Object Description Exchange Format) is defined by RFC 5070.
Notes Optional (defaults to rf=afrf). Defines the reporting format the sending MTA requests from the receiving MTA.
Tag= ri=
Value Defines the time in seconds between reports requested from the receiving MTA
Notes Optional (if omitted defaults to ri=86400 – 24 hours). Defines the reporting interval in seconds. receivimg MTAs must be able to send daily (86400) reports and should be able to send hourly (3600) reports but on a best efforts basis. Implicitly anything less than 1 hour (3600) can be rounded up to 1 hour by the receiving MTA.
Tag= rua=
Value A comma delimited list of URI(s) to which aggregate mail reports should be sent
Notes Optional. If not present aggregate reports will not be sent from the receiving MTA. URIs must be of the format mailto:user@example.com (implicit in the draft RFC). Aggregate report format is defined in section 7.2 of the draft RFC. Where a mailto address is lies with the sending zone no additional configuration is required, however if the mailto address lies outside the sending zone an additional empty DMRC RR is required. Thus, if the email sending zone is example.net and the DMARC TXT RR contains the parameter rua=mailto:dmarc-admin@example.net this lies inside the sending zone and no additional configuration is required. If, however the email sending zone is example.net and the DMARC TXT RR in the zone file for example.net contains the parameter rua=mailto:dmarc-admin@example.com this lies outside the sending zone and the zone example.com must validate that it will accept reports for the example.net domain by having the following minimal DMARC TXT RR: # example.com zone file fragment $ORIGIN example.com. … # authorises the receiving of DMARC reports for example.net example.net._report._dmarc TXT “v=DMARC1”
Tag= ruf=
Value A comma delimited list of URI(s) to which detailed failure reports should be sent
Notes Optional. If not present detailed failure reports will not be sent from the receiving MTA. URIs must be of the format mailto:user@example.com (implicit in the draft RFC). Where a mailto address is lies with the sending zone no additional configuration is required, however if the mailto address lies outside the sending zone an additional empty DMRC RR is required.
Thus, if the email sending zone is example.net and the DMARC TXT RR contains the parameter rua=mailto:dmarc-admin@example.net this lies inside the sending zone and no additional configuration is required. If, however the email sending zone is example.net and the DMARC TXT RR in the zone file for example.net contains the parameter rua=mailto:dmarc-admin@example.com this lies outside the sending zone and the zone example.com must validate that it will accept reports for the example.net domain by having the following minimal DMARC TXT RR: # example.com zone file fragment $ORIGIN example.com. … # authorises the receiving of DMARC reports for example.net example.net._report._dmarc TXT “v=DMARC1”.
Actualizado el: 29/01/2024
¡Gracias!