DMARC

SendSignal handles SPF and DKIM; DMARC is a policy you publish on your domain. Start with monitoring and tighten from there:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

When reports show all your legitimate mail authenticating, move to p=quarantine and then p=reject. Our DMARC checker explains every tag of your current policy.

Generating the record

POST /domains/{id}/dmarc regenerates the domain’s recommended _dmarc TXT record:

curl https://api.sendsignal.dev/domains/{id}/dmarc \
  -H "Authorization: Bearer ss_..." -H "Content-Type: application/json" \
  -d '{"policy": "quarantine"}'

• policy: none, quarantine, or reject. Note that none prevents BIMI, which requires enforcement.
• rua: optional bare email address for aggregate reports. If you point it at a different organizational domain, that domain must publish an external-destination-verification record or receivers discard the reports.

Every verify refreshes the record’s status from live DNS (verified, published_differs, invalid (multiple DMARC records), or pending) along with the domain’s effective policy, discovered per RFC 7489 (exact domain first, then the organizational domain). DMARC never gates domain verification.

Hosted aggregate reports

Omit rua and the recommended record can use a SendSignal-hosted report address instead: external-destination verification is handled for you, and incoming reports feed a built-in summary:

curl "https://api.sendsignal.dev/domains/{id}/dmarc/reports?days=7" \
  -H "Authorization: Bearer ss_..."

The response aggregates a trailing window (1–90 days, default 7): totals (total, aligned, via_sendsignal, report_count), reporting organizations, and top sending sources, each source classified by whether it passed DMARC and whether it’s attributed to your SendSignal sending. Reports typically start arriving within a day of publishing the record.