SPF, DKIM and DMARC explained, with examples

SPF, DKIM and DMARC are three DNS records that let a receiving server decide whether a message really comes from the domain it claims. SPF says which servers may send. DKIM adds a signature that proves the domain sent the message unchanged. DMARC ties both to the From address and says what to do when they fail.

None of them is new, but since 2024 they stopped being optional. Gmail and Yahoo require SPF or DKIM from every sender and all three from bulk senders; Outlook.com rejects high-volume mail without them since May 2025. Even if you send a few dozen messages a day, a domain without them looks like a domain anyone can forge.

SPF (RFC 7208) is one TXT record at your domain that lists the hosts allowed to send mail with your domain as the envelope sender, the address in the SMTP MAIL FROM command where bounces go. The receiver takes the connecting IP address and checks whether your record allows it.

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:spf.provider.example ~all"

The two rules that break SPF most often

• One record only. Two v=spf1 records at the same name give a permanent error (RFC 7208 §3.2). When you add a service, merge its include into the record you have.
• At most 10 DNS lookups. include, a, mx, ptr, exists and redirect each cost one, nested includes count too, and the 11th makes SPF fail (§4.6.4). Remove services you no longer use.

SPF has a blind spot: it checks the envelope sender, which the recipient never sees, so on its own it does not stop someone forging your From address. It also breaks when mail is forwarded, because the forwarder’s IP is not in your record. The SPF record generator builds a valid record and counts the lookups for you.

With DKIM (RFC 6376) the sending server signs selected headers and the body of each message with a private key, and adds a DKIM-Signature header. The receiver reads the domain (d=) and selector (s=) from that header, fetches the public key from DNS and checks the signature.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1;
  h=from:to:subject:date:message-id; bh=…; b=…

; either the key itself…
s1._domainkey.example.com.  3600  IN  TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkqh…"
; …or a CNAME to a key your provider publishes and rotates
s1._domainkey.example.com.  3600  IN  CNAME  s1.dkim.provider.example.

• Use 2048-bit RSA keys. RFC 8301 requires at least 1024 bits and recommends 2048, and forbids signing with SHA-1.
• Sign with your own domain. Many services sign with their domain by default. That passes DKIM but does not help your DMARC. Turn on custom-domain DKIM in each service.
• Prefer CNAME delegation. The provider can rotate keys without you touching DNS, and you avoid pasting a key longer than 255 characters into a dashboard that mangles it.

DKIM survives forwarding as long as nobody changes the message. Mailing lists that add a footer or rewrite the subject break it, which is why DMARC needs care on domains whose people post to lists.

DMARC adds what SPF and DKIM lack: a link to the From address people see. A message passes DMARC when SPF or DKIM passes and the domain that passed is aligned with the From domain. The record lives at _dmarc under your domain.

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Alignment, relaxed or strict

Relaxed alignment (the default) accepts any domain under the same organizational domain: a DKIM signature with d=mail.example.com aligns with From example.com. Strict alignment needs the exact same name. Most senders should stay relaxed.

The usual setup at an email provider shows why DKIM carries most of the weight: SPF passes for the provider’s own bounce domain, which does not align with yours, while DKIM signs with your domain and aligns. DMARC passes on DKIM alone, and one aligned pass is enough.

What changed with DMARCbis (RFC 9989)

• RFC 9989, published in May 2026 as a Proposed Standard, replaces RFC 7489 (which was only Informational). Reporting moved to RFC 9990 (aggregate) and RFC 9991 (failure).
• The organizational domain is now found with a DNS tree walk instead of the Public Suffix List, and the psd= tag lets registries mark the boundary.
• pct, rf and ri were removed; t=y replaces the old trick of pct=0. np= was added.
• The version tag stays v=DMARC1, so existing records keep working.
• Domains whose users post to mailing lists should not publish p=reject, and receivers must not reject on that policy alone (§7.4).

1. 1Publish p=none with a rua address. Nothing changes for delivery; you start getting reports.
2. 2Read the reports for two to four weeks. List every service that sends as your domain: the mail host, the CRM, invoicing, the newsletter, the website’s contact form.
3. 3Fix each one: add its SPF include or, better, turn on DKIM with your domain.
4. 4Move to p=quarantine (or p=quarantine; t=y first, to test). Watch the reports for another few weeks.
5. 5Move to p=reject only if nobody at the domain posts to mailing lists and the reports stay clean.

p=none is enough to meet the Gmail, Yahoo and Outlook.com rules. Enforcement is about stopping others from using your name.

The DMARC record generator writes the record for each stage. If a report points to an address on another domain, that domain must publish an authorization record (example.com._report._dmarc.reports-domain with v=DMARC1), or receivers will not send to it.

Open a message you sent to a Gmail or Outlook account and view the original (Gmail: Show original). The receiving server records its verdict in an Authentication-Results header:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@example.com header.s=s1;
  spf=pass smtp.mailfrom=bounces.provider.example;
  dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

Here SPF passed for the provider’s domain and DKIM for yours; DMARC passed through DKIM. If you see dmarc=fail, compare the header.from domain with header.i and smtp.mailfrom: at least one must be under your domain and pass. Only trust the header your receiving server added; anything above it can be written by the sender.

When you connect a domain, Skein writes these records for you on supported DNS providers; anywhere else you paste a few lines. More on the full setup in business email on your own domain.