A domain can have working email and still be vulnerable to impersonation. Attackers may place its name in the visible From address, hoping recipients will trust a message that did not come from an approved system. DMARC gives domain owners a way to connect SPF and DKIM authentication to that visible identity, request reports, and tell participating receivers how to handle messages that fail.

A safe DMARC setup is a process rather than a single aggressive DNS change. The reliable approach is to inventory every legitimate sender, make SPF or DKIM align correctly, begin with a monitoring policy, study the reports, fix gaps, and then move gradually toward quarantine or rejection.

What DMARC does

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. A receiving mail system evaluates SPF and DKIM results, checks whether the authenticated domain aligns with the domain shown in the message’s From header, and applies the published DMARC policy.

A message can pass DMARC when at least one of these paths succeeds:

• SPF passes and its authenticated MailFrom domain aligns with the visible From domain.
• DKIM passes and the domain in a valid DKIM signature aligns with the visible From domain.

Requiring alignment is important. SPF alone authenticates the envelope sender used during delivery, which may differ from the address a person sees. DKIM authenticates the signing domain, which also may be different. DMARC connects a successful authentication result to the visible identity. For a broader overview of the mechanism and its anti-phishing purpose, see this guide to DMARC.

Prepare SPF and DKIM first

Confirm every legitimate sending source

Create an inventory of systems that send mail using the domain: primary mail providers, marketing platforms, support desks, transaction services, billing tools, monitoring systems, website forms, and any service that sends on behalf of a subdomain. An incomplete inventory is the most common reason legitimate mail begins failing when enforcement increases.

Check SPF authorization and alignment

SPF lists which systems may send for an envelope domain. Make sure each legitimate source is covered without creating multiple SPF records or exceeding the protocol’s DNS-lookup limits. The existing article on how the SPF record works explains the authorization side in more detail.

For DMARC, an SPF pass is useful only when the authenticated MailFrom domain aligns with the visible From domain. Under relaxed alignment, the domains may share the same organizational domain. Strict alignment requires an exact match. A third-party platform may therefore pass its own SPF check but still fail the SPF path for your DMARC policy unless it supports a custom aligned return-path domain.

Enable DKIM signing with an aligned domain

DKIM adds a cryptographic signature to the message. The receiver retrieves the public key from DNS and verifies that signed parts of the message were not altered. Review the DKIM record guide if you need a refresher on selectors and public keys.

For DMARC alignment, the domain in the DKIM signature’s d= value must align with the visible From domain. Many email platforms support custom DKIM signing for this reason. DKIM often survives forwarding better than SPF, although mailing-list modifications can invalidate a signature if they change signed content.

Create the DMARC TXT record

Publish DMARC as a TXT record at _dmarc.example.com, replacing example.com with the domain used in the visible From address. A sensible monitoring record can look like this:

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

The essential tags are straightforward:

• v=DMARC1 identifies the protocol version and must appear first.
• p=none requests monitoring without asking receivers to quarantine or reject failures.
• rua provides one or more addresses for aggregate reports.
• pct specifies the percentage of applicable messages subject to the requested policy; 100 is the default.

Use a real, monitored mailbox or a suitable report-processing service for aggregate reports. Reports are typically XML files and may arrive in volume. Confirm that the receiving mailbox can handle the traffic and treat report data according to the organization’s privacy and retention requirements.

Understand policy and alignment options

Policy levels

• p=none: Request reporting and normal receiver handling. Use it to discover legitimate senders and authentication gaps.
• p=quarantine: Ask receivers to treat failing messages as suspicious, often by placing them in spam or applying extra scrutiny.
• p=reject: Ask receivers to reject messages that fail DMARC evaluation.

These are requested policies, and final message handling remains with the receiver. Moving directly to p=reject can block legitimate traffic if a forgotten service lacks alignment.

Relaxed and strict alignment

The aspf and adkim tags control SPF and DKIM alignment. Relaxed mode, represented by r, is the default and permits aligned subdomains within the same organizational domain. Strict mode, represented by s, requires the domains to match exactly. Strict alignment is not inherently necessary for every domain; use it only when sending architecture and policy require the tighter match.

Subdomain policy

The sp tag can define a separate requested policy for subdomains. Before setting it, identify subdomains that send mail and those used only for websites or services. A domain that should never send mail can often use stronger controls, but verify that no operational tool depends on it first.

Read aggregate reports before enforcing

Aggregate reports summarize how participating receivers see mail claiming to use the domain. They commonly show source IP addresses, message counts, SPF and DKIM results, alignment outcomes, and the policy applied. They do not automatically tell you whether a source is legitimate; administrators must map sources to known services and investigate unfamiliar traffic.

Use the monitoring period to answer practical questions:

• Which approved platforms send mail for the domain?
• Does each source pass aligned SPF, aligned DKIM, or both?
• Are forwarding and mailing-list flows producing expected failures?
• Do unknown sources indicate spoofing, stale systems, or an incomplete inventory?
• Are high-volume failures concentrated in one provider or subdomain?

Move to enforcement gradually

1. Start with p=none. Collect enough representative reports to cover normal campaigns, billing cycles, and infrequent systems.
2. Fix legitimate senders. Configure aligned DKIM or a custom return path, remove obsolete sources, and correct DNS records.
3. Test quarantine. Move to p=quarantine after known sources pass consistently. Continue checking reports and support feedback.
4. Increase coverage deliberately. If using pct during rollout, increase it only after reviewing the affected traffic and understanding receiver behavior.
5. Adopt reject when ready. Use p=reject when legitimate sources are aligned, exceptions are documented, and monitoring is ongoing.

DMARC does not replace correct mail routing. MX records still identify where inbound mail should be delivered, while DMARC evaluates messages that claim to come from a domain. The article MX record: Why is it important? explains that separate role.

Verify and maintain the deployment

After publishing the TXT record, query the exact _dmarc name from multiple resolvers and confirm that only one syntactically valid DMARC record is returned. Send controlled tests through every approved platform, inspect authentication results in message headers, and verify that aggregate reports begin arriving.

Continue reviewing reports after enforcement. Vendors, sending IPs, return-path domains, and DKIM selectors change over time. Add DMARC review to the onboarding and removal process for every email service, protect access to DNS and mail-provider accounts, and rotate DKIM keys according to provider capabilities and policy.

The protocol’s discovery, alignment, policy, and reporting model is defined in RFC 7489: Domain-based Message Authentication, Reporting, and Conformance.

Conclusion

A successful DMARC setup begins with visibility. Inventory legitimate senders, establish aligned SPF or DKIM, publish a monitoring record, analyze aggregate reports, and correct failures before enforcement. Gradual movement from none to quarantine and then reject protects legitimate mail while making domain impersonation harder and giving administrators useful feedback about abuse.