Build a valid DMARC TXT record in seconds - choose your policy, set reporting addresses, and publish to DNS
| Enter Your Domain Name: | |||
| DMARC Policy: | |||
| DMARC Sub Domain Policy: | |||
| Send Aggregate Reports To: | |||
|
|
|||
|
Add RUA Address
|
|||
| Send Failure Reports To: | |||
|
|
|||
|
Add RUF Address
|
|||
| Percentage of Mail Applied To: | |||
| SPF Identifier Alignment: | |||
| DKIM Identifier Alignment: | |||
| Reporting Interval: | |||
| Failure Reporting Options: | |||
|
| |||
A well-configured DMARC record tells receiving mail servers what to do when authentication fails - and keeps you informed with daily reports so you can tighten your policy over time.
Begin with p=none so all mail is still delivered while aggregate reports flow to your rua address. Review the data for 2–4 weeks to identify every sending source before moving to a stricter policy. Jumping straight to reject can block legitimate mail.
The rua tag is where daily aggregate reports are delivered - it's your primary visibility tool. Without it you're flying blind. Set it to an address you actively monitor, or pipe it into a DMARC reporting service that parses the raw XML for you.
Your ESP, CRM, transactional email provider, support platform, and any other service that sends mail using your From domain all need valid SPF or DKIM before you tighten policy. Missing even one source will cause legitimate mail to fail once you enforce quarantine or reject.
p=none is recommended for new setupsrua) - this is where your daily DMARC reports will be sentsp), alignment modes, percentage (pct), and reporting interval_dmarc.yourdomain.com and paste the value - then use the DMARC Lookup tool to confirm it's liveTXT record at _dmarc.yourdomain.com is valid - multiple records cause a "permerror" and DMARC fails entirely. Also remember that pct= only affects enforcement, not reporting: reports are always sent at 100% regardless of your pct value.
This DMARC record generator guides you through the configuration step-by-step, so you get a correctly formatted record without needing to understand every tag. Choose your policy, set your reporting address, and the tool handles the rest.
Simply enter your domain name and select your preferred policy. The tool offers clear explanations for each option, allowing you to choose whether to monitor (p=none) email activity for informational purposes, quarantine (p=quarantine) suspicious emails for further review, or reject (p=reject) unauthenticated emails outright. You can also specify email addresses to receive reports detailing authentication results - valuable for identifying unauthorized senders and potential security threats.
No technical expertise required. The generator handles the complexity of crafting a valid DMARC record, saving you time and ensuring your reporting is in place from day one. With aggregate report data in hand, you can make informed decisions about tightening your policy and protecting your domain from email-based attacks.
Once you have it set up, it's time to test it with our very own Email Tester.

| TAG | MEANING |
|---|---|
| v | Required: Specifies the version of the DMARC protocol being used. Always set to v=DMARC1 for the current DMARC protocol version. |
| p |
Required: Specifies the policy to be enacted by the receiving mail server when DMARC authentication fails. This tag determines what action should be taken if an email fails DMARC checks.
Possible Values:
|
| sp | Specifies the policy for handling messages from subdomains of the DMARC-aligned domain. Subdomains inherit policies from their parent domain unless explicitly overridden. |
| rua | Specifies the URI(s) to which aggregate DMARC reports should be sent, for example: rua=mailto:your@email.com. Aggregate reports provide statistics about DMARC usage and authentication results. |
| ruf | Specifies the URI(s) to which forensic DMARC reports should be sent (reports about individual failed messages), for example: ruf=mailto:your@email.com. Forensic reports contain detailed information about specific messages that failed DMARC checks. |
| adkim |
Specifies how DKIM (DomainKeys Identified Mail) alignment should be handled. DKIM alignment verifies that the DKIM signature on an email matches the sender's domain.
Possible Values:
|
| aspf |
Specifies how SPF (Sender Policy Framework) alignment should be handled. SPF alignment verifies that the SMTP MAIL FROM domain matches the domain used in the RFC5322.From header field.
Possible Values:
|
| fo |
Determines the level of detail in forensic reports generated when DMARC authentication fails.
Possible Values:
|
| rf |
This tag specifies the format for forensic DMARC reports sent to the specified reporting addresses (ruf).
Possible Values:
|
| pct | Specifies the percentage of messages subjected to DMARC policy filtering. Allows gradual enforcement of DMARC policies to monitor impact before full enforcement. Any integer value from 0 to 100. |
| ri | Specifies the interval at which aggregate DMARC reports should be generated and sent by receivers to the specified reporting addresses (rua). For example: ri=86400 indicates that aggregate reports should be sent daily (every 86400 seconds). |
Are You Ready To Experience The Difference?
Become a part of the Campaign Cleaner community today, and join countless satisfied customers who have witnessed significant improvements in their email deliverability and campaign success. Don't let HTML issues hold you back; let Campaign Cleaner optimize your campaigns and boost your inbox rates.