squirrelworks
The "Guest List" Analog: SPF is a DNS record that lists exactly which IP addresses and domains are authorized to send mail on your behalf. It’s the first line of defense against "spoofing."
When you send an email, the receiving server looks at the "Return-Path" address. It then checks the DNS records of that domain for an SPF entry. If the server sending the mail isn't on that list, the email is flagged as suspicious.
SPF records have a hard limit of 10 DNS lookups. If your record includes too many third-party services (like Mailchimp, Zendesk, and Google combined), the check will fail. This is why "SPF flattening" or moving to DKIM-based trust is critical for large enterprise environments.
While SPF checks the server, DKIM checks the message itself. It attaches a cryptographic digital signature to the email header, ensuring the content wasn't tampered with in transit.
Your sending server uses a private key to "hash" the email headers and body. This creates a unique string of characters that represents the exact state of that email when it was sent.
The public key is published in your DNS. The receiving server grabs this key and tries to decrypt the signature. If the hashes match, the server knows the email is authentic and hasn't been altered by a "Man-in-the-Middle."
DMARC is the policy layer that sits on top of SPF and DKIM. It tells the receiving server what to do if those checks fail. Without DMARC, a failed SPF check might not actually stop an email from reaching the inbox.
Technical Tip: For an email to be "DMARC Compliant," it only needs to pass one of the two checks (SPF or DKIM) AND have that check align with the domain in the "From" header. However, for maximum deliverability, industry standard is to implement all three.
| Feature / Aspect | SPF | DKIM | DMARC |
|---|---|---|---|
| Primary Function | Authorized IP/Server List | Digital Content Signature | Policy & Reporting Layer |
| Validation Target | The Sending Server's IP | Message Integrity (Body/Headers) | Authentication Result & Policy |
| DNS Record Type | TXT (v=spf1) | TXT/CNAME (selector._domainkey) | TXT (_dmarc) |
| Setup Complexity | Low (Simple list of IPs/Domains) | Medium (Requires Key Generation) | Medium (Requires Policy Logic) |
| Email Forwarding | Frequently Fails (IP changes) | Survives (Signature stays intact) | Depends on SPF/DKIM Survival |
| Cryptography | None (Plaintext IP matching) | Asymmetric (Public/Private Keys) | None (Logical Policy Check) |
| Spoofing Protection | Prevents unauthorized server use | Prevents message tampering | Prevents "From" header spoofing |
| Visibility/Feedback | None (Silent pass/fail) | None (Silent pass/fail) | High (Daily XML usage reports) |
| Main Weakness | Lookup limit (10) / Forwarding | Header modification by relays | Can block legitimate mail if misconfigured |
| Standard Policy | ~ (Softfail) or - (Fail) | Binary (Valid or Invalid) | None, Quarantine, or Reject |
* Note: While SPF and DKIM can function independently, DMARC acts as the "manager" that instructs ISPs on how to handle the data provided by the first two protocols.
In a perfect Squirrelworks mail flow, these three tools work as a unified stack. SPF provides the initial identity check, DKIM ensures the "cargo" wasn't tampered with, and DMARC provides the enforcement and reporting.
By monitoring DMARC reports (RUA/RUF), you gain visibility into your "Shadow IT"—identifying legitimate services sending mail on your behalf that you might have forgotten to authorize. This trio is the foundation of modern cybersecurity for email, moving the internet away from an "open" relay system toward a "zero-trust" architecture.
See also: Security Blog →