Network Tools
Email authentication / DNS TXT

DMARC Record Generator & Validator

Import an existing policy or build one tag by tag. Get a normalized record, exact byte and DNS chunk analysis, external-report authorization instructions, and a safer path to enforcement.

Runs entirely in your browser RFC 9989 + legacy aware No signup or network calls
Local syntax analysis only. This tool does not query DNS or a Public Suffix List, cannot prove which domain is organizational, and cannot confirm external report authorization. Supply the organizational domain you have independently verified when you want boundary-aware guidance.

1. Publication context

The protected domain becomes the DNS owner _dmarc.your-domain. Do not include the _dmarc label here.

ASCII or A-label domain, without protocol, path, port, or trailing dot.
Optional. Enter only after checking your DNS-tree or suffix context elsewhere.
Controls explanations only; no PSL assumption is made.
Current mode flags removed legacy tags and size suffixes; legacy mode retains them for installed-base compatibility.

2. Import or normalize a record

Paste a raw value, quoted TXT fragments, or a conventional zone-file TXT line. Import checks source order and duplicates before mapping recognized tags into the editor.

3. Policy editor

Blank optional fields are omitted. Output keeps v first and, when present, p second for broad compatibility.

Core policy and scope
Case-sensitive and must be the first tag.
Required by RFC 7489. Under RFC 9989, omission has effective p=none when processing continues; a valid rua is needed for that monitoring flow.
Useful on organizational-domain or PSD records.
Current in RFC 9989; originated in RFC 9091.
Requests that receivers not apply the stated policy and use special handling; RFC 9989 expects quarantine→none or reject→quarantine.
Use n only for a verified organizational domain, y only for a verified public suffix, or u/omit to leave discovery unresolved.
RFC 7489: integer 0–100. Removed by RFC 9989 due to inconsistent use.
Identifier alignment
Strict requires exact DKIM d= and From-domain equality.
Strict requires exact SPF MAIL FROM and From-domain equality.
Report destinations
Comma or line separated. Use mailto:address@domain. Legacy caps look like !10m.
Failure reports can expose message content and personal data; receiver support is limited.
Failure and aggregate report controls
Colon-separated 0, 1, d, s. Base options 0 and 1 conflict.
RFC 7489 registered afrf; removed from the RFC 9989 policy tag set.
Positive integer request; receivers choose actual scheduling.
Extension tags Preserved after known tags. Unknown tags are validly ignorable, but this tool checks their token syntax, duplicates, ASCII, and collisions.

Live normalized record

Fix all errors before publishing. Warnings document operational or standards-profile risks.

Checking record…
    Host / name _dmarc.example.com
    Type TXT
    TXT value Current profile 
    v=DMARC1; p=none; rua=mailto:[email protected]
    0 characters
    0 UTF-8 bytes
    1 TXT strings
    0 longest tag bytes

    Zone-file-safe TXT strings

    

      
    
        
        
        
        
        
      
    
      
    
      A fragment link contains every field, including report addresses, in the URL after #. It is not uploaded by this tool.
    
    

    
    
      
    External reporting authorization
    
      
    Different organizational domains generally require the report receiver to authorize your policy domain. The following is derived locally and is not a DNS result.
    
      
    
      
      
    
      
  
      

      


      
  
      Safer monitoring → quarantine → reject rollout
      
  
      Policy is a request and receivers retain local discretion. Advance only from evidence gathered across normal business cycles, not from elapsed time alone.
      
  
      
    
      
      
      Stage 1
      
      
      Monitor with p=none
      
      
      Collect aggregate data without asking receivers to change handling.
      
      
        
        
      • Inventory every legitimate sender and forwarding path.
        • 
        
      • Make at least one of DKIM or SPF pass with DMARC alignment.
        • 
        
      • Explain all material failures before enforcement.
        • 
      
      
    
      
    
      
      
      Stage 2
      
      
      Quarantine, then stabilize
      
      
      With t=y, receivers are asked not to apply the stated policy and may use special handling; RFC 9989 expects a one-level step-down. Remove t=y only after review.
      
      
        
        
      • Review high-value, third-party, and indirect mail flows.
        • 
        
      • Confirm subdomain policy and non-existent-domain intent.
        • 
        
      • Keep a documented rollback and incident owner.
        • 
      
      
    
      
    
      
      
      Stage 3
      
      
      Reject with continuous review
      
      
      Request rejection only when legitimate sources consistently pass aligned authentication.
      
      
        
        
      • Check acquisition, vendor, and dormant-domain changes.
        • 
        
      • Continue aggregate monitoring after enforcement.
        • 
        
      • Investigate sudden failures before weakening policy.
        • 
      
      
    
      
  
      

      


      
  Organizational domains, subdomains, and lookup limits
  
      
    
      An organizational domain is determined by DMARC policy discovery, not by simply taking the last two labels. RFC 9989 uses a bounded DNS tree walk; older RFC 7489 implementations used a Public Suffix List heuristic. This offline tool deliberately does neither.
      
    
      In RFC 9989, psd=n affirmatively marks the record's domain as the Organizational Domain for itself and its descendants; psd=y marks a Public Suffix Domain, while psd=u or omission leaves the boundary to tree-walk discovery.
      
    
      At an organizational-domain record, p governs the domain and is the fallback for descendants; sp can override existing subdomains and np can override non-existent subdomains. A DMARC record published directly on a subdomain uses its own p; descendant controls in that subdomain record are not a substitute for policy at the organizational domain.
      
    
      Publish one DMARC policy TXT record at the calculated owner. Multiple DMARC policy records can prevent reliable policy discovery. A long TXT value may be split into multiple quoted character-strings inside one TXT resource record; do not create multiple policy records.
      
  
      

      


      
  Standards profile and tag reference
  
      
    
      RFC 7489 defined the original informational DMARC protocol. RFC 9091 added the experimental np behavior. RFC 9989, published as a Proposed Standard in May 2026, obsoletes both, adds bounded DNS-tree discovery plus t and psd, and removes pct. RFC 9990 now defines aggregate reporting; RFC 9991 defines failure reporting. Legacy report-size suffixes are obsolete and current reporters ignore them.
      
    
      
      
        
      TagPurposeKey constraint
      
            
      
        
      vProtocol versionExactly DMARC1 and first
      
        
      p / sp / npDomain, subdomain, non-existent-subdomain policynone, quarantine, or reject; current-profile p omission has effective none when processing continues
      
        
      psdOrganizational or public-suffix boundary signaln means Organizational Domain; y means Public Suffix Domain; u leaves discovery unresolved
      
        
      t / pctCurrent testing / legacy samplingDo not combine; pct is removed in RFC 9989
      
        
      adkim / aspfDKIM / SPF identifier alignmentr (relaxed) or s (strict)
      
        
      rua / rufAggregate / failure report URIsmailto is universally required; external destinations need authorization
      
        
      foFailure report triggers0 or 1 base, optionally d and/or s
      
        
      rf / riLegacy failure format / report intervalLegacy profile only; receivers may ignore requests