Що таке SPF, DKIM і DMARC і чому від них залежить безпека листів скидання пароля?

Протокол SMTP не перевіряє відправника: будь-хто може надіслати лист з From: security@your-app.com. Три DNS-записи дозволяють поштовим сервісам відрізнити справжній лист від підробки.

SPF - які сервери мають право відправляти пошту домену:

your-app.com.  TXT  "v=spf1 include:mailgun.org include:_spf.google.com -all"

Отримувач перевіряє IP-адресу сервера-відправника. Обмеження: SPF перевіряє технічну адресу конверта (Return-Path), а не видимий користувачу From, і ламається при пересиланні листів.

DKIM - криптографічний підпис листа:

mg._domainkey.your-app.com.  TXT  "k=rsa; p=MIGfMA0..."

Поштовий сервіс підписує заголовки й тіло приватним ключем, отримувач перевіряє підпис публічним ключем з DNS. Лист не можна змінити дорогою, а підпис прив'язаний до домену.

DMARC - політика, що зв'язує все разом:

_dmarc.your-app.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@your-app.com; adkim=s; aspf=s"

• вимагає вирівнювання (alignment): домен у видимому From має збігатися з доменом, що пройшов SPF чи DKIM. Саме це захищає від підробки адреси, яку бачить користувач;
• політика: p=none (лише звіти), p=quarantine (у спам), p=reject (відхилити);
• rua - щоденні агреговані звіти: хто й скільки листів відправляє від імені домену.

Чому це питання безпеки, а не лише доставки:

• фішинг від вашого імені: без DMARC зловмисник надсилає «Скиньте пароль за посиланням» з вашого домену, і листи виглядають справжніми;
• листи скидання пароля й коди входу, що потрапили в спам чи відхилені, - користувачі не можуть увійти й звертаються в підтримку, де їх легше обдурити соціальною інженерією;
• з 2024 року Gmail і Yahoo вимагають від масових відправників (понад 5000 листів на день до Gmail) SPF, DKIM і DMARC, а від усіх відправників - щонайменше SPF чи DKIM; без них листи потрапляють у спам або відхиляються.

Як впроваджувати без зламаної пошти:

1. SPF і DKIM для кожного сервісу, що відправляє від вашого домену (Mailgun, SES, CRM, служба підтримки);
2. DMARC з p=none і звітами - кілька тижнів дивитися, хто ще відправляє;
3. поступово quarantine, потім reject.

Окремий піддомен для транзакційної пошти (mg.your-app.com) ізолює її репутацію від маркетингових розсилок.

Домени без пошти теж треба захистити: v=spf1 -all і p=reject, інакше їх використають для підробки.

Докладніше в документації: RFC 7489: DMARC