DMARC sits on top of SPF and DKIM. It asks whether the domain visible to the recipient in the From header is aligned with a domain that passed SPF or DKIM, then lets the domain owner publish a policy for messages that fail. The safest first DMARC project is therefore an inventory project. If you jump directly to `p=reject` while forgotten systems are still sending unauthenticated mail, you can block your own receipts, alerts, or marketing campaigns.

Start with a syntactically small monitoring record

A basic monitoring record can look like:

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

`v=DMARC1` identifies the protocol. `p=none` requests monitoring rather than quarantine or rejection. `rua=` tells receivers where aggregate XML reports may be sent.

Use a mailbox or reporting service that can actually process DMARC aggregate data. Raw XML is not friendly to read at scale, but it contains useful fields: source IP, message counts, SPF and DKIM outcomes, and the domains involved. If an external reporting provider receives reports on behalf of your domain, follow that provider’s authorization instructions.

Read reports as a sender-discovery tool

In the first review, group traffic by source IP or recognized provider. Mark each source as: 1. legitimate and aligned; 2. legitimate but failing or misaligned; 3. unknown and needing investigation; 4. clearly unauthorized.

A payroll platform or CRM that appears as “failing” is not something to reject until you understand why it fails. Determine whether it can DKIM-sign with your domain, use an aligned custom return path for SPF, or both.

DMARC can pass when either aligned SPF or aligned DKIM passes. You do not need both mechanisms to align for every message, though maintaining both correctly provides resilience and is required by some bulk-sender policies.

Alignment is the part most dashboards oversimplify

Suppose the visible address is `sales@example.com`. A marketing vendor sends using an envelope-from at `bounce.vendor.example` and signs with `vendor.example`. SPF and DKIM may both pass, but neither authenticated domain belongs to `example.com`; DMARC can fail.

Now suppose the vendor signs with `email.example.com`. Under relaxed DKIM alignment, that organizational relationship can align with the visible `example.com` From domain. Strict alignment is more exact. Most small businesses start with the default relaxed alignment unless they have a clear security reason to require stricter matching.

The same concept applies to SPF through its authenticated mail-from domain. A third-party vendor that supports a custom return-path subdomain can often make SPF alignment possible.

Move from observation to enforcement in stages

Google’s Workspace guidance recommends a gradual DMARC rollout. After you have enough report history to identify normal senders and you have fixed legitimate failures, consider `p=quarantine` for failing mail. Monitor what changes before moving to `p=reject`.

You can also use `pct=` during a staged rollout, but understand what your receivers support and do not use percentages to avoid fixing a known legitimate sender. The strongest final policy is the one your infrastructure can sustain without exceptions hidden in someone’s inbox.

Before each policy change, send production tests from every critical system and confirm alignment at several major mailbox providers. Save the headers.

What a weekly DMARC review should answer

The review does not need to become a security department. Answer four questions: Did any new sender appear? Did an established sender’s pass rate change? Is unauthorized traffic being observed? Are the remaining failures understood well enough to tighten policy?

Watch for infrastructure changes. Marketing platforms rotate IPs; businesses switch help desks; finance teams add invoice tools. The goal is not to memorize IP addresses forever but to maintain ownership of every authorized sending path.

DMARC does not solve consent or reputation

A fully aligned message can still be spam. DMARC helps receivers trust the domain identity and gives domain owners control over unauthenticated use of their domain; it does not prove that recipients asked for the message. Keep list quality, unsubscribe handling, and reputation monitoring as separate operating controls.

For a small business, the clean endpoint is a policy that rejects unauthenticated impersonation while every legitimate sender has a documented, tested aligned path. Starting at `p=none` lets you reach that endpoint without discovering your forgotten systems through customer complaints.

Expect forwarding to stress SPF before DKIM

Forwarding explains why a domain should not treat SPF and DKIM as interchangeable. SPF evaluates the server delivering the message against the envelope identity; a simple forward can change the connecting server and cause the original SPF path to fail. A valid DKIM signature can survive forwarding when the signed content is not modified, giving DMARC an aligned authentication path even when SPF no longer aligns.

Forwarders can also modify subjects, footers, or message bodies and break DKIM. That is why a DMARC report may show a legitimate stream with different SPF/DKIM outcomes depending on how recipients received it.

When reviewing aggregate reports, look for this pattern before declaring a source unauthorized. DMARC needs an aligned pass from SPF or DKIM, not both. Build legitimate mail so both mechanisms are configured correctly where practical, then use the reports to identify which path actually survives real delivery.