Difference between revisions of "DMARC"
| Line 17: | Line 17: | ||
! tag !! values !! description | ! tag !! values !! description | ||
|- | |- | ||
| − | | | + | | '''adkim''' |
| + | |<poem> | ||
| + | <code>s</code>: strict | ||
| + | <code>r</code>: relaxed | ||
| + | </poem> | ||
| + | | how closely to check DKIM configuration ("alignment") | ||
| + | |- | ||
| + | | '''aspf''' | ||
| + | |<poem> | ||
| + | <code>s</code>: strict | ||
| + | <code>r</code>: relaxed | ||
| + | </poem> | ||
| + | | how closely to check SPF configuration ("alignment") | ||
| + | |- | ||
| + | | '''fo''' | ||
| + | |<poem> | ||
| + | <code>0</code>: report DMARC failure if '''all''' underlying auths don't align | ||
| + | <code>1</code>: report DMARC failure if '''any''' underlying auths don't align | ||
| + | <code>d</code>: report DKIM failure if DKIM signature fails, regardless of alignment (see [https://datatracker.ietf.org/doc/html/rfc7489#ref-AFRF-DKIM AFRF-DKIM]) | ||
| + | <code>s</code>: report SPF failure if SPF evaluation fails, regardless of alignment (see [https://datatracker.ietf.org/doc/html/rfc7489#ref-AFRF-SPF AFRF-SPF]) | ||
| + | </poem> | ||
| + | | failure [reporting] options | ||
| + | |- | ||
| + | | '''p''' | ||
| | | | ||
| − | + | ||
| − | + | {| class="wikitable" | |
| − | | | ||
|- | |- | ||
| − | | | + | | <code>none</code> || no specific action |
| − | | | + | |- |
| − | + | | <code>quarantine</code> || treat all failed messages as suspicious (receiver can decide how to handle) | |
| − | + | |- | |
| − | | | + | | <code>reject</code> || reject all failed messages, preferably during the SMTP transaction (see [https://datatracker.ietf.org/doc/html/rfc7489#section-10.3 Section 10.3]) |
| + | |} | ||
| + | |||
| + | | Requested Mail Receiver policy | ||
|- | |- | ||
| − | + | | '''pct''' | |
| − | | | + | | <code>0</code> to <code>100</code>, default = <code>100</code> |
| − | + | | % of domain's messages subject to policy (except reports, which are always 100%) | |
| − | |||
| − | |||
| − | |||
| − | |||
|} | |} | ||
''documentation in progress'' | ''documentation in progress'' | ||
Revision as of 14:14, 15 August 2022
|
Domain-based Message Authentication, Reporting and Conformance (DMARC)
|
About
Configuring DMARC for any given domain requires only a DNS entry for that domain, containing machine-readable instructions for any message recipient to automatically authenticate an incoming message. The server receiving any message can check the "from" domain's DNS for a DMARC record. If one is found, the message will be accepted only if it passes the requirements.
The DMARC DNS entry for a given domain uses a "_DMARC" subdomain (_DMARC.<domain>). The explanation of the DNS record contents seems to begin in section 6.3 of RFC-7489.
Tags
| tag | values | description | ||||||
|---|---|---|---|---|---|---|---|---|
| adkim |
|
how closely to check DKIM configuration ("alignment") | ||||||
| aspf |
|
how closely to check SPF configuration ("alignment") | ||||||
| fo | failure [reporting] options | |||||||
| p |
|
Requested Mail Receiver policy | ||||||
| pct | 0 to 100, default = 100
|
% of domain's messages subject to policy (except reports, which are always 100%) |
documentation in progress
In Practice
It appears that some large email services (such as GMail) may reject messages if DMARC is not configured in a way they deem suitable; as far as I know, this is not officially documented anywhere (security by obscurity), and proper configuration can only be determined by experimentation.
Notes
For some reason, DigitalOcean apparently does not support wildcards in TXT DNS records, so you can't set up a wildcard DMARC recipient.