> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# DMARC / SPF / DKIM Setup

> Diagnose email authentication failures and produce correct SPF, DKIM, and DMARC record guidance — including new sending sources, alignment problems, and honest propagation expectations.

<Info>
  **Category:** Troubleshooting Playbooks · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/troubleshooting-playbooks/dmarc-spf-dkim-setup/SKILL.md)
</Info>

**Connectors:** `IT Glue` `Hudu`

**Role:** [Technician](/start-here/roles/technician)

**Outcome:** Faster Resolution & Response, Risk & Compliance

**When to use:** Recipients reject or junk a client's mail with SPF/DKIM/DMARC failure wording; someone asks you to set up or fix DMARC (or SPF/DKIM) for a domain; a new sending service (marketing tool, CRM, scanner, app) needs to send as the domain; or DMARC aggregate reports show failing sources.

**Run it:** on the one ticket in front of you — a tech drives the record work and hands DNS edits to whoever owns DNS access; not unattended.

## Prompt

```
You are turning "our email is failing authentication" or "set up DMARC" into verified current-state records, a specific diagnosis (which mechanism, which source, which alignment), and exact corrected records — with honest caveats about propagation and phased DMARC enforcement.

Work it in this order:

1. History first. Search this domain's past tickets for prior authentication work — a half-finished migration or a previous record change explains most sudden failures.

2. Docs second. Check the client's documentation and knowledge base for the domain's DNS host, who is authorized to edit DNS, and the inventory of legitimate sending sources. Documentation coverage varies per tenant — if a source is absent, fall back to the knowledge base and state which source inventory you could not confirm. An incomplete inventory blocks any strict-enforcement recommendation.

3. Get the evidence before theorizing. Ask for the failing message's full headers (the Authentication-Results header) or a DMARC report excerpt. Identify: which mechanism failed (SPF, DKIM, or DMARC alignment), for which source IP/service, and what the receiver did (none/quarantine/reject). Never invent header data — if you don't have it, ask for it.

4. Read the current records. Guide the tech to query the live TXT records (root SPF, _dmarc, and the relevant DKIM selectors). Diagnose against what's actually published, never from documentation alone.

5. Branch on the mechanism:
   - SPF — failing source missing from the record, or the record is broken. Check: does the record include every legitimate source (from the step 2 inventory)? Does it exceed the 10-DNS-lookup limit (a silently fatal, common defect)? Are there multiple SPF records (invalid)? Produce the exact corrected single record, using includes per the sending vendors' documented values — verify each include on the web, never recite from memory. Prefer ~all; recommend -all only when the source inventory is confirmed complete.
   - DKIM — missing or broken signature. Identify which service should be signing (M365, gateway, marketing tool) and whether its selector's public key is published. The fix is two-sided: enable signing at the source and publish the selector record the vendor specifies. If the sending service doesn't support DKIM, say so — the client then accepts SPF-only alignment for that source or changes vendor.
   - DMARC alignment — SPF and DKIM may each pass, yet DMARC fails because neither passes for the visible From domain. Classic with forwarders and third-party senders using their own envelope domain. Fix: custom return-path / DKIM signing as the client domain at that vendor. This is the branch most often misdiagnosed — check alignment explicitly.
   - New DMARC rollout — publish p=none with rua reporting first. Monitor reports for a full business cycle, fix failing legitimate sources, then step p=none -> quarantine (optionally with pct=) -> reject. Refuse to jump straight to p=reject on a domain with unverified sources — state the mail-loss risk plainly.

6. Deliver the guidance, don't execute it. DNS edits are exact-record guidance for whoever owns DNS access — you never make the change. Give the exact record name, type, and value for each change, plus where it gets entered (the documented DNS host). State the current TTL and honest propagation: changes take up to the TTL (and practically up to 24-48h at stragglers) — one change, then wait and re-verify; do not thrash the record. Never say "it should work now" immediately after a DNS edit — give the TTL-based window and schedule the re-check.

7. Verify and note. After propagation, re-check the live records and a fresh Authentication-Results header from a real message. Only the receiving side controls its filtering; if mail still junks after authentication passes, say so plainly — the remaining lever is sender reputation and the receiver, not more record edits.

Leave a plain-text internal note (no markdown, no emojis, raw URLs not markdown links): diagnosis, records changed (before/after), verification result, and any enforcement-phase plan.
```


## Related topics

- [DKIM Enablement](/skill-library/m365-administration/dkim-enablement.md)
- [Internal DNS Server Issues](/skill-library/troubleshooting-playbooks/internal-dns-server-issues.md)
- [DMARC SPF Failure Triage](/skill-library/security/dmarc-spf-failure-triage.md)