SPF Records

SPF - Sender Policy Framework

SPF (v1) provides a framework for domain owners to effectively whitelist authorized email sources (servers by IP, not persons who send) for a given domain.

---

All domains should have an SPF record.  
Why? Effective use of SPF can help protect domains against various forms of abuse, such as spoofed FROM address.  Example: badguy.com sends a message from his own or a compromised server and changes the FROM address to "goodguy.com" --> Goodguy.com gets "credit" for whatever spam, phishing, and/or malware is reported to be coming from [any_address]@goodguy.com.  
Because of this, Goodguy.com's domain reputation falls, and if unchecked, eventually even his legitimate emails are dumped into others' spam folders or rejected outright, simply because too many of the messages reportedly coming from Goodguy.com are being marked as spam.

What about domains that don't send mail?  All domains need an SPF record.  It's simple: create a "null" SPF record to specify that nobody is authorized to send mail from that domain.  It's a whitelist that's blank, thereby eliminating the opportunity for malicious persons/organizations to send fraudulent mail on behalf of a legitimate domain.  Just because a business or person doesn't USE a domain to send mail doesn't mean someone else can't maliciously spoof the FROM as that domain.  Why leave it unprotected when a 2-minute task can secure it?

Create a "null" SPF record: 

• Visit your domain registrar, navigate to edit DNS, and create a new TXT record
  • Leave host empty or "@"
  • Set the "value" to: v=spf1 -all

What does that do?  Literally, that says "The only authorized email senders on behalf of [whatever_domain.com] are the following: _[blank list]_.  Reject all others."  In other words, "nobody is allowed to send mail for [whatever_domain.com]."

---

Create standard SPF record: 

1. Enumerate all legitimate sources of mail for the given domain.  Be thorough: survey all departments in order to accurately discover any 3rd parties who do or may send email for the given domain.  Example: goodguy.com sends direct mail from GSuite, and mass-marketing via ConstantContact, and a private mail server located at a static IP (123.234.255.255) but no other entities are authorized to send on behalf of goodguy.com
2. Lookup SPF "inclusions" for each source and compile.  These are usually publicly available, however some entities are not up-to-speed or require a support ticket to provide any help.
3. Build the SPF record.  For the example above, GSuite's SPF record is: include:_spf.google.com and Constant Contact's SPF record is: include:spf.constantcontact.com.  Therefore, the SPF record for goodguy.com is:
   v=spf1 ip4:123.234.255.255 include:spf.constantcontact.com include:_spf.google.com ~all 
4. Publish the amalgamation as a TXT record.  NOTE: Do not use the SPF record type, as it is now depreciated and may not be honored.

NOTE: These instructions for a sending domain end with ~all instead of -all as this is the recommended method until there exists absolute certainty about the whitelist of authorized senders.  Small organizations with 100% certainty they only use a few specific sources can publish a -all at the end of their record.
Larger organizations or those who think there is even a chance there is another 3rd party sending legitimate emails on their behalf (think: confirmation emails, receipts, marketing departments that don't coordinate with the IT department, etc) should use the ~all instead, as it will not cause messages to be rejected.  Messages from sources not whitelisted in the record receive a "soft-fail" mark which increases their chance of being delivered to spam if there are any other red flags in the message source, subject, or body.
Until additional visibility into mailflow and sending sources can be obtained, it is recommended to keep the soft-fail mechanism in place.
The next step in protecting a domain's reputation and preventing spoofed messages is either DKIM, DMARC, or both.  DMARC provides reporting on all mail purporting to be from a given domain, and gives excellent insight into sources that may not have been known by the IT department.  It can be used for a thorough "discovery" process and SPF/DKIM records can be adjusted before rejection policies are made strict.  This process preserves legitimate mailflow alongside the illegitimate, but prevents legitimate messages from being rejected or stuffed into spam folders.