DMARC Record Published: How to Add, Verify, and Enforce It

A DMARC record published in DNS is an important milestone, but it does not automatically mean your email is authenticated, protected from spoofing, or ready for a reject policy. You still need to confirm the DNS record is visible, every legitimate sender is aligned, and real messages pass DMARC.

What a DMARC record published status actually means

When a DMARC checker says DMARC record published, it usually means it found a DNS TXT record at the expected hostname:

_dmarc.example.com

That is a DNS discovery result, not a full deployment verdict. A lookup can succeed even when the policy is too weak, the report mailbox is inaccessible, the record has unsupported tags, or the mail your tools send fails DMARC alignment.

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It uses the domain visible in a message's From: header and checks whether that identity aligns with a passing SPF result, a passing DKIM result, or both. The domain owner then publishes a requested handling policy for failures: monitoring, quarantine, or rejection.

Think of publication as the first of four separate checks:

1. DNS publication: A valid TXT record exists at _dmarc.yourdomain.com.
2. Authentication: A sending message passes SPF or DKIM.
3. Alignment: The passing SPF or DKIM domain aligns with the visible From: domain.
4. Policy enforcement: Your p= policy asks receivers to take an action when DMARC fails.

A record can pass step one while failing the other three. That distinction prevents a common and costly mistake: moving directly to p=reject because a checker found a DMARC record.

How DMARC works with SPF, DKIM, and alignment

DMARC is not a replacement for SPF or DKIM. It sits above them and decides whether either authentication result proves that the domain in the visible From: address is trustworthy.

SPF checks the envelope sender, not necessarily the visible From address

SPF evaluates the SMTP envelope sender, often called MAIL FROM, return-path, or bounce domain. A platform might send a message that looks like it came from:

From: receipts@example.com

while using this envelope sender:

bounce@mailer.vendor.example

SPF could pass for mailer.vendor.example, but that alone does not make the message pass DMARC for example.com. The SPF domain must align with the From: domain under the DMARC alignment mode in use.

DKIM is usually the more durable path for application email

DKIM attaches a cryptographic signature to an outgoing message. The receiving server looks up the public key in DNS and validates the signature. For DMARC, the domain in the DKIM signature's d= value must align with the visible From: domain.

For transactional mail, this is often the practical solution. Your email provider can sign with a custom domain such as mail.example.com, which aligns with example.com in relaxed alignment mode. Configure every system that sends as your domain—your workspace mailbox, product email API, support desk, CRM, billing system, form tool, and newsletter platform—to use authenticated sending domains.

If you are adding a provider for product messages, follow its domain-verification flow rather than assuming its shared signing domain will align. The relevant records and sending settings are usually documented in the provider's email API setup guides.

A message needs one aligned pass

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.
• DKIM passes and the DKIM signing domain aligns with the visible From: domain.

It does not need both SPF and DKIM to align, though configuring both is a resilient operational practice. Forwarding and mailing-list modifications can affect SPF or DKIM differently, so relying on one mechanism alone creates avoidable fragility.

The DMARC DNS record syntax to publish

A DMARC policy record is a DNS TXT record. Its fully qualified hostname is _dmarc. followed by the domain you use in the visible From: address.

For example.com, publish:

The smallest useful monitoring record is:

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

Here is what each component does:

The semicolons separate tag-value pairs. Use v=DMARC1 exactly. Do not confuse a DMARC record with SPF syntax: v=spf1 belongs in an SPF record, not under _dmarc.

Why start with p=none

p=none means monitoring mode. It asks receivers to send reports without requesting quarantine or rejection of failing mail under the DMARC policy. This is the correct starting point for most active sending domains because it reveals every legitimate platform that was overlooked during setup.

A monitoring policy is not a spoofing block. It gives you visibility first, which is essential before enforcement. Gmail's bulk-sender requirements also permit a DMARC policy of p=none, provided the sender meets the rest of the required authentication conditions.

The three policy values

DMARC uses these policy values:

p=none
p=quarantine
p=reject

• p=none requests monitoring without a DMARC enforcement action.
• p=quarantine asks receivers to treat DMARC failures suspiciously, commonly by placing them in spam or quarantine. Receiver behavior can vary.
• p=reject asks receivers to reject messages that fail DMARC.

A recipient server ultimately controls its own mail handling. DMARC publishes the domain owner's requested policy; it does not force every receiver to behave identically.

Optional tags to use carefully

You will see many longer examples online. Extra tags can be useful, but adding them before you understand your sending inventory makes troubleshooting harder.

Common optional tags include:

adkim=s
aspf=s

adkim=s requests strict DKIM alignment, and aspf=s requests strict SPF alignment. Under strict alignment, the authenticated domain must exactly match the domain in the visible From: address. Under relaxed alignment, a related subdomain can align, such as mail.example.com with example.com.

Start with the default relaxed alignment unless you have mapped every sender and deliberately need strict matching. A strict policy can unexpectedly break mail from legitimate platforms that sign with an aligned subdomain.

Avoid copying legacy tags solely because a generator includes them. DMARC specifications and receiver support evolve, while the practical foundation remains the same: one valid record, an explicit policy, a working aggregate-report destination, and aligned authentication.

How to publish the DMARC record in your DNS provider

Open the DNS management panel for the authoritative domain. This may be at your registrar, DNS host, hosting provider, or security platform. It is not normally configured inside Google Workspace, Microsoft 365, or an email API dashboard unless that service also hosts your DNS.

Create a new record using the following settings:

Type: TXT
Name: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
TTL: your provider default

Replace example.com in the reporting address with a mailbox you control. A dedicated address such as dmarc-reports@example.com is better than a founder's personal inbox because aggregate reports can become numerous and are machine-readable XML, often compressed.

Host field versus full hostname

DNS control panels differ. Some ask for a short host label and automatically append your domain; others ask for the full record name.

If your DNS zone is already example.com and the field is labelled Host, Name, or Subdomain, enter:

_dmarc

If it explicitly asks for the complete hostname, enter:

_dmarc.example.com

Entering _dmarc.example.com into an interface that automatically appends example.com can create the wrong record name:

_dmarc.example.com.example.com

That error is one reason a record may look saved in a DNS dashboard but remain invisible to public DMARC lookups.

Keep only one DMARC policy record

Publish one DMARC TXT policy record at a given _dmarc hostname. Multiple DMARC records at the same name can cause receivers to treat the domain's DMARC policy as invalid or unusable.

Do not combine the DMARC value with unrelated TXT values. Domain-verification tokens, SPF, DKIM public keys, and DMARC are different records with different hostnames and syntax. In particular, an SPF record accidentally returned at _dmarc.example.com is not a DMARC record, even though both use the TXT record type.

DNS quoting and record splitting

Most modern DNS dashboards accept the TXT value without quotation marks. Zone-file formats may display a value in quotes or split a long TXT value into multiple quoted strings. That display format is normal when the resulting DNS TXT content is equivalent.

The important test is the public DNS answer, not whether your dashboard visually adds quotation marks. Use a lookup after saving rather than relying on the provider's confirmation message.

How to verify that your DMARC record is published

A public DNS lookup is the fastest definitive check. Query the exact DMARC hostname, not the bare domain.

macOS and Linux

Run:

dig +short TXT _dmarc.example.com

A healthy result resembles:

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

You can also ask a public resolver directly:

dig @8.8.8.8 +short TXT _dmarc.example.com

Windows PowerShell

Run:

Resolve-DnsName -Name _dmarc.example.com -Type TXT

Look for a TXT string beginning with v=DMARC1 and containing a valid p= policy.

Windows Command Prompt

Run:

nslookup -type=TXT _dmarc.example.com

If the result is absent, inspect the hostname you created in DNS. If it returns an SPF string, a verification token, or a DKIM key, the record name is wrong or a wildcard DNS record is interfering.

A DNS checker is useful as a second opinion because it can query multiple resolvers. However, the DNS result only proves that the record is retrievable. It does not prove that your mail passes DMARC, that reporting works, or that your policy is safe to enforce.

How to tell whether DMARC is working on real email

After the DMARC record is visible, send a fresh message from each sending system to a mailbox you control. Test more than your primary inbox. Include receipts, password resets, support replies, calendar notifications, marketing campaigns, invoices, and any automation that uses your brand domain in From:.

Open the full message headers. Most email clients provide an option such as Show original, View message source, or View headers. Find the Authentication-Results: header and look for a result similar to:

spf=pass
 dkim=pass
 dmarc=pass header.from=example.com

The exact formatting differs by receiver, but dmarc=pass and the visible header.from= domain are the key signals.

What success looks like

For each legitimate sender, verify all of the following:

• The message arrives where you expect it to arrive.
• The visible From: address uses the intended domain.
• SPF passes with an aligned envelope domain, or DKIM passes with an aligned signing domain.
• The receiving mailbox records dmarc=pass.
• Aggregate reports begin arriving at the address listed in rua=.

A message can still land in spam despite passing DMARC. DMARC validates identity; it does not guarantee inbox placement. Content, recipient engagement, sending reputation, complaint rates, IP reputation, and other receiver-specific factors still influence delivery.

What a failure looks like

A frequent failure pattern looks like this:

spf=pass smtp.mailfrom=vendor-mail.example
dkim=pass header.d=vendor-mail.example
dmarc=fail header.from=example.com

Both SPF and DKIM passed, but neither authenticated domain aligns with example.com. The fix is not to weaken DMARC. Configure the vendor to use a custom DKIM signing domain or aligned bounce domain, or send with a From: domain that the platform can authenticate correctly.

A safe DMARC rollout from monitoring to reject

DMARC is most effective when it becomes an operating process rather than a one-time DNS task. The safe sequence is inventory, monitor, correct, enforce, and continue monitoring.

Step 1: Build a sender inventory

List every service capable of sending mail as your domain. Include systems owned by marketing, sales, customer success, finance, product, IT, HR, and external agencies.

Your inventory should capture:

• Product or vendor name
• Purpose of the message
• Visible From: domain
• Envelope or bounce domain, if known
• DKIM signing domain
• Whether SPF, DKIM, and DMARC pass in a real test
• Account owner and renewal status

This list reveals dormant but still active platforms, including old survey tools, event software, job platforms, and payment services. Those are the systems most likely to fail once you move beyond monitoring.

Step 2: Publish p=none and collect aggregate reports

Use a monitoring record such as:

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

Aggregate reports summarize messages observed by participating receivers. They can identify source IP addresses, sending volumes, SPF and DKIM outcomes, alignment results, and the disposition applied. RFC 9990 defines these reports as XML documents, so raw attachments are not especially pleasant to inspect manually.

You can process them with a DMARC reporting service, an internal parser, or a mailbox workflow. Whatever tooling you choose, treat the data as an investigation queue: identify unknown sources before treating them as attacks or blocking them.

Step 3: Fix legitimate failures

For every legitimate source that fails DMARC, choose a concrete remediation:

1. Enable the vendor's custom DKIM domain feature.
2. Add the vendor's required SPF include only after confirming it is necessary and that you still have one valid SPF record.
3. Configure an aligned custom return-path or bounce domain if the platform supports it.
4. Change the visible From: domain to one the platform can authenticate.
5. Stop using the service to send as your domain.

Do not publish multiple SPF records to accommodate new vendors. SPF permits one SPF record per domain, so new authorization mechanisms belong inside the existing record according to the provider's setup instructions.

Step 4: Move to quarantine, then reject

Once reports and live tests show that legitimate email is aligned, change the policy deliberately:

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

Continue monitoring for missed sources and indirect-mail issues. When you can account for legitimate failures and the domain's normal traffic consistently passes, move to:

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

Keep the reporting address after enforcement. A reject policy reduces direct spoofing risk, but aggregate reports remain useful for detecting abuse attempts, configuration drift, and a new tool sending without authentication.

Worked example: publishing and validating a DMARC record

Suppose Northstar Coffee owns northstarcoffee.example. It uses Google Workspace for employee mail, a transactional email provider for order confirmations, a support platform for ticket updates, and a marketing tool for newsletters.

The team creates a mailbox named dmarc-reports@northstarcoffee.example. Then it publishes this record in the authoritative DNS zone:

Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@northstarcoffee.example

The full DNS name becomes:

_dmarc.northstarcoffee.example

Next, the team verifies publication:

dig +short TXT _dmarc.northstarcoffee.example

Expected output:

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

That confirms the DMARC record is published. It does not yet justify p=reject.

The team then sends one message from every platform to a test inbox and reads each message's authentication headers. The employee-mail and transactional-email messages show dmarc=pass. The support platform shows this result:

spf=pass smtp.mailfrom=mailer.support-vendor.example
dkim=pass header.d=support-vendor.example
dmarc=fail header.from=northstarcoffee.example

The support platform is legitimate, but its shared vendor domains do not align with Northstar Coffee's visible From domain. The team enables the vendor's custom domain authentication feature, adds the required DKIM CNAME records, waits until the provider reports verification, then repeats the test.

The corrected message shows:

dkim=pass header.d=mail.northstarcoffee.example
dmarc=pass header.from=northstarcoffee.example

Because mail.northstarcoffee.example is a related subdomain, it aligns with northstarcoffee.example under relaxed alignment. The team repeats this exercise for the marketing platform and watches aggregate reports for any additional senders. Only after the inventory is clean should it consider changing p=none to p=quarantine and later p=reject.

Common reasons a published DMARC record still fails

The record is at the wrong hostname

The DMARC policy belongs at _dmarc.example.com, not at example.com. A TXT record at the root domain can be SPF, a site-verification token, or another value, but it is not automatically DMARC.

Also check whether the DNS editor appended the domain twice. Query the exact name publicly to catch this immediately.

The record has multiple values or conflicts

A domain may have several TXT records at the root, which is normal. At the DMARC hostname, however, you should have one DMARC policy record. Two separate values beginning with v=DMARC1 create ambiguity.

Review wildcard DNS settings too. A wildcard can return unrelated text at _dmarc, making a lookup appear to return a TXT record even though the returned value is not valid DMARC.

A vendor passes SPF or DKIM but not alignment

This is the most common operational issue. Shared provider infrastructure often authenticates the provider's domain rather than yours. Ask the provider for custom DKIM, custom return-path, branded sending domain, domain alignment, or authenticated sender-domain documentation.

Do not accept a dashboard statement that a domain is verified as proof of DMARC alignment. Send a message and inspect the headers.

The rua address is external and not authorized

If rua= points to a mailbox on a different domain, additional DNS authorization is generally required at the destination domain before receivers will send reports there. This is why beginning with a report mailbox on the same domain is simpler.

For example, use dmarc-reports@example.com for example.com during initial deployment. If you later use a reporting provider, follow that provider's exact external-report authorization instructions and validate them with the provider's checker.

The report mailbox exists but nobody reviews it

A rua= destination is only useful if reports are collected and interpreted. Aggregate reports may arrive compressed and in XML. A dedicated reporting tool, mailbox rule, or internal workflow is often necessary once mail volume grows.

The operational goal is not an empty report inbox. It is a documented explanation for each legitimate source and a plan for every unauthorized one.

DMARC for subdomains, parked domains, and third-party senders

Your root domain policy does not eliminate the need to think about subdomains. Product teams often use mail.example.com, updates.example.com, or notify.example.com in visible From addresses, while marketing teams may use a separate campaign subdomain.

For a high-control setup, give significant sending subdomains their own DMARC records and test them separately:

_dmarc.mail.example.com
_dmarc.updates.example.com
_dmarc.notify.example.com

This makes ownership clearer and lets you apply policies appropriate to the mail stream. It also reduces the chance that a configuration change for a marketing platform affects critical password-reset or account-security messages.

Parked domains deserve DMARC too. If a domain should never send mail, publishing a restrictive policy after confirming it has no legitimate sending sources helps communicate that mail claiming to be from it should not be trusted. Verify all redirects, legacy systems, and vendor configurations first; a domain that appears parked can still be referenced by an old application.

Third-party services need special attention because their setup screens vary. Some require CNAME records for DKIM, some provide SPF instructions, and some offer a custom bounce domain only on particular plans. Compare the actual header results, not marketing language, before marking the service compliant.

The practical business impact of DMARC enforcement

DMARC is an identity-control layer for your email brand. It helps receivers evaluate messages that claim to come from your domain and gives your team data about unknown mail sources. It is especially important for domains used for invoices, login links, password resets, customer communications, and executive correspondence.

For marketers and product teams, the second-order benefit is governance. DMARC reporting forces an organization to answer a question that otherwise remains hidden: exactly which systems can send as us? That inventory improves deliverability operations, vendor offboarding, incident response, and ownership of sender-domain settings.

It is not a complete anti-phishing program. Attackers can use lookalike domains, compromised legitimate accounts, or display-name impersonation. DMARC also does not guarantee inbox placement for valid mail. Pair it with secure account access, sensible sending practices, recipient education, and ongoing monitoring.

FAQ

Does DMARC record published mean DMARC is working?

No. It means a DNS lookup found a DMARC TXT record. Confirm that real messages from every legitimate sender show dmarc=pass in their authentication headers and that your aggregate reports are arriving.

Where do I publish a DMARC record?

Publish it in the authoritative DNS zone for the domain used in your visible From: address. The record name is _dmarc and the type is TXT, producing _dmarc.yourdomain.com.

What is the safest first DMARC record?

Use a monitoring policy with a report address you control:

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

Then inspect reports and test each sender before moving to enforcement.

Should I use p=quarantine or p=reject?

Use p=quarantine as an intermediate enforcement step when you have fixed legitimate failures and want to observe impact. Use p=reject after you can account for legitimate senders and want receivers to reject direct impersonation attempts that fail DMARC.

Why does SPF pass but DMARC fail?

SPF can pass for the envelope sender's domain while the visible From: address uses a different domain. DMARC requires the passing SPF domain or DKIM signing domain to align with the visible From domain. Configure an aligned custom sending or signing domain with the provider.