SPF, DKIM and DMARC Explained: How to Stop Email Spoofing

Anyone can send an email that claims to come from your domain. No hacking is required, because the basic email protocol doesn’t check who the sender really is. Criminals use that gap to send fake invoices, payroll change requests and password reset lures that look like they came from you.

SPF, DKIM and DMARC are the 3 DNS records that close that gap. Together they let receiving mail servers check whether a message claiming to be from your domain really is, and tell them what to do if it isn’t. Since February 2024, Google has also required them from bulk senders, and Microsoft followed for Outlook.com in May 2025, so they now affect whether your legitimate email lands in the inbox.

This guide explains each record in plain language, shows example setups and walks through moving DMARC to enforcement without blocking your own mail.

What SPF, DKIM and DMARC each do

Think of them as 3 layers that build on each other.

The key idea is alignment. SPF and DKIM on their own can pass for a domain that has nothing to do with the From address your recipient sees. DMARC closes that loophole by requiring the domain that passed SPF or DKIM to match the From domain.

How SPF works and how to set it up

SPF is a single TXT record that lists every service allowed to send mail using your domain in the envelope sender address. When a message arrives, the receiving server checks whether the sending IP address is on your list.

A typical record for a business using Microsoft 365 and a marketing platform looks like this:

v=spf1 include:spf.protection.outlook.com include:servers.mailprovider.example -all

• v=spf1 marks it as an SPF record.
• Each include: pulls in a provider’s list of servers. Your email and marketing providers publish the exact value to use.
• -all means “reject anything not listed.” ~all (soft fail) is gentler and common while you’re still testing.

Setup steps:

1. List every service that sends email as your domain: your mailbox provider, marketing platform, CRM, helpdesk, invoicing tool, website contact forms and any scanners.
2. Get the SPF include value from each provider’s documentation.
3. Publish one SPF TXT record at your root domain. Having 2 SPF records breaks SPF.
4. Stay under the limit of 10 DNS lookups set by the SPF standard. Each include counts, and nested includes count too. Too many and SPF returns an error.

SPF has a weakness: it often breaks when mail is forwarded, because the forwarding server isn’t on your list. That’s one reason DKIM matters.

How DKIM works and how to set it up

DKIM adds a digital signature to the header of every outgoing message. Your mail provider signs with a private key, and you publish the matching public key in DNS. Receiving servers use that public key to confirm the message came from an authorized sender and wasn’t altered.

Because the signature travels with the message, DKIM usually survives forwarding, which makes it the more reliable half of DMARC.

Setup steps:

1. In each sending service, find the DKIM or “domain authentication” setting. In Microsoft 365, it’s in the Microsoft Defender portal under email authentication settings. In Google Workspace, it’s under Gmail authentication in the Admin console.
2. The service gives you 1 or more DNS records, usually CNAME or TXT records at an address like selector1._domainkey.yourdomain.com.
3. Publish them in your DNS, then return to the service and turn signing on.
4. Use 2048-bit keys where the provider offers them, and rotate keys periodically.
5. Repeat for every third-party service that sends as your domain. Each one signs with its own selector.

How DMARC works

DMARC is the policy layer. It’s a TXT record at _dmarc.yourdomain.com that says 3 things: check that SPF or DKIM passed and aligned with the From domain, apply this policy when they don’t, and send reports here.

A starting record looks like this:

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

The main tags:

• p= is the policy: none (monitor only), quarantine (send to spam) or reject (block).
• rua= is the address for aggregate reports, daily summaries from receivers showing who sent mail as your domain and whether it passed.
• sp= sets a separate policy for subdomains, and np= (new in RFC 9989) covers subdomains that don’t exist.
• adkim= and aspf= set relaxed (default) or strict alignment.

The May 2026 update to the DMARC standard, RFC 9989, removed the old pct= tag that let you apply a policy to a percentage of mail, and added a t=y testing flag that asks receivers to apply a policy one step weaker than the one published. Existing records still start with v=DMARC1 and keep working.

Key takeaway: DMARC only protects you once it’s at enforcement (quarantine or reject). A record stuck at p=none meets Google’s bulk-sender minimum, but it doesn’t stop anyone from spoofing your domain.

Moving DMARC to enforcement safely

The fear with DMARC is blocking your own invoices or newsletters. The fix is to move in stages and let the reports guide you.

1. Publish p=none with reporting. Send rua reports to a dedicated mailbox or a DMARC reporting service, because raw reports are XML files that are hard to read by hand.
2. Watch for 2 to 4 weeks. Identify every legitimate source of mail. Expect surprises, such as an old billing system or a vendor sending on your behalf.
3. Fix each legitimate sender. Add it to SPF, turn on DKIM signing with your domain, or move it to a subdomain like mail.yourdomain.com with its own records.
4. Move to quarantine. Set p=quarantine. Optionally add t=y first so receivers treat it as a test. Keep watching reports.
5. Move to reject. When reports show only legitimate mail passing and failures are clearly spoofing, set p=reject.
6. Protect domains that never send email. Publish v=spf1 -all and a DMARC record with p=reject on parked or unused domains. CISA’s federal email directive, BOD 18-01, recommends exactly this approach.
7. Keep monitoring. Every time someone adds a new tool that sends email, it needs SPF or DKIM set up before it goes live.

What Google and Microsoft now require

Mailbox providers have turned these records from best practice into a requirement for many senders.

Even if you send far less than 5,000 messages a day, setting up all 3 records helps your mail get delivered and protects your brand.

Common mistakes to avoid

• 2 SPF records. Merge them into one.
• Too many SPF lookups. Remove services you no longer use, or move bulk senders to a subdomain.
• Forgetting third-party senders. Your CRM or invoicing tool may send as your domain without DKIM. DMARC reports will show it.
• Staying at p=none forever. Set a target date for reject.
• Ignoring subdomains. Attackers spoof billing.yourdomain.com too. Use sp= and np=.

Where to start

If you’ve never touched these records, block out 1 hour this week:

1. Look up your current records with your DNS provider or a free DNS lookup tool.
2. Make a list of every service that sends email as your domain.
3. Fix or publish SPF, and turn on DKIM in your main mailbox provider.
4. Publish a DMARC record at p=none with a reporting address.
5. Put a calendar reminder 3 weeks out to review reports and plan the move to quarantine.

Email authentication is one part of a wider defense. Pair it with the settings in our Microsoft 365 security checklist, MFA on every mailbox and the identity-first thinking in zero trust security. Spoofed email is also a common opening move in attacks covered in our guide to ransomware protection for small business. For quick definitions of terms like DNS or TLS, see the glossary.

The bottom line

SPF says who may send, DKIM proves the message is genuine, and DMARC enforces both against the address your customers actually see. Setting them up takes an hour or two. Reaching full enforcement takes a few weeks of watching reports. Both are worth it, because a domain at p=reject is far harder to impersonate.

Sources

• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — current DMARC standard, May 2026, tags including t and np, removal of pct
• RFC 7208: Sender Policy Framework (SPF) — SPF record syntax and the 10-lookup limit
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures — how DKIM signing works
• Google Workspace Admin Help: Email sender guidelines — Gmail requirements for all and bulk senders from February 2024
• Microsoft Tech Community: Outlook’s new requirements for high-volume senders — Outlook.com requirements from May 2025
• CISA: Binding Operational Directive 18-01 — staged move to DMARC reject and protecting non-sending domains