Sender Policy Framework (SPF) is an email authentication protocol designed to stop attackers from sending emails that appear to come from your domain. An SPF policy tells receiving mail servers which sending sources are legitimate for your domain, helping prevent email spoofing, phishing, and domain impersonation.

Your SPF policy is published in your Domain Name System (DNS) as a TXT record, listing the mail servers (IP addresses) authorized to send on your behalf. When an email is sent, the recipient’s mail server checks this policy to confirm whether the sending IP address is approved. If it matches, the message is delivered; if not, it may be flagged as spam or rejected.

An SPF lookup is when the DNS receiving your email has to ‘look up’ the IP addresses present in any of the include statements within your record, to check if they match with the IP sending your email. 

An SPF include is a feature within SPF records that allows domain owners to include the SPF records of other domains in their own SPF policy. This enables streamlined management and ensures that the included domains' email sending policies are considered when determining the legitimacy of emails sent from the including domain.

The SPF lookup limit is the number of times a recipient DNS can carry out a lookup for a domain with a maximum cap set at 10.

You can add unlimited singular IP addresses to your record without incurring additional DNS lookups, as they are directly visible in the record.

But this isn’t the case for include statements, and the number of IP addresses an include has equals the number of lookups the receiving DNS has to carry out. This contributes to your maximum total of 10. 

So for example, you might have 3 IP addresses listed in your SPF record as they are, an include statement for Google (which contains 4 IP addresses) and an include statement for Mimecast (which contains 6). The receiving DNS doesn’t need to carry out lookups for the visible IPs, but it does for the Google and Mimecast include statements. So in this case, you’ve reached your total of 10.

In reality, 10 lookups aren’t enough, because most businesses use a number of tools that send emails on their behalf. These will all have their own include statements, which will include IP addresses, and so will require lookups. If you go over the limit, then you’ll likely fail authentication and your deliverability will suffer.

One of the main reasons the SPF record might be failing for your email traffic is the “too many DNS lookups” error. The SPF specification limits the number of DNS lookups to 10. If your SPF record results in more than 10 DNS lookups then SPF will fail. The SPF mechanisms counted towards DNS lookups are: a, ptr, mx, include, redirect and exists. “ip4”, “ip6” and “all” do not count towards the lookup limit.

If that all sounds a bit too technical, think about it this way. G Suite alone takes up 4 DNS lookups, add in Hubspot for marketing which uses 7 lookups then you’ll already be over the 10 lookup limit! As soon as you go over 10 SPF lookups, your email traffic will begin to randomly fail validation.

DKIM stands for DomainKeys Identified Mail, which is an email authentication protocol designed to prevent message modification in transit, a method often used in phishing and email scams.

DKIM is a more recent standard and more complex than SPF. Its functionality is based on using asymmetric cryptography in the signature parts of the email. There is a private key stored on the server that sent the email, a place where it could never be read by the end-user, and a public key which is published in the DNS record of the sender’s domain and is used to decrypt email signatures.

In other words, when an email is composed, its headers and body are signed using the private key of the sender to create a digital signature, which is also sent as a header field along with the email. On the receiver’s side (if DKIM is enabled), the server retrieves the public key and verifies if the email was indeed signed by the sending domain. If the signature is successfully validated, that proves that the sending domain sent the message and also that the headers and body of the message have not been modified or tampered with during transmission.

A DKIM signature is a unique cryptographic value embedded in the header of an outgoing email. Generated using the sender’s private DKIM key, this signature allows the recipient’s mail server to retrieve the corresponding public key from DNS and confirm that the message was sent from an authorized source and that its content has not been altered in transit.

A DKIM key is the cryptographic key pair used in DKIM authentication. The private key is securely stored on the sending mail server and used to generate the DKIM signature for each outgoing email. The public key is published in the sending domain’s DNS as a TXT record, allowing receiving servers to verify the signature and confirm the email’s integrity and authenticity.

Get the in-depth scoop on all things DKIM in our technical configuration guide.

Yes. DKIM (DomainKeys Identified Mail) is a critical email authentication protocol that protects against spoofing, phishing, and message tampering. It adds a cryptographic signature to each outgoing message, enabling receiving servers to verify that the email’s content hasn’t been altered and that it comes from an authorized domain. DKIM is also a core component of the DMARC verification process, working alongside SPF to enforce domain alignment and strengthen email security.

SPF (Sender Policy Framework) verifies that an email is sent from an IP address authorized by the sending domain’s SPF record. DKIM (DomainKeys Identified Mail) uses a cryptographic signature, validated via a public key in DNS, to confirm that the email’s content hasn’t been altered and that it comes from an authorized domain. SPF focuses on sender authorization, while DKIM ensures message integrity and authenticity.