Guide
SPF, DKIM and DMARC: the guide for web agencies
Three DNS records, half an hour of work, and two problems solved at once: your clients stop landing in spam, and nobody can write in their name any more. Here is how to set them up, in the right order, without breaking anything.
8 min readUpdated August 25, 2026
1. Why this became your problem
For fifteen years, email authentication was the host's business. Then, in February 2024, Google and Yahoo tightened their requirements for regular senders: SPF, DKIM and DMARC properly set, one-click unsubscribe, and a complaint rate kept low. A misconfigured domain does not get its email refused overnight — it simply sees it arrive less and less often.
The second problem is older and more serious: without these settings, anyone can send an email that appears to come from your client's domain. That is the starting point of the overwhelming majority of invoice fraud. The accountant gets a message from their boss, with the right sender address, and pays.
You are neither their host nor their mail provider. But you hold the keys to their DNS zone, and you are the one who gets called when their quotes stop arriving. Better to handle it once, properly.
2. SPF: who may write in your name
SPF is a plain TXT record at the root of the domain, listing the servers allowed to send mail for it. It always starts with “v=spf1” and ends with an “all” mechanism saying what to do with everything else: “-all” refuses them, “~all” accepts them but flags them, “?all” expresses no opinion, and “+all” authorizes the entire world — that last one is a mistake, never an option.
Three rules not to forget. One SPF record per domain: two records make the whole check fail, and that is the most common error when a new sending tool is added without touching what exists. Ten DNS lookups maximum: every “include”, “a”, “mx” or “redirect” consumes one, and beyond ten the standard mandates failure. And SPF only protects the technical envelope of the message, not the address the recipient sees — hence DKIM and DMARC.
In practice, start with “~all”: unauthorized messages are accepted then flagged, which gives you time to spot a sending service you had forgotten. Move to “-all” once the DMARC reports stop turning up surprises.
3. DKIM: the signature proving nothing moved
DKIM signs each message with a private key held by the sending server. The matching public key is published in DNS, under a name of the form “selector._domainkey.example.com”. The recipient recomputes the signature: if it matches, the message was not altered in transit and really comes from who it claims.
The selector is chosen by your mail provider, and it can be named anything. That is the honest limit of every public tool, ours included: they probe a list of common selectors, and finding none does not prove there is none. To be certain, the only reliable source is your provider's own interface — with Google Workspace, it is “Authenticate email” in the admin console.
Nothing to write by hand here: the provider gives you the record, you paste it into the zone. The only possible mistake is enabling it on the provider's side before DNS has propagated, or the other way round.
4. DMARC: what happens when both fail
DMARC is the third TXT record, placed on “_dmarc.example.com”. It does two things. First it checks ALIGNMENT: that the domain authenticated by SPF or DKIM is the one the recipient sees in the “From” field. Then it gives an instruction: “p=none” observes without blocking, “p=quarantine” sends doubtful messages to spam, “p=reject” refuses them outright.
The second half of DMARC is the forgotten one: the “rua” tag names an address to which receiving servers send daily reports. It is the only way to learn who is sending mail in your domain's name — including the legitimate services your client set up without telling you.
Setting DMARC to “p=none” protects nothing but breaks nothing: it is the right first step. The danger is leaving it there for three years. A DMARC stuck on “none” indefinitely is a security camera whose footage nobody watches.
Check your own domain, right now
Enter a client's domain: we read their three records and tell you in plain language what is missing and what is wrong. No account needed.
5. The order to set them up
SPF first, DKIM next, DMARC last and on “p=none”. That order is not a preference: a DMARC set before SPF and DKIM are correct and aligned immediately starts failing legitimate mail.
Let it run two to four weeks on “p=none” and read the reports. You will almost always discover a sending service nobody told you about: a contact form, an invoicing tool, a mailing platform installed by the client. Add them to SPF, have them sign with DKIM, and wait until the reports are clean.
Then move to “p=quarantine”, wait another two weeks, then to “p=reject”. All in all, count one to two months between the first record and real protection. It is long, which is why almost nobody sees it through — and also what makes it worth selling.
6. The five mistakes we see most
Two SPF records on the same domain — often because a line was added instead of the existing one being extended. More than ten DNS lookups in the SPF, usually from stacking “include” after “include”. An SPF ending in “+all”, which gives the illusion of protection while authorizing the entire planet.
A DMARC left on “p=none” forever, with no “rua” address, so nobody ever reads anything. And a DKIM enabled at the provider whose DNS record was never pasted in — the sneakiest one, because everything appears to work until a strict recipient refuses the message.
None of these five mistakes causes a visible outage. They slowly degrade a domain's deliverability — and by the time the client notices, they blame something else.
Once set, they still degrade.
An SPF record breaks the day someone adds a sending tool. A DKIM key is dropped during a migration. A DMARC is overwritten by a copy-paste. DomainVigil re-reads all three records continuously across your domains and warns you when one of them changes.
Five domains free, forever. No card required.