What Is DMARC? How It Works and How to Set It Up

What is DMARC?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is published as a DNS TXT record at _dmarc.yourdomain.com. The record lets a domain owner request how participating receivers handle messages that fail DMARC and identify addresses that may receive reports.

DMARC is not a spam filter and does not prove that every passing message is safe. Its job is narrower: it checks whether authenticated email identifiers align with the domain shown to the recipient. That makes direct domain spoofing harder and gives domain owners visibility into systems sending on their behalf.

The current standards are RFC 9989 for the DMARC core, RFC 9990 for aggregate reporting, and RFC 9991 for failure reporting. They replace the older RFC 7489-era guidance.

What does a DMARC record look like?

A basic monitoring record can look like this:

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

This record declares the DMARC version, asks receivers to monitor rather than enforce a failing result, and provides an address for aggregate reports. Publish the value as a TXT record under the _dmarc label in your DNS provider.

An enforcement record might use p=reject after the owner has reviewed reports, found every legitimate sender, and corrected alignment problems. Policy values are requests to receiving systems, not guaranteed actions. Receivers still apply their own local rules.

Older guides may show the pct tag. It is not part of RFC 9989. The current specification uses the t tag for testing semantics, so do not copy percentage-based rollout examples into a new record.

How does DMARC work?

A receiver evaluates SPF and DKIM, identifies the domain visible in the RFC5322.From header, and checks alignment. DMARC passes if at least one authenticated identifier aligns with that visible From domain. If neither aligned SPF nor aligned DKIM passes, the receiver applies the published policy as one input to its handling decision.

Sender Policy Framework (SPF)

SPF checks whether the sending infrastructure is authorized for the domain used in the SMTP MAIL FROM, often displayed as the Return-Path. An SPF pass alone is not enough for DMARC: the authenticated SPF domain must also align with the visible From domain.

SPF can break during ordinary forwarding because the forwarding server may not be authorized by the original MAIL FROM domain. This is why well-configured senders usually rely on both SPF and DKIM rather than treating one method as a universal fallback.

DomainKeys Identified Mail (DKIM)

DKIM adds a cryptographic signature to a message. The receiver retrieves the public key from DNS and uses it to verify the signature and selected message content. The public key belongs in DNS; the private signing key must remain secure on the sender or email provider.

For DMARC, the DKIM signing domain in the d= value must align with the visible From domain. A valid signature from an unrelated provider domain can pass DKIM while still failing DMARC alignment.

Identifier alignment

Alignment connects authentication with the identity the recipient sees. Under relaxed alignment, the authenticated domain and visible From domain may be different subdomains of the same organizational domain. Strict alignment requires an exact domain match. Relaxed mode is the default and is usually easier to operate across legitimate services.

• Aligned SPF passes: DMARC passes even if DKIM fails.
• Aligned DKIM passes: DMARC passes even if SPF fails.
• Neither aligns: DMARC fails and the published policy becomes relevant.

Why use DMARC for email marketing?

Marketing programs often use several senders: an email service provider, customer-support software, billing systems, survey tools, and internal mail. DMARC reporting helps expose this inventory and shows which sources authenticate correctly.

• Reduce direct spoofing. Enforcement can make it harder to send unauthenticated mail that visibly impersonates your domain.
• Find legitimate and unknown senders. Aggregate reports show source IPs, message volumes, authentication results, and policy evaluation data.
• Support provider requirements. Major mailbox providers require authentication and DMARC for many high-volume senders. Review the current Google email sender guidelines before scaling sends.
• Create a consistent sending practice. Sender inventory, aligned domains, and monitored reports make new tools easier to onboard safely.

DMARC can support deliverability by improving authentication discipline, but it does not guarantee inbox placement. Reputation, recipient engagement, complaints, list quality, content, and receiver-specific filtering still matter.

DMARC setup process step-by-step

1. Inventory every authorized sender

List every service that sends with your domain in the visible From address: employee mail, newsletters, transactional platforms, help desks, ecommerce tools, CRM systems, invoices, alerts, and any vendor that sends on your behalf. Include low-volume and seasonal systems.

2. Confirm SPF and enable DKIM

Check that each legitimate source has a valid authentication path. Keep the SPF record within the protocol’s DNS-lookup limits, avoid duplicate SPF records, and enable DKIM with an aligned signing domain wherever the provider supports it. Use each provider’s current setup instructions rather than copying generic DNS values.

If you send with Selzy, follow the domain authentication instructions in your account.

3. Publish a monitoring record

Start with a record such as v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;. Use a dedicated mailbox or a trusted report-processing service because aggregate XML files are difficult to review manually at scale. Confirm that the reporting address can receive the expected volume.

DNS changes may take time to propagate according to the record’s TTL, but there is no universal 48-hour prerequisite. Validate the published TXT record directly and check that only one DMARC record is returned for the policy domain.

4. Review aggregate and failure reports

Participating receiving systems generate aggregate reports, usually as XML. They summarize source IPs, message counts, SPF and DKIM results, alignment, and policy evaluation. Reports come from receivers, not from your own sending provider.

Failure reports are optional and much less common. They may contain message-level or sensitive information, so consider privacy, retention, and access controls before requesting them with ruf. Do not depend on failure reports as the primary monitoring source.

5. Fix legitimate sources and move to enforcement

Review a representative reporting period, correct every authorized sender that fails alignment, and investigate unknown sources. When legitimate traffic is consistently aligned, move deliberately to p=quarantine or p=reject. Continue monitoring after enforcement because vendors, selectors, IPs, and sending routes can change.

A long-term p=none record provides visibility but does not request protection against failing mail. Conversely, moving directly to rejection without a sender inventory can block legitimate messages. Deployment quality—not a fixed waiting period—should determine the pace.

6. Perform troubleshooting

• Inspect the Authentication-Results header for SPF, DKIM, and DMARC outcomes.
• Compare the visible From domain with the SPF MAIL FROM domain and DKIM d= domain.
• Confirm the source IP belongs to an authorized system.
• Check DKIM selector DNS records and whether the provider is signing with the expected domain.
• Look for forwarding, mailing-list modifications, or third-party services that changed the authentication path.
• Verify policy discovery for organizational domains, subdomains, and non-existent subdomains.
• Recheck DNS syntax, duplicate records, report addresses, and recent provider changes.

Wrapping up

DMARC works by requiring alignment between the domain recipients see and a domain authenticated by SPF or DKIM. Publish a monitoring record, use aggregate reports to discover every sender, repair legitimate authentication, and move to enforcement when the data supports it. Keep the public DKIM key in DNS, protect the private key, and remember that one aligned authentication method is enough for DMARC to pass.

Treat DMARC as an ongoing operational control. Review reports after adding vendors or changing infrastructure, keep sender ownership documented, and investigate unexpected sources. The result is stronger protection against direct domain spoofing and a clearer view of how your domain is used.