Free DNS ToolCreate a valid DMARC record for your domain in just a few steps. Configure your email policy, reporting options, and alignment settings, then copy the ready-to-use DNS TXT record.
A DMARC record is a DNS TXT record built from these tags. The required tags define your policy, while the optional tags control reporting and how strictly authentication is enforced.
| Tag | Description |
|---|---|
vRequired | The DMARC version. Always set to DMARC1. |
pRequired | The policy applied to messages that fail authentication: none, quarantine, or reject. |
ruaOptional | Where aggregate reports about all messages sent from your domain should be sent. |
rufOptional | Where failure reports about individual failing messages should be sent. |
spOptional | A separate policy for subdomains, used when they should be treated differently from the main domain. |
adkimOptional | How strictly the domain in the DKIM signature must align with the From domain: relaxed (r) or strict (s). |
aspfOptional | How strictly the domain authenticated by SPF must align with the From domain: relaxed (r) or strict (s). |
foOptional | The conditions under which failure reports are generated, such as when either SPF or DKIM fails. |
rfOptional | The format used for failure reports, such as afrf or iodef. |
pctOptional | The percentage of failing messages the policy applies to, useful for gradual rollouts. |
riOptional | The requested interval in seconds between aggregate reports. |
FAQEverything you need to know about creating, publishing, and maintaining DMARC records for your domain, from policies to reports.
DMARC, short for Domain-based Message Authentication, Reporting, and Conformance, is an email authentication protocol that protects your domain from being spoofed. It builds on SPF and DKIM, tells receiving servers what to do when messages fail authentication, and sends you reports about who is sending email as your domain.
DMARC ties together the results of SPF and DKIM checks and compares them against the From address your recipients see. Your published DMARC record tells receiving servers what to do when authentication fails: take no action (none), deliver to spam (quarantine), or block the message (reject). It also tells them where to send reports about the messages they saw.
DMARC stops attackers from sending phishing and business email compromise attacks that appear to come from your domain. It also gives you visibility into every service sending email as you, and it improves deliverability, since major providers like Gmail and Yahoo now expect authenticated mail. Without DMARC, nobody tells you when your domain is being abused.
The policy (the p= tag) sets what happens to messages that fail authentication. • p=none: monitor only, nothing is blocked. The right starting point. • p=quarantine: failing messages are delivered to spam. • p=reject: failing messages are blocked entirely, the strongest setting. You can also set a separate policy for subdomains (sp=) and apply the policy to a percentage of messages (pct=).
Receiving servers that support DMARC send reports to the address published in your record. Aggregate reports (rua) arrive as XML files summarizing every message sent from your domain, whether it passed, and which service sent it. Failure reports (ruf) can send samples of individual failing messages. Our generator adds the rua address for you.
DMARC passes when at least one of SPF or DKIM passes and the domain it authenticates matches your visible From domain. That match is called alignment: relaxed alignment allows a subdomain match, while strict alignment requires an exact match. This is why SPF alone is not enough, since forwarded or relayed mail can pass SPF but still fail DMARC.
• Start with p=none and read your aggregate reports for a few weeks. • Add every legitimate sending source you discover, then move to p=quarantine. • Once reports show few failures, move to p=reject for full protection. • Set a separate subdomain policy if your subdomains send differently. • Send your reports to a mailbox you actually check.
