SPF, DKIM and DMARC: A Practical Setup Guide

SPF, DKIM and DMARC work together to help receiving mail systems evaluate whether a message is authorized to use your domain. For a small business, the practical task is to identify every legitimate sender, configure authentication, and move toward enforcement without breaking invoices, password resets, or support replies.

This setup guide is for domains you control. You will need access to DNS and each sending service. Authentication improves email spoofing protection, but it does not guarantee inbox placement or prevent impersonation through lookalike domains. Reputation, consent, content, and recipient behavior still matter.

What the three mechanisms actually do

SPF identifies servers permitted to send for the envelope-sender domain, typically visible in a delivered message’s Return-Path. DKIM attaches a signature that a receiver can verify using a public key in DNS. DMARC checks whether a passing SPF or DKIM identity aligns with the domain in the visible From address, and publishes your requested treatment for failures.

A DMARC pass needs at least one aligned mechanism to pass. Having a passing SPF result for a provider-owned domain is not necessarily enough for your From domain. The DMARC specification explains alignment; check your provider’s custom-domain instructions rather than assuming a green “connected” label proves it.

Step 1: inventory every sender

Write down all services that send on your behalf. Include everyday mailboxes, transactional product email, newsletters, support tools, billing software, contact forms, and older automation nobody has touched recently. For each, record the From domain, return-path domain, DKIM signing domain, owner, and expected volume.

Ask the finance and support teams what they actually use. A marketing migration can leave the old service active for renewal notices. It is much easier to resolve that now than to discover it after enforcing rejection.

Service: transactional email provider
Visible From: notifications@example.com
Custom return-path: bounce.example.com
DKIM signing domain: example.com
Owner: product operations
Test message: password-reset email to a controlled inbox

Step 2: publish one SPF policy per sending domain

An SPF record is a TXT record beginning with v=spf1. Use the exact mechanisms your providers document. This illustrative record uses reserved example addresses and must not be deployed unchanged:

example.com. IN TXT "v=spf1 ip4:192.0.2.10 include:_spf.mail-provider.example -all"

If multiple services need authorization, combine their requirements into one policy at that name. Multiple independent SPF policies are an error, not a way to let each provider manage its own list. Before removing a mechanism, identify which sender depends on it.

The evaluation limit concerns DNS-querying SPF terms, including nested includes and redirects; it is not simply a limit of ten services or ten TXT records. An overcomplicated policy can exceed the limit and return a permanent error. Validate the complete expansion and avoid copying unmanaged “flattened” IP lists that may go stale. See RFC 7208’s lookup limits.

Step 3: enable DKIM for each service

Have the sending provider generate or provision DKIM signing keys. It will supply a selector and either a TXT public-key record or CNAME records that delegate the key lookup. Publish exactly the records it specifies, then enable signing in its dashboard if that is a separate action.

# Replace the selector with one configured by your provider.
dig +short TXT selector1._domainkey.example.com
dig +short CNAME selector1._domainkey.example.com

An empty answer for a guessed selector does not establish that DKIM is missing. Read the selector from an actual signed message or the provider’s settings. Different services can use different selectors simultaneously. Keep a record of the owner so future DNS cleanup does not accidentally remove an active key.

Step 4: start DMARC in monitoring mode

Create a mailbox or reporting service that can receive aggregate reports. Publish a single DMARC TXT record at _dmarc.example.com:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

This requests reporting without asking receivers to quarantine or reject failures under this policy. It is useful for observation, not strong anti-spoofing enforcement. If reports go to a different organization’s domain, follow the reporting service’s external-destination authorization instructions.

Choose a reporting destination with controlled access. Aggregate reports are operational data and should not be copied into public tickets. Assign someone to review them; collecting unread attachments does not advance the rollout.

Step 5: test alignment with real messages

Send representative messages from every listed service to inboxes you control. Inspect the receiver’s Authentication-Results and visible From address. Look for DMARC pass and identify which aligned mechanism supports it. Save redacted examples for invoices, support replies, newsletters, and transactional messages.

Check forwarding and mailing-list cases separately. Forwarding can affect SPF, and message modification can affect DKIM. Do not interpret every failure as malicious activity. Correlate reports with known senders, then fix provider configuration before changing enforcement.

A DNS lookup tells you what is published. A delivered message tells you what a sender actually used. You need both kinds of evidence.

Step 6: move toward quarantine and reject

After legitimate streams consistently authenticate and align, change the policy in controlled stages:

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

Later, when the evidence supports it:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

These are policy requests to receivers, whose local handling can differ. Keep watching delivery metrics and reports after each change. Decide separately how subdomains should behave, and avoid changing relaxed versus strict alignment casually. A subdomain used by a service may need its own carefully tested policy.

Google and Yahoo requirements

Google’s current bulk-sender guidance for personal Gmail recipients requires SPF and DKIM, DMARC with at least a monitoring policy, and alignment; additional requirements include unsubscribe handling for applicable messages. Its bulk threshold is around 5,000 messages per day to personal Gmail accounts. Consult the official Gmail sender guidelines before a campaign.

Yahoo also requires bulk senders to use SPF, DKIM, and passing DMARC with at least p=none, alongside its other delivery requirements. Do not assume Gmail’s numeric threshold defines Yahoo’s policy. Use the Yahoo sender requirements as the source for Yahoo delivery.

Missing DMARC does not mean every message must land in spam. Conversely, publishing it does not purchase guaranteed delivery. Authentication is a necessary operational foundation, especially as your sending volume grows.

Keep the setup maintainable

Add email authentication to the onboarding checklist for every new sending service. Review DNS after vendor migrations and key rotations. Before enforcing a stricter policy, confirm who will respond if a legitimate stream fails. Tie this work to your wider website security checklist so DNS ownership and application ownership stay connected.

Check your own site — your first scan is free. Scanwise combines passive intelligence and non-destructive external checks, including DNS observations, with AI-assisted fix suggestions. It does not certify email delivery or replace testing messages from your actual senders. Starter credits require a verified account and are subject to anti-abuse limits.