Set up DMARC with a sender inventory and a working report destination

Define the decision

DMARC is a domain-owner policy, not an application login setting. The current specification is RFC 9989, published in 2026; older tutorials may describe legacy controls. Keep rollout decisions tied to observed legitimate traffic.

Work through the procedure

1. List every service using the visible From domain, including billing and support.
2. Inspect fresh messages to identify an aligned passing authentication path.
3. Arrange a monitored aggregate-report destination before publishing a monitoring policy.
4. Query the exact _dmarc name and review representative reporting periods before proposing enforcement.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Illustrative monitoring record, replace the destination before use:
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
Review queue: known sender, unknown sender, forwarding case
Enforcement gate: legitimate failures understood and corrected

Read the result

A monitoring record provides information for decisions; it does not request rejection of failing mail. Reports can contain legitimate infrastructure you forgot to include, so assign an owner rather than allowing them to accumulate unread.

Check before moving on

1. Verify that the reporting mailbox or processor receives reports.
2. Keep unrelated legitimate streams in the rollout review.

Limits and next action

Receiver implementations can differ during standards transitions. Do not use a legacy pct value as a guaranteed partial-enforcement switch; validate the intended policy behavior before expanding it.

Source: RFC 9989: current DMARC specification