DMARC record setup lets a domain owner tell receiving mail systems what to do when an email claiming to be from that domain fails authentication. Done carefully, it reduces direct-domain spoofing without blocking your own marketing, support, invoicing, or transactional mail.

What a DMARC record does—and what it does not do

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is a DNS-based email authentication policy that builds on two older mechanisms: SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail).

A receiving mail server evaluates a message’s visible From: domain, then checks whether SPF and/or DKIM passed and aligned with that visible domain. If neither aligned authentication mechanism passes, the receiver can apply the action requested in your DMARC record: do nothing special (none), place the message in spam or quarantine (quarantine), or refuse it (reject).

The key point is that DMARC protects the domain users see in the message header. An attacker may still send mail from a lookalike domain such as yourbrand-support.example or a different display name. DMARC does not stop those attacks on its own, nor does it encrypt email, scan attachments, or guarantee inbox placement. It makes impersonation of your exact domain substantially harder at participating receivers.

DMARC also gives domain owners aggregate reports. These reports show which IP addresses and sending services claimed to send mail for the domain, whether SPF and DKIM passed, and whether alignment succeeded. That visibility is why a cautious rollout begins with monitoring rather than immediately publishing a reject policy.

The three authentication checks you must understand

A successful dmarc record setup depends on the relationship among the visible From: address, the SMTP envelope sender used for SPF, and the DKIM signing domain. These are often different fields, especially when a third-party platform sends mail on your behalf.

SPF checks the envelope sender, not the visible From address

SPF is published as a TXT record at a domain and authorizes servers that can use that domain in the SMTP MAIL FROM command, also called the return-path or envelope-from domain. A simplified SPF record can look like this:

example.com. TXT "v=spf1 include:_spf.google.com -all"

This says that the systems authorized by Google’s published SPF record may send mail using an envelope sender at example.com; all other senders fail. The exact include value depends on your provider. Do not copy the Google example for Microsoft 365, Amazon SES, HubSpot, SendGrid, or another service unless that service’s documentation explicitly tells you to use it.

SPF passes when the connecting sending IP address is authorized by the relevant SPF record. For DMARC, that passing SPF domain must also align with the visible From: domain. If a newsletter tool sends with Return-Path: bounce.vendor-mail.example but your visible From address is news@example.com, SPF may pass for the vendor domain and still not count for DMARC.

DKIM signs part of the message and names a signing domain

DKIM attaches a cryptographic signature in a DKIM-Signature header. The header has a d= value that identifies the signing domain and an s= selector. A receiver retrieves the public key from DNS at a name similar to:

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=...public-key..."

The sender retains the private key. You should never place a DKIM private key in DNS or paste it into a ticket, document, or chat.

For DMARC, a DKIM signature must pass cryptographic validation and the d= domain must align with the visible From domain. A service may sign a message with its own domain by default; configure a custom sending domain or domain authentication feature so it signs with example.com or a valid subdomain such as mail.example.com.

Alignment is the requirement that surprises most teams

DMARC passes when either SPF passes and aligns or DKIM passes and aligns. You do not need both mechanisms to align for every message, although operating both is the resilient choice.

Under the default relaxed alignment mode, a subdomain can align with an organizational domain. For example, a visible From domain of example.com can align with a passing DKIM d=mail.example.com. Under strict alignment, domains must match exactly.

The practical consequences are important:

A message can have spf=pass and dkim=pass in a mailbox interface yet still show dmarc=fail because both passing domains belong to a vendor, not your domain.
A forwarding service can break SPF because the final receiving server sees the forwarder’s IP address. A surviving aligned DKIM signature can still allow DMARC to pass.
An email platform that signs mail with an aligned DKIM domain generally gives you a more durable DMARC path than relying only on SPF.
Changing the display name, such as Example Support <billing@somewhere-else.example>, does not create DMARC alignment. The domain in the RFC 5322 From: header is what matters.

Inventory every legitimate sender before you publish policy

The most common DMARC deployment failure is not invalid DNS syntax. It is forgetting a system that sends mail as the domain. A strict policy can then cause legitimate email to be quarantined or rejected.

Create a sender inventory before changing DMARC. Ask owners in marketing, sales, support, finance, product, IT, HR, and engineering—not only the mail administrator. Review SaaS billing records, DNS records, application configuration, website forms, and past campaign headers. Aggregate reports collected during monitoring will find additional senders, but an initial inventory makes those reports much easier to interpret.

Include at least these categories:

Primary employee mail, such as Google Workspace, Microsoft 365, or a self-hosted mail system.
Transactional mail from applications, including password resets, receipts, alerts, and webhook notifications.
Marketing automation, newsletters, CRM campaigns, event tools, and survey platforms.
Customer support, help desk, live chat, and ticketing systems.
Billing, e-signature, recruiting, payroll, project management, and status-page products.
Printers, scanners, servers, network devices, and legacy business applications that relay mail directly.
Agencies or other partners permitted to send mail using the domain.

For each service, record the visible From domain, envelope-from/return-path domain, DKIM d= domain, how the service is authenticated, its account owner, and a sample message header. Add whether it needs a branded tracking or bounce domain. This document becomes both your DMARC migration checklist and an ongoing change-control record.

Do not solve a discovery problem by adding every vendor you recognize to SPF. SPF has a limit of 10 DNS-interactive lookups during evaluation. Nested include, redirect, a, mx, exists, and ptr mechanisms can contribute to that total. Exceeding the limit causes an SPF permanent error, often called permerror. More importantly, an SPF include alone does not ensure DMARC alignment.

DMARC record syntax explained tag by tag

A DMARC policy is a TXT record at _dmarc beneath the domain being protected. For example.com, the DNS host/name is:

_dmarc.example.com

Some DNS control panels automatically append your zone name. In a zone for example.com, entering _dmarc.example.com in a field that expects only the host can accidentally create _dmarc.example.com.example.com. Read the provider’s field hint and verify the published name after saving.

Here is a conservative monitoring record:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

DMARC tags are separated by semicolons. Whitespace is generally tolerated, but use a simple one-line value to avoid copy-and-paste errors. The v=DMARC1 tag must appear first.

Core policy tags

v=DMARC1 identifies the record as DMARC. A valid record has one version tag, and it must be first.

p= defines the requested disposition for mail that fails DMARC:

p=none asks receivers to take no DMARC-specific enforcement action. It is used for monitoring.
p=quarantine asks receivers to treat failing messages as suspicious, commonly placing them in spam or junk. Receiver behavior is not identical everywhere.
p=reject asks receivers to reject failing messages during SMTP delivery.

rua= supplies one or more destinations for aggregate reports. The value uses a mailto: URI, for example rua=mailto:dmarc-reports@example.com. Reports are XML files, frequently compressed, and can become numerous for domains with meaningful traffic. Use a dedicated mailbox or, more commonly, a DMARC reporting service rather than a person’s normal inbox.

adkim= controls DKIM alignment: r means relaxed and s means strict. aspf= does the same for SPF. Relaxed is the default if these tags are absent. Begin with relaxed alignment unless you have a documented reason and verified sender configuration for strict alignment.

pct= specifies the percentage of messages to which the requested policy should be applied. pct=100 is the default. It can be useful during a staged move from p=none to enforcement, but it is not a substitute for fixing unknown senders. Also, the DMARC specification notes that receivers may apply local policy, so treat pct as a request, not a mathematically guaranteed traffic split.

Useful but optional tags

sp= provides a policy for subdomains. If it is absent, subdomains inherit the parent domain’s p policy, subject to DMARC’s organizational-domain discovery process. Example:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@example.com

This rejects failing mail from example.com while asking for quarantine for failing mail from subdomains that do not publish their own DMARC record. Set sp deliberately if your organization sends mail from subdomains or delegates them to teams and vendors.

ruf= is intended for forensic or failure reports. In practice, support for these reports is limited, and the reports can expose message-level information. Aggregate rua reporting is the normal starting point. Avoid relying on ruf for operational visibility.

fo= requests conditions for generating failure reports, but it has the same practical limitations as ruf. It does not change DMARC pass/fail logic.

ri= asks for an aggregate report interval in seconds. The default specified interval is 86,400 seconds. Receivers can choose their own reporting cadence, so do not treat ri=3600 as a promise of hourly reports.

rf= identifies a requested report format. XML is the defined aggregate report format; in day-to-day deployments, you usually do not need this tag.

Avoid adding obsolete or nonstandard tags copied from blog posts. Unknown tags should be ignored by receivers, but they make audits harder and can conceal a typo in a tag that matters.

A worked DMARC record setup example

Assume a fictional company, Northstar Studio, owns northstarstudio.com. It uses Microsoft 365 for employee mail, a transactional-email provider for receipts, and a marketing platform for newsletters. All three systems use visible From addresses ending in @northstarstudio.com.

The company should not start by publishing p=reject. First, it configures each sender according to that provider’s domain-authentication instructions:

Microsoft 365 has its required SPF configuration and DKIM enabled for northstarstudio.com.
The transactional provider is configured to DKIM-sign with d=mail.northstarstudio.com, not merely with the provider’s own domain.
The marketing platform is configured with a branded sending domain such as news.northstarstudio.com and DKIM signing that aligns with it or with the parent domain under relaxed alignment.

Northstar then creates a mailbox or reporting-service address solely for aggregate reports. Its initial DNS record is:

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@northstarstudio.com; adkim=r; aspf=r; pct=100
TTL: 3600

The TTL is an example, not a DMARC requirement. DNS providers may use a different default or restrict available TTL values. A lower temporary TTL can make correction faster while deploying; a stable, ordinary TTL is fine after validation.

After publishing, Northstar sends test messages from each platform to test inboxes at different receiving providers. It examines the full headers. A desired result might resemble:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=mail.northstarstudio.com;
  dkim=pass header.d=mail.northstarstudio.com;
  dmarc=pass header.from=northstarstudio.com

The exact header formatting differs by receiver. The important observation is dmarc=pass and a passing, aligned SPF or DKIM identity. If the marketing platform instead shows dkim=pass header.d=vendor.example and spf=pass smtp.mailfrom=vendor.example, it has not been fully authenticated for Northstar’s domain even though both individual checks passed.

Northstar reviews aggregate reports over enough normal business cycles to capture recurring sends: monthly invoices, campaign days, automated notices, and less frequent administrative systems. When all known legitimate sources pass DMARC and unexplained sources are investigated, it can move to enforcement:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@northstarstudio.com; adkim=r; aspf=r; pct=100

After continuing to see legitimate mail pass, its final policy can be:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@northstarstudio.com; adkim=r; aspf=r; pct=100

This progression is a process, not a calendar schedule. A small domain with one well-controlled sender may validate quickly; a large organization with multiple subsidiaries and agencies may need a longer monitoring period.

How to publish the record in DNS without breaking it

Open the authoritative DNS provider for the domain, which may be different from your domain registrar. Create a single TXT record at _dmarc for the domain. Do not create multiple DMARC TXT records at the same name; DMARC requires a single valid policy record, and multiple records can cause receivers to treat DMARC processing as a permanent error.

A practical publication checklist is:

Confirm that SPF and DKIM are already configured for each known sender.
Copy the initial DMARC value as plain text, preserving semicolons and the mailto: prefix.
Add it as a TXT record at _dmarc, not at the root @ and not at _domainkey.
Save the record and wait for DNS propagation according to the published TTL and provider behavior.
Query public DNS to confirm the hostname and value are exactly what you intended.
Send real test messages from every sending system and inspect authentication results.
Monitor aggregate reports before increasing enforcement.

You can query DNS from a terminal with:

dig +short TXT _dmarc.example.com

On Windows, a comparable command is:

nslookup -type=TXT _dmarc.example.com

Online DMARC lookup tools can also validate syntax and show the discovered policy. They are useful for a quick check, but do not upload sensitive raw email, DKIM private material, or credentials to an untrusted site.

DNS interfaces sometimes split long TXT content into quoted chunks. That can be normal at the DNS protocol level; resolvers concatenate TXT character-strings for evaluation. What matters is the final logical record value, not whether a dashboard visually wraps it. Conversely, do not add literal quotation marks inside the value unless your DNS provider’s interface specifically requires them.

Reading reports and verifying that DMARC works

DMARC aggregate reports are not polished dashboards. They are XML data sent by participating receivers, usually with counts grouped by source IP, policy outcome, and authentication result. A reporting platform can parse and visualize them, but you should still understand the underlying questions.

For every high-volume source, ask:

Which organization or service owns this sending IP or sending domain?
Is the visible From domain one you expect?
Did SPF pass, and what envelope-from domain was evaluated?
Did DKIM pass, and what d= domain signed the mail?
Did at least one passing identifier align with the From domain?
How many messages were affected, and was the volume expected?
Did the receiver apply a disposition that differs from your requested policy?

A record with p=none can still yield dmarc=fail in receiver headers and aggregate reports. That is expected: monitoring changes the requested treatment, not the underlying authentication result. The objective of monitoring is to drive the number of legitimate DMARC failures toward zero before enforcement.

Test messages should include more than a single manual email. Trigger an actual password-reset message, submit a website form, issue a test invoice if your platform supports it, open a support ticket, and send a campaign to a controlled test segment. These flows often use different infrastructure and different From identities.

Mailbox providers expose headers differently. In Gmail, use the message menu and choose “Show original.” In Outlook clients and Outlook on the web, the precise path varies by product and deployment, but the message headers/source option exposes Authentication-Results. Your email security gateway may also provide a trace view with SPF, DKIM, and DMARC outcomes.

Common DMARC setup failures and precise fixes

SPF passes but DMARC fails

This usually means the SPF-authorized envelope sender does not align with the visible From domain. For example, From: offers@example.com might use bounce@mailer.vendor.example as the return path.

Fix it by configuring the provider’s custom return-path, branded bounce domain, or domain-authentication feature if available. More reliably, enable aligned DKIM. Do not assume adding the vendor to example.com SPF alone resolves alignment.

DKIM passes but DMARC fails

Check the DKIM d= domain in the message header. If it is a vendor-owned domain, the signature is valid but unaligned.

Configure the provider’s custom DKIM records and verify that new messages show a signing domain aligned with the From domain. Some vendors require you to add multiple CNAME records rather than a raw TXT public key; follow the vendor’s exact DNS instructions because selector names and record types are provider-specific.

There are multiple DMARC records

This can happen when separate teams each add a TXT record at _dmarc. Consolidate all intended tags into one valid record. Unlike SPF, where multiple records are also a problem, DMARC does not merge independent policy records.

The report address is external

If example.com uses rua=mailto:reports@reportingvendor.example, DMARC requires an external-destination authorization record at the report destination domain. The pattern is:

example.com._report._dmarc.reportingvendor.example. TXT "v=DMARC1"

Many DMARC reporting providers publish and manage this authorization themselves or instruct you how to do it. The exact domain names must match the policy domain and report destination. Without authorization, receivers may decline to send reports to that external address.

SPF exceeds the DNS lookup limit

Do not keep appending include: mechanisms. Review the SPF tree with an SPF analysis tool, remove retired services, and use a provider-supported consolidation method where appropriate. A dedicated subdomain for a particular sender can simplify operations, but it does not magically fix mail sent with the parent domain in the visible From header; alignment still matters.

Forwarded mail fails after enforcement

Forwarding can invalidate SPF. Check whether an aligned DKIM signature survives. If it does not, investigate whether an intermediary modifies signed content, whether DKIM signing is absent, or whether the selected signature algorithm/configuration is unsupported. Do not weaken your domain-wide policy solely on a theory; first identify which forwarding paths affect real, legitimate traffic and whether aligned DKIM can solve the issue.

A subdomain unexpectedly inherits reject

If alerts.example.com has no dedicated DMARC record, it may inherit the organizational domain’s policy. Publish a subdomain DMARC record when that subdomain has different sending requirements, or use the parent sp= tag intentionally. Treat delegated subdomains as separate sending identities during your inventory.

Choosing p=none, quarantine, or reject

The correct end state for a domain that does not intentionally permit unauthenticated mail is generally a fully enforced policy. p=reject is the clearest signal to receivers that mail failing DMARC should not be accepted as authentic mail from the domain.

p=none is valuable during discovery, but it does not provide enforcement against direct spoofing. Leaving it indefinitely means you receive intelligence while asking receivers not to apply your DMARC policy to failures. Some receivers may use their own anti-abuse controls anyway, but that is not equivalent to a domain owner requesting quarantine or rejection.

p=quarantine is often an intermediate operational stage. It helps expose unforeseen issues in a lower-impact way than rejection, but users can still see and interact with spoofed mail in spam folders. Organizations with a well-understood sender inventory sometimes move directly from monitoring to reject after validation; organizations with complex ecosystems may use quarantine first.

Strict alignment (adkim=s; aspf=s) is a separate decision from policy enforcement. It can provide tighter identity matching but may break legitimate systems that use aligned subdomains under relaxed mode. Do not switch it on simply because a template includes it. Use it only after examining real header data and confirming every intended sender can meet exact-domain alignment.

Operational practices that keep DMARC healthy

DMARC is not a one-time DNS task. New SaaS tools, acquisitions, agencies, product launches, and changes in mail routing can create failures months after an apparently successful deployment.

Make DMARC part of vendor onboarding. Before a team is allowed to send as your domain, require an answer to these questions: Can the platform DKIM-sign with our domain or approved subdomain? What DNS records are required? What return-path domain does it use? Can it send with a separate subdomain? Who owns the account and renewal? How will it be removed when the service is retired?

Use subdomains to separate mail streams where it improves control. For example, employee mail can remain at example.com, marketing can use news.example.com, and transactional mail can use mail.example.com. This can make reputation, diagnostics, and vendor transitions easier. It also requires clear DMARC policy and DNS ownership for each subdomain.

Keep an eye on SPF and DKIM during every sending-platform change. SPF is an allowlist with lookup constraints; DKIM involves selectors, public keys, and key rotation. A DMARC policy is only as reliable as the authentication below it. If a provider changes its sending configuration, re-run header tests before sending production traffic.

Finally, distinguish reporting volume from risk. A single source IP with a large count may be your primary provider; a small, unfamiliar source could be a legitimate forgotten application or attempted abuse. Investigate based on identity, alignment, message purpose, and volume—not just on whether a row is red in a dashboard.

DMARC record setup checklist

Before declaring a deployment complete, verify all of the following:

One valid TXT record exists at _dmarc.yourdomain.
The record begins with v=DMARC1 and contains the intended p= policy.
A dedicated, monitored rua destination is receiving and parsing aggregate reports.
Every approved sender has at least one aligned passing mechanism, preferably aligned DKIM as well as correctly configured SPF.
SPF has one record per sending domain and remains within its DNS lookup limit.
DKIM selectors resolve in public DNS and test messages show dkim=pass.
Test flows cover employee mail, applications, forms, support, invoices, campaigns, and uncommon scheduled sends.
Unknown senders in aggregate reports are identified, authorized and fixed, or treated as spoofing.
The final policy is enforced intentionally at quarantine or reject, with subdomain behavior considered.
The sender inventory and ownership record are maintained as part of normal email operations.

FAQ

What is the minimum DMARC record I can publish?

The smallest useful syntax is v=DMARC1; p=none. In practice, add an aggregate report destination, such as rua=mailto:dmarc-reports@example.com, so you can discover authentication failures before enforcing a policy.

Does DMARC require both SPF and DKIM?

No. DMARC passes when either SPF passes and aligns with the visible From domain or DKIM passes and aligns. Using both is strongly preferable because forwarding and message handling can affect SPF or DKIM differently.

How long does DMARC DNS propagation take?

DNS visibility depends on the record TTL, resolver caches, and your DNS provider. Query authoritative/public DNS and test actual message headers rather than assuming that a change is active immediately. Allow enough monitoring time to capture all normal sending systems before enforcement.

Can I use more than one DMARC record?

No. Publish one TXT record at a given _dmarc hostname. Combine the tags you need into that record. Multiple DMARC records at the same name can make the policy invalid for receivers.

Should I set DMARC to reject immediately?

Only if you have already verified every legitimate mail stream has aligned SPF or DKIM and you understand subdomain behavior. Most organizations should begin with p=none, use reports and header tests to fix alignment, then move to quarantine or reject.

DMARC Record Setup: A Practical DNS Guide From Monitoring to Reject