DMARC Record Builder

The DMARC Record Builder creates Domain-based Message Authentication, Reporting, and Conformance (DMARC) DNS records through an interactive interface that guides you through all available policy tags. Select a policy like p=reject, configure reporting addresses, and get a complete record such as v=DMARC1; p=reject; rua=mailto:[email protected] ready to publish at _dmarc.yourdomain.com.

Understanding DMARC

DMARC is the policy layer that ties SPF and DKIM together into a coherent email authentication system. On its own, SPF checks whether the sending server is authorized. On its own, DKIM verifies the message was not tampered with. But neither tells receiving servers what to do when checks fail, and neither requires that the authenticated domain matches the domain in the From header that users actually see. DMARC fills both gaps: it defines a policy for handling failures and it requires domain alignment, making it much harder for attackers to spoof your domain in phishing campaigns.

When you publish a DMARC record, you are telling every receiving mail server on the internet three things: how to handle messages that fail both SPF and DKIM checks (ignore them, quarantine them, or reject them), where to send reports about authentication results so you can monitor what is happening, and how strictly the authenticated domains must match your From header domain. Without DMARC, a phisher can send an email that fails SPF and DKIM for your domain, but the receiving server has no policy telling it to reject the message -- it might accept it anyway and let it land in the recipient's inbox.

The other major benefit of DMARC is reporting. When you set a rua address, receiving servers send you daily XML reports summarizing every message they saw claiming to come from your domain, along with the SPF and DKIM results for each. These reports reveal unauthorized senders you did not know about -- whether they are phishers abusing your domain, legitimate services you forgot to add to your SPF record, or forwarding servers breaking authentication. This visibility is essential before you tighten your policy, because moving to p=reject without understanding your email ecosystem will almost certainly block some legitimate mail.

How to Build a DMARC Record

1. Choose your policy (p=): none for monitoring, quarantine for spam folder, or reject to block failures
2. Optionally set a subdomain policy (sp=) if subdomains need different handling
3. Set the percentage (pct=) to gradually enforce the policy (e.g., start at 10%)
4. Enter aggregate report (rua=) email address to receive daily XML reports
5. Optionally enter forensic report (ruf=) email address for individual failure reports
6. Configure alignment modes (aspf=, adkim=) for strict or relaxed matching
7. Copy the generated record and publish it as a TXT record at _dmarc.yourdomain.com

DMARC Record Examples

DMARC Tag Reference

When to Use the DMARC Record Builder

• Starting email authentication on a domain with no existing DMARC policy
• Progressive DMARC rollout -- moving from p=none to quarantine to reject over weeks
• Configuring DMARC reporting to gain visibility into who is sending email as your domain
• Setting separate subdomain policies when subdomains have different email requirements
• Auditing alignment settings to decide between strict and relaxed matching for SPF and DKIM
• Meeting compliance requirements that mandate DMARC enforcement (PCI DSS, NIST, government mandates)

How DMARC Authentication Works

The Authentication Flow

When a receiving server gets an email from your domain, it evaluates DMARC in this order:

1. Check SPF: Does the sending IP match the SPF record? Does the RFC5321.MailFrom domain align with the From header domain?
2. Check DKIM: Is there a valid DKIM signature? Does the signing domain (d=) align with the From header domain?
3. Apply DMARC: If either SPF or DKIM passes and aligns, DMARC passes. If both fail or neither aligns, apply the DMARC policy.

Relaxed vs. Strict Alignment

• Relaxed (aspf=r, adkim=r): The authenticated domain and From domain must share the same organizational domain. Example: mail.example.com aligns with example.com.
• Strict (aspf=s, adkim=s): The authenticated domain must exactly match the From domain. mail.example.com does not align with example.com.

Relaxed alignment is the default and is appropriate for most organizations. Strict alignment provides stronger protection but can break legitimate email flows from subdomains.

Recommended Rollout Strategy

Week 1-2:  v=DMARC1; p=none; rua=mailto:[email protected]
           -> Monitor reports, identify all legitimate senders

Week 3-4:  v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]
           -> Quarantine 10% of failures, watch for false positives

Week 5-6:  v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]
           -> Increase to 50%

Week 7-8:  v=DMARC1; p=reject; pct=25; rua=mailto:[email protected]
           -> Begin rejecting 25% of failures

Week 9+:   v=DMARC1; p=reject; rua=mailto:[email protected]
           -> Full enforcement

DMARC Deployment in Practice

The biggest risk in DMARC deployment is moving to p=reject too quickly. Many organizations publish a DMARC record with p=none, collect reports for a week or two, and then jump straight to p=reject because the reports look clean. The problem is that some legitimate email flows only happen periodically -- monthly newsletters, quarterly billing notifications, annual renewal reminders -- and may not appear in a short reporting window. The pct tag exists precisely for this scenario: it lets you enforce your policy on only a percentage of failing messages, so you can catch problems at scale without blocking all your email if something goes wrong.

A common surprise during DMARC deployment is discovering just how many services send email on your behalf. Marketing sends through Mailchimp, support tickets come from Zendesk, invoices go through QuickBooks, password resets come from Auth0, and system alerts route through PagerDuty. Each of these services needs to either pass SPF (by being included in your SPF record) or pass DKIM (by signing with a key aligned to your domain). The p=none monitoring phase is your opportunity to identify all these services before enforcement begins. Use the aggregate reports to build a complete inventory of your email sending services.

The subdomain policy (sp=) deserves careful thought. By default, subdomains inherit the parent domain's policy. If you set p=reject on example.com, it also applies to mail.example.com, app.example.com, and every other subdomain. If some subdomains send email through different infrastructure or are not yet configured for DKIM, set sp=none or sp=quarantine to give yourself room to work on subdomain authentication separately from the main domain.

Frequently Asked Questions

Where do I publish the DMARC record in DNS?

DMARC records are always published as a TXT record at _dmarc.yourdomain.com. For example, if your domain is example.com, the record goes at _dmarc.example.com. This is a fixed location defined by the DMARC specification -- there is no flexibility in the naming.

What is the difference between rua and ruf reports?

The rua tag specifies where aggregate reports are sent -- these are daily XML summaries showing authentication results for all messages. The ruf tag specifies forensic reports -- detailed reports about individual messages that failed authentication. Many providers only support aggregate reports due to privacy concerns with forensic data. Start with rua only; add ruf if you need detailed failure investigation.

Can I send DMARC reports to an email address on a different domain?

Yes, but the receiving domain must publish a DNS authorization record. If your domain is example.com and reports go to [email protected], then monitor.com must publish a TXT record at example.com._report._dmarc.monitor.com with the value v=DMARC1. This prevents abuse where someone publishes a DMARC record directing a flood of reports to an arbitrary email address.

What does pct=25 mean in practice?

It means only 25% of messages that fail DMARC will have the policy applied. The other 75% are treated as if the policy were none (monitored but not acted on). Receiving servers use this percentage probabilistically. This allows you to gradually ramp up enforcement and observe the impact before going to full enforcement at pct=100 (which is the default when pct is omitted).

How do I read DMARC aggregate reports?

DMARC aggregate reports are XML files compressed with gzip or zip. They contain data about every message received from your domain: sending IP, SPF result, DKIM result, and the disposition (none, quarantine, or reject). Reading raw XML is impractical at scale. Most administrators use a DMARC reporting service that parses the XML and presents dashboards showing authentication pass/fail rates, unauthorized senders, and alignment issues.

Does DMARC affect email forwarding?

Yes. Email forwarding is one of the biggest challenges with DMARC enforcement. When a message is forwarded by an intermediary (such as a mailing list or a university alumni forwarding address), the sending IP changes, which breaks SPF. If the forwarder also modifies the message (adding a footer, changing the subject), DKIM breaks too. With p=reject, the forwarded message will be rejected by the final recipient's server. Solutions include ARC (Authenticated Received Chain), which some receivers support to preserve authentication through forwarding.

Related Tools

• SPF Record Builder - Build SPF records with proper syntax
• SPF Record Length Checker - Check SPF record length and lookup limits
• DKIM TXT Record Formatter - Format DKIM records with proper quoting
• DNS Record Set Deduper - Find and remove duplicate DNS records
• Zone File Linter - Check zone files for syntax errors and duplicates