SPF vs DKIM: What Each Does and Why You Need Both

SPF and DKIM answer two different questions. SPF asks whether the server that delivered a message is allowed to send for your domain. DKIM asks whether the message carries a valid cryptographic signature from your domain and arrived unaltered. You need both, and you need DMARC on top, because neither SPF nor DKIM alone checks the address your recipient actually sees.

If you run a small business in Wisconsin, this is not an academic point. Spoofed invoices, fake wire instructions and look-alike vendor emails all rely on domains that nobody has locked down. Below, we explain how each protocol works, show an SPF record you can model yours on, and walk through a safe order for setting up all three.

TL;DR

• SPF publishes a list of servers allowed to send mail for your domain. It checks the path the message took.
• DKIM adds a digital signature to each message and publishes the public key in DNS. It checks that the message is authentic and unchanged.
• You need both. Each covers a gap the other leaves, especially around forwarded mail.
• DMARC is the third piece. It checks that SPF or DKIM results line up with the visible From address, and it sends you reports.
• Start DMARC in monitoring mode, read the aggregate reports, then tighten the policy.

Table of Contents

• SPF vs DKIM at a glance
• How SPF works
• How DKIM works
• Do I need SPF if I have DKIM?
• Are SPF and DKIM enough?
• Where DMARC fits
• Setting up DMARC the safe way
• What DMARC aggregate reports tell you
• Check your domain, then fix the gaps
• Let us handle SPF, DKIM and DMARC for you
• FAQ
• Sources

SPF vs DKIM at a glance

	SPF	DKIM
What it verifies	The sending source is authorized for the domain	The message signature is valid and the signed content is intact
How it works	A DNS record lists permitted senders	A private key signs the message; recipients fetch the public key from DNS
Where it lives	A TXT record at your domain	A record at a selector under _domainkey
Survives forwarding	Often not	Usually yes
Checks the visible From address	No, not on its own	No, not on its own
Typical failure	A new sending service nobody added to the record	A key that was never published, or a service that signs with its own domain

NIST describes the split this way: SPF provides source authentication, DKIM provides message-integrity authentication, and DMARC gives the domain owner feedback on how well both are working.

How SPF works

SPF stands for Sender Policy Framework. You publish a record in DNS that names the servers, addresses or services allowed to send email for your domain. When a message arrives, the receiving server looks up that record and checks whether the sending source is on the list.

Two details matter in practice. First, SPF is published as a DNS TXT record, and its job is to advertise your legitimate sources, as Cisco's email authentication guidance explains. Second, SPF primarily authenticates the hidden return-path address (the MAIL FROM used in the SMTP exchange), not the From address your recipient sees in their inbox. That gap is why spoofers can pass SPF and still show your brand name in the From line.

An SPF record example

Here is a generic record, using documentation-reserved values:

v=spf1 ip4:192.0.2.10 include:provider.example ~all

Read it left to right:

• v=spf1 marks the record as SPF version 1.
• ip4:192.0.2.10 authorizes one IPv4 address, such as an on-premises mail server or a scanner.
• include:provider.example authorizes whatever senders that provider's own SPF policy permits. This is how you add Microsoft 365, a marketing platform or a billing system.
• ~all is a soft fail: mail from any other source is flagged as suspicious but not outright rejected. -all is the stricter hard fail.

The mechanisms and the closing qualifier are laid out in the Cisco guide.

SPF record best practices

The M3AAWG email authentication best practices are a good checklist. They recommend:

1. Publish SPF records for both your MAIL FROM and EHLO domains.
2. Limit the number of authorized IP addresses to what you actually use.
3. Align the MAIL FROM domain with the visible From domain wherever possible.
4. Publish an SPF record ending in -all on any domain that sends no mail at all, such as old or parked domains.

One practical habit we add: keep a written list of every system that sends email as your company. Payroll, the CRM, the website contact form, the copier that scans to email and the accounting package all count. Every time someone adds a new one, the SPF record needs a matching change.

How DKIM works

DKIM stands for DomainKeys Identified Mail. Your sending system keeps a private key and uses it to sign selected headers and the body of each outgoing message. The signature rides along in a DKIM-Signature header. The receiving server reads the selector named in that header, looks up the matching public key in your DNS, and validates the signature.

NIST gives the DNS pattern: for a selector called mailkey and a domain example.com, the public key sits at mailkey._domainkey.example.com. The selector is what lets one domain run several keys, for example one per sending service, and rotate them without breaking mail.

Because the signature travels inside the message, it does not depend on which server relays it. That is why DKIM tends to survive forwarding, where SPF often breaks. If you want a plain-language walkthrough of how selector records and signing are set up on a business mailbox platform, this business email setup guide covers the DKIM side in detail.

Do I need SPF if I have DKIM?

Yes. Microsoft describes the two as complementary. According to its explanation of email authentication in Microsoft 365, SPF identifies authorized MAIL FROM sources but can fail when mail is forwarded. DKIM can survive forwarding, but it does not require the signing domain to match the visible From domain.

In plain terms:

• SPF alone can be defeated by a message that is relayed or forwarded, and it says nothing about whether the content was tampered with.
• DKIM alone proves someone holding a valid key signed the message, but that signer may be a different domain from the one the recipient sees.
• Both together give receivers two independent signals, so one failing does not automatically sink a legitimate message.

Are SPF and DKIM enough?

No. Microsoft states that SPF, DKIM and DMARC work together for effective protection, because SPF and DKIM on their own do not verify that the domains they authenticate align with the visible From domain. The Australian Government's cyber security guidance makes the same point: SPF and DKIM can be bypassed when the authenticated domain differs from the From domain.

That means an attacker can send mail that passes SPF for their own domain while displaying yours. Closing that hole is DMARC's job.

Where DMARC fits

DMARC is not just SPF and DKIM combined. RFC 7489 defines it as a system in which you publish a policy in DNS, receivers compare the visible From domain with the SPF and DKIM results, and then apply your policy. It adds three things:

• Alignment. An SPF or DKIM pass only counts toward DMARC if the authenticated domain matches the visible From domain.
• Policy. You tell receivers what to do with mail that fails: nothing (p=none), quarantine, or reject.
• Reporting. Receivers send you data about what they saw.

NIST's guidance on trustworthy email lists SPF, DKIM and DMARC as the DNS-based mechanisms recommended to build trust in email, and says it is useful for small and medium-sized organizations as well as federal systems. DMARC is not only for large enterprises.

DMARC vs SPF and DKIM in one sentence each

• SPF authorizes the envelope sender.
• DKIM validates a signed message.
• DMARC evaluates both against the visible From domain and applies the owner's requested handling, as RFC 7489 specifies.

A clear explanation of how the three combine to protect an organization's domain is also in this overview of email verification methods.

Setting up DMARC the safe way

A starter record looks like this, published as a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

The rua tag names the mailbox for aggregate reports. Cisco notes that rua identifies the destination for daily aggregate reports. M3AAWG recommends every DMARC record include a rua destination, and says reporting must accompany even a monitoring-only deployment, since owners need evidence that legitimate mail authenticates before enforcing quarantine or rejection.

A sensible order for a small business:

1. Inventory your senders. List every system and vendor that sends mail as your domain.
2. Publish or fix SPF. Include each legitimate sender and end with ~all while you are still learning.
3. Turn on DKIM for each sender. Publish each public key at its selector in DNS.
4. Publish DMARC with p=none and a reporting address.
5. Read the reports for a few weeks. Find the senders that fail or do not align, and fix them.
6. Move to quarantine, then reject, once your real mail passes consistently.
7. Lock down parked domains with an SPF -all record, as M3AAWG advises.

What DMARC aggregate reports tell you

Aggregate reports are XML files, sent by receiving mail systems, summarizing the mail they saw claiming to be from your domain. Per RFC 7489, they can show the policy discovered and applied, the receiver's disposition, SPF and DKIM identifiers and results, whether each aligned, and counts of messages.

Used well, they let you:

• Spot legitimate services you forgot to authorize.
• Detect forged mail streams pretending to be you.
• Correct authentication failures before they cost you deliverability.
• Decide whether stricter enforcement is safe.

Raw XML is hard to read, so most small businesses use a tool or a managed provider to turn it into something a person can act on. That is a task we take on for clients.

Our perspective

We see the same pattern in small and mid-sized Wisconsin companies. Someone set up SPF years ago, DKIM was never turned on for the invoicing platform, and DMARC is either missing or sitting at p=none with reports going to a mailbox nobody opens. The domain looks protected on paper. It is not.

Email authentication is infrastructure, not a one-time checkbox. New senders appear, vendors change their servers, keys age, and every change can quietly break a record. That is why we treat it as part of a fully managed stack: the records are documented, monitored and updated as your business changes, and the reports are read by people who know what to do with them.

For manufacturers, law firms, dental practices and financial firms, a spoofed domain is not a spam problem. It is an invoice-fraud and client-trust problem. Our approach is simple: authenticate everything you send, watch the reports, enforce when the data says it is safe, and pair it with the controls that catch what authentication cannot, like verified call-backs for payment changes.

No smoke and mirrors. Know what sends mail as you, and prove it.

Dustin Collett

Check your domain, then fix the gaps

Before you change any DNS record, find out where you stand. Our Email Trust Checker looks at your domain's email authentication setup so you can see what is missing before an attacker does. If you want to understand why these signals matter beyond deliverability, read why email trust metrics matter and how real emails can still be phishing.

Authentication stops forged mail from your domain. It does not stop a compromised mailbox or a convincing look-alike domain. For that, see our business email compromise prevention guide and the piece on catching BEC attacks in progress.

Let us handle SPF, DKIM and DMARC for you

If you would rather not maintain DNS records and read XML reports yourself, that is what our managed IT service is for. We run a standardized, fully loaded IT stack for a fixed cost per user, with 24/7 monitoring, proactive support and security management included. Email authentication is part of keeping your infrastructure owned and documented, not an add-on.

The best first step is a paid assessment: Book the IT & Security Assessment and we will review your email authentication, your security posture and your compliance documentation, then give you a plain list of what to fix. If you want to see the ongoing service, start with Managed IT Services.

FAQ

Do I need SPF if I have DKIM?

Yes. SPF and DKIM cover different weaknesses. SPF can fail when mail is forwarded, while DKIM can survive forwarding but does not by itself have to match the visible From domain. Microsoft recommends using both, plus DMARC.

Is DMARC a combination of SPF and DKIM?

Not exactly. DMARC uses SPF and DKIM results, but it adds alignment with the visible From domain, a policy telling receivers how to treat failures, and reporting back to you. These are defined in RFC 7489.

Is DKIM and SPF enough?

No. Without DMARC, nothing requires the domains that pass SPF or DKIM to match the From address people see. Government and vendor guidance, including the Australian Government's advice, notes that this gap can be exploited.

Where do SPF, DKIM and DMARC records go?

All three are published in your domain's DNS. SPF is a TXT record on the domain, DKIM is a record at a selector under _domainkey, and DMARC is a TXT record at _dmarc. Your DNS host or IT provider can add them, and each should be tested after it is published.

Is DMARC worth it for a small business?

Yes. NIST's email guidance says SPF, DKIM and DMARC are useful for small and medium-sized organizations, not only large ones. Starting at p=none with reporting carries little risk and shows you who is sending as your domain.

Sources

• Email Authentication Mechanisms: DMARC, SPF and DKIM (NIST Technical Note 1945)
• SP 800-177, Trustworthy Email (NIST)
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance
• How email authentication works in Microsoft 365
• Best Practice for Email Authentication (Cisco)
• M3AAWG Email Authentication Recommended Best Practices
• How to combat fake emails (Cyber.gov.au)
• Email verification methods