Sender Policy Framework (SPF)

The Sender Policy Framework (SPF) is a technique that is used for email-authentication which helps prevent spammers and social engineers from sending messages on behalf of your domain(s). Organizations can publish their authorized email servers on an SPF record in the Domain Name System (DNS). These records include a list of which specific IP addresses can send email for that domain name. When an SPF record is checked, the email provider verifies the SPF record by searching for the domain name in the “from” address in the DNS. If the email was sent from an IP address that wasn’t specified to do so in the SPF record, the message fails authentication. This process happens before the body of the message is received. Users can set up what happens should the message fail the SPF authentication check, such as: allowing the message through, quarantining the message, or blocking the message altogether.

Here’s a simple breakdown of how this exchange might work:

1. The sending server issues its “MAIL FROM” command in the SMTP conversation, sending over the email information to the receiving server
2. The receiving server obtains the information sent from the sending server; the receiving server then looks up the SPF record in the Domain Name System of the MAIL FROM email address to see if there is a match for the source IP address of the SMTP connection
3. The Domain Name System sends back whether the message passed or failed the SPF record check, in which this case it did
4. The receiving mail server gets notification that the message passed the SPF record check and is sent and/or loaded at the end destination for the email message

An SPF record is a text record that contains specific letters and characters (or “syntax”) that tell the server what it should do when it gets a message. This syntax contains two separate parts: mechanisms and modifiers. Modifiers as a whole are optional and typically only used in special circumstances. Generally, when managing and troubleshooting you’ll only be using SPF records that contain mechanisms. These mechanisms describe which hosts can send messages from your domain. The syntax options contain:

• all – matches any host and is placed at the end of the SPF record as a “catch all” for any senders that did not match other mechanisms listed ahead of it.
• ip4 – matches a single IPv4 address or IPv4 network range.
• ip6 – matches a single IPv6 address of IPv6 network range.
• a – matches a host name or domain name. The IP addresses that the name resolves to in DNS are matched against the sender’s IP address. This mechanism is useful for matching against a web server IP address based on the domain name.
• mx – matches against the MX records for the domain. This mechanism is useful when the outbound mail is handled by the same servers as the MX records resolve to for inbound mail.
• ptr – reverse DNS queries are used to match the sender IP address to the host names that it resolves to. This mechanism is generally not recommended due to the DNS load it causes.
• exists – simply checks that the domain exists in DNS.
• include – matches the sender IP against the SPF record on another domain. This is commonly used when your outbound email is routing via a cloud service such as Exchange Online Protection.

Mechanisms are combined with a qualifier that tells the server what it should do if a match is found. The qualifiers are:

• “+” for pass (this is the default if no qualifier is explicitly provided)
• “–” for HardFail (email from unauthorized hosts should be rejected)
• “~” for SoftFail (may result in email being accepted but marked as “likely spam”)
• “?” for Neutral (regardless of the result the email should be accepted)

An example of a mechanism paired with a qualifier is “-all” at the end of an SPF record, which means “Fail/reject email from any sender who did not match an earlier mechanism in the SPF record.” Typically, qualifiers should be set to HardFail as SoftFail and Neutral settings still offer the chance to send potentially illegitimate emails to inboxes.

An example SPF record may look like this:

v=spf1 mx a:www.exchangeserverpro.net -all

Here’s what the syntax within the SPF record means:

• Domain’s inbound servers may send mail (in other words, the servers listed as MX records also handle outbound email)
• An additional domain name whose A record is a valid outbound email server (a common example of this is an externally hosted website that uses its own SMTP service to send notifications and other emails)
• This domain sends mail only from the IP addresses identified above (in other words, anything else trying to send email from my domain name should be considered unauthorized)

There are several tools one can use to check their SPF record, our favorite is the MXToolbox SPF record validator, which can be found at https://mxtoolbox.com/spf.aspx. This tool can show you how your SPF record is configured and is useful for troubleshooting excessive DNS lookups or syntax problems. Be careful, however, as an incorrectly configured SPF record can make it so that no email messages are allowed to go outbound of the organization, so it’s important to ensure that it is properly setup and validated. Speak with your network solutions manager or provider to get assistance with setting up an SPF record.

DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail (DKIM) is a protocol that authenticates which domain an email came from and helps to prove that the email was not changed or tampered with during transit. The receiving mail server can then opt to filter out or reject messages that fail this DKIM check. To perform this email authentication, DKIM makes use of public key encryption. This means that there is a secret key, that only the signer of the message knows, and a public key that everyone knows and can be used to verify the message. The email server that is sending the message automatically creates a string of characters known as a hash. This hash is generated using the content of each outbound email. Then, the sending email server encrypts the hash with its private key and adds it to the email header. This is what’s known as the DKIM signature.

The email receiving server then locates the public key in the sending server’s DKIM Domain Name System (DNS) record and uses that public key to decrypt the DKIM signature found in the email header. It also generates a hash of the email in exactly the same way the email sending server did. If the hash matches the decrypted DKIM signature, then the email passes the DKIM check. This means that the email came from where it says it came from and has not changed in transit.

It is required that separate DKIM keys and DNS entries be created and utilized for each service that an organization sends email from. Businesses should also consider third-party applications and services that send email on their behalf, in addition to their own mail servers.

This diagram shows how DKIM works:

Here are the steps for this process:

• The originating sender uploads their public key to their Domain Name System (DNS) DKIM record so that receivers may verify that their message’s key matches
• The sending email server adds a DKIM signature to the outbound email message and sends it to the receiving mail server
• The receiving mail server then checks with the Domain Name System using the public key to find out if the DKIM signature matches
• The Domain Name System then sends back whether or not the email message passed DKIM authentication (whether or not the DKIM signature matched)
• If it does, it forwards the email to the receiver’s inbox – if it does not match, the receiving email service fails or rejects the invalid email

Domain-based Message Authentication, Reporting, & Conformance (DMARC)

Domain-based Message Authentication, Reporting, & Conformance (DMARC) certifies that legitimate email messages are correctly authenticated with regards to approved DKIM and SPF standards, and that illegitimate email activity appearing to come from domains under the businesses’ control (active sending domains, non-sending domains, and defensively registered domains) is blocked. There are two core processes within DMARC that ensure its operation: domain alignment and reporting.

DMARC’s alignment feature helps prevent spoofing of the “FROM” address in the email header by:

1. Matching the “header from” domain name with the “envelope from” domain name used during an SPF check, and
2. Matching the “header from” domain name with the “d= domain name” in the DKIM signature.

The way it works is to help email receivers determine if the purported message “aligns” with what the receiver knows about the sender. If not, DMARC includes guidance on how to handle the “non-aligned” messages. For example, if a receiver deploys SPF and DKIM, plus its own spam filters, the flow may look something like this:

For an email message to pass DMARC, the message must pass SPF authentication and SPF alignment and/or DKIM authentication and DKIM alignment. A message will fail DMARC and be quarantined/rejected (depending on configurations) if the message fails both (1) SPF or SPF alignment and (2) DKIM or DKIM alignment.

DMARC allows senders to instruct email providers on how to handle unauthenticated mail via a DMARC policy, removing any guesswork on how they should handle messages that fail DMARC authentication. Senders can either:

• Monitor all mail, to understand their brand’s email authentication ecosystem, and ensure legitimate mail is authenticating properly without interfering with the delivery of messages that fail DMARC
• Quarantine messages that fail DMARC (e.g., move to the spam folder)
• Reject messages that fail DMARC (e.g., don’t deliver the mail at all)

Mailbox providers send regular DMARC aggregate and forensic reports back to senders, giving them visibility into what messages are authenticating, what messages are not, and why.

Helpful resources and information gathered from:

• https://www.dmarcanalyzer.com/spf/
• https://blog.returnpath.com/how-to-explain-spf-in-plain-english/
• https://practical365.com/exchange-server/a-sender-policy-framework-spf-primer-for-exchange-administrators/
• https://blog.returnpath.com/how-to-explain-dkim-in-plain-english-2/
• https://www.gov.uk/government/publications/email-security-standards/domainkeys-identified-mail-dkim
• https://postmarkapp.com/blog/explaining-dkim
• https://blog.returnpath.com/how-to-explain-dmarc-in-plain-english/
• https://dmarc.org/overview/