Nombre de la Categoría: > Seguridad

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.

Para configurar DMARC debe:

  1. 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= Value Notes
 v= DMARC1 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.
 p= May take one of the following values: Mandatory and must be the second tag=value pair. Defines the policy the sending MTA advises the receiving MTA to follow.
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.
 sp= Same values as for p= (reject, quarantine, none) 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.
 adkim= r (relaxed – default) or s (strict) mode 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.
 aspf= r (relaxed) or s (strict) mode 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.
 pct= value from 0 to 100 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.
 fo= the following values: reporting policy the sending MTA requests from the receiving MTA. Multiple options may be defined using colon (:) separated values, for example, fo=0:s
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.
 rf= May take one or more of the following values: Optional (defaults to rf=afrf). Defines the reporting format the sending MTA requests from the receiving MTA.
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.
 ri= Defines the time in seconds between reports requested from the receiving MTA 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.
 rua= A comma delimited list of URI(s) to which aggregate mail reports should be sent 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»
 ruf= A comma delimited list of URI(s) to which detailed failure reports should be sent 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»

 


Ver Tambien:
« | »