Skip to content
Duva Duva

← All articles

SPF, DKIM and DMARC: setting up a sending domain, step by step

· 6 min read

For a receiving server to believe an email really comes from your domain, it compares what it receives to what your DNS announces. Three mechanisms share the work: SPF, DKIM and DMARC. Mixing them up is the first source of configuration problems. Here is what each one does, how to publish them without breaking what already works, and how to check.

What each mechanism does

SPF (Sender Policy Framework) says which servers are allowed to send for a domain. The receiving server looks at the envelope return address (the "Return-Path") and checks that the sender's IP address is listed in that domain's SPF.

DKIM (DomainKeys Identified Mail) signs the message. The sender signs with a private key; the matching public key is published in your DNS, at <selector>._domainkey.your-domain. The receiving server checks the signature: the message really comes from the signing domain and its content did not change along the way.

DMARC ties both to what the person sees. It checks that the domain of the From address (the one displayed) is aligned with the domain authenticated by SPF or DKIM, then tells the receiving server what to do when it is not: nothing (none), quarantine (quarantine) or reject (reject). It also asks for reports.

A message passes DMARC if SPF or DKIM succeeds and the authenticated domain is aligned with the From domain. Alignment is the subtle part: an SPF that passes for a provider's domain, but not for yours, is not enough on its own.

What the large providers require

Gmail publishes rules for senders. According to Google's help page (consulted on October 1, 2026):

  • all senders: SPF or DKIM, valid forward and reverse DNS records for the sending IP addresses, an encrypted connection (TLS), and a reported spam rate in Postmaster Tools below 0.3%;
  • more than 5,000 messages per day to Gmail: SPF, DKIM and DMARC, a From domain aligned with the SPF or DKIM domain, and, for marketing and subscribed messages, one-click unsubscribe.

Keep the simplest takeaway: publish all three, even if your volume is low. It is the configuration everyone expects today, and it protects you against spoofing of your domain.

  1. DKIM first. It cannot break an existing flow: it is a new key published at a new DNS name.
  2. SPF next, with care (see below).
  3. DMARC last, first in monitoring mode (p=none), then tightened.

To verify a domain, Duva requires two records:

  • the DKIM key: a TXT record at <selector>._domainkey.your-domain, whose value is shown on the domain's DNS screen;
  • a return CNAME: bounce.your-domain, pointing to a given target. The return address of every email is on that subdomain, and that is where bounces and complaints come back.

Optional but recommended: the SPF at the root of the domain, DMARC, and the tracking CNAME track.your-domain if you use open and click tracking. Because the return address is on bounce.your-domain, a subdomain of your domain, DMARC can align through DKIM and through that subdomain's SPF.

The DNS screen gives the exact values to copy at your DNS host, and a button lets you request a new verification once the records are published. See also the FAQ.

SPF: the three classic mistakes

One SPF record per domain. If you publish two, the result is invalid. If your domain already has an SPF (because you also use an office suite or a newsletter platform), add the new include: to the existing record. Never create a second SPF record.

example.ca.  TXT  "v=spf1 include:_spf.other-service.com include:_spf.provider.example ~all"

At most 10 DNS lookups. The SPF standard limits to ten the number of mechanisms that trigger a DNS query (include, a, mx, redirect...). Beyond that, SPF fails. Every third-party service you add uses a few of them.

"~all" and "-all". ~all (soft fail) is the prudent value when you start. -all (hard fail) is stricter. Only move to -all after you have listed every service that sends on your behalf.

DKIM: what to know

  • The selector (the prefix before ._domainkey) lets you have several keys at once, for example one per provider.
  • If your DNS host limits the length of a TXT value, the key may have to be split into several quoted pieces: that is normal for a 2048-bit key.
  • Copy the value as displayed, without adding any space or line break.

DMARC: start in monitoring mode

A reasonable first record:

_dmarc.example.ca.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"
  • p=none: takes no action on messages, but asks for reports.
  • rua=: the address to receive aggregate reports (XML files, one per provider per day).

Read the reports for a few weeks. They show everything that sends on your behalf, including services you had forgotten. When everything legitimate passes, move to p=quarantine, then to p=reject if you want to block spoofing. Each step protects more, but risks making a legitimate email disappear if you had not listed its source.

At Duva, when report reception is enabled, the DMARC page of the dashboard offers a ready-to-publish record, with the address to put in rua, and summarizes what the reports show.

Checking what you published

With the dig tool (or any web DNS lookup interface):

dig +short TXT example.ca
dig +short TXT selector._domainkey.example.ca
dig +short TXT _dmarc.example.ca
dig +short CNAME bounce.example.ca

Then send a test email to a Gmail address and open "Show original": the page tells you whether SPF, DKIM and DMARC passed, and for which domain.

The mistakes that come up most often

  • Two SPF records instead of one.
  • A DKIM key copied with an extra break or quote: check with dig, not by eye.
  • A change that has not propagated yet. A record can take a while to be visible everywhere. Ask for verification again later before concluding that it does not work.
  • The host name: some DNS hosts automatically append the domain name. Typing selector._domainkey.example.ca in a field that already appends .example.ca produces a name that does not work.
  • DMARC at reject too early, before reading a single report.

Sources