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

A DMARC record creator is useful only if it produces a policy that matches your real sending setup. The DNS line is short; the hard part is identifying every service that sends as your domain, ensuring SPF or DKIM aligns, and enforcing the policy only when the reports show you are ready.

DMARC—Domain-based Message Authentication, Reporting, and Conformance—is an email authentication policy published in DNS. It tells receiving mail systems what to do when a message claiming to be from your domain fails DMARC, and where to send aggregate reports about those messages.

For a domain such as example.com, the basic record is:

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

That is a safe starting point for most organizations. It asks recipients to send aggregate reports, but it does not ask them to quarantine or reject mail. Do not copy a p=reject record from a template until you know every legitimate sender passes DMARC.

What a DMARC record does—and does not do

DMARC sits on top of SPF and DKIM. It evaluates the visible domain in the message's From: header, then checks whether either SPF or DKIM passed and aligned with that visible domain.

A DMARC pass requires one of these conditions:

• Aligned SPF pass: SPF passes for the SMTP envelope sender (also called Return-Path or MAIL FROM), and that authenticated domain aligns with the visible From: domain.
• Aligned DKIM pass: A DKIM signature validates, and its signing domain in d= aligns with the visible From: domain.

In practical terms, DKIM is usually the more durable route for SaaS platforms and transactional email providers. Forwarding often breaks SPF because the forwarding server is not authorized in the original sender's SPF record. A properly preserved DKIM signature can still pass DMARC after forwarding.

DMARC does not encrypt mail, stop every phishing message, guarantee inbox placement, or replace secure mail infrastructure. It does give mailbox providers a standardized signal for detecting unauthorized use of your domain and gives you reporting data to find both attacks and overlooked legitimate senders.

Alignment is the part many first-time setups miss

Suppose a customer sees this:

From: Billing <billing@example.com>

Your email platform may use an envelope sender such as bounce.provider-mail.net and sign DKIM as provider-mail.net. SPF and DKIM may each pass, yet DMARC can fail because neither authenticated domain aligns with example.com.

Most email services solve this by asking you to configure a custom return-path domain, a branded tracking domain, and/or DKIM CNAME records. After that setup, the provider might use bounce.example.com for SPF and example.com or mail.example.com for DKIM. Those domains align with example.com under relaxed alignment.

DMARC is evaluated by receivers, not your DNS provider

Publishing a valid TXT record does not force every recipient to handle mail identically. Each receiving organization makes its own filtering and enforcement decisions. Your p= tag is a requested disposition for mail that fails DMARC, not a magic delivery command.

That is why reports and controlled rollout matter. A syntax checker can tell you whether DNS looks valid; it cannot tell you whether an unlisted marketing platform, help desk, CRM, invoice tool, or employee forwarding workflow will fail once you enforce DMARC.

The DMARC record creator inputs you need first

Before generating a record, make an inventory. The most common DMARC deployment failure is not bad punctuation—it is forgetting a sender.

List every system that can send a message with a visible From: address at your domain. Include systems managed by other teams, agencies, and vendors.

Build a sender inventory

Typical senders include:

1. Your primary mailbox provider, such as Google Workspace or Microsoft 365.
2. Transactional email from your application, product, or website.
3. Marketing automation and newsletters.
4. Customer-support, ticketing, chat, and CRM tools.
5. Accounting, billing, receipt, and subscription platforms.
6. Recruiting, HR, surveys, event, and booking software.
7. Security alerts, monitoring, and form plugins.
8. A parent company, franchise, agency, or outsourced service that sends on your behalf.

For each sender, record the visible From: domain, the envelope sender domain if available, its DKIM d= domain, whether it provides custom-domain authentication, and who owns the account. A spreadsheet is enough.

Ask each vendor for its exact SPF, DKIM, and DMARC configuration guidance. Do not assume its general SPF include statement is all you need. An include can make SPF pass while DMARC still fails because the envelope domain is not aligned.

Choose a reporting mailbox you control

DMARC aggregate reports arrive as XML attachments, commonly compressed in ZIP or GZIP files. They are machine-oriented and can become numerous for domains with meaningful mail volume. Use a dedicated address or reporting service rather than a founder's normal inbox.

For a small deployment, create an address such as:

dmarc-reports@example.com

Make sure it can receive external mail and that someone is responsible for reviewing it. If you use a DMARC analytics provider, it will give you a report address such as reports@your-provider.example; place that address in rua=. The analytics service can group IP addresses, identify known platforms, show alignment status, and make rollout decisions substantially easier.

If the report destination is on another domain, DMARC has an external reporting authorization mechanism. Many reporting providers handle this automatically. Do not simply point reports to a third party and assume every receiver will send them; the destination domain may need to publish an authorization TXT record.

DMARC record syntax, tag by tag

A DMARC record is a DNS TXT value made of semicolon-separated tag=value pairs. Tags are case-insensitive in the protocol, but using lowercase consistently makes records easier to maintain. Values must not contain accidental line breaks or smart quotation marks.

The record must begin with the version tag:

v=DMARC1;

The only required policy tag is p, but a useful operational record usually also has rua.

The essential tags

A practical monitoring record:

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

A gradual quarantine record:

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

A full enforcement record:

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

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

p=none is monitoring mode. Receivers still evaluate DMARC and can use their own spam defenses, but you are not requesting a special DMARC disposition. This is the right baseline while you discover senders and fix authentication.

p=quarantine asks receivers to treat DMARC-failing mail as suspicious, commonly placing it in spam or junk. It is an intermediate enforcement setting, but it can still affect genuine mail. Use it after reports show that authorized sources authenticate and align.

p=reject asks receivers to reject mail that fails DMARC. It provides the strongest clear protection against direct spoofing of your domain. It is appropriate only after you have investigated legitimate failures and decided how to handle exceptions.

Relaxed versus strict alignment

With relaxed alignment (adkim=r and aspf=r), subdomains align with the organizational domain. For example, news.example.com can align with example.com under the normal organizational-domain rules.

With strict alignment (adkim=s or aspf=s), the authenticated domain must exactly match the visible From: domain. Strict mode can be valuable for tightly controlled high-risk domains, but it is less forgiving and often incompatible with vendor defaults. Start relaxed unless you have tested strict mode and know why you need it.

Tags that require caution

ruf= requests forensic or failure reports. These reports may contain sensitive message information, are not sent consistently by receivers, and can create privacy and operational concerns. Most organizations should use aggregate rua reports and omit ruf.

fo= controls when failure reports are requested, so it matters only when using ruf. ri= suggests an aggregate report interval in seconds; recipients are not required to honor it. Avoid adding tags merely because a generator exposes them. A smaller, understandable record is easier to operate.

Create and publish your record in DNS

A DMARC record creator should output two separate things: the DNS host/name and the TXT value. Confusing the two is a frequent cause of failed lookups.

For the domain example.com, publish one TXT record at:

_dmarc.example.com

In many DNS dashboards, the zone is already example.com. In that case, enter only _dmarc in the Name or Host field. Other dashboards expect the full hostname. Check the UI's preview or documentation rather than blindly entering both forms.

Worked example: a SaaS company starting DMARC

Imagine Acme Analytics owns acmeanalytics.com. Its team sends employee mail through Microsoft 365, product notifications through an email API provider, marketing through a newsletter platform, and support responses through a help-desk tool.

The team creates dmarc-reports@acmeanalytics.com and configures a DMARC analytics service to receive those reports. It then confirms the following before deploying enforcement:

• Microsoft 365 has DKIM enabled for acmeanalytics.com.
• The application email provider has its required DKIM CNAME records published and shows the domain as verified.
• The newsletter platform uses an authenticated sending domain, not the platform's shared DKIM domain.
• The help-desk tool is configured to send from a properly authenticated support subdomain or to use the company's authenticated domain.

Its initial DNS record is:

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

The team publishes exactly one DMARC TXT record at _dmarc.acmeanalytics.com. It does not add this record to an SPF record, and it does not place it at acmeanalytics.com without the _dmarc label.

After receiving and reviewing reports across normal business cycles—including campaign sends, product receipts, support traffic, and monthly invoices—it finds an old survey service sending as team@acmeanalytics.com without aligned authentication. The team either configures the vendor's custom DKIM domain or changes the visible From address to a domain it controls correctly. Only after the source disappears from DMARC failures does it move toward enforcement.

It can then test quarantine exposure with:

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

If reports remain clean, it raises pct deliberately, ultimately using:

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

The exact observation window is a business decision, not a universal fixed number. It must be long enough to capture every legitimate sending pattern, including low-frequency systems and seasonal campaigns.

DNS publishing checklist

1. Open the authoritative DNS provider for the exact domain in the visible From address.
2. Search existing TXT records for _dmarc; edit the existing DMARC record if one exists rather than creating a second one.
3. Add a TXT record with host _dmarc and your generated value.
4. Use a normal TTL such as 3600 seconds unless your DNS provider or change process requires another value.
5. Save the record and wait for DNS propagation and cache expiry.
6. Query public DNS and validate the visible record before treating the job as complete.

TXT records can be displayed with quoted strings or split into adjacent strings by DNS interfaces. That can be valid DNS representation. What matters is that resolvers reconstruct the intended full DMARC value without extra characters.

Validate the record and test a real message

A record that exists is not necessarily a working DMARC deployment. Validation has three layers: DNS lookup, record syntax, and live-message authentication.

Check DNS directly

On macOS or Linux, run:

dig TXT _dmarc.example.com +short

On Windows PowerShell, run:

Resolve-DnsName -Type TXT _dmarc.example.com

You want to see a single effective record containing v=DMARC1 and your policy. If no answer appears, check whether you used the correct DNS zone, omitted or duplicated the root domain in the host field, or published to a non-authoritative DNS provider.

A DMARC lookup tool can flag malformed tags and duplicate records, but command-line lookup gives you a useful independent check of what public DNS actually returns.

Inspect authentication results in a received email

Send test messages from every platform to a mailbox you control. In Gmail, use Show original. In Microsoft Outlook interfaces, view message headers or source. Look for an Authentication-Results: header resembling:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@acmeanalytics.com header.s=s1;
       spf=pass smtp.mailfrom=bounces.acmeanalytics.com;
       dmarc=pass header.from=acmeanalytics.com

The key result is dmarc=pass, not merely spf=pass or dkim=pass. Also check that the header.from domain is the one you intended to protect.

A message can have multiple DKIM signatures. The relevant result is whether at least one valid, aligned signature supports DMARC. Likewise, a message may have SPF pass from a vendor domain while still failing DMARC due to non-alignment.

How to tell the deployment worked

Your deployment is working when all of these are true:

• A public DNS lookup returns one valid DMARC record at _dmarc.yourdomain.
• Test emails from every authorized source show dmarc=pass at a major receiving mailbox.
• Aggregate reports show recognized, authorized sources passing SPF alignment or DKIM alignment.
• Unknown IP addresses and unauthorized sources are identifiable as failures rather than mysterious noise.
• After enforcement, legitimate mail volume and support tickets show no unexplained delivery regression.

The final point is important. DMARC reports can lag, and individual recipient systems differ. Keep monitoring after switching policy; DMARC is an ongoing domain-control process, not a one-time DNS task.

Read aggregate reports without getting lost in XML

Aggregate reports summarize how receivers evaluated mail claiming to be from your domain. They generally include the reporting organization, source IP address, message count, policy result, the visible header From domain, SPF evaluation, and DKIM evaluation.

A simplified conceptual pattern looks like this:

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

The IP range shown is documentation-only; do not infer that an example IP identifies a real sender. In actual reports, match IPs and domains against your vendor inventory and each vendor's published sending infrastructure.

A useful triage process

For each source shown in reports, classify it as one of the following:

• Known and passing: Document the owner and keep monitoring.
• Known but failing: Fix custom DKIM, SPF alignment, the visible From domain, or the vendor configuration before enforcement.
• Unknown but legitimate: Investigate internally. It may be a forgotten tool, a subsidiary, or a vendor operated by another team.
• Unknown and unauthorized: Preserve the evidence, check for brand abuse, and let enforcement protect recipients once legitimate gaps are closed.

Do not authorize a source by adding its IP address to SPF merely because it appears in a report. First determine what it is. Broad SPF additions create maintenance and spoofing risk, and SPF has a DNS lookup limit that can be exceeded by an overgrown include chain.

If you are launching a product or switching providers, authenticate the sending domain before the first production send. A domain-focused sending platform should provide clear DKIM and custom-domain instructions; compare its configuration needs with the email API reference and setup guides before wiring it into production.

Move safely from monitoring to enforcement

The standard rollout is not “publish reject immediately.” It is inventory, monitor, remediate, stage enforcement, and continue monitoring.

A conservative rollout sequence

Phase 1: Publish monitoring. Use p=none with rua. Confirm the record resolves and test all known senders.

Phase 2: Remediate. Configure authenticated custom domains at every vendor. Prefer DKIM alignment where possible. Remove or reconfigure services that are no longer approved to send as your domain.

Phase 3: Quarantine a portion. Set p=quarantine; pct=25, for example. The percentage applies to mail that fails DMARC, not to all mail. Review reports and business delivery signals.

Phase 4: Increase enforcement. Raise pct as your confidence grows. Some organizations use 50, then 75, then 100; the values and timing should reflect their sender inventory and risk tolerance.

Phase 5: Reject. Move to p=reject; pct=100 only after legitimate traffic is consistently authenticated and aligned.

A note on pct: the protocol defines it as a requested percentage, and recipients ultimately control their own handling. Treat it as a risk-reduction mechanism, not a mathematically exact traffic experiment.

Subdomains deserve an explicit decision

DMARC policy can apply to subdomains if a subdomain has no DMARC record of its own. This surprises teams that use addresses like news.example.com, support.example.com, or mail.example.com.

If your root domain should reject spoofing but your subdomains need a different transition policy, use sp= in the root record. For example:

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

That example rejects failures for the organizational domain but asks for monitoring treatment on inheriting subdomains. Alternatively, publish a dedicated DMARC record at _dmarc.news.example.com for a specific subdomain. Test each sending subdomain rather than assuming root-domain results cover it.

Common DMARC record creator mistakes and fixes

Publishing multiple DMARC records

DMARC expects one record at the queried name. Multiple TXT records containing separate DMARC policies can make the policy invalid or lead to unpredictable results.

Fix: consolidate tags into one record. You may have other unrelated TXT records in the DNS zone; the prohibition concerns multiple DMARC policy records at the same _dmarc name.

Putting DMARC at the root domain

A record named example.com with v=DMARC1 is not a correctly located DMARC policy record.

Fix: use _dmarc.example.com, or _dmarc in DNS interfaces that append the zone automatically.

Treating SPF pass as DMARC pass

SPF can pass for mailer.vendor.example while the customer-facing From address is example.com. Without alignment, DMARC fails.

Fix: configure a custom envelope or return-path domain, or enable aligned DKIM with the vendor. Verify dmarc=pass in an actual received message.

Enforcing before low-volume senders appear

A yearly renewal notice, quarterly accounting system, or occasional recruiting campaign might not show up during a brief monitoring period.

Fix: consult the sender inventory and business calendar. Ask departments and agencies directly, and maintain a process for onboarding new sending services.

Forgetting third-party report authorization

When rua points outside your domain, some receivers may require the external destination to authorize receiving those reports.

Fix: follow your reporting vendor's instructions. The relevant authorization record is published under a hostname based on the policy domain and report destination domain, so copying it incorrectly can prevent reports from arriving.

Relying on a single inbox test

One Gmail or Outlook test is useful but does not represent every mailbox provider or every sending platform.

Fix: inspect headers for each sender, review aggregate reports from multiple receivers, and watch operational outcomes after each policy change.

DMARC, mailbox-provider requirements, and sender reputation

Major mailbox providers publish sender requirements that include authentication expectations, especially for high-volume senders. Their specific thresholds, enforcement details, and interfaces can change, so consult the provider's current official requirements for mail sent to that provider.

The durable takeaway is simple: authenticated, aligned mail is foundational deliverability hygiene. DMARC also makes your domain's sending ecosystem legible. That visibility helps marketing, product, support, and security teams work from one map instead of each adding disconnected vendors.

DMARC is not a substitute for sound list practices. You still need consent, sensible sending behavior, clear unsubscribe handling where applicable, low complaint rates, and clean addresses. Before a campaign or product import, use an email address verification tool to reduce obvious invalid-address risk; then ensure the sending platform is domain-authenticated before it uses your visible From domain.

Choosing a generator or DMARC reporting tool

A free DMARC record creator is enough to build the initial syntax. A reporting service becomes more valuable as the number of senders, domains, and message streams increases.

Choose a generator that lets you explicitly set the policy, report address, alignment modes, and subdomain policy rather than hiding them behind a “secure” preset. It should show the exact host and TXT value, explain its defaults, and validate the published record independently.

For reporting, prioritize these capabilities:

• Source-IP grouping and vendor identification.
• SPF and DKIM alignment breakdowns, not merely pass/fail totals.
• Domain and subdomain filtering.
• Clear handling of external rua authorization.
• Access control appropriate for security and deliverability teams.
• Data retention and privacy terms that fit your organization.

No tool can know whether an unfamiliar source is legitimate. That decision requires ownership data from your organization. Treat tool classifications as leads to investigate, not automatic authorization decisions.

Conclusion: create the smallest safe record, then operate it

The best DMARC record creator does not push every domain straight to p=reject. It creates a valid monitoring record, makes the alignment requirement visible, and supports a disciplined path to enforcement.

Start with v=DMARC1; p=none; rua=mailto:..., publish it at _dmarc.yourdomain, and validate real messages. Use the resulting reports to find all authorized senders, authenticate them with aligned SPF or DKIM, and then increase enforcement in stages. When p=reject is backed by clean reports and tested mail flows, it becomes a meaningful defense against direct spoofing rather than a risky DNS change.

FAQ

What is the simplest valid DMARC record?

The minimum form is v=DMARC1; p=none. In practice, add rua=mailto:your-report-address@yourdomain.com so you can receive aggregate reports and make an informed enforcement decision.

Where do I put a DMARC record in DNS?

Publish a TXT record at _dmarc.example.com for example.com. In a DNS dashboard for that zone, the host field is often just _dmarc; verify whether the dashboard automatically appends your domain.

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

Start with p=none while you inventory and authenticate legitimate senders. Use quarantine for staged enforcement, then use reject only when reports and live tests show that authorized mail reliably passes DMARC.

Why does SPF pass but DMARC fail?

DMARC requires alignment. SPF may pass for a vendor-controlled envelope domain that does not align with the domain in the visible From: header. Configure an aligned custom return-path domain or aligned DKIM signing.

How long should I monitor before enforcing DMARC?

There is no universal number of days. Monitor long enough to capture every normal and low-frequency sender in your organization, remediate failures, and confirm behavior through aggregate reports and real-message header tests.