DMARC Record Builder for Safer Email

Private working draft

Build the policy your evidence supports.

Stays in this browser

01Domain and live policy

Visible From domain

Use the domain after @, without https://, a path or a port.

Current DMARC TXT value optional but strongly recommended

Paste the live value to reveal settings this draft changes or omits. Find the current DMARC record.

02Choose a controlled stage

Test mode uses t=y to lower the requested action by one policy level. It replaces percentage sampling as the current standard's rollout mechanism.

Start hereMonitorp=noneCollect evidence without requesting quarantine or rejection. Test modeTest quarantinep=quarantine; t=yRequests none while testing the next policy level. EnforcementEnforce quarantinep=quarantineNeeds representative evidence and a rollback route. Test modeTest rejectp=reject; t=yRequests quarantine while testing reject. Highest policyEnforce rejectp=rejectOnly after monitored, tested and approved mail flows.

03Reporting destinations

Aggregate report mailbox

One address per line, up to four. Use a controlled mailbox or trusted processor that can safely handle DMARC aggregate XML.

Add failure reporting (ruf)Advanced and privacy-sensitive. Many receivers do not send these reports.

Failure report mailbox

Failure reports can expose headers, addresses or message content. Review lawful basis, access and retention before enabling them.

04Alignment and subdomains

DKIM alignment

Relaxed alignment accepts an organisational-domain match.

SPF alignment

Strict alignment can disrupt legitimate provider arrangements.

Subdomain policy (sp)

Set only when subdomains need a different policy.

Non-existent subdomains (np)

Applies to mail using a From domain that does not exist in DNS.

05Evidence gate

The selected stage decides which checks are required now. Later-stage checks remain visible so the path is clear.

I checked the current public DMARC policy.I will maintain one policy at _dmarc and reconcile rather than blindly add or replace a record.Required now I control or have approved the report destination.I have checked access, retention and any processor arrangement.Required now I inventoried every legitimate sender.Mailboxes, websites, CRM, billing, support, marketing, alerts and third parties are included.Required now Every sender has an aligned passing path.Representative messages show aligned SPF or DKIM, not merely the presence of DNS records.Later-stage evidence I reviewed aggregate reports across representative traffic.Normal business cycles, low-frequency senders and expected failure sources were included.Later-stage evidence I considered indirect mail flows.Forwarding, mailing lists, gateways, ticketing and delegated senders were tested or understood.Later-stage evidence A change owner and rollback route are recorded.The current value, TTL, observation window, approver and restoration path are available.Later-stage evidence An earlier monitoring or quarantine stage was completed.I am not jumping directly to reject without observed and approved evidence.Later-stage evidence

Reviewable DNS draft

example.com

3 evidence checks remaining

Host / name_dmarc.example.com

Record typeTXT

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

Requested policy: none
Effective test action: none
Characters: 54

Next review stageTest quarantine

Move only when the required evidence exists. There is no universal safe timetable.

Draft review

Receiver behaviour remains discretionary
This draft requests monitoring. Receiving systems can still apply local policy and other evidence.

Monitoring draft created. Complete the required evidence checks before copying.

Draft, not a publishing instruction. This tool cannot verify your senders, message alignment, reporting service, external authorization, receiver behaviour or legal obligations. Back up the live value and use an approved change with rollback.

A defensible rollout

Policy follows evidence, not ambition.

A DMARC record does not create SPF or DKIM alignment. It tells receivers how the domain owner would prefer failed messages to be handled and where supported reports may be sent.

01
Inventory
List every service that sends with the visible From domain and identify its aligned SPF or DKIM path.
02
Observe
Start with aggregate reporting and review representative traffic, including low-frequency and indirect flows.
03
Test one level
Use t=y when the next requested policy needs a controlled test under the current standard.
04
Approve and verify
Preserve the old record and TTL, schedule rollback, then verify public DNS and legitimate mail after any change.

Current primary standards

Built around DMARC's current specification.

The builder uses the May 2026 DMARC standard and its current reporting specifications. Provider-specific implementation guidance still takes priority for your service.

RFC 9989: DMARCPolicy, alignment, discovery and test mode RFC 9990: Aggregate reportingReport format and transport RFC 9991: Failure reportingPrivacy-sensitive failure report handling

DMARC builder questions

What this draft can and cannot decide.

Should I start with p=reject?

No. Start with sender inventory and monitoring, review representative reports, test the next level and keep a rollback path. Reject can disrupt legitimate mail when a sender or indirect flow was missed.

Why does the builder use t=y instead of pct?

RFC 9989 marks the older pct sampling tag as historic. Its current test-mode tag lowers the requested action by one level: reject to quarantine, or quarantine to none.

Do I need both SPF and DKIM to pass DMARC?

No. A message can pass DMARC when at least one authenticated path passes and aligns with the visible From domain. Having both working improves resilience across different mail flows.

Can I send reports to another domain?

Yes, but the destination can require a public authorization record before receivers send reports there. Confirm the reporting provider's exact setup and inspect the published result.

Does p=reject guarantee rejection?

No. It publishes the domain owner's requested handling policy. Receivers retain local discretion, and a generated record cannot guarantee delivery, rejection or inbox placement.

DMARC record builder for safer email policy.

Policy follows evidence, not ambition.

Built around DMARC's current specification.

What this draft can and cannot decide.