SMTP – SPAM Challenges & Solutions

SPF (Sender Policy Framework)

What it is: SPF is an email authentication protocol that allows the owner of a domain to specify which mail servers they use to send mail from that domain.

How it works: Brands sending email to publish SPF records in the Domain Name System (DNS). These records list which IP addresses are authorized to send emails on behalf of their domains.

But SPF has a few major problems:

1. Keeping SPF records updated as brands change service providers and add mail streams is difficult due to lack of visibility.
2. Just because a message fails SPF, doesn’t mean it will always be blocked from the inbox—it’s one of several factors email providers take into account.
3. SPF breaks when a message is forwarded.
4. SPF does nothing to protect brands against cybercriminals who spoof the display name or “header from” address in their message, which is the more frequently spoofed “from” address since it’s the address most visible to the email recipient.

TXT records

 DMARC policy

A DMARC policy allows a sender’s domain to indicate that their emails are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes – such as to reject the message or quarantine it. The policy can also specify how an email receiver can report back to the sender’s domain about messages that pass and/or fail.

These policies are published in the public Domain Name System (DNS) as text TXT records.

DMARC doesn’t directly address whether or not an email is spam or otherwise fraudulent. Instead, DMARC can require that a message not only pass DKIM or SPF validation, but that it also pass alignment. Under DMARC a message can fail even if it passes SPF or DKIM, but fails alignment.

Setting up DMARC may have a positive impact on deliverability for legitimate senders.

Alignment

DMARC operates by checking that the domain in the message’s From: field (also called “RFC5322.From”^[2]) is “aligned” with other authenticated domain names. If either SPF or DKIM alignment checks pass, then the DMARC alignment test passes.

Alignment may be specified as strict or relaxed.

For strict alignment, the domain names must be identical.

For relaxed alignment, the top-level “Organizational Domain” must match. The Organizational Domain is found by checking a list of public DNS suffixes, and adding the next DNS label. So, for example, “a.b.c.d.example.com.au” and “example.com.au” have the same Organizational Domain, because there is a registrar that offers names in “.com.au” to customers. Albeit at the time of DMARC spec there was an IETF working group on domain boundaries, nowadays the organizational domain can only be derived from the Public Suffix List.^[6]

Like SPF and DKIM, DMARC uses the concept of a domain owner, the entity or entities that are authorized to make changes to a given DNS domain.

SPF checks that the IP address of the sending server is authorized by the owner of the domain that appears in the SMTP MAIL FROM command. (The email address in MAIL FROM is also called the bounce address, envelope-from or RFC5321.MailFrom.) In addition to requiring that the SPF check pass, DMARC additionally checks that RFC5321.MailFrom aligns with 5322.From.

DKIM allows parts of an email message to be cryptographically signed, and the signature must cover the From field. Within the DKIM-Signature mail header, the d= (domain) and s= (selector) tags specify where in DNS to retrieve the public key for the signature. A valid signature proves that the signer is a domain owner, and that the From field hasn’t been modified since the signature was applied. There may be several DKIM signatures on an email message; DMARC requires one valid signature where the domain in the d= tag aligns with the sender’s domain stated in the From: header field.

What is a DKIM record?

DKIM (DomainKeys Identified Mail) is an email security standard designed to make sure messages aren’t altered in transit between the sending and recipient servers. It uses public-key cryptography to sign an email with a private key as it leaves a sending server. Recipient servers then use a public key published to a domain’s DNS to verify the source of the message, and that the body of the message hasn’t changed during transit. Once the signature is verified with the public key by the recipient server, the message passes DKIM and is considered authentic.

Why is a DKIM record important?

While DKIM isn’t required, having emails that are signed with DKIM appear more legitimate to your recipients and are less likely to go to Junk or Spam folders. Spoofing email from trusted domains is a popular technique for malicious spam and phishing campaigns, and DKIM makes it harder to spoof email from domains that use it.

DKIM is compatible with existing email infrastructure and works with SPF and DMARC to create multiple layers of security for domains sending emails. Mail servers that don’t support DKIM signatures are still able to receive signed messages without any problems. It’s an optional security protocol, and DKIM is not a universally adopted standard.

Even though it’s not required, we recommend you add a DKIM record to your DNS whenever possible to authenticate mail from your domain. An additional benefit of DKIM is that ISPs use it to build a reputation on your domain over time. As you send email and improve your delivery practices (low spam and bounces, high engagement), you help your domain build a good sending reputation with ISPs, which improves deliverability.

How do DKIM records work?

DKIM uses two actions to verify your messages. The first action takes place on a server sending DKIM signed emails, while the second happens on a recipient server checking DKIM signatures on incoming messages. The entire process is made possible by a private/public key pair. Your private key is kept secret and safe, either on your own server or with your ESP, and the public key is added to the DNS records for your domain to broadcast it to the world to help verify your messages. Let’s dive a little deeper into how DKIM works on servers that are sending and receiving email.

To give you an idea of how DKIM works, let’s explain the process on Postmark. We keep your private key securely stored on our servers and sign each message as it is sent. When a message is sent we create a hash from the content of the message headers and then use your private key to sign the hash. This signature carries everything a recipient server needs to validate the message and looks like this:

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=20130519032151pm; d=postmarkapp.com;
h=From:Date:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:To:Message-ID;
i=support@postmarkapp.com; bh=vYFvy46eesUDGJ45hyBTH30JfN4=;
b=iHeFQ+7rCiSQs3DPjR2eUSZSv4i/Kp+sipURfVH7BGf+SxcwOkX7X8R1RVObMQsFcbIxnrq7Ba2QCf0YZlL9iqJf32V+baDI8IykuDztuoNUF2Kk0pawZkbSPNHYRtLxV2CTOtc+x4eIeSeYptaiu7g7GupekLZ2DE1ODHhuP4I=

Here’s what each part of the header means:

• DKIM-Signature: The header registered for DKIM signed messages.
• v=1; The version of DKIM being used by the sending server.
• a=rsa-sha1; The algorithm used to generate the hash for the private/public key. There are two officially supported signature algorithms for this hash, rsa-sha1 and rsa-sha256.
• c=relaxed/relaxed; Sets the canonicalization posture for the sending domain. This regulates whitespace and text wrapping changes in a message. There are two canonicalized postures. `Simple` doesn’t allow any changes, and `relaxed` allows common changes to whitespace and header line-wrapping. Canonicalization in the header and body can be managed individually and uses a header/body format.
• s=20130519032151pm; Used as a selector for the public DKIM key for verification. Domains can have multiple public DKIM keys, and the selector value makes sure recipient servers are using the correct public key.
• d=postmarkapp.com; The email domain that signed the message. It’s important that your DKIM signature use your domain name here because this bolsters your domain’s reputation with ISPs as you send valid email, regardless of the Email Service Provider you use.
• From:Date:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:To:Message-ID; The headers included with the message when it was cryptographically signed.
• i=support@postmarkapp.com; The identity of the signer and is usually provided as an email address.
• bh=vYFvy46eesUDGJ45hyBTH30JfN4=; The value of a body hash generated before the message headers are signed.
• b=iHeFQ+7rCiSQs3DPjR2eUSZSv4i/Kp+sipURfVH7BGf+SxcwOkX7X8R1RVObMQsFcbIxnrq7Ba2QCf0YZlL9iqJf32V+baDI8IykuDztuoNUF2Kk0pawZkbSPNHYRtLxV2CTOtc+x4eIeSeYptaiu7g7GupekLZ2DE1ODHhuP4I=The cryptographic signature of all the preceding information from the DKIM-Signature field. This entry is treated as an empty string during the verification process.

How do I add a DKIM record to my domain?

No matter which ESP or mail server you use, the general setup for DKIM is the same. You need a private key stored somewhere safe, and you need to share a public key in your domain’s DNS records. Similar to SPF, DKIM also uses DNS TXT records with a special format.

It’s considered best practice to periodically rotate your DKIM keys. The DKIM standard recommends rotating your keys every quarter, and it also recommends you revoke your old DKIM keys as part of this rotation. The best way to manage this is by adding your new keys, and a few days later removing your old keys DNS records for your domain. Postmark is one of the only ESPs that make it easy to manage this rotation because we keep your old private key active while your new public key propagates.