DMARC FAQ: Setup, Alignment, Policies, and Reports

DMARC FAQ answers often start with a DNS record, but successful DMARC is really an email identity program: inventory every sender, authenticate it correctly, monitor what receivers see, and only then enforce policy. This guide explains the protocol in practical terms for teams sending application, transactional, support, and marketing email.

What is DMARC?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is a DNS-based email authentication and policy protocol that lets the owner of a domain tell participating mailbox providers how to evaluate mail using that domain in the visible From: header.

DMARC builds on two existing mechanisms:

• SPF checks whether the connecting sending server is authorized to use the SMTP envelope sender domain, also called MAIL FROM or Return-Path.
• DKIM checks whether a signed portion of a message verifies against a public key published in DNS.
• DMARC checks whether SPF or DKIM passed and whether the passing domain aligns with the domain shown to the recipient in From:.

The current DMARC core specification is RFC 9989, published in May 2026. It obsoletes the older RFC 7489 material that many tutorials still reference. Aggregate-reporting and failure-reporting behavior are now described separately in RFCs 9990 and 9991. (datatracker.ietf.org)

The practical purpose is straightforward: a recipient should be able to distinguish an authorized message from billing@example.com from a forged message that merely displays billing@example.com in its visible sender field. DMARC does not guarantee inbox placement, and it does not make every authenticated message trustworthy. It gives receivers a reliable signal about whether a message is authorized to use the domain in From:.

Why does DMARC matter for transactional email?

Transactional email is especially sensitive to impersonation. Password resets, magic links, invoices, account verification, receipts, alerts, and security notifications all ask recipients to take an action. If attackers can spoof the domain used for those messages, they can make fraudulent mail look like a legitimate product email.

For a developer, DMARC has two connected benefits:

1. Domain protection: It gives receivers a policy for messages that claim to be from your domain but fail authentication.
2. Operational visibility: Aggregate reports can reveal unknown systems, misconfigured vendors, forwarding patterns, and attempted abuse using your domain.

It also matters for delivery. Gmail’s sender guidelines require bulk senders—those sending roughly 5,000 or more messages to personal Gmail accounts in a 24-hour period—to configure SPF, DKIM, and DMARC. Gmail permits a monitoring policy such as p=none, but its alignment requirements still matter. (support.google.com)

DMARC is therefore not a marketing-email-only project. A production application may send from a REST email API, an SMTP relay, a help desk, a billing system, a status page, CI/CD alerts, and an employee mail platform. Each of those sources can affect the domain’s authentication posture.

How does DMARC decide whether a message passes?

A message passes DMARC when at least one of these conditions is true:

• SPF passes and the SPF-authenticated domain aligns with the visible From: domain; or
• DKIM passes and the d= domain in at least one valid DKIM signature aligns with the visible From: domain.

It is not necessary for both SPF and DKIM to align for a DMARC pass. In practice, however, configuring both is strongly recommended. SPF can break when mail is forwarded, while DKIM is generally more resilient if intermediaries do not modify signed content or headers. Microsoft also notes that SPF alone does not prevent spoofing; SPF, DKIM, and DMARC work together. (learn.microsoft.com)

The identities involved

A typical message has several domains. They are not interchangeable:

From: Acme Alerts <alerts@example.com>
Return-Path: <bounce@mailer.example.net>
DKIM-Signature: v=1; d=example.com; s=tx2026; ...

In this example:

• The header From domain is example.com. DMARC starts here.
• The SPF identity is normally the envelope sender domain, mailer.example.net.
• The DKIM identity is the d= domain, example.com.

If the DKIM signature verifies, d=example.com aligns exactly with From: ...@example.com, so DMARC passes through DKIM even if SPF does not align. If SPF passes for mailer.example.net but there is no aligned DKIM signature, DMARC would fail under strict alignment because mailer.example.net and example.com are different domains.

What does alignment mean?

Alignment connects the domain the recipient sees in From: to the domain that passed SPF or DKIM. There are two modes:

• Relaxed alignment is the default. Organizationally related domains can align. For example, news.example.com can align with example.com.
• Strict alignment requires an exact domain match. news.example.com does not strictly align with example.com.

The DMARC record controls these modes through aspf for SPF and adkim for DKIM. Most domains should begin with relaxed alignment because it works well with normal subdomain architecture while still preventing unrelated domains from passing.

What DNS record do I need for DMARC?

Publish one TXT record at _dmarc.yourdomain. For example.com, the DNS host/name is:

_dmarc.example.com

A safe starting record is:

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

In most DNS control panels, enter the pieces as follows:

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

Do not put this record at the root domain unless your DNS provider automatically interprets _dmarc relative to the zone. The complete queried name must resolve as _dmarc.example.com, not simply example.com.

The first tag must be v=DMARC1; it identifies the TXT value as a DMARC policy record. The p tag is required for an organizational-domain record and sets the requested handling policy for mail that fails DMARC. RFC 9989 defines DMARC as a way for domain owners to publish validation and handling preferences, while receivers retain the ability to make their own delivery decisions. (rfc-editor.org)

Can I publish multiple DMARC TXT records?

No. Publish one DMARC record at a given _dmarc name. Multiple TXT strings may be used by DNS to represent a single long record, but publishing multiple independent DMARC policy records can cause receivers to treat the policy as invalid or unusable.

This is different from SPF, where the rule is also one SPF record per domain, but it is a common source of confusion when DNS panels show several TXT records together. Consolidate tags into a single DMARC policy value.

How can I check the published record?

Use command-line DNS tools:

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

You can also inspect records with MXToolbox, Google Admin Toolbox Dig, or a DMARC analysis service. Check the authoritative result after DNS propagation rather than relying only on what the DNS UI displays.

What do p=none, p=quarantine, and p=reject mean?

The p tag is the policy you request for mail that fails DMARC.

p=none: monitor

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

p=none asks receivers to take no specific enforcement action based solely on the DMARC policy, while sending aggregate reports when they support them. It is the right starting point for most domains because it lets you find legitimate email sources before potentially blocking them.

A monitoring policy is not “no DMARC.” Receivers still evaluate DMARC, and reports can reveal failures. Gmail explicitly allows bulk senders to use p=none while requiring authentication and DMARC setup. (support.google.com)

p=quarantine: treat failures as suspicious

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

p=quarantine asks receivers to treat DMARC-failing mail as suspicious. A receiver may send it to spam, add warnings, or apply another local handling action. It is not a guaranteed spam-folder command: mailbox providers use their own anti-abuse systems and can make a different final decision.

p=reject: request refusal of failures

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

p=reject asks receivers to reject mail that fails DMARC. This is the strongest policy and usually the end goal for a domain that is not expected to send unauthenticated email.

A rejection can appear as an SMTP permanent failure, but exact text and enhanced status codes vary by receiver. One commonly seen Gmail response for DMARC-policy rejection is 550 5.7.26, indicating unauthenticated mail was not accepted due to the domain’s DMARC policy. Treat the entire SMTP response as diagnostic context; do not build application logic around one provider’s wording. (support.google.com)

Should every domain use p=reject immediately?

No. Immediate rejection is appropriate only when you know every legitimate sender is accounted for and authenticated. It can break password resets, support replies, CRM mail, calendar notifications, and automated vendor mail if one source was overlooked.

A safer rollout is:

1. Publish p=none with aggregate reporting.
2. Inventory and fix all known legitimate failures.
3. Move to p=quarantine after reports are stable.
4. Move to p=reject after continued monitoring shows no important unaligned sources.

The duration of each stage depends on your sending complexity. For a single application domain with one sending service, a few weeks may be enough. For a company with acquired domains, regional teams, support platforms, and many SaaS vendors, inventory and remediation can take much longer.

Which DMARC tags should I use?

A practical record often starts small:

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

Then add tags only when you understand their effect. Common tags include:

What does sp do?

sp sets the requested policy for subdomains if they do not have their own DMARC record. For example:

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

This asks receivers to reject failing mail from example.com and quarantine failing mail from a subdomain such as news.example.com, unless _dmarc.news.example.com publishes its own policy.

Subdomains are useful for separating mail streams. A product might send application email from notify.example.com, marketing mail from news.example.com, and corporate mail from example.com. Separate subdomains can limit blast radius, simplify vendor changes, and allow a stricter policy for domains with narrowly controlled mail sources.

Should I set adkim=s and aspf=s?

Not by default. Strict alignment is valuable when exact-domain control is a deliberate design choice, but it can create avoidable failures when a platform signs with a related subdomain or uses a subdomain in the envelope sender.

Use strict DKIM alignment when you can ensure the d= value exactly matches the domain in From:. Use strict SPF alignment only if your envelope-sender design is controlled and you have tested every sender. A common resilient pattern is relaxed SPF alignment plus an exactly aligned DKIM signature.

Does pct gradually enforce DMARC?

pct requests policy application to a percentage of messages that fail DMARC, for example:

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

This can be useful during a cautious transition, but it is not a substitute for fixing failures. Receivers may apply local policy and not every receiver must implement gradual enforcement identically. Keep pct=100 once the domain is ready.

How do SPF, DKIM, and DMARC work with an email API or SMTP relay?

Whether your application sends through an HTTP API or SMTP, the authentication model is the same. Your sending platform must send with identities that your domain authorizes and that align with the visible From: address.

For a typical transactional setup, confirm these four things:

1. Visible From domain: Your application uses an address such as receipts@example.com, not an unverified domain or a consumer mailbox address.
2. DKIM signing domain: The provider signs mail with d=example.com or an aligned subdomain such as d=mail.example.com under relaxed alignment.
3. Envelope sender: The SMTP MAIL FROM/bounce domain passes SPF and preferably aligns with the From domain.
4. DNS ownership: The required DKIM and SPF DNS records remain published after configuration and provider migrations.

Many providers ask you to publish CNAME records that delegate DKIM selector lookups, while others provide a TXT public key directly. Follow the exact values issued by the provider; do not replace them with illustrative records from another service. For REST API and SMTP relay implementations, compare the configured From domain, Return-Path domain, and DKIM d= value in a delivered message before declaring DMARC complete. For implementation details, consult the provider’s email API setup guides.

Example: aligned transactional mail

From: Example App <no-reply@example.com>
Return-Path: bounce@bounce.example.com
DKIM-Signature: v=1; d=example.com; s=tx1; ...

With relaxed alignment, both of these can support DMARC:

• SPF passes for bounce.example.com, which is organizationally aligned with example.com.
• DKIM passes for example.com, which exactly aligns with example.com.

The DKIM path is especially important because forwarders commonly change the connecting IP address. That can make SPF fail even when the original sender was legitimate.

What are DMARC aggregate reports, and how do I read them?

Aggregate reports, requested with rua, are periodic XML summaries from participating receivers. They are normally compressed attachments and commonly arrive daily, though timing and coverage vary by receiver.

A report may show rows such as:

<record>
  <row>
    <source_ip>198.51.100.24</source_ip>
    <count>143</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
</record>

This does not necessarily mean all 143 messages failed DMARC. The row’s policy result needs to be interpreted alongside authentication details and alignment. The important questions are:

• Is the source IP expected for one of your senders?
• Is the header_from domain one you own?
• Did DKIM or SPF pass and align?
• Is the receiver applying none, quarantine, or reject?
• Is the volume consistent with a known mail stream?

Aggregate reporting is now standardized in RFC 9990, which describes XML reports and the use of destinations declared in DNS. (datatracker.ietf.org)

Where should aggregate reports go?

Use a mailbox or service dedicated to DMARC reporting:

rua=mailto:dmarc-reports@example.com

Avoid an individual employee inbox. Reports can be numerous, compressed, and difficult to interpret manually. A DMARC reporting platform can parse XML, group traffic by sender, identify alignment failures, and retain historical trends. For a low-volume domain, a dedicated mailbox plus occasional manual review may be sufficient initially.

If the report destination is outside the domain publishing the DMARC record, external-destination authorization requirements can apply. This protects third parties from being unwillingly flooded with reports about someone else’s domain. RFC 9990 defines the external reporting authorization mechanism. (rfc-editor.org)

Are forensic or failure reports useful?

Failure reports are requested with ruf and related options, but do not expect universal delivery. They can contain message-level detail and may raise privacy, volume, and operational concerns, so receiver support is limited compared with aggregate reports.

Start with rua. Add failure-reporting only when your security and privacy teams understand what may be received, where it will be stored, and how it will be handled. RFC 9991 describes DMARC failure reports as reports about individual messages that failed DMARC authentication. (datatracker.ietf.org)

How do I test DMARC before enforcing it?

Testing should include DNS, real messages, and receiver-side results. A DMARC record that looks correct in a dashboard can still fail because the actual application uses a different From domain, the provider signs with the wrong domain, or an old SMTP relay remains active.

Use this checklist:

• Query _dmarc.example.com with dig or nslookup.
• Send a test from every application, environment, and vendor using the domain.
• Deliver to Gmail, Outlook.com, and another mailbox you control where possible.
• Inspect the received message’s Authentication-Results: header.
• Confirm spf=pass and/or dkim=pass, then verify dmarc=pass.
• Test a production-like password reset or receipt, not only a hand-written test email.
• Send a copy to mail-tester.com for a broad deliverability and authentication check.
• Use MXToolbox to inspect DNS record syntax and obvious configuration issues.

A successful header often resembles this:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=tx1;
       spf=pass smtp.mailfrom=bounce.example.com;
       dmarc=pass header.from=example.com

The exact formatting differs by mailbox provider. Look for the result values, the DKIM signing domain, the SPF mail-from identity, and the domain used for DMARC evaluation.

Google Postmaster Tools can provide authentication, reputation, delivery-error, and spam-rate information for eligible domains. It is useful as a trend signal, but it does not replace reviewing your own message headers and DMARC reports. (support.google.com)

Why does DMARC fail when SPF or DKIM says pass?

This is the most common DMARC troubleshooting question. A pass for SPF or DKIM alone is not enough; the passing result must align with the visible From domain.

SPF passes but DMARC fails

Example:

From: notifications@example.com
Return-Path: bounce@vendor-mail.net
SPF: pass for vendor-mail.net
DKIM: none
DMARC: fail

SPF passed for vendor-mail.net, but that domain is unrelated to example.com. With no aligned DKIM signature, DMARC fails.

Fixes include using a custom bounce/envelope domain under example.com, enabling domain-aligned DKIM with the sending provider, or both. Do not assume adding the provider to the SPF record solves DMARC: it authorizes an SPF identity, but it does not automatically make that identity align.

DKIM passes but DMARC fails

Example:

From: notifications@example.com
DKIM: pass for vendor-mail.net
SPF: fail
DMARC: fail

The signature is valid, but its d=vendor-mail.net domain is not aligned with example.com. Configure the provider to sign with your domain or an aligned subdomain. This normally requires publishing the provider’s DKIM DNS records and verifying the sending domain in the provider account.

SPF fails after forwarding

Forwarders often relay an original message from a new IP address. Since that forwarder is not listed in the original sender’s SPF record, SPF can fail. This is expected behavior, not proof the original sender was malicious. Microsoft’s troubleshooting guidance specifically identifies forwarding as a common cause of SPF failure. (learn.microsoft.com)

An aligned DKIM signature can preserve DMARC passing through forwarding if the message remains intact. Mailing lists and security gateways may modify content, subject lines, or footers, which can then break DKIM too. These indirect-mail flows are a known interoperability challenge for DMARC.

Too many SPF lookups

SPF evaluation has DNS lookup limits. RFC 7208 requires implementations to limit certain DNS-triggering terms to 10 during SPF evaluation; exceeding the limit can produce a permerror. (rfc-editor.org)

This can happen when several vendors are added through nested include: mechanisms. Reduce unnecessary includes, use a controlled subdomain for a specific service, or work with your sender to simplify authorization. Do not add multiple separate v=spf1 records; merge authorized mechanisms into one SPF record.

What should I do when moving to p=reject?

Treat enforcement as a controlled production change, not as a DNS cleanup task. Before changing policy, review at least several reporting cycles that cover normal business activity, scheduled jobs, low-volume systems, and incident notifications.

Create a sender inventory with these columns:

The third row is the kind of problem that a p=none phase exposes. Fix it before enforcement, even if recipients appear to receive the mail today. A later mailbox-provider change, stricter destination, or forwarding path can turn a tolerated authentication failure into a visible delivery incident.

After switching to p=quarantine or p=reject, continue monitoring. New SaaS tools, agency campaigns, and engineering changes can introduce unauthorized senders after the initial project is complete.

DMARC best practices for developers

DMARC is easier when domain architecture is intentional. These practices reduce long-term maintenance:

• Use a domain you control for every production From address.
• Prefer a dedicated transactional subdomain, such as notify.example.com, when it helps isolate application traffic from corporate or marketing mail.
• Enable aligned DKIM for every sender; regard it as the durable path through forwarding and infrastructure changes.
• Use a custom bounce domain when supported so SPF can align too.
• Keep test, staging, and production domains separate. Never let staging send with a production From domain unless it is authenticated exactly like production.
• Maintain a named owner for each third-party sender and review it during offboarding.
• Check deployed mail headers after changes to DNS, providers, templates, or routing rules.
• Protect DNS account access. An attacker who can alter DKIM, SPF, or DMARC records can undermine email authentication.

Also distinguish authentication from reputation. A fully authenticated message can still land in spam because of poor list quality, high complaint rates, deceptive content, weak engagement, or a damaged sending reputation. Conversely, a good reputation does not excuse missing authentication. DMARC is foundational infrastructure, not a deliverability shortcut.

FAQ

Does DMARC require both SPF and DKIM to pass?

No. DMARC passes when either SPF or DKIM passes and the passing domain aligns with the visible From domain. Configure both anyway: they protect against different failure modes, especially forwarding and message modification.

Is p=none enough for Gmail’s bulk sender requirements?

Gmail permits a DMARC policy of p=none for bulk senders, but senders still need SPF and DKIM and must meet alignment requirements. p=none is a monitoring policy, not enforcement. (support.google.com)

How long should I use p=none before enforcing DMARC?

Use it long enough to observe all legitimate mail streams, including monthly invoices, rare alerts, support workflows, and vendor campaigns. For simple domains, that may be weeks; for complex organizations, it can be months. Move forward when reports show understood, remediated, or intentionally retired sources—not merely when the record has existed for a certain number of days.

Can a subdomain have its own DMARC policy?

Yes. Publish a record such as _dmarc.notify.example.com to define policy specifically for notify.example.com. A subdomain-specific record takes precedence over inherited organizational-domain policy for that subdomain.

Does DMARC guarantee inbox placement?

No. DMARC helps verify identity and reduce spoofing, but mailbox providers also assess reputation, user complaints, content, sending behavior, recipient engagement, and other anti-abuse signals. A DMARC pass is necessary infrastructure for serious senders, not a guarantee of inbox placement.