- June 1, 2021
- Posted by: Syed Shujaat
- Category: Cloud Solutions, Technology
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:
- Keeping SPF records updated as brands change service providers and add mail streams is difficult due to lack of visibility.
- 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.
- SPF breaks when a message is forwarded.
- 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 are a type of Domain Name System (DNS) record that contains text information for sources outside of your domain. You add these records to your domain settings.
You can use TXT records for various purposes. Google uses them to verify domain ownership and to ensure email security.
Use TXT records to verify domain ownership
When you set up your Google Workspace or Google Cloud account, Google gives you a record to add to your domain settings. When Google sees that you’ve added the record, your domain ownership is confirmed
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.
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.
DMARC operates by checking that the domain in the message’s
From: field (also called “RFC5322.From”) 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.
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.