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.

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.

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

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#

Related#

• SPF
• DKIM
• Email deliverability
• BIMI
• Email in Connect