Ending unsolicited email (SPAM)

See also: the Identifying Phishing blog post at MxToolbox

The traditional email acceptance model is to accept email unless you have a reason to reject it. Trust, unless there is a reason not to. The spammer sends emails; recipients complain and filters are adjusted to block the current batch. The spammer makes changes that avoid the filters, and the cycle continues.

One such filter is sender’s IP address. Blocking email by sender IP address is a maintenance burden made worse by IPv6.

The model needs to change to one that accepts only those sources where there is a reason to trust. The solution must extend the current email mechanisms when adding a trust mechanism.

Part of the solution is for the sender to implement a Sender Policy Framework (SPF) text record in the Domain Name System (DNS). The SPF record lists which IP addresses are permitted to email on behalf of the domain. The recipient’s email server (Mail Transfer Agent or MTA) can compare the sending IP address with those listed in the DNS. The MTA can make informed decisions about whether to accept the email without requiring maintenance.

A DomainKeys Identified Mail (DKIM) text record in the DNS enables the sending organization the sign messages. The DKIM record contains a public key from a asymmetric RSA key pair. The recipient’s MTA can verify that the message was sent by the organization which claims to have sent it.

A Domain-based Message Authentication, Reporting & Conformance (DMARC) text record in the DNS indicates the recommended disposition of an email which fails SPF source verification or DKIM authentication. The recipient MTA could be advised to accept the email, accept the email as spam, or reject the email.

Responsible mail senders are advised to implement SPF, DKIM, and DMARC quickly. Email recipients will want a no-maintenance method for disposing of spam.

https://blogs.msdn.microsoft.com/tzink/2016/02/19/common-errors-in-spf-records/