DNS DMARC Policy Record Builder & Syntax Validator

DNS DMARC Policy Record Builder & Syntax Validator

Generate RFC 7489 compliant DMARC DNS TXT records with policy enforcement (none/quarantine/reject), rua/ruf aggregate reports, and alignment tags.

Presets:
Enforcement Percentage (pct=)100%
Domain: example.comPolicy: rejectPct: 100%
Security Health ScoreSecurity Grade A+ (100/100)

Maximum defense against spoofing, BEC attacks, and phishing impersonation.

100/100
DMARC DNS TXT Value
v=DMARC1; p=reject; rua=mailto:[email protected]!10m
BIND 9 / RFC 1035 Master Zone Syntax
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]!10m"
DNS Management Table
Host / Name_dmarc(or _dmarc.example.com)
Record TypeTXT
TTL3600 (or Auto)
Length: 60 charsUDP DNS: < 255 B (Single String)
RFC 7489 Valid
Policy Statep=reject (100%)
Reporting Feeds1 RUA / 0 RUF
Alignment ModesDKIM: Relaxed | SPF: Relaxed

RFC 7489 Compliant Syntax

Instantly formats valid v=DMARC1 tags with strict tag order and validation.

Zero-Knowledge In-Browser Builder

All policy calculation and parser execution happen client-side with zero telemetry.

Multi-Platform Export Engine

Generate BIND zone records, Cloudflare/Route53 configs, dig CLI probes, and RFC 7489 Section 7.1 external reporting authorizations.

Technical Reference & Architecture Guide

DNS DMARC Policy Record Builder & Syntax Validator — Reference Guide

Generate RFC 7489 compliant DMARC DNS TXT records with policy enforcement (none/quarantine/reject), rua/ruf aggregate reports, and alignment tags.

Key Parameters & Controls

v (Protocol Version)Enum ("DMARC1")

Identifies the record as a DMARC policy specification. Must appear as the first tag in the TXT string, uppercase, followed by a semicolon.

Default: DMARC1
p (Receiver Policy)Enum ("none" | "quarantine" | "reject")

Enforcement policy applied by receiver MTAs when messages fail both SPF and DKIM authentication. 'none' monitors traffic without rejection; 'quarantine' diverts failures to spam/junk; 'reject' outright denies delivery at the SMTP transaction layer.

Default: none
sp (Subdomain Policy)Enum ("none" | "quarantine" | "reject")

Overrides the organizational policy 'p' specifically for all subdomains. Explicitly setting 'sp=reject' safeguards non-sending or newly provisioned subdomains from spoofing.

Default: Inherit (same as p)
rua (Aggregate Feedback Reporting URIs)URI List (mailto:address)

Comma-separated list of mailto: URIs receiving daily aggregated XML telemetry reports summarizing authentication outcomes, IP sources, and volume.

Default: None
ruf (Forensic Failure Reporting URIs)URI List (mailto:address)

Comma-separated list of mailto: URIs designated for immediate redaction-formatted failure incident telemetry generated upon specific verification failures (RFC 6591 AFRF).

Default: None
pct (Policy Enforcement Percentage)Integer (0 - 100)

Percentage of failing messages to which the specified policy 'p' or 'sp' is applied. Facilitates a staged rollout (e.g., quarantine 25% -> 50% -> 100%) before enforcing full rejection.

Default: 100
adkim / aspf (Alignment Modes)Enum ("r" | "s")

Specifies DKIM and SPF domain alignment string strictness. 'r' (relaxed) permits organizational domain matches (subdomain.example.com vs example.com); 's' (strict) enforces an exact FQDN match.

Default: r (relaxed)

Pro Tips & Best Practices

Start on 'p=none' for 2

Start on 'p=none' for 2 to 4 weeks while monitoring 'rua' aggregate XML reports to identify all legitimate third-party sending services (SendGrid, Google Workspace, Zendesk). Once SPF and DKIM align across 99%+ of valid streams, advance to 'p=quarantine; pct=25', incrementing to 100%, and finally locking to 'p=reject'.

If your domain is 'example.com'

If your domain is 'example.com' and your 'rua' destination points to 'mailto:[email protected]', RFC 7489 Section 7.1 requires the target domain to host a DNS TXT record at 'example.com._report._dmarc.thirdparty.com' containing 'v=DMARC1;'. Without this handshake, receiving mail servers will suppress reports to prevent DDoS attacks.

Threat actors rarely spoof apex

Threat actors rarely spoof apex domains directly; they register or spoof arbitrary subdomains (e.g., accounts.example.com). Setting 'v=DMARC1; p=none; sp=reject; rua=mailto:...' leaves your apex email deliverability unaffected while instantly neutralizing subdomain phishing.

When an email passes through

When an email passes through intermediate relays, forwarders, or automated mailing lists, the RFC 5321 MAIL FROM envelope IP changes, invariably causing SPF alignment to fail. Cryptographic DKIM signatures survive transit unaltered, preventing false-positive rejections under strict DMARC enforcement.

Common Gotchas & Troubleshooting

External aggregate reports ('rua') are never received from major providers (Google, Yahoo, Microsoft)

Verify that your rua URI includes the mandatory 'mailto:' scheme prefix (e.g., 'mailto:[email protected]'). If reporting to a third-party domain, ensure the target domain has published the external report authorization record ('senderdomain.com._report._dmarc.targetdomain.com' TXT 'v=DMARC1;'). Additionally, verify recipient inbox storage quotas.

Valid emails sent via marketing platforms or CRM systems land in junk or bounce after setting 'p=quarantine' or 'p=reject'

Check your aggregate XML reports for SPF and DKIM alignment failures. Ensure the third-party sender has a dedicated custom DKIM selector matching your RFC 5322 From: header domain rather than sending signed solely by their shared domain. If using custom Return-Path (SPF), configure the matching CNAME record in DNS.

DNS lookup tools report 'DMARC Record Not Found' or 'Duplicate DMARC Records Detected'

DMARC records must strictly be published as a TXT record at the subdomain '_dmarc.yourdomain.com' (never at the apex '@' or naked hostname). Ensure there is exactly one TXT record starting with 'v=DMARC1'; RFC 7489 dictates that publishing multiple DMARC records causes receiving MTAs to invalidate all records and execute no policy.

Frequently Asked Questions

What is the technical relationship between SPF, DKIM, and DMARC?▼

SPF (RFC 7208) authenticates the sending server's IP address against the envelope return-path (MAIL FROM). DKIM (RFC 6376) cryptographically signs email headers and body content to verify authenticity in transit. DMARC (RFC 7489) binds both protocols to the user-visible 'From:' header (RFC 5322), requiring identifier alignment and instructing receiving MTAs on how to handle authentication failures while providing feedback reporting.

Does an email need to pass both SPF and DKIM to achieve DMARC alignment?▼

No. Under RFC 7489, an email achieves DMARC pass if EITHER SPF alignment OR DKIM alignment passes. It does not require both simultaneously. However, establishing alignment across both mechanisms provides critical redundancy against forwarding breakages.

What is the distinction between relaxed ('r') and strict ('s') alignment modes?▼

In relaxed mode ('r', default for both aspf and adkim), the domain in the SPF envelope (Return-Path) or DKIM signature ('d=' tag) must share the same organizational root domain as the 'From:' header (e.g., mail.example.com aligns with example.com). In strict mode ('s'), the domain in the signature or envelope must match the 'From:' header FQDN character-for-character.

Why do automated mailing lists and auto-forwarders break DMARC?▼

Auto-forwarders replace the SMTP envelope sender IP address with their own, breaking SPF validation. Furthermore, mailing lists frequently append footers or modify subjects, invalidating the DKIM cryptographic body hash (bh). To mitigate this industry-wide issue, MTAs employ ARC (Authenticated Received Chain, RFC 8617) to preserve the original authentication verdict across hops.

What is the difference between 'rua' aggregate and 'ruf' forensic failure reports?▼

'rua' reports provide consolidated daily XML files detailing aggregate send volumes, originating IP addresses, and authentication results across all receiving networks without message content. 'ruf' reports send real-time redacted copies of individual messages that failed authentication. Due to privacy and GDPR concerns regarding PII exposure in message bodies, many modern mail providers (like Google and Microsoft) no longer dispatch 'ruf' reports.

Related Tools & Utilities

All Tools →
DNS CAA (Certification Authority Authorization) Record GeneratorSecurity

Construct RFC 8659 compliant DNS CAA records to restrict SSL/TLS certificate issuance to trusted authorities (Let's Encrypt, DigiCert, Sectigo).

Open tool→
DNS DKIM TXT Record Builder & Selector HelperSecurity

Generate RFC 6376 compliant DNS DKIM TXT records with selector, public key formatting (v=DKIM1; k=rsa; p=...), and verification guidance.

Open tool→
MTA-STS Policy & TLS-RPT DNS Record GeneratorSecurity

Generate RFC 8461 Mail Transfer Agent Strict Transport Security (MTA-STS) policy files and _mta-sts/_smtp._tls DNS TXT records.

Open tool→
JWT Token Decoder & Security InspectorSecurity

Decode JSON Web Tokens, inspect header/payload claims, calculate expiration time and verify integrity locally.

Open tool→
Cryptographically Secure Password GeneratorSecurity

Generate ultra-secure passwords using Web Crypto API with custom length, symbols, and memorability.

Open tool→
Multi-Algorithm Hash Generator (SHA-256, SHA-512, MD5)Security

Compute instant cryptographic hashes entirely in browser with zero server transmission.

Open tool→