1. DNS/DMARC

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.