How to set up SPF, DKIM
and DMARC from scratch

These three records answer three different questions, and none can replace another. SPF — who may send as your domain. DKIM — was the message altered in transit. DMARC — what to do when the checks fail. Without the third the first two decide nothing: the receiver can see the message is forged and still has no instruction.

The order of work

1. SPF. One TXT record at the domain root. It lists your senders.
2. DKIM. Your mail provider issues the key; you publish it as TXT on a subdomain like selector._domainkey.
3. DMARC. TXT at _dmarc with p=none and a reporting address. Read the reports for two or three weeks, then tighten.

That order matters. A strict DMARC published first throws away mail from your own forgotten services — and its reports are the only way to learn they exist.

SPF: who may send

One record per domain, at the root:

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

• include: — “ask this domain too”. That is how Google Workspace, a mailing service or a CRM gets added.
• ip4: and ip6: — specific addresses of your own server, if it sends mail itself.
• ~all at the end — “treat everyone else as suspicious”. Strict -all comes later, once you are sure the list is complete.

The main trap is the ten-lookup limit. Every include costs one, and other people's records have their own includes inside. Cross ten and the record stops working entirely, not partially. Check your number with the SPF checker.

There must be exactly one SPF record. Two mean permerror: the checker rejects both rather than picking the better one.

DKIM: the signature

DKIM is a cryptographic signature your mail server adds to every outgoing message. The receiver takes the public key from your DNS and verifies the message was not altered after sending.

You do not invent the key — the provider issues it:

• Google Workspace: Admin → Apps → Gmail → Authenticate email. Generate the record, publish the TXT it gives you, come back and switch it on.
• Other providers give the same name/value pair in their domain settings.

The record name looks like google._domainkey.example.com, where google is the selector. Several selectors are fine — each service has its own.

Use a 2048-bit key. 1024 still works but is increasingly flagged as weak.

DMARC: what to do with failures

The record lives on the _dmarc subdomain:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1

p=none blocks nothing — and that is the point of the first step. It turns reports on, and reports show what you do not know: who else sends as your domain. There is almost always a forgotten CRM, an old mailing service or a script on a server.

Two or three weeks later: add what you found to SPF and DKIM → p=quarantine → a month later p=reject. Build the line with the DMARC generator.

Why DMARC fails with valid SPF and DKIM

The least obvious part. DMARC does not just want “a check passed” — it wants the domain that passed to match the From header.

A message from you@company.com sent through a mailing service with its own envelope passes SPF — but the service's domain passed. To DMARC that is a stranger: spf=pass, dmarc=fail.

The cure is a DKIM signature with your own domain; nearly every service allows it. Confirm with the header analyzer: compare d= in the signature with the From domain.

Checking that it landed

DNS does not update instantly: usually minutes, sometimes up to a day. Check with a query rather than by eye in the registrar panel:

• SPF checker — the record, its lookups, duplicates.
• DMARC — policy, reports, alignment.
• Header analyzer — send yourself a message on Gmail and see what all three checks say at once.

What Gmail and Yahoo require

Since 2024, senders of more than 5000 messages a day need all of it: SPF, DKIM, DMARC with at least p=none, a List-Unsubscribe header with one-click opt-out, and a complaint rate under 0.3%. Not advice — without it mail is not accepted.

For everything else that affects delivery, see staying out of spam.