WHAT IS SENDER POLICY FRAMEWORK (SPF)?
Sender Policy Framework (SPF) is an authentication protocol that lists IP addresses in a DNS TXT record that are authorized to send email on behalf of domains.
A typical SPF record looks like this:
“v=spf1 ip4:64.34.183.84 ip4:64.34.183.88 include:mmsend.com -all”
When you send an email message, the receiving system will check to see if there is an SPF record published.
- If there is a valid SPF record AND your sending IP is on the list, you PASS.
- If the IP is NOT on the list, you FAIL the SPF check and could either be rejected or placed in the spam folder.
Unfortunately, SPF authentication has some limitations in terms of validating the message source. SPF also breaks when a message is forwarded and does not protect brands against bad actors who can spoof the display name or Friendly-From address. These limitations are some of the reasons why DKIM was created.
WHAT IS DOMAINKEYS IDENTIFIED MAIL (DKIM)?
Think of domainkeys identified mail (DKIM) as an ID or passport that can verify who you are. When you are sent from your email server, the server attaches DKIM so the receiving server can verify you.
Technically speaking, DKIM authentication provides a method for validating a domain’s identity that is associated with a message through cryptographic authentication
It does this by using an encrypted key pair (one public in DNS and one private) to add a digital signature to every email message.
Receiving email servers use this DKIM signature to both validate the authenticity of the sender and to identify if the message was changed or altered during transit. DKIM-signed messages provide Mailbox Providers (MBPs) with trust that the message is authentic and is not being spoofed.
MBPs’ internal filtering algorithms use SPF and DKIM along with other factors to determine if an email should be placed in the inbox, spam folder, or be rejected. However, both SPF and DKIM don’t allow domain owners to instruct MBPs how to treat a message if the authentication checks can’t be validated.
To help tell MBPs know what to do if DKIM and/or SPF fail, senders can implement DMARC. DMARC leverages both SPF and DKIM and provides instructions from the domain owner about what to do with unauthenticated email.
WHAT IS DOMAIN-BASED MESSAGE AUTHENTICATION, REPORTING & CONFORMANCE (DMARC)?
Our third authentication component, Domain-based Message Authentication, Reporting & Conformance (DMARC), is an email authentication, policy, and reporting protocol. It helps domains address domain spoofing and phishing attacks by preventing unauthorized use of the domain in the Friendly-From address of email messages.
DMARC allows the domain owner to specify how unauthenticated messages should be treated by MBPs. This is accomplished by what is known as a “policy” that is set in the DMARC DNS record. The policy can be set to one of three options: NONE, QUARANTINE, and REJECT.
- Policy = (p=none): no action and message delivered as normal
- Policy = (p=quarantine): places the message to spam/junk/quarantine folder
- Policy = (p=reject): the message rejected/bounced
The R in DMARC is for the Reporting component of the protocol. These reports allow the domain owner to see where all email using their domain in the From address is being sent from.
HOW DO YOU GET STARTED WITH SPF, DKIM, AND DMARC?
The first step to configuring SPF, DKIM, and DMARC is to reach out to your support team and check to see if you are already using email authentication. If you aren’t, they will have the necessary documentation to help you set up the correct authentication for their platform. If you are, you can check that task off your list!
Enabling email authentication isn’t only an email best practice to help get your email delivered, but they are critical tools in helping to protect your brand’s reputation by limiting the chances that an unauthorized sender can successfully use your domain without your consent or knowledge.