Home / Blog / Security and Reliability / How to Set Up SPF, DKIM, and DMARC
If your invoices land in spam, or a customer reports a phishing email “from” your domain that you never sent, the cause is usually missing or broken email authentication. SPF, DKIM, and DMARC are three DNS records that together let receiving mail servers verify that a message claiming to be from your domain really is from you.
They are not deliverability magic — passing all three does not guarantee the inbox — but without them, mailbox providers have little reason to trust your mail at all. Since February 2024, Google and Yahoo have required authentication from bulk senders, and enforcement has tightened since. This guide explains what each record does, the order to set them up, and how to reach enforcement without blocking your own legitimate mail.
Each record answers a different question:
selector._domainkey.yourdomain) and checks the signature, proving the message was not altered after signing.Alignment is the piece people skip. A newsletter tool may send your campaign with its own bounce domain: SPF passes for the tool, not for you, so DMARC fails unless the tool also signs with DKIM as your domain. A message can show SPF pass and DKIM pass and still fail DMARC if neither authenticated domain aligns with the From domain.
The most common setup failure is forgetting a sender. Before touching DNS, list every service that sends mail as your domain:
Each one needs to be covered by SPF (authorised to send) or DKIM (signing as your domain), or it will fail DMARC when you reach enforcement. This inventory is the single most valuable step in the whole process.
SPF is a TXT record at your domain root. A typical record looks like this:
example.com. TXT "v=spf1 include:_spf.google.com include:spf.mailprovider.example -all"
The parts:
v=spf1 identifies the record as SPF.include: adds another provider’s authorised servers. Your email provider’s documentation gives you the exact value to include — use theirs, do not guess.-all at the end means “fail mail from any server not listed”. The softer ~all means “soft-fail” and is sometimes used during testing, but -all is the correct end state.Rules that catch people out:
v=spf1 records breaks SPF. Merge all providers into a single record.include: counts). Providers that include other providers can burn through the limit quickly. If you exceed it, SPF returns an error and fails. Flattening includes or removing unused providers is the fix — check with a lookup-counting tool before publishing.DKIM works in two parts: a private key held by the sender, and a public key published in DNS.
selector._domainkey.example.com, where selector is the name your provider gives you (for example, google for Google Workspace, or s1/s2 for some transactional providers). The record looks like:google._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."DKIM-Signature header and an Authentication-Results line showing dkim=pass.Each sending service has its own selector and key. If you send through three services, you will have three DKIM records, each under its own selector.
DMARC is a TXT record at _dmarc.example.com:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
v=DMARC1 identifies the record.p=none is the policy: take no action on failing mail, just report it. This is monitoring mode, and it is where everyone should start.rua=mailto:[email protected] is where aggregate reports go. Use a dedicated mailbox — reports arrive daily and the volume adds up.Start at p=none and stay there for at least two to four weeks. The reports will show you every source sending mail as your domain, including the ones you forgot in your inventory, and whether each one passes or fails. Fix the legitimate senders that fail — add a missing SPF include, enable DKIM signing, fix alignment — before you tighten anything. Jumping straight to enforcement before reading any reports is the single most common way to break legitimate mail.
Once reports show your legitimate mail passing consistently, move to p=quarantine — failing mail goes to spam — watch reports for another one to two weeks, then move to p=reject, where failing mail is refused.
A stricter record looks like:
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=r; aspf=r"
The adkim and aspf tags set alignment to relaxed (r, the default, where the organisational domain must match) or strict (s, where the domain must match exactly). Relaxed alignment is the usual choice. Forensic reports (ruf) give detail on individual failures but are sent by only some receivers and can be voluminous — aggregate reports (rua) are the essential ones.
Google’s sender guidelines define a bulk sender as one sending around 5,000 or more messages to personal Gmail accounts in 24 hours (counted across the primary domain and its subdomains, and permanent once assigned). Bulk senders must authenticate with both SPF and DKIM, publish a DMARC record of at least p=none, align the From domain, support one-click unsubscribe on marketing mail, and keep spam complaint rates below 0.3% (Google recommends staying below 0.1%). Non-compliant mail faces temporary errors, spam placement, or rejection. Even if you never send bulk mail, every sender needs SPF or DKIM, valid forward and reverse DNS, and TLS.
Note that authentication does not buy an inbox. RFC 9989 itself says a DMARC pass only shows the domain was used with permission and “does not guarantee” delivery. Complaints, sending habits, and reputation still decide the rest.
After publishing each record, allow time for DNS propagation, then verify:
bash
dig TXT example.com
dig TXT google._domainkey.example.com
dig TXT _dmarc.example.comspf=pass, dkim=pass, and dmarc=pass with alignment.p=reject on day one, blocking a forgotten sender such as the website’s contact form.p=none, read the reports, fix legitimate senders, then move to quarantine and reject.Discovering your site has been hacked is a bad day that gets worse with the wrong first moves. This guide gives the order of operations: contain, preserve evidence, clean or rebuild, rotate every credential, and harden the site afterwards.
A 99.9% uptime claim allows about 43 minutes of downtime a month — but only if you know what counts, what is excluded, and how to claim. This guide decodes the SLA.
DDoS protection can absorb enormous attacks — and still leave your site down. This guide explains the attack types, the layers of defence, and the honest limits.