DMARC Record Builder: Create, Publish, and Verify Your DMARC Policy

A DMARC record builder helps you turn your email-sending setup into one DNS TXT record that mailbox providers can read. The hard part is not typing v=DMARC1; p=none; it is identifying every system that sends mail as your domain, ensuring SPF or DKIM aligns with the visible From address, and choosing an enforcement policy that will not block legitimate messages.

DMARC—Domain-based Message Authentication, Reporting, and Conformance—builds on SPF and DKIM. A message passes DMARC when at least one authentication method passes and the authenticated domain aligns with the domain in the visible From: header. The protocol lets a domain owner publish a requested treatment for messages that fail this test and request reporting about activity using the domain. (rfc-editor.org)

This guide gives you a practical DMARC record builder, copy-ready record syntax, an implementation checklist, a worked example, troubleshooting steps, and a way to prove the deployment worked.

What a DMARC record builder needs from you

A DMARC record is a DNS TXT record published at a special hostname:

_dmarc.example.com

The value is a semicolon-separated list of tag=value pairs:

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

A useful builder asks for more than a domain name. Before it outputs a record, it should collect the following information:

1. The domain in your visible From address. If customers receive mail from hello@example.com, the DMARC domain is example.com. If marketing mail uses news@updates.example.com, decide whether that subdomain needs its own record and sending configuration.
2. Every legitimate sending platform. Typical examples include Google Workspace or Microsoft 365, an application email API, a transactional provider, a marketing automation platform, a help desk, an ecommerce platform, a CRM, and a payroll or invoicing system.
3. How each platform authenticates mail. Record the envelope sender or Return-Path domain used for SPF, the DKIM d= signing domain, and the human-facing From: domain. These values reveal whether alignment will pass.
4. A report destination you control. Aggregate reports are machine-readable XML files, commonly compressed, and can become noisy. Use a dedicated mailbox, group, or DMARC reporting service rather than a founder’s normal inbox.
5. Your desired rollout stage. Start with monitoring (p=none), then move to quarantine or reject after reports show that legitimate traffic is aligned.

DMARC does not itself authorize an email platform to send mail. SPF publishes permitted sending infrastructure, while DKIM publishes public keys used to verify signatures. DMARC evaluates those results against the visible From domain. Google describes the relationship simply: SPF helps establish that a server sent the message, while DKIM helps establish that the domain signed it. (support.google.com)

The fastest safe DMARC record to publish

For most domains that have not yet inventoried their senders, use this monitoring record first:

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

Replace example.com with your own domain in the reporting mailbox. In many DNS dashboards, entering _dmarc as the host automatically creates _dmarc.example.com; other dashboards require the complete hostname. Check the provider’s preview rather than assuming its convention.

This record means:

• v=DMARC1 identifies the record as DMARC.
• p=none asks receivers to monitor failures rather than apply a DMARC enforcement action.
• rua=mailto:... requests aggregate reports at the specified address.

A monitoring policy is not a complete anti-spoofing outcome. It gives you visibility, but it does not ask receivers to quarantine or reject mail that fails DMARC. It is the right starting point because a strict policy can disrupt legitimate messages from forgotten vendors or incorrectly configured systems.

Google’s setup guidance explicitly recommends confirming SPF and/or DKIM before enabling DMARC and notes that report volume varies with how much mail the domain sends and where it sends it. It recommends a dedicated group or mailbox for handling reports. (support.google.com)

Build the record: DMARC tags that matter

A record builder should default to a short record. Every extra tag is a policy decision, not decorative metadata. Start with the core tags, then add only tags that solve a real operational need.

v: protocol version

Use this exact value and place it first:

v=DMARC1

Do not use DMARC2, omit the tag, or place unrelated text before it. The interoperable DMARC record identifier remains DMARC1.

p: the policy for DMARC failures

The p tag is required. It defines your requested handling for mail that fails DMARC:

p=none
p=quarantine
p=reject

Choose the value based on deployment maturity:

Mailbox providers retain discretion in delivery decisions. A DMARC policy is a published request, not a contractual guarantee that every receiver will make an identical disposition.

rua: aggregate reporting address

Use rua to request aggregate reports:

rua=mailto:dmarc-reports@example.com

You may list more than one destination, separated by commas:

rua=mailto:dmarc-reports@example.com,mailto:security@example.com

Aggregate reports summarize authentication results for groups of messages, usually by source IP address and evaluated domain. The current DMARC aggregate-reporting specification defines these reports as XML documents delivered to a destination declared through the associated record. (rfc-editor.org)

Avoid using a personal inbox as your long-term rua destination. XML attachments, compressed files, and reports from multiple receivers are difficult to review manually. A dedicated mailbox plus a reporting parser is usually enough for a small domain; larger programs often use a DMARC monitoring platform.

adkim and aspf: alignment strictness

These optional tags set the alignment mode for DKIM and SPF:

adkim=r; aspf=r

The choices are:

• r for relaxed alignment.
• s for strict alignment.

Relaxed alignment permits a related subdomain arrangement. For example, a DKIM signature with d=mail.example.com can align with a visible From domain of example.com under relaxed alignment. Strict alignment requires an exact domain match.

For a first deployment, omit both tags or explicitly use adkim=r; aspf=r. Relaxed alignment is the safer operational default for organizations that use delegated sending subdomains, vendor-managed DKIM domains, or multiple email products. Move to strict alignment only after you understand every stream and have intentionally designed your domain layout around exact matches.

A DMARC pass needs one aligned method, not both. If SPF fails but aligned DKIM passes, DMARC can pass. If DKIM fails but aligned SPF passes, DMARC can pass. This is especially important for forwarded mail, mailing lists, and providers whose envelope sender differs from the visible From domain. (rfc-editor.org)

sp: policy for subdomains without their own DMARC record

Use sp when the domain has subdomains that might be used in visible From addresses:

p=reject; sp=quarantine

If sp is omitted, subdomains without their own DMARC record generally inherit the parent policy. The tag is useful when you want to protect the primary domain aggressively while keeping an intentionally separate rollout path for subdomain mail.

For example:

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

This can be appropriate while example.com is fully authenticated but updates.example.com is still being audited. It should be temporary: an unprotected subdomain can be attractive to impersonators, and it can confuse recipients who see a familiar brand domain.

np, t, and version-specific tags

The DMARC standards have evolved. RFC 9989 is the standards-track successor to RFC 7489 and introduces or formalizes capabilities including a policy for non-existent subdomains (np) and a testing signal (t), while older DMARC documentation and many DNS tools still surface tags from the earlier record model. RFC 9989 obsoletes RFC 7489 and RFC 9091. (datatracker.ietf.org)

For a durable, broadly compatible record builder, treat these as advanced, version-aware options rather than defaults:

• np can express the policy for mail using a non-existent subdomain.
• t can signal testing behavior in implementations that support the newer model.
• Legacy tools may still offer pct, ri, and rf; do not add them merely because a generator exposes them.

The practical rule is simple: a short record with v, p, and rua works as a safe baseline. Add sp, alignment modes, or newer tags only after you can explain the delivery behavior each one is intended to control.

ruf and fo: failure-report options

Some generators offer forensic or failure reporting options such as:

ruf=mailto:dmarc-failures@example.com; fo=1

Do not make these a default. Failure reports can contain more message-level detail, receiver support is inconsistent, and privacy or data-handling concerns are higher than with aggregate reports. Start with rua aggregate reports. Add failure reporting only if your security team has a defined use case, secure handling process, and a receiver ecosystem that actually sends the data.

DMARC record builder templates

Use these as starting points, not as a substitute for checking your SPF, DKIM, and sender inventory.

Template 1: New deployment, monitoring mode

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

Use this when you have never reviewed DMARC reports or are uncertain whether every legitimate service signs with an aligned domain.

Template 2: Monitoring with explicit relaxed alignment

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

Use this when you want the record to document the intended alignment setting rather than rely on defaults.

Template 3: Controlled enforcement

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

Use this only after report data shows that all important legitimate sources pass DMARC consistently. Review transactional mail, password resets, order confirmations, support replies, invoices, employee mail, and marketing campaigns—not just a test newsletter.

Template 4: Full enforcement

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

Use this after you have remediated all legitimate sources and established an ongoing review process for new vendors. A full enforcement policy is the clearest request to reject unauthorized messages claiming to be from your domain.

Template 5: Parent domain enforced, subdomains still monitored

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

Use this only where there is a known subdomain rollout plan. Document who owns each subdomain and set a deadline to bring it under an explicit policy.

Worked example: build a record for a SaaS company

Assume Acme Labs owns acmelabs.com and sends mail through four systems:

• Google Workspace for employee email from name@acmelabs.com.
• An application email provider for password resets and product notifications from support@acmelabs.com.
• A marketing platform for newsletters from news@acmelabs.com.
• A help desk that sends ticket replies from help@acmelabs.com.

The team wants to stop obvious spoofing but does not know whether all vendors are aligned. Here is the correct rollout.

Step 1: Create a sender inventory

Make a table before touching DMARC:

The key column is not “does the vendor say SPF and DKIM are enabled?” The key question is whether SPF or DKIM passes and aligns with acmelabs.com, the domain recipients see in From:.

For example, suppose the application platform signs with d=mailer.vendor.example. DKIM may technically pass, but it does not align with acmelabs.com. If the Return-Path is also at the vendor’s domain, SPF may pass without alignment too. That stream fails DMARC until Acme configures the platform’s custom DKIM domain or aligned bounce domain.

Step 2: Configure SPF and DKIM per sender

Each vendor’s documentation should provide exact DNS records. Do not combine multiple separate SPF TXT records at the same hostname; SPF is evaluated as a single policy record, so consolidate authorized services into one valid SPF record. Keep the number of include mechanisms and lookups within SPF’s protocol limits, and remove vendors you no longer use.

For DKIM, publish the CNAME or TXT records supplied by each vendor and enable signing inside the vendor dashboard. Prefer a custom DKIM configuration that uses your domain or an intentionally managed subdomain such as mail.acmelabs.com.

This is the stage where developers should verify what their application actually emits. Send a password-reset message to a test Gmail or Outlook mailbox, open the raw headers, and identify the visible From:, Return-Path:, DKIM-Signature: d=, and authentication-results lines. An API provider’s setup screen is not proof that production messages are aligned.

Step 3: Publish monitoring DMARC

Acme creates a dedicated mailbox, dmarc-reports@acmelabs.com, then publishes:

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@acmelabs.com; adkim=r; aspf=r

The DNS zone should contain one DMARC TXT record at _dmarc.acmelabs.com. Multiple DMARC records can cause receivers to treat the policy as invalid or unreliable. If an existing record is present, edit and replace it deliberately; do not add a second record beside it.

Step 4: Read reports and correct failures

Acme reviews reports for each source IP and sending domain. A legitimate source that shows an SPF or DKIM failure is not automatically a crisis. First classify it:

• Known sender, aligned pass: expected and healthy.
• Known sender, unaligned pass: fix vendor authentication before enforcement.
• Known sender, authentication fail: investigate missing SPF authorization, unsigned mail, a broken DKIM key, or a changed vendor configuration.
• Unknown sender, DMARC fail: likely spoofing or an unapproved service; do not add it to SPF simply because it appears in a report.

The common mistake is treating every report row as a sender to authorize. Doing that expands your attack surface. An unknown source should be validated against internal ownership, vendor contracts, application logs, and the actual type of message received.

Step 5: Move to quarantine, then reject

Once Acme sees that its employee, product, marketing, and help-desk streams pass with aligned authentication, it changes the policy to:

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

After another review period without unexplained legitimate failures, it changes to:

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

That staged process is much safer than publishing p=reject on day one. It also creates operational discipline: any team that adds a new email vendor must prove aligned SPF or DKIM before using the main domain in a From address.

How to add the TXT record in DNS

The mechanics vary by DNS provider, but the required data is consistent:

Record type: TXT
Host/name: _dmarc
Content/value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
TTL: provider default or your normal DNS TTL

Use these precautions:

• Do not add quotation marks unless your DNS UI adds or requires them. Zone-file syntax may show quoted strings; many web dashboards want only the text inside the quotes.
• Do not publish a record at the root as @. DMARC belongs at _dmarc.example.com, not example.com.
• Do not split a record manually across multiple DNS records. Long TXT values may be displayed in chunks by a DNS provider, but they must still represent one logical TXT record.
• Do not create two DMARC TXT records at the same name. Merge required tags into one record.
• Do not copy a vendor’s example domain. rua=mailto:postmaster@example.com is only an example; reports would go to the wrong place.

DNS changes take effect according to your authoritative DNS publication and recursive resolver caching. A record appearing in your DNS dashboard does not prove outside resolvers can see it yet. Query public DNS after saving.

Verify that your DMARC record works

Verification has three separate layers: DNS publication, authentication configuration, and real message behavior. Passing one layer does not prove the others.

1. Check DNS resolution

Use a DNS lookup tool or run one of these commands:

dig TXT _dmarc.example.com +short

On Windows PowerShell:

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

You should see one logical TXT value containing your policy, such as:

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

If the lookup returns no answer, check the hostname, the authoritative nameservers, and whether you edited the active DNS zone rather than a parked or duplicate zone.

2. Validate the record syntax

A DMARC validator should report that the record is syntactically valid and identify its policy, reporting address, and alignment modes. Syntax validation cannot determine whether your vendors send aligned mail; it only confirms that receivers can parse the published policy.

3. Send real test mail and inspect headers

Send messages from every stream to test mailboxes at more than one major provider. In the received message source, look for an authentication result similar to:

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

The exact header formatting varies by receiver. What matters is the DMARC outcome and the header.from domain. A DKIM pass for vendor.example alone is not enough if the visible From domain is example.com.

4. Confirm reports arrive and make sense

Aggregate reports do not normally appear immediately after publishing a record, and not every receiver sends reports on the same cadence. When they arrive, verify that recognized mail streams are represented and that their pass/fail results match your test messages.

5. Keep monitoring after enforcement

A p=reject record is not a one-time project completion badge. New vendors, changed DKIM selectors, changed bounce domains, acquired brands, and subdomain launches can all change DMARC outcomes. Make DMARC checks part of procurement and release processes.

Common DMARC record builder mistakes

Publishing DMARC before SPF or DKIM is ready

DMARC depends on SPF and DKIM results. Publishing p=reject before legitimate sources are authenticated can cause password resets, receipts, employee email, and support messages to fail delivery. Google specifically warns that enabling DMARC without first setting up SPF and/or DKIM can lead to delivery issues. (support.google.com)

Confusing a pass with an aligned pass

This is the most important technical failure. A vendor may correctly report “DKIM enabled,” but its d= value may be the vendor’s domain. In that case DKIM passes but is not aligned with your customer-facing From domain.

Adding multiple SPF records

DMARC does not fix SPF design mistakes. If you have multiple TXT strings that each begin with v=spf1 at the root domain, receivers can return an SPF permerror. Consolidate services into one SPF policy and test before moving DMARC to enforcement.

Using strict alignment without a domain design

Strict adkim=s and aspf=s can be appropriate for tightly controlled sending infrastructure. They are not an automatic security upgrade for a mixed SaaS stack. Strict alignment can break a valid delegated setup where a service signs as mail.example.com while users see example.com.

Setting p=reject and assuming deliverability is solved

DMARC protects against unauthorized use of your domain in the visible From address. It does not guarantee inbox placement, fix spam complaints, replace list hygiene, or override a receiver’s abuse filters. Google’s sender guidance, for example, also covers authentication, TLS, DNS, message formatting, and keeping reported spam rates below its stated threshold. (support.google.com)

Forgetting about subdomains

Teams often protect example.com while sending campaigns from news.example.com or letting vendors use subdomains. Map every visible From domain. Decide whether each needs an independent DMARC record, should inherit the parent policy, or should be retired.

Sending reports to a third-party domain without authorization

If rua points outside the domain’s organizational domain—for example, to a DMARC monitoring vendor—receivers can require an external reporting authorization DNS record at the report receiver’s domain. The report destination provider normally documents and publishes this record, but you should verify it when reports do not arrive. (dmarc.org)

Choosing between none, quarantine, and reject

The right answer depends on your evidence, not your ambition.

Choose p=none when:

• You do not yet have a complete sender inventory.
• Reports show unknown but possibly legitimate sources.
• A vendor is still configuring custom DKIM or an aligned return path.
• You have not tested critical transactional and support mail.

Choose p=quarantine when:

• Known sources consistently pass aligned DMARC.
• The remaining failures have been investigated.
• You want an enforcement stage that exposes problems through spam placement before a hard rejection request.

Choose p=reject when:

• All authorized senders have been configured and tested.
• Ongoing report review is owned by a real person or team.
• New email services cannot be deployed without authentication review.
• You want the strongest published defense against direct domain spoofing.

For bulk mail to personal Gmail accounts, Google requires SPF, DKIM, and DMARC for senders that send more than 5,000 messages per day to Gmail accounts; its guidance permits a DMARC policy of none for that requirement. That makes monitoring mode a compliance starting point, not necessarily the security end state. (support.google.com)

A practical DMARC operating checklist

Use this checklist whenever you build or change a DMARC record:

1. List all platforms that can send mail using your visible From domain.
2. For each one, record the From domain, Return-Path domain, SPF result, DKIM d= domain, and expected alignment.
3. Publish or confirm one valid SPF record for each relevant envelope-sender domain.
4. Enable DKIM for every platform and use a custom, aligned signing domain where the platform supports it.
5. Publish one TXT record at _dmarc.yourdomain.com with p=none and a monitored rua address.
6. Verify DNS resolution from outside your DNS provider.
7. Send actual messages from every stream and inspect receiver headers for dmarc=pass.
8. Parse aggregate reports and classify every material failure as authorized, misconfigured, or unauthorized.
9. Fix misconfigured authorized streams; do not casually authorize unknown sources.
10. Move deliberately from none to quarantine, then to reject when reports support the decision.
11. Revisit the inventory whenever a team buys, replaces, or enables an email-sending product.

Conclusion: build the smallest correct record first

The best DMARC record builder does not encourage you to add every available tag. It produces a syntactically valid record, makes your rollout stage explicit, and forces the questions that determine whether mail will pass: which systems send as you, what domains they use for SPF and DKIM, and whether either one aligns with the visible From domain.

Start with a monitored record such as v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. Use reports and real-message header tests to fix each sender. Then move to quarantine and reject only when your evidence shows that authorized mail is consistently aligned. That is how a DNS TXT record becomes a dependable anti-spoofing control rather than a risky one-line configuration change.

FAQ

What is the DMARC record hostname?

Publish a TXT record at _dmarc.example.com, replacing example.com with the domain shown in the visible From address. In many DNS dashboards, enter _dmarc in the host field; verify the generated fully qualified name before saving.

What is the minimum valid DMARC record?

A practical minimum is:

v=DMARC1; p=none

However, add rua=mailto:... during deployment so you can receive aggregate reports and see whether your mail streams are passing. A monitoring record without reports gives you far less operational value.

Does DMARC require both SPF and DKIM to pass?

No. DMARC can pass when either SPF or DKIM passes and that passing domain aligns with the visible From domain. Configuring both is still strongly recommended because one mechanism can survive situations where the other fails.

Can I publish more than one DMARC TXT record?

No. Publish one logical DMARC TXT record at a given _dmarc hostname. Merge the tags you need into that record. Multiple separate DMARC policy records can make evaluation fail or become unreliable.

How long should I stay at p=none?

Stay in monitoring mode until you have classified the material sources in aggregate reports and confirmed real mail from every legitimate system passes aligned SPF or DKIM. The deciding factor is evidence of complete sender coverage, not an arbitrary number of days.