SPF, DKIM and DMARC Explained for Small Businesses

SPF, DKIM and DMARC are three DNS records that prove an email really came from your domain. SPF lists which servers may send mail for you, DKIM signs each message so receivers can check it was not altered and that your domain stands behind it, and DMARC tells receivers what to do when a message fails those checks and sends you reports about it. For a small business the safe order is SPF, then DKIM, then DMARC set to monitor only, then tighter rules once the reports look clean. This guide explains each record in plain language, shows the rollout steps, lists what Gmail requires, and covers the mistakes that most often break email delivery. It cites the technical standards and Google's published guidance, and it avoids promising that authentication alone will put you in the inbox.

Why this matters for outreach and client email

Email that fails authentication is more likely to be treated with suspicion, and anyone can try to send a message that claims to come from your domain. Authentication helps receivers tell your real mail from forgeries, and it is now a baseline requirement for reaching some inboxes.

Gmail's sender guidelines apply to messages sent to personal Gmail accounts. In summary:

Other mailbox providers publish their own requirements, so check those for the audiences you write to. Passing authentication is necessary for good deliverability but not sufficient. Reputation, complaint rates, bounces and content still decide whether a message lands in the inbox.

What each record does

SPF: who may send for you

The Sender Policy Framework standard, RFC 7208, describes how a domain owner can explicitly authorize the hosts allowed to use its domain name and how a receiving host can check that authorization. In practice it is one line of text in your DNS.

Here is an example for a business that sends through Google Workspace. Check your provider's current instructions before copying anything:

v=spf1 include:_spf.google.com ~all

Reading it from left to right: version one of SPF, then include the servers that Google lists, then treat everything else as a soft fail.

Google's guidance on SPF records adds several cautions:

• One SPF record per domain. Every service that sends for you must be in that single record.
• Keep to 10 lookups. RFC 7208 says implementations must limit the terms that cause DNS queries (include, a, mx, ptr, exists and the redirect modifier) to 10, and must return a permanent error if the limit is exceeded. Adding a CRM, a newsletter tool, an invoicing tool and an outreach platform can reach that limit quickly.
• Put the all mechanism last. Anything after it is ignored.
• Soft fail or hard fail. The tilde version (soft fail) asks receivers to treat unlisted senders as suspicious. The hyphen version (hard fail) lets receivers reject them, and Google warns that a misconfigured record can then send more of your legitimate mail to spam. Google recommends using DMARC reports to identify all your senders before relying on hard fail.

DKIM: a signature on each message

DomainKeys Identified Mail, defined in RFC 6376, lets an organization take responsibility for a message by associating its domain with it. That responsibility is validated through a cryptographic signature, and by querying the signer's domain to retrieve the public key.

For a small business, this means two things happen. Your email service signs each outgoing message with a private key it holds, and you publish the matching public key in DNS. You usually do not generate keys by hand. Your email provider or sending tool gives you the record to add, and each service that sends for you, whether it is your mailbox provider, a CRM or an outreach tool, may need its own DKIM setup for your domain. Gmail asks for keys of at least 1024 bits and recommends 2048.

DMARC: the policy and the reports

DMARC, described in RFC 7489, lets a domain owner state a policy for messages that fail authentication and ask receivers for reports. It adds one important idea, alignment: the domain in the visible From address must match a domain validated by SPF or DKIM. A message can pass SPF for some technical domain and still fail DMARC if that domain does not match the From address.

A DMARC record has a few key parts:

• The policy (p). None asks receivers to take no specific action. Quarantine asks them to treat failing mail as suspicious, for example by placing it in spam. Reject asks them to reject failing mail during delivery.
• Reports (rua). The address that receives aggregate reports. If it is absent, receivers do not generate aggregate reports.
• Percentage (pct). The share of messages the policy applies to, with a default of 100, so you can tighten gradually.

A first record, for monitoring only, looks like this:

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

A safe rollout order

Google's recommended DMARC rollout gives a cautious sequence. Adapt it to your size.

1. List every service that sends email as your domain. Include the mailbox provider, CRM, invoicing tool, newsletter tool, support desk and any outreach platform. Missing one is the usual cause of trouble.
2. Set up SPF and DKIM first. Google says to do this at least 48 hours before setting up DMARC.
3. Test. Send a message to yourself, view the full headers, and look at the Authentication-Results header to see whether SPF, DKIM and DMARC passed.
4. Publish DMARC with p=none and a reporting address. Read the reports for about a week, daily if you can, to find senders that fail.
5. Fix what fails. Add missing senders to SPF, enable DKIM in each service, and make sure the From domain aligns.
6. Move to quarantine on a small percentage. Do this only after about a week of reports shows no problems, and raise the percentage gradually until it covers all mail.
7. Consider reject only when you are confident that every legitimate sender passes, because rejected messages are not delivered.

Note that p=none gives you visibility but little protection against forged mail. It is a starting point, not a destination.

Authentication is not the whole story

Passing all three checks does not guarantee inbox placement. Gmail's guidelines add the other half: keep the spam rate shown in Postmaster Tools below 0.3 percent, with 0.10 percent recommended, send only to people who want your messages, and do not buy lists. For outreach, that means small relevant lists, verified addresses and an easy way to opt out, as explained in the guide to writing a cold email that gets replies. A new domain or mailbox has no sending history, so it is common practice to increase volume gradually, not all at once. That is a convention among senders, not a published rule.

Common mistakes

• Two SPF records. Merge them into one.
• Going over 10 lookups. Remove services you no longer use.
• Forgetting a third-party sender. The tool you forgot is the one whose mail will fail.
• Hard fail too soon. Check your reports first.
• Jumping straight to reject. Monitor, then quarantine in steps.
• Not reading the reports. A DMARC record nobody reads protects little.
• Authenticating the wrong domain. Align the visible From domain with the domain that passes.
• Assuming authentication fixes everything. It does not replace a clean list and good content.

Next step

List every service that sends email as your domain, then check your current records and publish a DMARC record set to monitor. If you would like an outside view of your outreach setup and how it fits your lead generation, you can book a free audit. For the wider picture of lead channels, see eight lead generation channels compared, or browse the rest of the blog.

Sources

• Gmail Help, Email sender guidelines
• RFC 7208, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
• RFC 6376, DomainKeys Identified Mail (DKIM) Signatures
• RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• Google Workspace Help, About SPF records
• Google Workspace Help, Recommended DMARC rollout