= DNS/DMARC =

<<TableOfContents()>>
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
https://datatracker.ietf.org/doc/html/rfc7489


偽称されたメールを受信側がどう扱ってほしいかの方針を
ドメインの管理者側が宣言するための仕組みです。

https://sendgrid.kke.co.jp/blog/?p=3137  DMARC

https://www.dmarc25.jp/?gclid=EAIaIQobChMItY6J4p7R9wIVBwRgCh0-_w8iEAAYAiAAEgL3mvD_BwE

{{{
_dmarc.iij.ad.jp.	3600	IN	TXT	"v=DMARC1; p=none; adkim=s; aspf=s; rua=mailto:dmarc-rua@dmarc.iij.ad.jp"


iij.ad.jp.		3600	IN	TXT	"v=spf1 include:spf.iij.ad.jp -all"

spf.iij.ad.jp.		3600	IN	TXT	"v=spf1 ip4:210.128.13.205 ip4:210.128.13.206 ip4:203.180.38.48/31 ip4:203.180.38.160/28 ip4:210.148.192.254 ip4:210.149.167.250 ip4:160.13.17.56/29 ip4:160.13.17.64/29 ip4:210.128.50.96/27 include:v6spf.iij.ad.jp ~all"

}}}



5.  Use of RFC5322.From

   One of the most obvious points of security scrutiny for DMARC is the
   choice to focus on an identifier, namely the RFC5322.From address,
   which is part of a body of data that has been trivially forged
   throughout the history of email.

   Several points suggest that it is the most correct and safest thing
   to do in this context:

   o  Of all the identifiers that are part of the message itself, this
      is the only one guaranteed to be present.

   o  It seems the best choice of an identifier on which to focus, as
      most MUAs display some or all of the contents of that field in a
      manner strongly suggesting those data as reflective of the true
      originator of the message.

   The absence of a single, properly formed RFC5322.From field renders
   the message invalid.  Handling of such a message is outside of the
   scope of this specification.