In the early days of ‘modern email’, there were limited mechanisms available to support sender verification. Nearly all spam, scams, and viruses that spread through email did so using falsified sender information – as some still do today. Verifying who email senders actually are was and still is a difficult process.

Take the example of visiting www.google.com and submitting a search. You’re generally pretty confident that Google has control over what gets sent back to you for your search and the search results are secure. This is because the Domain Name System (DNS)—a distributed network of servers that act as a phonebook—connects the domain with a variety of records, including where to find the real google.com.

Email uses a later adaptation of this same system to verify senders, which is exactly what a Sender Policy Framework (SPF) record is.

Advantages and Potential Drawbacks of SPF

SPF is adept at preventing phishing. Without it, SMTP would expose your address to those who could forge it for spamming purposes. With SPF in place, when a hacker attempts to initiate an email from your address, the receiving server’s SPF security detects it and identifies it as invalid. Using SPF shows your organization is committed to protecting against cyber threats, a sign that positively impacts your sender reputation.

When a user outside your domain forwards an email that originated from you, the delivery may not occur because of a mismatch between the IP record and the SPF record. Many mail exchange and transfer agents are now using the Sender Rewriting Scheme (SRS) to enhance the deliverability of email forwards. The SPF record also must reflect any changes in third-party email services providers to ensure they correspond for deliverability.

How SPF Works

At the most basic level, SPF email establishes a method for receiving servers to verify that incoming email from a domain was sent from a host authorized by that domain’s administrators. The following three steps outline how SPF works:

1. A domain administrator publishes the policy defining mail servers that are authorized to send email from that domain. This policy is called an SPF record, and it is listed as part of the domain’s overall DNS records.

2. When an inbound mail server receives an incoming email, it looks up the rules for the bounce (Return-Path) domain in DNS. The inbound server then compares the IP address of the mail sender with the authorized IP addresses defined in the SPF record.

3. The receiving mail server then uses the rules specified in the sending domain’s SPF record to decide whether to accept, reject, or otherwise flag the email message.

   
   

To take the first step of inspecting your own SPF record, you can do so with SparkPost’s free tool – the SPF Inspector.

Once you’ve identified which servers are authorized to send on behalf of a domain, you can then create an SPF record for your domain through the SPF Builder.

Creating an SPF record will move you one step closer to ensuring that legitimate email that comes from your domain is successfully delivered to customer inboxes.

When it comes to verifying that an email message was sent from an authorized mail server, that’s where DKIM comes in.

Advantages and Potential Drawbacks of DKIM Authentication

DKIM email’s primary advantage is its ability to protect against both spoofing and phishing attacks. The authentication appears within the message itself to prevent forgery and safeguard users from replying to illegitimate emails with sensitive personal data. Both spoofing and phishing have the potential to harm your sending reputation and future deliverability, so protection against the two is beneficial.

Creating an email with DKIM has the same potential disadvantage as SPF when it comes to forwarding messages. For example, an email that automatically routes from an office computer to a user’s mobile may appear as illegitimate to the receiving server. Many popular email services have resolved this issue. One other challenge that may present itself is a DKIM that is too short in length. With more support for longer keys, shorter ones may not pass authentication.

How DKIM Works

Simply put, DKIM works by adding a digital signature to the headers of an email message. This signature can then be validated against a public cryptographic key that is located in the organization’s DNS record.

The domain owner publishes a cryptographic key. This is specifically formatted as a TXT record in the domain’s overall DNS record.

After a message is sent by an outbound mail server, the server generates and attaches the unique DKIM signature to the header of the message.

The DKIM key is then used by inbound mail servers to detect and decrypt the message’s signature and compare it against a fresh version. If the values match, the message can be proved authentic, and unaltered in transit, and therefore, not forged or altered.

You can validate your email with the DKIM Validator.