こんにちは、Habr！ この記事では、DKIM / SPF / DMARCレコードの構成について説明します。 そして、ロシア語での文書の完全な欠如は、私にこの記事を書くように促しました。 私が見つけたこの主題に関するすべての記事は、非常に有益ではありませんでした。
1. DKIM
DKIM（DomainKeys Identified Mail）は、デジタル署名認証に基づく電子メール認証方法です。 公開鍵はTXTドメインレコードに保存されます。
なぜ必要なのですか？
メールサービスが送信者が信頼できるかどうかを確認できるように、DKIMが必要です。 つまり さまざまな不正な手紙（送信者のアドレスの代わりに送信される）から手紙の受信者を保護します。
DKIM署名とDNSレコードを構成する
このために、キーペアを作成する必要があります。
openssl genrsa -out private.pem 1024 // 1024
openssl rsa -pubout -in private.pem -out public.pem //
または、オンラインサービスを使用することもできます。これを強くお勧めします。
次に、メールサーバーの構成ファイルの秘密キー（このため、ドキュメントを読むことをお勧めします）とDNSの公開キーを使用してパスを指定する必要があります。
エントリの例は次のとおりです。
mail._domainkey.your.tld TXT "v=DKIM1; k=rsa; t=s; p=< >"
どこで
mailはセレクターです。 異なるセレクターで複数のレコードを指定できます。各レコードには独自のキーがあります。 複数のサーバーが関係する場合に適用されます。 （各サーバーには独自のキーがあります）
v -DKIMのバージョン。常に値
v=DKIM1ます。 （必須）
kはキータイプで、常に
k=rsaです。 （少なくとも今のところ）
pは、base64でエンコードされた公開キーです。 （必須）
tフラグ：
t=yテストモード。 このような区別は、符号なしとは異なり、結果を追跡するためにのみ必要です。
t=sレコードが属するドメインにのみレコードが使用されることを意味します。サブドメインを使用する場合はお勧めしません。
可能な：
h優先ハッシュアルゴリズム。値はh = sha1およびh = sha256になります。
s -DKIMを使用したサービスのタイプ。 値は
s=email （email）および
s=* （すべてのサービス）で、デフォルトでは「*」です。
; -セパレータ。
また、手紙に署名する必要があるかどうかを理解できるADSPレコードを処方する価値があります。
_adsp._domainkey.example.com. TXT "dkim=all"次の3つの値があります。
allすべての文字に署名する必要があります
discardable -署名のないメールは受け付けません
unknown -不明（本質的に、レコードがないことに似ています）
2. SPF
SPF（Sender Policy Framework）-SMTP経由で電子メールを送信するためのプロトコルの拡張。 SPFはRFC 7208（
Wiki ）で定義されています。 簡単に言えば、SPFは送信者サーバーをチェックしてメッセージを認証するメカニズムです。 私にとっては、このテクノロジーは他のテクノロジー（DKIMおよびDMARC）と併用すると便利です。
SPFレコードを構成する
通常のSPFレコードの例は
your.tld. TXT "v=spf1 a mx ~all" your.tld. TXT "v=spf1 a mx ~all"ここに：
v=spf1はバージョン、常にspf1
a-送信者のドメインのAおよび\またはAAAAレコードで指定されたアドレスからのレターの送信を許可します
mx -mxドメインレコードで指定されたアドレスからレターを送信できます
（aおよびmxの場合、たとえば
a:example.com 、別のドメインを指定できます。送信者のドメインではなく、
example.comを記録でき
ます ）
また、
ip4:および
ip6:を使用して個々のIPアドレスを追加することもでき
ip6: たとえば、
ip4:1.1.1.1 ip6: 2001:0DB8:AA10:0001:0000:0000:0000:00FB 。
include: （
include:spf.example.com ）もあり
include:これにより、別のドメインのspfレコードを追加で接続できます。 これはすべてスペースと組み合わせることができます。 別のドメインのエントリを補足せずに使用する必要がある場合は、
redirect:を使用
redirect:が最善
redirect: （
redirect:spf.example.com ）
-allポリシーに準拠していない文字で何が起こるかを意味し
-all ： "-"-拒否、 "+"-スキップ、 "〜"-追加チェック、 "？" -ニュートラル。
3.DMARC
ドメインベースのメッセージ認証、レポートおよび適合性、またはDMARCは、送信者の電子メールドメインの識別に基づいてスパムおよびフィッシング電子メールの数を減らすように設計された組織のグループによって作成された技術仕様です受信者のメールサーバー（
Wiki ）に設定されたルールと機能に基づきます。 つまり、メールサーバーはメッセージが良いか悪いかを判断し（たとえば、上記のポリシーに基づいて）、DMARCレコードに従って動作します。
DMARCレコードの設定
典型的なエントリは次のようになります：
_dmarc.your.tld TXT "v=DMARC1; p=none; rua=mailto:postmaster@your.tld"レポートの準備と送信以外のアクションは実行しません。
タグの詳細：
vバージョン、値を取る
v=DMARC1 （必須パラメーター）
pはドメインのルールです。 （必須）
none 、
quarantine 、
reject場合があります。ここで、
p=noneはレポートを準備するだけです
p=quarantineはスパムメールを追加します
p=rejectは手紙
p=reject拒否します
spはサブドメインを担当し、
pと同じ値を取ります
aspfと
adkim 、レコード
adkimチェック
adkim許可し、
rと
s値を取ることができます。ここで、rは、sよりも緩やかな緩やかなチェックです。
pctはフィルタリングされる文字の数に責任があり、パーセンテージで示されます。たとえば、
pct=20は20％の文字をフィルタリングします。
ruaたとえば、
rua=mailto:postmaster@your.tld 、電子メールで日次レポートを送信できます。スペースを使用して複数の電子メールを指定することもできます（
rua=mailto:postmaster@your.tld mailto:dmarc@your.tld ）
レポートの例 <record> <row> <source_ip>1.1.1.1</source_ip> <count>1</count> <policy_evaluated> <disposition>none</disposition> </policy_evaluated> </row> <identities> <header_from>your.tld</header_from> </identities> <auth_results> <dkim> <domain>your.tld</domain> <result>pass</result> <human_result></human_result> </dkim> <spf> <domain>your.tld</domain> <result>pass</result> </spf> </auth_results> </record> <record> <row> <source_ip>1.1.1.1</source_ip> <count>1</count> <policy_evaluated> <disposition>none</disposition> <reason> <type>forwarded</type> <comment></comment> </reason> </policy_evaluated> </row> <identities> <header_from>your.tld</header_from> </identities> <auth_results> <dkim> <domain>your.tld</domain> <result>pass</result> <human_result></human_result> </dkim> <spf> <domain>your.tld</domain> <result>pass</result> </spf> </auth_results> </record>
ruf -DMARC検証に合格しなかった手紙のレポート。 それ以外の場合、すべては上記と同じです。
エピローグ
DKIM / SPF / DMARCを設定し、なりすましに抵抗する方法を学びました。 残念ながら、これは、サーバーがハッキングされたり、これらのテクノロジーをサポートしていないサーバーにレターを送信した場合のセキュリティを保証するものではありません。 幸いなことに、人気のあるサービスはまだそれらをサポートしています（これらのポリシーのイニシエーターもあります）。
この記事は、一種のドキュメントである自己調整レコードの説明です。 各サーバーは一意であり、独自の構成が必要であるため、意図的な既製の例はありません。
私は建設的な批判と修正を喜んでいます。