DKIM SPF DMARC explained: the three records that prove your mail is yours

An SPF record is one TXT record listing the sources allowed to send for a domain (RFC 7208). The receiver takes the domain from the envelope sender, the MAIL FROM address the sending server announces before the message, and checks the connecting IP address against that domain’s record. It never looks at the From header. A bounce has an empty MAIL FROM, so for bounces SPF checks the name the server gave in HELO instead (§2.4).

acme.example.   TXT   "v=spf1 include:_spf.google.com ~all"

Two services go in the same record, one include each, before the ending. Never publish a second v=spf1 record for the new service:

acme.example.   TXT   "v=spf1 include:_spf.google.com include:spf.newsletter.example ~all"

A service that sends from its own return-path subdomain of yours, as Rasket does and as Shopify’s CNAME records do, needs no include in this record at all: SPF is checked at that subdomain, which has a record of its own. Terms are read left to right and the last one is the catch-all. The qualifier on it decides what an unlisted server gets:

Which ending to use is a real trade-off, not a rule. With -all, some receivers reject a forwarded message during the SMTP conversation, before DMARC or DKIM is ever evaluated, so mail that would have passed DMARC on its signature is lost. With ~all, DMARC does the enforcing and SPF just reports. Once DMARC is at quarantine or reject, ~all loses you nothing, which is why the records Rasket generates for its own return path end in it.

DKIM (RFC 6376) adds a signature header covering chosen headers and a hash of the body. The sending service holds the private key; the public key is a TXT record under a selector, a label that lets one domain publish several keys at once.

rasket._domainkey.acme.example.   TXT   "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

The v= and k= tags many panels show are optional (RFC 6376 §3.6.1), so a bare p= is a complete key. An empty p= means the key is revoked.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=acme.example; s=rasket; h=from:to:subject:date:message-id;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSb...

A receiver reads d= and s=, fetches the key at s._domainkey.d, and recomputes both hashes. Nothing in that depends on which server connected, so a signature usually survives forwarding. It breaks when something rewrites a signed part of the message, such as a mailing list adding a footer or a gateway rewriting links.

A DMARC record sits at _dmarc under the domain in the From header. If there is none, receivers fall back to the domain you registered, its organisational domain (acme.example for mail.acme.example); RFC 9989 receivers find it by walking up the DNS tree, older ones from the Public Suffix List. A sensible first record:

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

In a DNS panel the Host or Name box gets _dmarc and the Value box gets the quoted text. Publish exactly one: when a name has two DMARC records, receivers discard both and the domain has no policy (RFC 9989 §4.10).

A message passes DMARC when SPF or DKIM passes for a domain that aligns with the From domain, meaning it is the From domain or shares its organisational domain. It fails only when neither produces an aligned pass. One aligned leg is enough, which is why publishing both is worth it: they fail in different places.

Receivers that send aggregate reports to the rua address usually send one a day: how many messages claimed your domain, from which IP addresses, and which checks passed. Many small receivers send none. Failure reports (ruf) contain parts of individual messages and few receivers send them; leave them off unless you need them. On a small team the reports belong to whoever can edit DNS, since every fix they lead to is a record change. If nobody there wants to read XML, a DMARC report service will: it gives you an rua address on its domain and publishes the record that authorises it, here acme.example._report._dmarc.reports.example with the value v=DMARC1, without which receivers will not send to another domain (RFC 9990 §4). This is the part of a report to read:

<record>
  <row>
    <source_ip>192.0.2.10</source_ip>
    <count>412</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>acme.example</header_from></identifiers>
  <auth_results>
    <dkim><domain>acme.example</domain><selector>rasket</selector><result>pass</result></dkim>
    <spf><domain>mailer.example.net</domain><result>pass</result></spf>
  </auth_results>
</record>

auth_results holds the raw checks; policy_evaluated holds the aligned ones DMARC used. Here SPF passed for mailer.example.net, which does not align with acme.example, so DMARC counted SPF as failed; the aligned DKIM pass carried the message. A row where both are fail is either a forger or a sender of yours that still needs its records.

import gzip, sys, zipfile
import xml.etree.ElementTree as ET

LIMIT = 20_000_000  # a report is untrusted input: refuse a decompression bomb

def read(path):
    if path.endswith(".zip"):
        with zipfile.ZipFile(path) as archive, archive.open(archive.namelist()[0]) as stream:
            data = stream.read(LIMIT + 1)
    else:
        with (gzip.open if path.endswith(".gz") else open)(path, "rb") as stream:
            data = stream.read(LIMIT + 1)
    if len(data) > LIMIT:
        sys.exit(f"{path}: over {LIMIT} bytes uncompressed")
    return data

def field(record, path):
    return record.findtext("{*}row/{*}" + path, "?")

# {*} matches any namespace: RFC 9990 reports have one, older reports have none.
root = ET.fromstring(read(sys.argv[1]))
for record in root.iterfind(".//{*}record"):
    dkim = field(record, "policy_evaluated/{*}dkim")
    spf = field(record, "policy_evaluated/{*}spf")
    flag = "  <- no aligned pass" if "pass" not in (dkim, spf) else ""
    print(f"{field(record, 'source_ip'):<15} {field(record, 'count'):>6}  dkim={dkim} spf={spf}{flag}")

$ python3 dmarc_rows.py 'google.com!acme.example!1760140800!1760227199.xml.gz'
192.0.2.10         412  dkim=pass spf=fail
198.51.100.23     1180  dkim=fail spf=fail  <- no aligned pass
203.0.113.7          3  dkim=fail spf=fail  <- no aligned pass

Before changing any DNS, look at what receivers already think. In Gmail, open a message you sent, choose Show original from the three-dot menu, and the top of the page lists SPF, DKIM and DMARC with PASS or FAIL beside each. In Outlook it is View message source. Under that summary is the header it was built from: every large mailbox provider writes its email authentication results into an Authentication-Results header (RFC 8601).

Authentication-Results: mx.google.com;
       dkim=pass header.i=@acme.example header.s=rasket;
       spf=pass (google.com: domain of bounce@rasket.acme.example designates 192.0.2.10 as permitted sender) smtp.mailfrom=bounce@rasket.acme.example;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=acme.example

Each verdict names a domain, and DMARC’s alignment test compares them. header.from is the domain the reader sees. smtp.mailfrom is the domain SPF was checked for. header.i is the identity DKIM signed as: its domain is the signature’s d= or a subdomain of it, and some receivers print header.d, the d= itself, instead. Here all three sit under acme.example, so DMARC passes. The common failure is spf=pass for your sending service’s own domain: a real pass that aligns with nothing of yours.

The numbers are from each provider’s own page. The bulk sender checklist covers the rest of the bulk rules, unsubscribe and spam rate included. For this article the point is that records are checked on every message, so a record dropped in a DNS migration becomes a delivery incident the same day.

• Day 1: SPF and DKIM for every service that sends as you. Your mailbox provider, your product mail, your store, your newsletter tool, your helpdesk. Each shows its records in its own settings, usually under a name like sender domain or domain authentication. A WooCommerce store’s records come from whichever mail service its WordPress site sends through.
• Day 1: DMARC at p=none with a rua address. It changes nothing about delivery and starts the reports.
• Then read the reports for a full sending cycle. That is a month if a monthly invoice run sends as you. The usual find is a forgotten sender: an invoicing system, a survey tool or, for a store, a review-request app sending as your domain without alignment. Fix or remove each one.
• Then p=quarantine, then p=reject. Rehearse reject first with the testing record from the RFC 9989 section above. RFC 9989 §7.4 says a domain at reject “MUST apply valid DKIM signatures” rather than rely on SPF alone, and that one whose people post to mailing lists “SHOULD NOT” publish reject at all; if it does, it should spend “at least a month” at p=none and as long again at p=quarantine first. To back out, publish p=none again; receivers see it once the old record’s TTL runs out, so lower the TTL a day before each step. The p=none to p=reject guide has each stage and how long to hold it.

dig +short TXT acme.example | grep spf1
dig +short TXT rasket._domainkey.acme.example
dig +short TXT _dmarc.acme.example

Each command should print one record. A selector published as a CNAME, as Shopify’s and Microsoft 365’s are, prints the CNAME target on a line above it. No output means the record is missing or at the wrong name; two SPF lines means a permanent error. A new record usually answers within minutes. A changed one can keep serving its old value until the old TTL runs out, and a name you looked up before it existed stays “not found” for the zone’s negative-caching TTL (RFC 2308). To see what you just published without either cache, ask your DNS host’s own server: add @ns1.yourdnshost.example, the name dig NS acme.example prints. Shopify says its records can take up to 48 hours.

Adding a domain generates its DKIM key under the rasket selector, signed as your own domain so DKIM aligns exactly, and the records for a return path at rasket.yourdomain, so SPF aligns in relaxed mode. Records keep being re-checked. When one stops resolving, its status changes on the domain page and a domain.updated webhook event fires, so your code can alert on it.

DMARC is not required to verify a domain, so it is the one record we do not check. If your domain has no DMARC policy, the domain page suggests the p=none record above for you to publish, with reports going to your own address, not to us; tightening it is your decision. The return path article explains the SPF half in detail, and the verification walkthrough covers publishing.

If you only send from Google Workspace or Microsoft 365, you do not need a sending service for any of this: both generate a DKIM key and tell you the SPF include to add.