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.
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 standard SPF 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.