DMARC Record Generator: Build, Publish, and Validate Your Policy

A DMARC record generator helps you turn email-authentication choices into a valid DNS TXT record. The generator is the easy part; the important work is choosing a reporting address, discovering every service that sends as your domain, and increasing enforcement without blocking legitimate 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-published policy that tells participating receiving mail systems how to evaluate messages claiming to be from your domain in the visible From: header.

It builds on two older controls:

• SPF authorizes servers or services to send mail for an envelope-sender domain.
• DKIM adds a cryptographic signature to a message and identifies the domain that signed it.
• DMARC requires that SPF or DKIM pass and that the passing identifier aligns with the visible From: domain. It also publishes a requested disposition for failures and an address for aggregate reports.

That distinction matters. Publishing a DMARC record does not repair a broken SPF record, add DKIM signatures, stop every phishing message, or guarantee inbox placement. It gives receivers a consistent way to distinguish authorized, aligned mail from mail that merely displays your domain in the From line.

A simple example illustrates the point. A criminal can send a message with From: CEO <ceo@yourcompany.com> from an unrelated server. If SPF fails for yourcompany.com, no aligned DKIM signature exists, and your DMARC policy is p=reject, a receiver that honors the policy can reject the message rather than deliver it under your brand.

DMARC protects the domain used in the RFC 5322 From: field—the address recipients see. It does not automatically protect lookalike domains such as yourcornpany.com, which uses an rn instead of an m, nor does it protect a domain you do not own. Those need separate defensive measures such as domain monitoring, user education, and, where appropriate, defensive registrations.

Before using a DMARC record generator: inventory your senders

Do not begin by publishing p=reject. Begin by identifying everything that can send mail with your domain in the visible From address. The most common DMARC rollout failure is forgetting a legitimate sender outside the main mailbox provider.

Create an inventory that includes the service, purpose, From domain, envelope-sender/return-path domain, DKIM signing domain, volume, owner, and whether it is still needed. Ask both marketing and engineering teams. A domain may send mail from more places than the IT team expects.

Typical sources include:

1. Google Workspace, Microsoft 365, Fastmail, or another employee mailbox platform.
2. Transactional-email providers used by an application for receipts, password resets, verification links, and alerts.
3. Marketing platforms for newsletters, lifecycle campaigns, and event invitations.
4. CRM, support desk, survey, billing, recruiting, and calendar systems.
5. Website forms, WordPress plugins, printers, scanners, monitoring tools, and server scripts.
6. Agencies or subsidiaries that send using the parent company’s domain.

For each sender, configure its vendor-provided SPF mechanism or custom return-path domain and enable DKIM with a domain you control. Many email platforms provide a “domain authentication” workflow that asks you to add CNAME or TXT records; complete it rather than relying on the vendor’s shared sending domain if your visible From address is your own domain.

Application mail deserves special attention. A developer can often send a message with any From address, but that does not make it DMARC-compliant. Configure the sending domain, DKIM keys, and bounce/return-path domain in the provider dashboard, then test a real message. Consult your provider’s email API setup guides when configuring domain verification and authenticated sending.

Also decide whether subdomains send independently. news.example.com and alerts.example.com can each have their own DMARC records. A policy at example.com can govern subdomains that do not publish a more specific record, but explicit records are often clearer for independently managed sending streams.

How DMARC authentication and alignment actually work

A DMARC receiver extracts the domain in the visible From header, evaluates SPF and DKIM, then tests alignment. DMARC passes if either SPF passes and aligns or DKIM passes and aligns. Both mechanisms do not need to pass.

SPF alignment

SPF is evaluated against the SMTP envelope sender, commonly shown as Return-Path, not necessarily the visible From address. If the envelope sender is empty—for example, for some bounce messages—a receiver can use the HELO/EHLO identity instead.

Suppose a message has:

From: updates@example.com
Return-Path: bounce@mailer.example.com

SPF may pass for mailer.example.com, but it is not aligned with example.com under either strict or relaxed alignment because the domains are unrelated. The message can still pass DMARC if a DKIM signature with d=example.com or an aligned subdomain passes.

DKIM alignment

DKIM verification checks the signature and the d= domain in the DKIM-Signature header. A message signed with d=example.com aligns with From: person@example.com. Under relaxed alignment, a signature from d=mail.example.com normally aligns with From: person@example.com because both share the same organizational domain.

DKIM is frequently the more durable path for third-party senders. SPF can break when an intermediary forwards a message or when a service uses a different envelope domain. A valid, aligned DKIM signature can preserve DMARC success in those cases.

Relaxed versus strict alignment

The adkim and aspf tags control DKIM and SPF alignment modes:

• r means relaxed alignment. Related subdomains under the same organizational domain can align.
• s means strict alignment. The domains must match exactly.

Relaxed alignment is the normal starting choice and the default if you omit the tags. Strict alignment can be useful for organizations with tightly controlled domain architecture, but it can expose overlooked vendor configurations. Treat it as a deliberate hardening decision, not a default checkbox.

The organizational domain is determined using the public suffix rules. For example, mail.example.co.uk and example.co.uk may be related for relaxed alignment, while example.co.uk and otherexample.co.uk are not.

DMARC record syntax: tags a generator should produce

A DMARC record is a TXT record at a special host name. For the domain example.com, the host/name is:

_dmarc.example.com

The record value is semicolon-separated tag/value pairs. Whitespace after semicolons is generally accepted, but use a clean, predictable format. The version tag must come first.

Here is a sound monitoring-stage record:

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

The core tags are:

A few optional tags are often misunderstood. ruf requests failure/forensic reports, but support varies substantially and privacy concerns limit its usefulness; do not make your deployment depend on receiving them. fo expresses failure-reporting options, again only where receivers support reporting. ri requests an aggregate-report interval in seconds, but receivers may choose their own cadence. Aggregate reports are the dependable operational input; individual failure reports are not.

Avoid unsupported or invented tags. Receivers generally ignore unknown extension tags, which can hide a configuration mistake rather than produce a useful error. A generator should emit only tags you understand and can operate.

Generate the right record for your rollout stage

A practical DMARC record generator should ask four questions: what root domain you are protecting, where aggregate reports should go, what enforcement policy you want, and whether subdomains need a separate policy. The outputs below are templates, not records to copy unchanged: replace example.com and the report mailbox with your real values.

Stage 1: monitor all mail

Publish this when you have SPF and DKIM in progress or need to discover unknown senders:

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

A one-hour TTL is a reasonable operational choice while testing, though DNS providers use different interfaces and may impose different minimum TTLs. A longer TTL is also valid once the record is stable. p=none asks receivers to send reports without requesting quarantine or rejection, but a receiver can still apply its own spam and fraud defenses.

Stage 2: quarantine a controlled percentage

After reports show that authorized mail passes DMARC, move to quarantine gradually:

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

Increase pct only after reviewing another representative reporting period. For example, use 25, then 50, then 100 if legitimate streams remain aligned. The percentage is a receiver instruction for messages that fail DMARC; it is not a guaranteed precise sample and should not replace testing.

Stage 3: reject spoofed mail

When reports and tests show no unexplained legitimate failures, use:

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

This is the policy that offers the clearest request to block unauthenticated impersonation. Receivers retain discretion in how they apply DMARC, so no policy is an absolute delivery guarantee. Still, p=reject is materially different from a permanent monitoring record: it tells participating receivers that mail failing aligned SPF and DKIM should not be accepted as your domain’s mail.

A subdomain-aware variant

If your root domain does not send mail but subdomains do, set an explicit subdomain policy while you investigate them:

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

This rejects failed mail from the organizational domain while asking receivers only to monitor unmatched subdomains. It is a temporary containment approach, not necessarily the end state. Once subdomain sending is understood, set sp=quarantine or sp=reject, or publish dedicated records such as _dmarc.news.example.com for subdomains with their own operating model.

Worked example: generate and publish a record for a SaaS company

Assume Acme Cloud owns acmecloud.io. Employees send through Google Workspace, the product sends password resets through a transactional provider, and marketing sends newsletters through a separate platform. Every message uses an address ending in @acmecloud.io.

First, Acme creates a dedicated report destination: dmarc-reports@acmecloud.io. This mailbox should accept high-volume automated XML attachments, or it can forward to a DMARC analysis service. Do not send aggregate reports to a personal executive inbox.

Second, Acme completes the domain-authentication steps in both email vendors. The transactional provider supplies DKIM CNAME records, and the marketing platform supplies its own DKIM records and a custom bounce domain. Acme verifies that each platform signs using acmecloud.io or a subdomain such as mail.acmecloud.io, and checks whether the return-path uses a related domain.

Third, Acme’s DNS administrator adds this record in the DNS zone for acmecloud.io:

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

DNS dashboard fields vary. In a provider that automatically appends the zone name, entering _dmarc as the host produces _dmarc.acmecloud.io. In a provider that expects a fully qualified name, enter _dmarc.acmecloud.io. Check the provider’s preview or resulting DNS record; accidentally creating _dmarc.acmecloud.io.acmecloud.io is a common error.

Fourth, Acme sends test messages from all three sources to mailboxes at more than one major provider. In the received message’s authentication results, it looks for a result shaped like:

Authentication-Results: ...;
  spf=pass ... smtp.mailfrom=mail.acmecloud.io;
  dkim=pass header.d=acmecloud.io;
  dmarc=pass header.from=acmecloud.io

Header wording differs by receiver. What matters is dmarc=pass, plus enough detail to identify whether aligned SPF, DKIM, or both supplied the pass. Acme keeps p=none while it collects reports and finds an old billing tool that is sending as invoices@acmecloud.io without aligned authentication.

Fifth, Acme configures DKIM in the billing tool, validates new messages, and confirms that its report data no longer shows unexplained DMARC failures from known sending infrastructure. It then changes only the policy portion of the record to p=quarantine; pct=25, watches the results, increases to 100, and finally publishes p=reject; pct=100.

This sequence is safer than guessing. It turns DMARC reports into an inventory of actual mail observed by participating receivers rather than relying entirely on a spreadsheet of systems people remember.

Publish the DNS TXT record without formatting mistakes

Use one DMARC record per domain or subdomain. Multiple records at the same _dmarc host can cause receivers to treat DMARC processing as invalid. If an old record exists, edit or replace it rather than adding another TXT value.

The precise DNS UI differs among Cloudflare, Route 53, GoDaddy, Squarespace Domains, and other providers, but the required components are the same:

1. Open DNS management for the domain—not a website builder’s unrelated settings page.
2. Search for existing records named _dmarc.
3. Add or edit a TXT record.
4. Set the host/name to _dmarc or _dmarc.example.com, according to the provider’s naming convention.
5. Paste the generated value as one logical string beginning with v=DMARC1.
6. Save, wait for DNS propagation according to the chosen TTL and resolver caching, then query the public DNS result.

Use a command-line lookup where possible:

dig +short TXT _dmarc.example.com

On Windows PowerShell, you can use:

Resolve-DnsName -Type TXT _dmarc.example.com

The output may place quotes around text or split a long TXT value into multiple quoted strings. DNS permits TXT character-strings of limited length and resolvers concatenate them; this is not automatically an error. What matters is that the reconstructed value is one valid DMARC record.

Do not put the record at dmarc.example.com, at the root example.com host, or inside your SPF TXT record. SPF and DMARC are separate TXT records at different names. Also do not use HTML entities, curly quotation marks, or line breaks copied from a document editor.

Read aggregate reports and decide whether it is safe to enforce

DMARC aggregate reports are machine-readable XML files, commonly compressed, sent by participating receivers to the rua address. They summarize observed messages, source IPs, authentication results, alignment, and the policy disposition. They are not a complete log of all global mail and they are not instant alerts, but they are the central evidence for a safe rollout.

A report viewer can make XML usable. Dedicated DMARC platforms, some email-security products, and open-source parsers can group results by sending source, header From domain, DKIM domain, and SPF domain. If you use a vendor, understand its data retention, recipient permissions, and alerting behavior before directing reports there.

For each DMARC failure, classify it:

• Authorized sender, misconfigured: enable or repair aligned DKIM/SPF.
• Authorized sender, obsolete: stop it, remove its DNS authorization where appropriate, and document the retirement.
• Forwarded or mailing-list mail: assess whether an aligned DKIM signature survives; do not weaken your policy blindly to accommodate every forwarding behavior.
• Unauthorized impersonation: no remediation is needed for the sender; enforcement is the desired outcome.
• Unknown: identify the owner before changing policy.

A useful enforcement gate is not “zero DMARC failures.” Spoof attempts should fail. The gate is that legitimate mail streams are understood and pass DMARC, while remaining failures are known abuse, unwanted legacy traffic, or traffic you deliberately do not authorize.

Pay particular attention to a stream with a high count, a business-critical From address, or a source that appears only periodically, such as monthly invoices or quarterly event campaigns. A few days of clean reports may not expose a sender that runs once a month.

Common DMARC generator mistakes and how to fix them

Using p=none forever

p=none is valuable for discovery, but it does not ask receivers to quarantine or reject DMARC failures. If your goal is to reduce direct spoofing of your domain, establish an owner, a review process, and a planned path to enforcement. Do not move faster than the evidence supports, but do not confuse monitoring with protection.

Forgetting that SPF must align

An SPF pass alone is insufficient if it passes for an unrelated return-path domain. Configure a custom MAIL FROM/bounce domain where your provider supports it, or rely on an aligned DKIM signature. Inspect actual headers rather than assuming a platform’s “SPF verified” status means DMARC passes.

Having more than one DMARC TXT record

This frequently happens when an administrator adds a new record without noticing an old one. Consolidate the desired tags into one record at _dmarc.example.com. Multiple TXT strings that are segments of one long record are different from multiple separate DMARC policies, but most DNS dashboards make the distinction clear enough to avoid ambiguity.

Pointing reports to an external domain without authorization

If example.com sends reports to dmarc@reports-provider.net, receivers may require the external reporting domain to authorize that destination. The authorization record is published at a name shaped like:

reports-provider.net._report._dmarc.example.com

with a TXT value such as:

v=DMARC1

The reporting provider normally manages this for its destination domain. This mechanism prevents a domain owner from directing large volumes of reports to an arbitrary third party. If reports never arrive at an external destination, verify the provider’s required authorization process and the exact domains in the rua address.

Publishing a malformed value

The version tag must be v=DMARC1, policy values are lowercase (none, quarantine, or reject), and each tag needs a semicolon separator. Start with a minimal valid record if debugging:

v=DMARC1; p=none

Then add rua, alignment settings, and subdomain policy one element at a time. A DNS lookup verifies publication; a dedicated DMARC checker can additionally flag syntax and policy issues.

DMARC, bulk-sender rules, and practical deliverability

DMARC is primarily an identity and anti-spoofing control, but it also intersects with deliverability requirements. Large mailbox providers publish sender guidelines that may require or strongly expect SPF, DKIM, and DMARC for higher-volume mail. Requirements are provider-specific, can differ by recipient type and volume, and should be checked directly before a major sending change.

For example, Google’s sender guidelines describe authentication expectations for bulk senders delivering to personal Gmail accounts, including a DMARC record with a policy of at least p=none and aligned SPF or DKIM. That is a floor for a particular provider’s program, not proof that p=none is the right permanent security policy for every domain.

DMARC cannot compensate for poor sending practices. Continue to send wanted mail, maintain clear consent, honor unsubscribes, avoid deceptive headers, and keep complaint rates low. Authentication tells a receiver who is responsible for a message; it does not make an unwanted campaign wanted.

For founders and marketers, the operational implication is clear: involve deliverability, security, engineering, and lifecycle marketing in the rollout. Security may own the DNS policy, but marketing and product teams often own the systems that must authenticate correctly.

A practical DMARC validation checklist

A record is “working” only when DNS publication, message authentication, reporting, and policy behavior agree. Use this checklist after every major change:

• Query _dmarc.yourdomain.com publicly and confirm one intended DMARC policy is returned.
• Send test messages from every approved platform and inspect full message headers for dmarc=pass.
• Confirm the aligned identifier: smtp.mailfrom for SPF and header.d for DKIM should align with header.from under your selected mode.
• Confirm aggregate reports arrive at rua and can be read or processed.
• Investigate every legitimate-looking failure before increasing pct or changing to a stronger policy.
• Test low-frequency and emergency senders, not only the main newsletter and application flow.
• Recheck after changing email vendors, adding a new SaaS platform, changing a From domain, or rotating DKIM configuration.

Keep a copy of the previous DNS value and change record. Rollback is simple if you need it, but rolling back because customer mail was rejected is still disruptive. Gradual policy changes, report review, and real-message header tests prevent most avoidable incidents.

FAQ

What is the simplest valid DMARC record?

The minimum practical syntax is v=DMARC1; p=none published as a TXT record at _dmarc.example.com. Add an rua address to receive aggregate reports; without reporting, you have far less visibility into whether legitimate mail is aligned.

Should I use p=none, p=quarantine, or p=reject?

Start with p=none while you discover and fix authorized senders. Use p=quarantine as a staged enforcement step if needed, then use p=reject after reports show that legitimate mail passes DMARC. The correct pace depends on the completeness of your sender inventory and reporting data.

Does DMARC require both SPF and DKIM to pass?

No. DMARC passes when either SPF passes with alignment or DKIM passes with alignment. Operating both is still recommended because each can fail in circumstances where the other succeeds.

How long does a DMARC record take to work?

DNS visibility depends on your TTL, DNS provider publication, and resolver caches. Once receivers can retrieve the record, they can evaluate it for new messages. Aggregate reports arrive on each receiver’s reporting schedule, so allow enough time to observe normal and low-frequency sending patterns.

Can I put DMARC reports in a different domain’s mailbox?

Yes, but external reporting destinations may need a DNS authorization record from the destination domain. Use the reporting provider’s documented setup instructions and verify that reports are actually accepted before relying on the data.