# DMARC

DMARC is a DNS record that tells a receiving mail server what to do with a message claiming to be from your domain when neither SPF nor DKIM lines up with the address a human sees. It adds one idea to those two — alignment — plus a policy and a reporting address. Connect publishes no DMARC record for anyone; it sends through the mailbox a workspace already owns.

- **Status:** Reference
- **Audience:** both, developer
- **Channels:** email
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/technology/dmarc/

## Alignment is the entire idea

SPF and DKIM each authenticate something a reader never sees. SPF checks the envelope sender — the `MAIL FROM` the sending server gave at the SMTP conversation, which is where bounces go. DKIM checks the `d=` domain in the signature header. Neither has any necessary relationship to the `From:` line displayed in the mail client, and forgery lives in exactly that gap: a message can pass SPF for `mailer.example.net` while showing `billing@example.com` to the recipient.

DMARC closes it by requiring that at least one of the two passes **and** matches the visible `From:` domain. Matching comes in two strengths, set per mechanism.

| Tag | Mode | What counts as a match |
|---|---|---|
| `aspf=r`, `adkim=r` | Relaxed (the default) | The organisational domains match — `mail.yourdomain.example` aligns with `yourdomain.example` |
| `aspf=s`, `adkim=s` | Strict | The domains are identical, subdomain included |

A message that fails both aligned checks is what the policy applies to. A message that passes one of them is delivered on the strength of that one, which is why DKIM alignment is the more valuable of the pair: DKIM signatures survive forwarding, and SPF alignment usually does not.

## Policy, subdomains and reports

**`p=none`** — Do nothing differently. This is a monitoring position, not a protection: it changes no delivery decision and exists to turn reporting on.
**`p=quarantine`** — Treat a failing message as suspicious — in practice, the spam folder.
**`p=reject`** — Refuse a failing message at the SMTP conversation, so it never reaches a folder at all.
**`sp=`** — The same three values, applied to subdomains only. A domain that never sends from subdomains is safer with `sp=reject` even while the parent is still at `none`.
**`rua=`** — Where aggregate reports go. These are XML summaries, usually daily, counting messages per source IP with their authentication results. They contain no message content.
**`ruf=`** — Where failure reports go — per-message, potentially carrying recipient data, and honoured by far fewer receivers than `rua`.

```dns
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"
```

> **Note** Aggregate reports are the working part of DMARC and the part most domains never read. They are the only view a domain owner gets of who is sending as them — including the payroll system, the ticketing tool and the one contractor nobody remembered.

## The order that does not lose mail

1. Get SPF and DKIM right for every legitimate sender first, including the ones outside the mail provider — invoicing, marketing tools, the helpdesk, the website's contact form.
   - Result: Alignment becomes possible. Publishing a policy before this is how a business rejects its own invoices.
2. Publish `p=none` with a `rua` address and leave it for several weeks.
   - Result: Reports arrive naming every source sending as the domain. Nothing in the mail flow has changed yet.
3. Fix or retire each unaligned source the reports reveal, then move to `p=quarantine`, ideally on subdomains first through `sp=`.
   - Result: Forged mail starts landing in spam rather than the inbox, and a mistake is recoverable from the spam folder.
4. Move to `p=reject` once the reports show only aligned traffic.
   - Result: Forgery is refused at the door. This is also the point at which a newly added third-party sender breaks immediately and loudly.

Two things break alignment for reasons that are nobody's fault. A mailing list that rewrites the subject or appends a footer invalidates the DKIM signature, and the list's own server fails SPF alignment. Plain forwarding breaks SPF alignment while leaving DKIM intact — which is the practical argument for making DKIM the mechanism you rely on.

## Does Connect use DMARC?

Educational only, with one indirect consequence worth knowing. Connect does not host DNS, does not publish or edit a DMARC record for a workspace, does not collect `rua` reports and does not evaluate incoming DMARC results itself.

Mail leaves through the mailbox a workspace connected — Gmail through the Gmail API, Microsoft Graph, or an IMAP/SMTP server the workspace named. The authentication posture of that path is whatever the domain already configured for it, so a domain that has DMARC at enforcement keeps it, and one that has nothing gains nothing by connecting a mailbox here.

The indirect consequence is at the send boundary. A message is reported as **sent** only when the provider has acknowledged it, and there is a third state — **uncertain** — for the case where the acknowledgement never arrived. A domain at `p=reject` with a misconfigured third-party sender produces refusals that surface as failures rather than silent losses, which is the correct behaviour but is not Connect enforcing DMARC. It is the receiving world enforcing it, visible through evidence Connect keeps.

## Questions

### Do I have to change DNS before connecting a mailbox to Connect?

No. Sending runs over the same authenticated path the mailbox already uses, so a Google Workspace domain whose SPF and DKIM are set up for Google keeps exactly that. You would change DNS for your own reasons — moving to enforcement, adding a new sender — not because of Connect.

### Is `p=none` protecting anything?

No. It is a listening post. It causes receivers to send you aggregate reports and changes no delivery outcome, which makes it the right first step and a poor final one. A domain that has sat at `p=none` for two years is publishing an announcement that nobody is watching.

### Why does mail to a mailing list fail DMARC?

Because lists modify messages. A rewritten subject or an appended footer breaks the DKIM signature, and the list relays from its own servers, which fail SPF alignment for your domain. Some lists work around this by rewriting the `From:` header to their own domain; ARC exists to let a receiver trust an intermediary's own assessment, and is honoured unevenly.

## Related

- [SPF](https://connectbyjbrh.com/docs/technology/spf/)
- [DKIM](https://connectbyjbrh.com/docs/technology/dkim/)
- [Email deliverability](https://connectbyjbrh.com/docs/technology/deliverability/)
- [BIMI](https://connectbyjbrh.com/docs/technology/bimi/)
- [Email in Connect](https://connectbyjbrh.com/docs/email/)

## What this page is based on

- RFC 7489 — Domain-based Message Authentication, Reporting and Conformance (https://www.rfc-editor.org/rfc/rfc7489)
- Source pack: email — `docs-source/sources/CHANNELS.md` §1 (sending, evidence and compliance)
- Connect capability registry (`docs-source/facts.py`)