↓
 

What are Send Policy Framework – SPF Records ?

PIP Posted on by

What is Sender Policy Framework SPF ?

The Sender Policy Framework (SPF) is an email verification method intended to prevent email spoofing. By using SPF records, domain owners can designate which email servers are permitted to send emails on behalf of their domain. This helps ensure that incoming emails claiming to be from a particular domain actually originate from an authorized server, thereby lowering the risk of phishing, spam, invoice manipulation, and payment hijacking.

Often, attackers send emails with spoofed or cloned From addresses to make incoming messages appear as if it comes legitimately from your company or an employee. This way, the unsuspecting recipient might not realize that the email is fraudulent. It is crucial not to change BSB or bank details based solely on an email, nor should you pay unexpected invoices—even from a trusted supplier—without verifying their legitimacy first. However, sometimes mistakes occur, and the SPF system helps provide additional security against these phishing emails.

What is the History of Sender Policy Framework SPF ?

The framework for this Email verification method was first thought of on 2000 but scams where not as prevalent then so was largely ignored.

By 2002, Dana Valerie Reese and Paul Vixie independently proposed SPF-like specifications, which led to the formation of the IETF Anti-Spam Research Group. The SPF system though was not really a SPAM fighting tool and therefore, other SPMA fighting tools and practices where primarily implemented.

In 2003, Meng Weng Wong merged various proposals to create a unified SPF specification.

Between then and 2006 It was published as an experimental RFC 4408. Was renamed from “Sender Permitted From” to “Sender Policy Framework” and put back on the shelf.

By 2014, SPF authentication was standardised in RFC 7208.

By this time, very few Internet Service Providers had adopted SPF. PIP ran a few gateway services with the framework turned on, but very few clients took advantage of it. The major problem stemmed from devices such as mobile devises, faxes and copiers using random ISP SMTP servers to send company Email which rendered the system unusable.

In 2022-2023 The majority of the world had migrated to some form of centralised Email service. This was either On-Premise Enterprise Exchange, a private Exchange farm with a email service provider like PIP, Microsoft 365 Exchange or Gmail. At the same time the number of malicious emails had steadily increased. Email from spam was taking over the resources of the large Email providers so they started softly enforcing the use of these SPF protocols and checking valid SPF records.

How Does Sender Policy Framework SPF Work ?

  1. Publishing SPF Records:
    • The domain owner identifies their DNS provider from their domain registrar
    • The domain owner then must change their DNS records by adding a DNS txt record
    • The domain owner creates an SPF record which is a type of DNS (Domain Name System) record, in their DNS zone file.
    • This record lists all the IP addresses and hostnames that are authorized to send emails on behalf of the domain.
    • The SPF record is published in the DNS so that it can be accessed by mail servers around the world.
    • Only a single spf record per particular domain can be added and it must be a single string of text
    • Do not touch mx records
  2. Sending an Email:
    • When an email is sent from a domain, the sending mail server includes the domain in the “MAIL FROM” command during the SMTP (Simple Mail Transfer Protocol) transaction.
  3. Receiving the Email:
    • The recipient’s mail server receives the email and extracts the domain from the “MAIL FROM” command from the email headers.
    • The recipient’s mail server then queries the DNS for the domain’s SPF record.
  4. SPF Record Lookup:
    • The recipient’s mail server performs DNS lookups and retrieves the SPF record from the DNS for specific domain.
    • The SPF record contains a list of authorized IP addresses and hostnames.
  5. SPF Verification:
    • The receiving mail server compares the sending IP address of the sending email server with the list of authorized IP addresses in the valid SPF record.
    • Based on this comparison, the receiving server determines whether the incoming messages are coming from an authorized source.
  6. SPF Result:
    • The recipient’s mail server assigns an SPF result to the email. The possible results are:
      • Pass: The email comes from an authorized IP address.
      • Fail: Hard Fail – The email does not come from an authorized IP address.
      • SoftFail: The email does not come from an authorized IP address, but the domain owner has indicated that the policy is not strict ensuring email deliverability
      • Neutral: The domain owner has not specified a policy.
      • None: No SPF record was found for the domain.
  7. Action Based on SPF Result:
    • The recipient’s mail server takes action based on the SPF result. This action can vary depending on the server’s configuration and the organization’s email policies.
    • Common actions include:
      • Accepting the email: If the SPF result is “Pass”.
      • Marking the email as spam: If the SPF result is “Fail” or “Soft Fail”.
      • Rejecting the email: If the SPF result is “Fail”.

Example Sender Policy Framework SPF Records

For the majority of PIP users, SPF record syntax will be something like :

v=spf1 include:spf.pip.com.au -all

  • v=spf1: Indicates that this is an SPF version 1 record.
  • include: spf.pip.com.au: Authorizes any IP addresses listed in the SPF record for pip.com.au
  • -all: Indicates that emails from any other IP addresses should be rejected.

Does DMARC interact with SPF ?

Yes it does, SPF (Sender Policy Framework) and DMARC (Domain-based Message Authentication, Reporting & Conformance) work together to enhance email security and prevent spoofing.

SPF Records: This DNS record specifies which mail servers are authorized to send emails on behalf of your domain. When an email is received, the receiving server checks the SPF record to verify if the sending server’s IP address is listed. If it is, the email passes the SPF check.
DMARC Records: This policy builds on SPF and DKIM (DomainKeys Identified Mail) by instructing receiving servers on how to handle forged emails that fail SPF or DKIM checks. DMARC policies are published in DNS records and can specify actions like quarantining or rejecting emails that don’t pass authentication.
Interaction:

Verification: When an email is received, the server first checks the SPF record to see if the sending server is authorized. If the SPF check passes, the email moves to the next step.
Policy Enforcement: DMARC then evaluates the results of the SPF mechanism (and DKIM) checks. Based on the DMARC policy, the receiving server decides what to do with emails that fail these checks. This could mean rejecting, quarantining, or allowing the email through but marking it as suspicious.

Together, SPF and DMARC help ensure that only legitimate emails from your domain are delivered, reducing the risk of phishing and spoofing attacks.

Best practices for your domain is to ensure you have installed and up-to-date records on your domain for

Of course if you need any further information on these records, need records updated or just want to talk Email security, please get in touch with the good folk @ PIP

Comments are closed.

↑