Blame
Date:
Sun Jan 29 05:00:28 2023 UTC
Message:
Daily backup
01
2023-01-22
jrmu
version=pmwiki-2.2.130 ordered=1 urlencoded=1
02
2023-01-22
jrmu
agent=Mozilla/5.0 (X11; Linux armv7l) AppleWebKit/537.36 (KHTML, like Gecko) Raspbian Chromium/78.0.3904.108 Chrome/78.0.3904.108 Safari/537.36
03
2023-01-22
jrmu
author=Hawk
04
2023-01-22
jrmu
charset=UTF-8
05
2023-01-22
jrmu
csum=
06
2023-01-22
jrmu
ctime=1622890179
07
2023-01-22
jrmu
host=2001:8a0:6813:4501:18d4:42f5:d6fb:184f
08
2023-01-22
jrmu
name=DNS.DMARC
09
2023-01-22
jrmu
rev=10
10
2023-01-22
jrmu
targets=
11
2023-01-22
jrmu
text=(:title DMARC:)%0a%0a!! Recommended Reading%0a%0aThis guide only provides a quick simplified overview of DMARC and a howto for%0aconfiguring your DNS resource records. To better understand the subject, you%0ashould check out [[https://dmarc.org/overview/|the official DMARC website]].%0a[[http://www.zytrax.com/books/dns/ch9/dmarc.html|DNS for Rocket Scientists]] is%0aalso helpful.%0a%0a!! Why DMARC%0a%0aTo prevent phishing emails and spam, we use SPF and DKIM. However, sometimes real%0amessages may not authenticate properly, and other times fake messages may get%0aaccepted. Senders need some way to get feedback on how many emails are being%0asent and marked as fake. This helps with troubleshooting, improving delivery%0arates, and detecting fraud.%0a%0aThe Domain-based Message Authentication, Reporting and Conformance ('''DMARC''')%0aprovides a way for mail senders and receivers to share this information.%0a%0aDMARC helps:%0a%0a# reduce false positives%0a# report on how much mail has authenticated%0a# tell the receiver the sender's policy%0a# reduce phishing%0a%0aInside a DMARC record, you tell the mail server:%0a%0a# if you are using DKIM, SPF, or both.%0a# how to handle mail that doesn't validate.%0a# if you want a feedback report, and how to report.%0a%0aNote that DMARC uses DKIM and SPF; it does not replace either.%0a%0aTo use DMARC, you just add a TXT record in your DNS zone:%0a%0a!! How it works%0a%0a|| border=1 width=100%25 class="sortable simpletable"%0a||! Tag ||! Indicates ||! Example ||! Meaning ||%0a|| v || DMARC version || v=DMARC1 || First DMARC version; DMARC must be all uppercase; required ||%0a|| pct || Percent of mail to filter || pct=20 || Filter 20%25 of mails; increase slowly over time to detect configurations mistakes gradually ||%0a|| ruf || Reporting URI for forensic reports || ruf=mailto:postmaster@example.com || Report to postmaster@example.com[[%3c%3c]]'''Warning''': make sure the address is inside the current zone or else you need an extra DMARC record ||%0a|| rua || Reporting URI of aggregate reports || rua=mailto:postmaster@example.com || Report to postmaster@example.com[[%3c%3c]]'''Warning''': make sure the address is inside the current zone or else you need an extra DMARC record ||%0a|| p || Policy for domain || p=%3cvalue> || Required; applies to domain (and subdomains if sp= not specified) ||%0a|| || || p=none || No advice given ||%0a|| || || p=quarantine || If checks fail, mail is suspicious ||%0a|| || || p=reject || If checks fail, reject mail ||%0a|| sp || Policy for subdomains || sp=%3cvalue> || Same as above, but for subdomains only ||%0a|| adkim || Strictness of DKIM headers|| adkim=%3cvalue> || (Optional; default adkim=r) Checks if d=name matches ||%0a|| || || adkim=r || Relaxed; subdomains of d=name are accepted ||%0a|| || || adkim=s || Strict; subdomains of d=name not accepted ||%0a|| aspf || Strictness of From headers || aspf=%3cvalue> || (Optional; default aspf=r) Checks MAIL FROM (SMTP) and From: header in message ||%0a|| || || aspf=r || Relaxed; subdomains of d=name are accepted ||%0a|| || || aspf=s || Strict; subdomains of d=name not accepted ||%0a|| fo || When to Report || fo=%3cvalue> || (Optional; default fo=0) ||%0a|| || || fo=0 || Send only if all requested checks fail ||%0a|| || || fo=1 || Send if any requested checks fail ||%0a|| || || fo=d || Send if DKIM fails ||%0a|| || || fo=s || Send if SPF fails ||%0a%0a!! Example Records%0a%0aTXT records are used to store DMARC information to avoid having to upgrade DNS%0asoftware to support special resource record types.%0a%0a!!! Permit and Report Everything%0a%0a[@%0a_dmarc IN TXT "v=DMARC1;p=none;pct=0;fo=1;rua=mailto:postmaster@example.com;ruf=mailto:postmaster@example.com"%0a@]%0a%0aBetween the two quotation marks "", we put in our DMARC information, which is made up%0aof key=value pairs separated by semicolons ;.%0a%0a|| border=1 width=100%25 class="sortable simpletable"%0a||! Pair ||! Meaning ||%0a|| v=DMARC1 || First DMARC version ||%0a|| p=none || No advice is given ||%0a|| pct=0 || Filter 0%25 of mails ||%0a|| fo=1 || Report all errors from DKIM and SPF ||%0a|| rua=mailto:postmaster@example.com || Send user aggregate reports to postmaster@example.com ||%0a|| ruf=mailto:postmaster@example.com || Send forensic reports to postmaster@example.com ||%0a%0aThis record will provide you with reports for both DKIM/SPF, but will not%0aenforce any filtering whatsoever. This makes this entry very useful for testing%0aout if a new mail server is configured properly. However, this loose configuration%0amay allow more spammers to spoof your domain because bad email is not rejected.%0a%0a!!! Reject and Quarantine All Failed Mail%0a%0a[@%0a_dmarc IN TXT "v=DMARC1;p=reject;sp=quarantine;pct=100;fo=1;rua=mailto:postmaster@example.com;ruf=mailto:postmaster@example.com"%0a@]%0a%0a|| border=1 width=100%25 class="sortable simpletable"%0a||! Pair ||! Meaning ||%0a|| v=DMARC1 || First DMARC version ||%0a|| p=reject || Reject failed mail from example.com ||%0a|| sp=quarantine || Quarantine failed mail from %3csubdomain>.example.com ||%0a|| pct=100 || Filter 100%25 of mails ||%0a|| fo=1 || Report all errors from DKIM and SPF ||%0a|| rua=mailto:postmaster@example.com || Send user aggregate reports to postmaster@example.com ||%0a|| ruf=mailto:postmaster@example.com || Send forensic reports to postmaster@example.com ||%0a%0aThis rejects and quarantines all mail where DKIM and SPF are not perfectly configured.%0aThis is very good at stopping spam and phishing pretending to come from your domain.%0a%0a'''Warning''': you may lose a lot of real mail if there is a misconfiguration. May%0acause issues when mail is forwarded by mailing lists.%0a
12
2023-01-22
jrmu
time=1637621543
13
2023-01-22
jrmu
title=DMARC
14
2023-01-22
jrmu
author:1637621543=Hawk
15
2023-01-22
jrmu
diff:1637621543:1622976647:minor=46c46%0a%3c || rua || Reporting URI of aggregate reports || rua=mailto:postmaster@example.com || Report to postmaster@example.com[[%3c%3c]]'''Warning''': make sure the address is inside the current zone or else you need an extra DMARC record ||%0a---%0a> || rua || Reporting URI of aggregate reports || rua=mailto:postmasters@example.com || Report to postmaster@example.com[[%3c%3c]]'''Warning''': make sure the address is inside the current zone or else you need an extra DMARC record ||%0a76,77c76,77%0a%3c of key=value pairs separated by semicolons ;.%0a%3c %0a---%0a> of key=value pairs separated by semicolors ;.%0a> %0a84c84%0a%3c || rua=mailto:postmaster@example.com || Send user aggregate reports to postmaster@example.com ||%0a---%0a> || rua=mailto:postmaster@example.com || Send user aggregate reports to postmaster@example.com||%0a105c105%0a%3c || rua=mailto:postmaster@example.com || Send user aggregate reports to postmaster@example.com ||%0a---%0a> || rua=mailto:postmaster@example.com || Send user aggregate reports to postmaster@example.com||%0a
16
2023-01-22
jrmu
host:1637621543=2001:8a0:6813:4501:18d4:42f5:d6fb:184f
17
2023-01-22
jrmu
author:1622976647=jrmu
18
2023-01-22
jrmu
diff:1622976647:1622976019:=108,109c108,109%0a%3c This rejects and quarantines all mail where DKIM and SPF are not perfectly configured.%0a%3c This is very good at stopping spam and phishing pretending to come from your domain.%0a---%0a> This rejects all mail where DKIM and SPF are not perfectly configured. This%0a> is very good at stopping spam and phishing pretending to come from your domain.%0a
19
2023-01-22
jrmu
host:1622976647=38.81.163.143
20
2023-01-22
jrmu
author:1622976019=jrmu
21
2023-01-22
jrmu
diff:1622976019:1622971234:=64,65d63%0a%3c !! Example Records%0a%3c %0a69,70d66%0a%3c !!! Permit and Report Everything%0a%3c %0a92,93c88,89%0a%3c !!! Reject and Quarantine All Failed Mail%0a%3c %0a---%0a> Here's a different record:%0a> %0a101,103c97,98%0a%3c || p=reject || Reject failed mail from example.com ||%0a%3c || sp=quarantine || Quarantine failed mail from %3csubdomain>.example.com ||%0a%3c || pct=100 || Filter 100%25 of mails ||%0a---%0a> || p=none || No advice is given ||%0a> || pct=0 || Filter 0%25 of mails ||%0a108,112c103,167%0a%3c This rejects all mail where DKIM and SPF are not perfectly configured. This%0a%3c is very good at stopping spam and phishing pretending to come from your domain.%0a%3c %0a%3c '''Warning''': you may lose a lot of real mail if there is a misconfiguration. May%0a%3c cause issues when mail is forwarded by mailing lists.%0a---%0a> _dmarc IN TXT "v=DMARC1;p=reject;sp=quarantine"%0a> %0a> Failed mail from user@example.com would be rejected but failed mail from user@subdomain.example.com would be quarantined.%0a> %0a> %0a> %0a> _dmarc IN TXT "v=DMARC1;p=reject;sp=quarantine"%0a> %0a> Examples%0a> Example 1: Single Domain Name using DKIM and SPF - Aggressive%0a> %0a> This is an aggressive policy and should only be adopted where the sender is certain that both DKIM and SPF are correctly configured. Not for the faint-hearted. Assume the domain example.net only sends mail in the form user@example.net (mail is not sent from any subdomain) and that both DKIM and SPF are used in relaxed format. The domain owner wishes to have a daily aggregate report from mail receivers (in Abuse Report format - RFC 5965) of any problems at the address dmarc-admin@example.com if either SPF or DKIM fails, suggests that mail failing any checks should be rejected and that 100%25 of mail should be checked. The following addition to example.net's zone file implements such a policy:%0a> %0a> # example.net zone file fragment%0a> $ORIGIN example.net.%0a> ...%0a> _dmarc TXT ( "v=DMARC1;p=reject;sp=reject;pct=100;"%0a> "adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:dmarc-admin@example.com")%0a> %0a> # NOTE: since the required email address is out-of-zone the %0a> # following change to the zone file for example.com must be made%0a> # example.com zone file fragment%0a> $ORIGIN example.com.%0a> ...%0a> example.net._report._dmarc TXT "v=DMARC1"%0a> # functionally identical%0a> example.net._report._dmarc.example.com. TXT "v=DMARC1"%0a> ...%0a> %0a> Strictly, the adkim=, aspf=, ri= and pct= are not necessary since their defaults are used. However, explicit use of defaults is good defensive configuration policy, and can prevent catastrophic errors in the event that a default is subsequently changed. The use of an out-of-zone email address requires an additional change in the report receivers zone file (example.com in this case) to authorize the reports from the example.net organizational name (see rua/ruf parameters.%0a> Example 2: Single Domain Name using DKIM and SPF - Timid%0a> %0a> This is a timid (or cautious if you prefer) policy where the sender is discovering the real pathology of their mail service and is unsure (or has no idea) if either DKIM and SPF are correctly configured. Assume the domain example.net only sends mail in the form user@example.net (mail is not sent from any subdomain) and that both DKIM and SPF are used in relaxed format. The domain owner wishes to have a daily aggregate report from mail receivers (in Abuse Report format - RFC 5965) of any problems at the address dmarc-admin@example.net if either SPF or DKIM fails, does not want the receiver to reject any failing mail and suggests that only 10%25 of mail should be checked. The following addition to example.net's zone file implements such a policy:%0a> %0a> # example.net zone file fragment%0a> $ORIGIN example.net.%0a> ...%0a> _dmarc TXT ( "v=DMARC1;p=none;sp=reject;pct=10;"%0a> "adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:dmarc-admin@example.net")%0a> %0a> Strictly, the adkim=, aspf=, ri= and pct= are not necessary since their defaults are used. However, explicit use of defaults is good defensive configuration policy.%0a> Example 3: Single Domain Name using SPF only - Aggressive%0a> %0a> This is an aggressive policy and should only be adopted where the sender is certain that SPF is correctly configured. Assume the domain example.net only sends mail in the form user@example.net (mail is not sent from any subdomain) and that only SPF is used in relaxed format. The domain owner wishes to have a daily aggregate report from mail receivers (in Abuse Report format - RFC 5965) of any problems at the address dmarc-admin@example.net if SPF checks fail, suggests that all mail failing the SPF checks should be rejected and that 100%25 of mail should be checked. The following addition to example.net's zone file implements such a policy:%0a> %0a> # example.net zone file fragment%0a> $ORIGIN example.net.%0a> ...%0a> _dmarc TXT ( "v=DMARC1;p=reject;sp=reject;pct=100;"%0a> "aspf=r;fo=0;ri=86400;rua=mailto:dmarc-admin@example.net")%0a> %0a> Strictly, the aspf=, ri= and pct= are not necessary since their defaults are used. However, explicit use of defaults is good defensive configuration policy. It is the presence or absence of either DKIM headers or an SPF RR tested when the mail arrives at the receiver that determine which mail security method is in use rather than the configuration of the DMARC RR. In this case we have eliminated the adkim= to make the actual policy explicit and, since only SPF is in operation, fo=0. The same functional result would have ocurred if adkim=r had been retained and fo=1 as in Example 1 above. If only DKIM was being used adkim=r would have been added and aspf=r removed - but again the previous comment also applies - it is the received mail that determines which checks are invoked not the DMARC RR.%0a> Example 4: No mail%0a> %0a> This is a supreme act of good neighborliness. Assume the domain never sends email. The presence of a DMARC is good practice since mail could be forged with the domain's name. There is, however, no way to explictly configure a DMARC RR to indicate that mail will never be sent from this domain. Again, this emphasizes the point that DMARC processing is only invoked once the incoming mail protection mechanisms have been discovered. To indicate that a domain will never send mail must be done with a DMARC RR AND a dummy SPF TXT RR as shown:%0a> %0a> # example.net zone file fragment%0a> $ORIGIN example.net.%0a> ...%0a> # negative (or dummy) SPF RR%0a> example.net. TXT "v=spf1 -all"%0a> ...%0a> _dmarc TXT "v=DMARC1;p=reject;sp=reject;pct=100;aspf=s"%0a> %0a> In this case the DMARC is simply saying reject any mail from this domain that fails the SPF check and the SPF TXT RR, by use of the -all ensures that all mail fails the SPF test. Net result - no mail is allowed to be sent from this domain name.%0a
22
2023-01-22
jrmu
host:1622976019=38.81.163.143
23
2023-01-22
jrmu
author:1622971234=jrmu
24
2023-01-22
jrmu
diff:1622971234:1622971155:=45,46c45,46%0a%3c || ruf || Reporting URI for forensic reports || ruf=mailto:postmaster@example.com || Report to postmaster@example.com[[%3c%3c]]'''Warning''': make sure the address is inside the current zone or else you need an extra DMARC record ||%0a%3c || rua || Reporting URI of aggregate reports || rua=mailto:postmasters@example.com || Report to postmaster@example.com[[%3c%3c]]'''Warning''': make sure the address is inside the current zone or else you need an extra DMARC record ||%0a---%0a> || ruf || Reporting URI for forensic reports || ruf=mailto:postmaster@example.com || Report to postmaster@example.com\\ '''Warning''': make sure the address is inside the current zone or else you need an extra DMARC record ||%0a> || rua || Reporting URI of aggregate reports || rua=mailto:postmasters@example.com || Report to postmaster@example.com\\ '''Warning''': make sure the address is inside the current zone or else you need an extra DMARC record ||%0a
25
2023-01-22
jrmu
host:1622971234=38.81.163.143
26
2023-01-22
jrmu
author:1622971155=jrmu
27
2023-01-22
jrmu
diff:1622971155:1622970920:=45,46c45,46%0a%3c || ruf || Reporting URI for forensic reports || ruf=mailto:postmaster@example.com || Report to postmaster@example.com\\ '''Warning''': make sure the address is inside the current zone or else you need an extra DMARC record ||%0a%3c || rua || Reporting URI of aggregate reports || rua=mailto:postmasters@example.com || Report to postmaster@example.com\\ '''Warning''': make sure the address is inside the current zone or else you need an extra DMARC record ||%0a---%0a> || ruf || Reporting URI for forensic reports || ruf=mailto:postmaster@example.com || Report to postmaster@example.com; '''Warning''': make sure the address is inside the current zone or else you need an extra DMARC record ||%0a> || rua || Reporting URI of aggregate reports || rua=mailto:postmasters@example.com || Report to postmaster@example.com; '''Warning''': make sure the address is inside the current zone or else you need an extra DMARC record ||%0a55c55%0a%3c || aspf || Strictness of From headers || aspf=%3cvalue> || (Optional; default aspf=r) Checks MAIL FROM (SMTP) and From: header in message ||%0a---%0a> || aspf || Strictness of From headers|| aspf=%3cvalue> || (Optional; default aspf=r) Checks MAIL FROM (SMTP) and From: header in message ||%0a103,167d102%0a%3c _dmarc IN TXT "v=DMARC1;p=reject;sp=quarantine"%0a%3c %0a%3c Failed mail from user@example.com would be rejected but failed mail from user@subdomain.example.com would be quarantined.%0a%3c %0a%3c %0a%3c %0a%3c _dmarc IN TXT "v=DMARC1;p=reject;sp=quarantine"%0a%3c %0a%3c Examples%0a%3c Example 1: Single Domain Name using DKIM and SPF - Aggressive%0a%3c %0a%3c This is an aggressive policy and should only be adopted where the sender is certain that both DKIM and SPF are correctly configured. Not for the faint-hearted. Assume the domain example.net only sends mail in the form user@example.net (mail is not sent from any subdomain) and that both DKIM and SPF are used in relaxed format. The domain owner wishes to have a daily aggregate report from mail receivers (in Abuse Report format - RFC 5965) of any problems at the address dmarc-admin@example.com if either SPF or DKIM fails, suggests that mail failing any checks should be rejected and that 100%25 of mail should be checked. The following addition to example.net's zone file implements such a policy:%0a%3c %0a%3c # example.net zone file fragment%0a%3c $ORIGIN example.net.%0a%3c ...%0a%3c _dmarc TXT ( "v=DMARC1;p=reject;sp=reject;pct=100;"%0a%3c "adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:dmarc-admin@example.com")%0a%3c %0a%3c # NOTE: since the required email address is out-of-zone the %0a%3c # following change to the zone file for example.com must be made%0a%3c # example.com zone file fragment%0a%3c $ORIGIN example.com.%0a%3c ...%0a%3c example.net._report._dmarc TXT "v=DMARC1"%0a%3c # functionally identical%0a%3c example.net._report._dmarc.example.com. TXT "v=DMARC1"%0a%3c ...%0a%3c %0a%3c Strictly, the adkim=, aspf=, ri= and pct= are not necessary since their defaults are used. However, explicit use of defaults is good defensive configuration policy, and can prevent catastrophic errors in the event that a default is subsequently changed. The use of an out-of-zone email address requires an additional change in the report receivers zone file (example.com in this case) to authorize the reports from the example.net organizational name (see rua/ruf parameters.%0a%3c Example 2: Single Domain Name using DKIM and SPF - Timid%0a%3c %0a%3c This is a timid (or cautious if you prefer) policy where the sender is discovering the real pathology of their mail service and is unsure (or has no idea) if either DKIM and SPF are correctly configured. Assume the domain example.net only sends mail in the form user@example.net (mail is not sent from any subdomain) and that both DKIM and SPF are used in relaxed format. The domain owner wishes to have a daily aggregate report from mail receivers (in Abuse Report format - RFC 5965) of any problems at the address dmarc-admin@example.net if either SPF or DKIM fails, does not want the receiver to reject any failing mail and suggests that only 10%25 of mail should be checked. The following addition to example.net's zone file implements such a policy:%0a%3c %0a%3c # example.net zone file fragment%0a%3c $ORIGIN example.net.%0a%3c ...%0a%3c _dmarc TXT ( "v=DMARC1;p=none;sp=reject;pct=10;"%0a%3c "adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:dmarc-admin@example.net")%0a%3c %0a%3c Strictly, the adkim=, aspf=, ri= and pct= are not necessary since their defaults are used. However, explicit use of defaults is good defensive configuration policy.%0a%3c Example 3: Single Domain Name using SPF only - Aggressive%0a%3c %0a%3c This is an aggressive policy and should only be adopted where the sender is certain that SPF is correctly configured. Assume the domain example.net only sends mail in the form user@example.net (mail is not sent from any subdomain) and that only SPF is used in relaxed format. The domain owner wishes to have a daily aggregate report from mail receivers (in Abuse Report format - RFC 5965) of any problems at the address dmarc-admin@example.net if SPF checks fail, suggests that all mail failing the SPF checks should be rejected and that 100%25 of mail should be checked. The following addition to example.net's zone file implements such a policy:%0a%3c %0a%3c # example.net zone file fragment%0a%3c $ORIGIN example.net.%0a%3c ...%0a%3c _dmarc TXT ( "v=DMARC1;p=reject;sp=reject;pct=100;"%0a%3c "aspf=r;fo=0;ri=86400;rua=mailto:dmarc-admin@example.net")%0a%3c %0a%3c Strictly, the aspf=, ri= and pct= are not necessary since their defaults are used. However, explicit use of defaults is good defensive configuration policy. It is the presence or absence of either DKIM headers or an SPF RR tested when the mail arrives at the receiver that determine which mail security method is in use rather than the configuration of the DMARC RR. In this case we have eliminated the adkim= to make the actual policy explicit and, since only SPF is in operation, fo=0. The same functional result would have ocurred if adkim=r had been retained and fo=1 as in Example 1 above. If only DKIM was being used adkim=r would have been added and aspf=r removed - but again the previous comment also applies - it is the received mail that determines which checks are invoked not the DMARC RR.%0a%3c Example 4: No mail%0a%3c %0a%3c This is a supreme act of good neighborliness. Assume the domain never sends email. The presence of a DMARC is good practice since mail could be forged with the domain's name. There is, however, no way to explictly configure a DMARC RR to indicate that mail will never be sent from this domain. Again, this emphasizes the point that DMARC processing is only invoked once the incoming mail protection mechanisms have been discovered. To indicate that a domain will never send mail must be done with a DMARC RR AND a dummy SPF TXT RR as shown:%0a%3c %0a%3c # example.net zone file fragment%0a%3c $ORIGIN example.net.%0a%3c ...%0a%3c # negative (or dummy) SPF RR%0a%3c example.net. TXT "v=spf1 -all"%0a%3c ...%0a%3c _dmarc TXT "v=DMARC1;p=reject;sp=reject;pct=100;aspf=s"%0a%3c %0a%3c In this case the DMARC is simply saying reject any mail from this domain that fails the SPF check and the SPF TXT RR, by use of the -all ensures that all mail fails the SPF test. Net result - no mail is allowed to be sent from this domain name.%0a
28
2023-01-22
jrmu
host:1622971155=38.81.163.143
29
2023-01-22
jrmu
author:1622970920=jrmu
30
2023-01-22
jrmu
diff:1622970920:1622968167:=41,46c41,45%0a%3c || border=1 width=100%25 class="sortable simpletable"%0a%3c ||! Tag ||! Indicates ||! Example ||! Meaning ||%0a%3c || v || DMARC version || v=DMARC1 || First DMARC version; DMARC must be all uppercase; required ||%0a%3c || pct || Percent of mail to filter || pct=20 || Filter 20%25 of mails; increase slowly over time to detect configurations mistakes gradually ||%0a%3c || ruf || Reporting URI for forensic reports || ruf=mailto:postmaster@example.com || Report to postmaster@example.com; '''Warning''': make sure the address is inside the current zone or else you need an extra DMARC record ||%0a%3c || rua || Reporting URI of aggregate reports || rua=mailto:postmasters@example.com || Report to postmaster@example.com; '''Warning''': make sure the address is inside the current zone or else you need an extra DMARC record ||%0a---%0a> || Tag || Indicates || Example || Meaning ||%0a> || v || DMARC version || v=DMARC1 || First DMARC version; required ||%0a> || pct || Percent of mail to filter || pct=20 || Filter 20%25 of mails ||%0a> || ruf || Reporting URI for forensic reports || ruf=mailto:postmaster@example.com || Report to postmaster@example.com ||%0a> || rua || Reporting URI of aggregate reports || rua=mailto:postmasters@example.com || Report to postmaster@example.com ||%0a52,63c51%0a%3c || adkim || Strictness of DKIM headers|| adkim=%3cvalue> || (Optional; default adkim=r) Checks if d=name matches ||%0a%3c || || || adkim=r || Relaxed; subdomains of d=name are accepted ||%0a%3c || || || adkim=s || Strict; subdomains of d=name not accepted ||%0a%3c || aspf || Strictness of From headers|| aspf=%3cvalue> || (Optional; default aspf=r) Checks MAIL FROM (SMTP) and From: header in message ||%0a%3c || || || aspf=r || Relaxed; subdomains of d=name are accepted ||%0a%3c || || || aspf=s || Strict; subdomains of d=name not accepted ||%0a%3c || fo || When to Report || fo=%3cvalue> || (Optional; default fo=0) ||%0a%3c || || || fo=0 || Send only if all requested checks fail ||%0a%3c || || || fo=1 || Send if any requested checks fail ||%0a%3c || || || fo=d || Send if DKIM fails ||%0a%3c || || || fo=s || Send if SPF fails ||%0a%3c %0a---%0a> %0a82,102d69%0a%3c %0a%3c This record will provide you with reports for both DKIM/SPF, but will not%0a%3c enforce any filtering whatsoever. This makes this entry very useful for testing%0a%3c out if a new mail server is configured properly. However, this loose configuration%0a%3c may allow more spammers to spoof your domain because bad email is not rejected.%0a%3c %0a%3c Here's a different record:%0a%3c %0a%3c [@%0a%3c _dmarc IN TXT "v=DMARC1;p=reject;sp=quarantine;pct=100;fo=1;rua=mailto:postmaster@example.com;ruf=mailto:postmaster@example.com"%0a%3c @]%0a%3c %0a%3c || border=1 width=100%25 class="sortable simpletable"%0a%3c ||! Pair ||! Meaning ||%0a%3c || v=DMARC1 || First DMARC version ||%0a%3c || p=none || No advice is given ||%0a%3c || pct=0 || Filter 0%25 of mails ||%0a%3c || fo=1 || Report all errors from DKIM and SPF ||%0a%3c || rua=mailto:postmaster@example.com || Send user aggregate reports to postmaster@example.com||%0a%3c || ruf=mailto:postmaster@example.com || Send forensic reports to postmaster@example.com ||%0a%3c %0a
31
2023-01-22
jrmu
host:1622970920=38.81.163.143
32
2023-01-22
jrmu
author:1622968167=jrmu
33
2023-01-22
jrmu
diff:1622968167:1622891649:=40a41,46%0a> || border=1 width=100%25 class="sortable simpletable"%0a> ||! Record ||! Meaning ||%0a> || "v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@dmarcdomain.com" || ||%0a> %0a> In this example, the sender requests that the receiver outright reject all non-aligned messages and send a report, in a specified aggregate format, about the rejections to a specified address. If the sender was testing its configuration, it could replace reject with quarantine which would tell the receiver they shouldnt necessarily reject the message, but consider quarantining it.%0a> %0a52,54c58,60%0a%3c TXT records are used to store DMARC information to avoid having to upgrade DNS%0a%3c software to support special resource record types.%0a%3c %0a---%0a> TXT records are used to avoid having to upgrade DNS software to support special%0a> resource record types.%0a> %0a56c62%0a%3c _dmarc IN TXT "v=DMARC1;p=none;pct=0;fo=1;rua=mailto:postmaster@example.com;ruf=mailto:postmaster@example.com"%0a---%0a> _dmarc IN TXT "%3cdmarc text>"%0a59,69c65%0a%3c Between the two quotation marks "", we put in our DMARC information, which is made up%0a%3c of key=value pairs separated by semicolors ;.%0a%3c %0a%3c || border=1 width=100%25 class="sortable simpletable"%0a%3c ||! Pair ||! Meaning ||%0a%3c || v=DMARC1 || First DMARC version ||%0a%3c || p=none || No advice is given ||%0a%3c || pct=0 || Filter 0%25 of mails ||%0a%3c || fo=1 || Report all errors from DKIM and SPF ||%0a%3c || rua=mailto:postmaster@example.com || Send user aggregate reports to postmaster@example.com||%0a%3c || ruf=mailto:postmaster@example.com || Send forensic reports to postmaster@example.com ||%0a---%0a> We replace @@%3cdmarc text>@@ with our actual text.%0a
34
2023-01-22
jrmu
host:1622968167=38.81.163.143
35
2023-01-22
jrmu
author:1622891649=jrmu
36
2023-01-22
jrmu
diff:1622891649:1622891564:=51c51%0a%3c || rua || Reporting URI of aggregate reports || rua=mailto:postmasters@example.com || Report to postmaster@example.com ||%0a---%0a> || rua || Reporting URI of aggregate reports || rua=mailto:postmasters@example.com | Report to postmaster@example.com|%0a
37
2023-01-22
jrmu
host:1622891649=38.81.163.143
38
2023-01-22
jrmu
author:1622891564=jrmu
39
2023-01-22
jrmu
diff:1622891564:1622890179:=0a1%0a> %0a52c53%0a%3c || p || Policy for domain || p=%3cvalue> || Required; applies to domain (and subdomains if sp= not specified) ||%0a---%0a> || p || Policy for domain || p=%3cvalue> || Required ||%0a56c57%0a%3c || sp || Policy for subdomains || sp=%3cvalue> || Same as above, but for subdomains only ||%0a---%0a> || sp || Policy for subdomains || sp=reject || Reject mail from subdomain ||%0a
40
2023-01-22
jrmu
host:1622891564=38.81.163.143
41
2023-01-22
jrmu
author:1622890179=jrmu
42
2023-01-22
jrmu
diff:1622890179:1622890179:=1,66d0%0a%3c %0a%3c (:title DMARC:)%0a%3c %0a%3c !! Recommended Reading%0a%3c %0a%3c This guide only provides a quick simplified overview of DMARC and a howto for%0a%3c configuring your DNS resource records. To better understand the subject, you%0a%3c should check out [[https://dmarc.org/overview/|the official DMARC website]].%0a%3c [[http://www.zytrax.com/books/dns/ch9/dmarc.html|DNS for Rocket Scientists]] is%0a%3c also helpful.%0a%3c %0a%3c !! Why DMARC%0a%3c %0a%3c To prevent phishing emails and spam, we use SPF and DKIM. However, sometimes real%0a%3c messages may not authenticate properly, and other times fake messages may get%0a%3c accepted. Senders need some way to get feedback on how many emails are being%0a%3c sent and marked as fake. This helps with troubleshooting, improving delivery%0a%3c rates, and detecting fraud.%0a%3c %0a%3c The Domain-based Message Authentication, Reporting and Conformance ('''DMARC''')%0a%3c provides a way for mail senders and receivers to share this information.%0a%3c %0a%3c DMARC helps:%0a%3c %0a%3c # reduce false positives%0a%3c # report on how much mail has authenticated%0a%3c # tell the receiver the sender's policy%0a%3c # reduce phishing%0a%3c %0a%3c Inside a DMARC record, you tell the mail server:%0a%3c %0a%3c # if you are using DKIM, SPF, or both.%0a%3c # how to handle mail that doesn't validate.%0a%3c # if you want a feedback report, and how to report.%0a%3c %0a%3c Note that DMARC uses DKIM and SPF; it does not replace either.%0a%3c %0a%3c To use DMARC, you just add a TXT record in your DNS zone:%0a%3c %0a%3c !! How it works%0a%3c %0a%3c || border=1 width=100%25 class="sortable simpletable"%0a%3c ||! Record ||! Meaning ||%0a%3c || "v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@dmarcdomain.com" || ||%0a%3c %0a%3c In this example, the sender requests that the receiver outright reject all non-aligned messages and send a report, in a specified aggregate format, about the rejections to a specified address. If the sender was testing its configuration, it could replace reject with quarantine which would tell the receiver they shouldnt necessarily reject the message, but consider quarantining it.%0a%3c %0a%3c || Tag || Indicates || Example || Meaning ||%0a%3c || v || DMARC version || v=DMARC1 || First DMARC version; required ||%0a%3c || pct || Percent of mail to filter || pct=20 || Filter 20%25 of mails ||%0a%3c || ruf || Reporting URI for forensic reports || ruf=mailto:postmaster@example.com || Report to postmaster@example.com ||%0a%3c || rua || Reporting URI of aggregate reports || rua=mailto:postmasters@example.com | Report to postmaster@example.com|%0a%3c || p || Policy for domain || p=%3cvalue> || Required ||%0a%3c || || || p=none || No advice given ||%0a%3c || || || p=quarantine || If checks fail, mail is suspicious ||%0a%3c || || || p=reject || If checks fail, reject mail ||%0a%3c || sp || Policy for subdomains || sp=reject || Reject mail from subdomain ||%0a%3c %0a%3c TXT records are used to avoid having to upgrade DNS software to support special%0a%3c resource record types.%0a%3c %0a%3c [@%0a%3c _dmarc IN TXT "%3cdmarc text>"%0a%3c @]%0a%3c %0a%3c We replace @@%3cdmarc text>@@ with our actual text.%0a
43
2023-01-22
jrmu
host:1622890179=38.81.163.143
IRCNow