In this guide, we’ll have a look at the topmost DNS SPF Record creation steps as well as the best email configuration practices to make sure that everything runs smoothly. SPF records are a type of DNS TXT record commonly used for email authentication. SPF records include a list of IP addresses and domains authorized to send emails from that domain.
For your information, a DNS SPF Record is just one of many DNS-based mechanisms that can help email servers confirm whether an email comes from a trusted source. Domain-based Message Authentication Reporting and Conformance (DMARC) and DomainKeys Identified Mail (DKIM) are two other useful mechanisms used for email authentication.
It is worth noting that, at one point, SPF records had a dedicated DNS record type. The dedicated record type has since been deprecated and only TXT records are to be used. With the help of a DNS such as Cloudflare, you can easily and quickly choose the type of record you would like to create for your email configuration.
On one hand, if your domain sends an email, you can create a record for SPF, DMARC, or DKIM. On the other hand, if your domain is not used for sending emails, you’ll need to prevent illegitimate email traffic on your domain. Realistically, because these DNS records all function slightly differently, each of their components is unique from the others as we’ll discuss.
Sender Policy Framework (SPF)
The Sender Policy Framework or SPF allows you to specify all IP addresses and hostnames that are permitted to send emails on behalf of your domain. If you don’t configure SPF on your domain your email may be blocked or marked as spam by email receivers.
SPF records can be formatted to protect domains against attempted phishing attacks by rejecting any emails sent from the domain. To do so, an SPF record must use the following format.
v=spf1 -allNote: SPF records are set directly on the domain itself, meaning they do not require a special subdomain.
Here is what the individual components of this record mean:
v=spf1lets the server know that the record contains an SPF policy. All SPF records must begin with this component.- The indicator
-alltells the server what to do with non-compliant emails or any senders that are not explicitly listed in the SPF record. With this type of SPF record, no IP addresses or domains are allowed, so-allstates that all non-compliant emails will be rejected. For this type of record, all emails are considered non-compliant because there are no accepted IP addresses or domains.
Domain-Based Message Authentication Reporting And Conformance (DMARC)
Domain-based Message Authentication Reporting and Conformance or DMARC tells an email receiver how to treat incoming emails from your domain that fail email security checks. You can also specify a reporting email address to receive regular reports about outgoing emails on your domain.
DMARC policies can also help protect domains that do not send emails by rejecting all emails that fail SPF and DKIM. In this case, all emails sent from a domain not configured to send emails would fail SPF and DKIM checks.
Below is an example of how to format a policy this way:
| Name | Type | Content |
|---|---|---|
_dmarc.example.com |
TXT |
v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s |
Other key important features:
-
-
- The name field ensures that the record is set on the subdomain called
_dmarc.example.com, which is required for DMARC policies. TXTindicates the DNS record type.v=DMARC1tells the server that this DNS record contains a DMARC policy.p=rejectindicates that email servers should reject emails that fail DKIM and SPF checks.adkim=srepresents something called the alignment mode. In this case, the alignment mode is set to “s” for strict. Strict alignment mode means that the server of the email domain that contains the DMARC record must exactly match the domain in theFromheader of the email. If it does not, the DKIM check fails.aspf=sserves the same purpose asadkim=s, but for SPF alignment.
- The name field ensures that the record is set on the subdomain called
-
DomainKeys Identified Mail (DKIM)
DKIM (DomainKeys Identified Mail) is a protocol that allows an organization to take responsibility for transmitting a message by signing it in a way that mailbox providers can verify. DKIM record verification is made possible through cryptographic authentication. It adds a public key to your DNS for email receivers to verify your outgoing signed email.
DKIM records protect domains by ensuring emails were actually authorized by the sender using a public key and a private key. DKIM records store the public key that the email server then uses to authenticate that the email signature was authorized by the sender. For domains that do not send emails, the DKIM record should be configured without an associated public key.
Below is an example:
| Name | Type | Content |
|---|---|---|
*._domainkey.example.com |
TXT |
v=DKIM1; p= |
Other key important features:
*._domainkey.example.comis the specialized name for the DKIM record (where “example.com” should be replaced with your domain). In this example, the asterisk (referred to as the wildcard) is being used as the selector, which is a specialized value that the email service provider generates and uses for the domain. The selector is part of the DKIM header and the email server uses it to perform the DKIM lookup in the DNS. The wildcard covers all possible values for the selector.TXTindicates the DNS record type.v=DKIM1sets the version number and tells the server that this record references a DKIM policy.- The
pvalue helps authenticate emails by tying a signature to its public key. In this DKIM record, thepvalue should be empty because there is no signature/public key to tie back to.
Illegitimate Traffic:
As we aforementioned, the illegitimate traffic configuration option allows you to prevent illegitimate email traffic on your domain. This means, that if your domain is not used for sending emails, you can signal this to receive email servers by adding specific DNS records. These records prevent someone from maliciously sending emails on your behalf.
Overall, the idea is that creating these specific DNS records helps protect domains that do not send emails from being used in domain spoofing attacks. Fortunately, the Cloudflare Email Security DNS Wizard makes it simple to set up the correct DNS TXT records and block spammers from using a domain.
How A DNS SPF Record Helps Mitigate Email Vulnerability
To enumerate, a DNS SPF Record is otherwise known as a Sender Policy Framework Record — a type of DNS TXT record that lists all the servers authorized to send emails from a particular domain. On the other side, a DNS TXT (“text”) record lets a domain administrator enter arbitrary text into the Domain Name System (DNS) to configure the settings.
TXT records were initially created for the purpose of including important notices regarding the domain but have since evolved to serve other purposes. SPF records were originally created because the standard protocol used for email — the Simple Mail Transfer Protocol (SMTP) — does not inherently authenticate the “from” address in an email.
This means, that without SPF or other authentication records, an attacker can easily impersonate a sender and trick the recipient into taking action or sharing information they otherwise would not. Think of SPF records like a guest list that is managed by a door attendant. If someone is not on the list, the door attendant will not let them in.
Similarly, if an SPF record does not have a sender’s IP address or domain on its list, the receiving server (door attendant) will either not deliver those emails or mark them as spam. So, how does a mail server check an SPF record? Well, on that note, a majority of mail servers go through a relatively simple process when checking an SPF record.
Consider the following:
- Server One sends an email. Its IP address is 192.0.2.0 and the return path the email uses is [email protected]. (A return-path address is different from the “from” address and is used specifically for collecting and processing bounced messages.)
- The mail server that is receiving the message (Server Two) takes the return-path domain and searches for its SPF record.
- If Server Two finds an SPF record for the return path’s domain, it searches the SPF record for Server One’s IP address in its list of authorized senders. If the IP address is listed in the SPF record, the SPF check passes and the email will go through. If the IP address is not listed in the SPF record, the SPF check fails. In this case, the email will be rejected or marked as spam.
But, wait a minute… What does an SPF record look like? SPF records must follow certain standards in order for the server to understand how to interpret its contents.
Here is an example of the core components of an SPF record:
v=spf1 ip4=192.0.2.0 ip4=192.0.2.1 include:examplesender.email -allAs a result, the above sample event lets the server know what type of record this is — it states the approved IP addresses and a third party for this domain. And then, thereafter, it tells the server what to do with non-compliant emails.
Let’s break down how the individual components accomplish this:
v=spf1tells the server that this contains an SPF record. Every SPF record must begin with this string.- Then comes the “guest list” portion of the SPF record or the list of authorized IP addresses. In this example, the SPF record is telling the server that
ip4=192.0.2.0andip4=192.0.2.1are authorized to send emails on behalf of the domain. include:examplesender.netis an example of the include tag, which tells the server what third-party organizations are authorized to send emails on behalf of the domain. This tag signals that the content of the SPF record for the included domain (examplesender.net) should be checked and the IP addresses it contains should also be considered authorized. Multiple domains can be included within an SPF record but this tag will only work for valid domains.- Finally,
-alltells the server that addresses not listed in the SPF record is not authorized to send emails and should be rejected.- Alternative options here include
~all, which states that unlisted emails will be marked as insecure or spam but still accepted, and, less commonly,+all, which signifies that any server can send emails on behalf of your domain.
- Alternative options here include
While the example used in this article is fairly straightforward, SPF records can certainly be more complex. For that reason, there are just a few things to keep in mind to ensure SPF records are valid during the configuration stage.
Consider the following:
- There cannot be more than one SPF record associated with a domain.
- The record must end with the
allcomponent or include aredirect:component (which indicates that the SPF record is hosted by another domain). - An SPF record cannot contain uppercase characters.
Check out the official SPF record documentation for more information.
How DNS SPF Records Is Used In Daily Activities
There are many reasons domain operators use SPF records:
- Preventing attacks: If emails are not authenticated, companies and email recipients are at risk for Phishing attacks, spam emails, and email spoofing. With SPF records, it is harder for attackers to imitate a domain, reducing the likelihood of these attacks.
- Improving email deliverability: Domains without a published SPF record may have their emails bounce or be marked as spam. Over time, bounced emails or emails marked as spam can hurt a domain’s ability to reach its audience’s inboxes, compromising efforts to communicate with customers, employees, and other entities.
- DMARC compliance: DMARC is an email validation system that helps ensure that emails are sent only by authorized users. DMARC policies dictate what servers should do with emails that fail SPF and DKIM checks. Based on the DMARC policy instructions, those emails will either be marked as spam, rejected, or delivered as normal. Domain administrators receive reports about their email activity that help them make adjustments to their policy.
The Cloudflare Email Security DNS Wizard makes it simple to set up the correct DNS TXT records and block spammers from using a domain. Read more about the Wizard here.
Summary Thoughts:
It’s, important to realize, that domains that do not send emails can still be used in email spoofing or phishing attacks, but there are specific types of DNS Text (TXT) records that can be used to stifle attackers. Each of these records sets rules for how unauthorized emails should be treated by mail servers, making it harder for attackers to exploit these domains.
For such reasons, a DNS TXT Record allows domain administrators to enter text into the Domain Name System (DNS). DNS TXT records are used for processes like email authentication because they can store important information that servers can use to confirm whether or not a domain has authorized an email sender to send messages on its behalf.
Examples of domains that do not send emails include domains purchased to protect a brand name or for a future business. Defunct, legacy domains also have no reason to send emails and could benefit from these types of records.
Get Free Updates
Notice: All content on this website including text, graphics, images, and other material is intended for general information only. Thus, this content does not apply to any specific context or condition. It is not a substitute for any licensed professional work. Be that as it may, please feel free to collaborate with us through blog posting or link placement partnership to showcase brand, business, or product.
