Enter Your Domain
Start by entering the domain you want to create a DMARC record for.
What is DMARC?
DMARC (Domain-based Message Authentication, Reporting & Conformance) is defined in RFC 7489. It builds on top of SPF and DKIM by adding two key capabilities: a policy that tells receivers how to handle unauthenticated mail (monitor, quarantine, or reject), and a reporting mechanism that sends you XML reports on who's sending mail from your domain and whether it's passing authentication.
Crucially, DMARC adds the concept of **alignment** — the domain in the email's visible "From" header must match the domain authenticated by SPF or DKIM. This prevents attackers from passing SPF/DKIM on a different domain while spoofing your domain in the From header.
Why do you need DMARC?
1Header From protection
SPF and DKIM alone don't protect the visible From address — DMARC closes that gap with alignment
2Enforcement policy
You decide what happens to failing mail: monitor it, send to spam, or reject it outright
3Aggregate reporting
Daily XML reports (RUA) show every IP sending mail with your domain and pass/fail rates
4Forensic reporting
Failure reports (RUF) send a redacted copy of individual failing messages for investigation
5Required by Google/Yahoo
Since Feb 2024, bulk senders must have DMARC at p=none minimum to reach Gmail/Yahoo inboxes
6Brand protection
Prevents phishing emails that impersonate your brand from reaching your customers
How DMARC works — step by step
You publish a DMARC TXT record at `_dmarc.yourdomain.com` specifying your policy and report addresses.
A message arrives at the receiving server. It runs SPF and DKIM checks independently.
DMARC alignment is tested: does the authenticated domain (from SPF or DKIM) match the header From domain?
If either SPF+alignment OR DKIM+alignment passes, DMARC passes for the message.
If both fail, the receiver applies your policy: none (deliver), quarantine (spam folder), or reject (bounce).
The receiver collects authentication data for your domain and sends aggregate (RUA) or forensic (RUF) reports to the addresses you specified.
DMARC record syntax
v=DMARC1; p=quarantine; pct=100; sp=reject;
rua=mailto:dmarc-reports@yourdomain.com;
ruf=mailto:dmarc-failures@yourdomain.com;
adkim=s; aspf=s; fo=1Tag reference
v=DMARC1— version, requiredp=— policy for the domainsp=— policy for subdomainspct=— % of failing mail the policy applies torua=— aggregate report recipients (mailto:)ruf=— forensic report recipients (mailto:)adkim=— DKIM alignment: r=relaxed, s=strictaspf=— SPF alignment: r=relaxed, s=strictfo=— failure reporting options (0,1,d,s)ri=— report interval in seconds (default 86400)The three DMARC policies
DMARC alignment explained
Common DMARC failures and fixes
SPF alignment failure
The envelope From (return-path) domain doesn't match the header From — common with ESPs using their own return-path
DKIM alignment failure
The d= domain in the DKIM signature doesn't match the visible From domain — configure your ESP to sign with your domain
Missing RUA address
Without rua= you get no reports and no visibility — always include at least one report address
Subdomains not covered
Add sp=reject to extend your policy to subdomains, or publish separate DMARC records per subdomain
Frequently Asked Questions
To generate a secure DMARC record, start by defining your policy (p). We recommend beginning with p=none to monitor your traffic via reports. Once you've verified all legitimate sources are authenticated, move to p=quarantine and finally p=reject to block unauthorized emails completely. Our generator makes this process simple by providing clear options for each tag.
The 'rua' tag specifies where you want to receive aggregate reports (daily XML summaries), while the 'ruf' tag is for forensic failure reports (details on individual failures). Including at least an 'rua' address is highly recommended, as it provides the data you need to identify spoofing attempts and ensure your legitimate emails are passing authentication.
You can use the 'sp' tag in your root domain's DMARC record to define a policy for all subdomains (e.g., sp=reject). If you don't include an 'sp' tag, the subdomains will inherit the root domain's policy (p). This is a powerful way to protect your entire domain infrastructure with a single record.
The 'pct' (percentage) tag allows you to apply your DMARC policy to only a portion of your failing emails. For example, p=reject; pct=20 tells servers to reject only 20% of failing mail. This is an excellent way to 'ramp up' your security settings gradually and minimize the risk of accidentally blocking legitimate mail during a transition.
These tags define how strictly DMARC checks for alignment between the From address and the authenticated domains. 'r' (relaxed) allows subdomains to match the root domain, while 's' (strict) requires an exact domain match. Relaxed alignment is the most common choice as it provides flexibility for various email platforms.
Start at p=none to collect reports without affecting delivery, then move to p=quarantine and finally p=reject as you confirm all legitimate mail passes SPF and DKIM alignment. Use the pct tag to roll out enforcement gradually, for example pct=25, and watch your aggregate reports at each step before tightening further.
The DNS record itself propagates within minutes to a couple of hours, depending on your TTL. But building confidence to enforce a strict policy takes longer: plan on a few weeks of monitoring aggregate reports at p=none before tightening to quarantine or reject.
You should have at least one passing and aligned, but configuring both is strongly recommended. DMARC checks that SPF or DKIM passes and aligns with your visible From domain, so having both in place gives you redundancy and the highest chance of consistent authentication.