How to set up SPF, DKIM, and DMARC (a practical walkthrough)

SPF, DKIM, and DMARC are DNS records, not settings inside your email client. That distinction matters because it means the work happens in your domain's DNS zone, not in Gmail, Outlook, or whatever platform sends the mail. Get the order and syntax right, and authentication becomes something you set once and rarely touch again. Get it wrong, and you can accidentally block your own legitimate mail while trying to stop spoofers.

This walkthrough assumes no specific provider - the steps apply whether your DNS lives at Cloudflare, your registrar, or your hosting panel.

Step 1: Inventory every system that sends as your domain

Before touching a single DNS record, list every service that sends mail using your domain in the From address: your mailbox provider (Workspace or Microsoft 365), CRM, booking or scheduling tool, helpdesk, e-commerce platform, newsletter tool, and any transactional email API used by your website for password resets or order confirmations. Missing one of these later shows up as mysterious authentication failures.

Step 2: Publish one correct SPF record

SPF is a single TXT record at your domain's root that lists which servers are authorized to send mail for you. The record starts with v=spf1 and lists includes for each sending platform, ending with ~all (soft fail) or -all (hard fail).

• Never publish two separate SPF TXT records - DNS only allows one to be evaluated reliably, so merge every sender into a single record.
• Use include: statements for hosted services rather than listing raw IP addresses when the provider supports it, since their sending IPs can change.
• Stay under the 10 DNS lookup limit that SPF enforces, or receivers may treat the record as a permanent failure.

A common syntax slip: a team adds a new sending tool by copy-pasting its include statement into a brand-new TXT record instead of merging it into the existing one. DNS now has two SPF records for the same domain, which most receivers treat as an outright failure for everyone - including senders that were passing perfectly well before the change. If mail that worked yesterday suddenly fails today, checking for a duplicate SPF record is often the fastest diagnosis.

Step 3: Enable DKIM in every sending platform

DKIM is configured per platform, not once for your whole domain. Each service - Workspace, your CRM, your newsletter tool - generates its own key pair and gives you a CNAME or TXT record to publish, often using a unique selector like google._domainkey or a platform-specific name. Add each one exactly as provided, and enable DKIM signing inside the platform itself; publishing the DNS record alone does nothing if the sending service is not told to sign with it.

Step 4: Add DMARC and start in monitoring mode

DMARC is the record that tells receivers what to do when SPF or DKIM checks fail, and where to send reports about it. Start conservatively:

1. Publish a DMARC record with p=none - this only monitors and reports, without blocking anything.
2. Point the rua= reporting address at a mailbox you actually check, or a monitoring tool that parses reports for you.
3. Watch reports for one to two weeks to confirm every legitimate sender is passing.
4. Move to p=quarantine once reports look clean, then to p=reject once you are confident nothing legitimate will be caught.

A note on subdomains and third-party senders

Authentication on the root domain does not automatically extend to every subdomain that sends mail. If a marketing tool sends from news.yourdomain.com or a support platform sends from tickets.yourdomain.com, each subdomain generally needs its own SPF and DKIM setup, and DMARC policy inheritance depends on the record's subdomain (sp=) tag. Treat every subdomain that sends mail as its own small authentication project rather than assuming the root domain's records cover it.

Reading DMARC aggregate reports

Aggregate reports arrive as XML attachments, which is unreadable at a glance - most teams use a free or paid parser to turn them into a simple table. The table you want to see shows a source IP, a volume of messages, and SPF/DKIM alignment results. Any source you recognize and expect that is failing needs its SPF or DKIM fixed. Any source you do not recognize sending as your domain is worth investigating on its own.

Common mistakes and how to avoid breaking mail

1. Jumping straight to p=reject before confirming every sender passes - this can silently block real customer-facing mail.
2. Forgetting to update SPF after adding or removing a sending tool.
3. Leaving a stale DKIM selector active after switching email providers, which can confuse alignment checks.
4. Assuming DMARC alone fixes deliverability - it only controls what happens after authentication fails, not spam scoring based on reputation or content.
5. Treating a subdomain as automatically covered by the root domain's SPF and DKIM setup.

A short checklist

1. List every sender using your domain.
2. Merge them into one SPF record under the lookup limit.
3. Enable DKIM per platform and publish the records they provide.
4. Add DMARC at p=none, watch reports, then tighten gradually.
5. Re-check all three whenever you add, remove, or migrate a sending tool.

None of this requires a background in mail server administration - it requires patience, one correct record at a time, and reading the reports before tightening policy. Killer Click often bundles this work with a Workspace or Microsoft 365 migration, so authentication lands in the same change window as MX updates instead of becoming an afterthought.