Build a valid DMARC record with our guided tool. Select your policy, add reporting, and copy your DNS TXT record.
If not set, subdomains use whatever policy you set above.
Daily XML reports showing who sends email from your domain. Always recommended.
Real-time failure reports for individual messages. Optional — not all providers send these.
Policy applies to all failing messages (default).
Relaxed allows subdomain matching. Strict requires exact domain match.
Relaxed allows subdomain matching. Strict requires exact domain match.
How often aggregate reports are sent, in seconds. Default is 86400 (24 hours). Most providers only send daily regardless of this setting.
Controls when forensic reports are generated. Only applies if you have a ruf= address configured.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol that protects your domain from unauthorized use and spoofing. It builds on two existing protocols — SPF and DKIM — by adding a policy layer that tells receiving mail servers what to do when authentication checks fail.
Without DMARC, anyone can send email that appears to come from your domain. Phishing attacks, business email compromise, and brand impersonation all become trivially easy. Attackers regularly spoof domains to trick recipients into clicking malicious links, wiring money, or handing over credentials. DMARC gives you a mechanism to fight back.
When you publish a DMARC record, you're telling every receiving mail server on the internet: “Here's how to verify that email from my domain is legitimate, and here's what to do if it isn't.” You can choose to monitor (p=none), quarantine (send failures to spam), or reject (block entirely). You also get reports — detailed data showing exactly who is sending email from your domain, whether it passed or failed authentication, and from which IP addresses.
Your DMARC record lives as a DNS TXT record at _dmarc.yourdomain.com. Every time a receiving server gets an email claiming to be from your domain, it queries this DNS record to find your policy. The entire check happens in milliseconds, transparently, with zero impact on the sender or recipient experience.
As of 2024, major email providers including Gmail, Microsoft Outlook, and Yahoo require DMARC for bulk senders. Google's updated sender guidelines mandate DMARC for anyone sending more than 5,000 messages per day to Gmail addresses. But even low-volume senders benefit significantly from DMARC — it improves deliverability, protects your brand reputation, and gives you visibility into your email ecosystem that you simply cannot get any other way.
DMARC works by checking “alignment” between the domain in the visible From header and the domains authenticated by SPF and DKIM. An email passes DMARC if either SPF or DKIM passes AND the authenticated domain aligns with the From domain. This alignment requirement is what makes DMARC significantly more powerful than SPF or DKIM alone — it closes the gap that allows attackers to pass SPF checks while spoofing the From address.
The policy tag (p=) is the most critical part of your DMARC record. It determines what receiving servers do with messages that fail DMARC authentication. Choosing the right policy depends on where you are in your DMARC deployment journey.
Monitor Mode
The starting point for every domain. Receiving servers deliver all email normally regardless of DMARC results but still send you reports. This gives you complete visibility into your domain's email ecosystem without any risk of disrupting legitimate mail. Stay here for at least 2 to 4 weeks while you identify all your sending sources and fix authentication gaps.
Spam Folder
Messages that fail DMARC get routed to the recipient's spam or junk folder. This is the middle ground — you're actively filtering unauthorized email, but if you missed a legitimate sender during monitoring, their messages end up in spam rather than disappearing entirely. Recipients can still find and recover them. Use this after you've reviewed your aggregate reports and fixed authentication for all legitimate senders.
Full Enforcement
Receiving servers block messages that fail DMARC entirely. The email is never delivered — the recipient never sees it, not even in spam. This is the ultimate level of domain protection against phishing and spoofing. It tells the world that you take email security seriously and that any unauthorized use of your domain will be stopped. This is the end goal for every domain.
p=none (2-4 weeks minimum) -- Collect reports. Identify all senders. Fix authentication gaps.p=quarantine; pct=25 (1-2 weeks) -- Quarantine 25% of failing messages. Watch for problems.p=quarantine; pct=100 (2-4 weeks) -- Quarantine all failing messages. Confirm nothing legitimate is caught.p=reject -- Full enforcement. Unauthorized email is blocked.This entire process typically takes 6 to 12 weeks. That might feel slow, but it's dramatically better than jumping to p=reject on day one and discovering that your sales team's email sequences, your marketing automation, or your transactional receipts are all getting blocked.
Every DMARC record is composed of tags — key-value pairs separated by semicolons. Some tags are required, others are optional with sensible defaults. Here is a complete reference for every valid DMARC tag.
| Tag | Required | Example | Description |
|---|---|---|---|
v | Yes | v=DMARC1 | Version. Must be DMARC1. Must be the first tag in the record. |
p | Yes | p=reject | Policy for the domain. Tells receivers what to do with messages that fail DMARC: none, quarantine, or reject. |
sp | No | sp=quarantine | Subdomain policy. Sets a different policy for subdomains. If omitted, subdomains inherit the domain policy. |
rua | No* | rua=mailto:dmarc@example.com | Aggregate report URI. Where daily XML reports are sent. Strongly recommended -- this is how you monitor your email authentication. |
ruf | No | ruf=mailto:forensics@example.com | Forensic report URI. Where individual failure reports are sent. Not all providers support or send these. |
pct | No | pct=50 | Percentage of failing messages the policy applies to. Default is 100. Use lower values for gradual enforcement rollouts. |
adkim | No | adkim=s | DKIM alignment mode. 'r' for relaxed (subdomain match OK), 's' for strict (exact match only). Default is relaxed. |
aspf | No | aspf=s | SPF alignment mode. 'r' for relaxed (subdomain match OK), 's' for strict (exact match only). Default is relaxed. |
ri | No | ri=86400 | Reporting interval in seconds. Requests how often aggregate reports are sent. Default is 86400 (24 hours). |
fo | No | fo=1 | Failure reporting options. Controls when forensic reports are generated: 0 (all fail), 1 (any fail), d (DKIM fail), s (SPF fail). |
* While rua is technically optional, publishing a DMARC record without it means you receive no reports and have no visibility into your domain's email authentication. Always include it.
Deploying DMARC is not a single action — it's a process. Rushing through it leads to blocked legitimate email, confused teams, and rollbacks. Here is the proven approach that minimizes risk and maximizes protection.
DMARC depends on SPF and DKIM. If either one is misconfigured or missing, DMARC cannot do its job. Use our SPF Checker to verify your SPF record and confirm DKIM signing is enabled for every service that sends email from your domain. Fix any issues before proceeding.
Use the generator at the top of this page to create your record. Set the policy to none and add your aggregate report email address. Add the generated TXT record to your DNS at _dmarc.yourdomain.com. This starts the monitoring phase without affecting any email delivery.
Within 24 to 48 hours of publishing your record, you'll start receiving aggregate reports. These XML files show every IP address that sent email from your domain, whether it passed or failed SPF and DKIM, and what the alignment result was. Use a DMARC report analyzer to make sense of the data.
Your reports will reveal every service sending email from your domain -- marketing platforms, CRMs, transactional email providers, and potentially services you forgot about. Make sure each one has proper SPF authorization and DKIM signing configured.
Once all legitimate senders pass DMARC, update your record to p=quarantine with pct=25. This means 25% of failing messages go to spam while the other 75% are still delivered normally. Monitor for a week or two to catch any edge cases.
Bump pct= from 25 to 50, then 75, then 100. At each stage, review your reports to confirm no legitimate email is being quarantined. If something breaks, you can always lower the percentage or drop back to p=none.
When you're confident that every legitimate sender passes DMARC and your quarantine policy at 100% has been running cleanly for at least two weeks, switch to p=reject. This is the final step -- unauthorized email from your domain is now blocked entirely.
DMARC is not set-and-forget. Keep your rua= reports active. Whenever you add a new email service, update your SPF and DKIM records before sending. Periodically check your DMARC record with our DMARC Checker to make sure it's still valid and working.
DNS dashboard > Add Record > TXT > Name: _dmarc > paste record > DNS only > Save.
My Products > DNS > Add > TXT > Host: _dmarc > TXT Value: paste record > TTL: 1 Hour > Save.
Domain List > Manage > Advanced DNS > Add New Record > TXT > Host: _dmarc > Value: paste record.
Domain Management > DNS > Edit > Add TXT > Subdomain: _dmarc > Answer: paste record > Save.
If you're running cold email campaigns, DMARC isn't optional — it's foundational. Cold email operates under heavier scrutiny from receiving mail servers because the recipients haven't opted in to receive your messages. A properly configured DMARC record signals that you're a legitimate sender who takes authentication seriously, which directly affects whether your emails reach the inbox or get filtered.
Without DMARC, your cold email domain is missing one of the three pillars of modern email authentication (SPF, DKIM, DMARC). Gmail, Microsoft 365, and Yahoo all factor authentication into their filtering decisions. A domain without DMARC is more likely to land in spam or get throttled, regardless of how well-written your email content is or how targeted your list may be.
For new cold email domains during the warm-up period (first 2 to 4 weeks of sending), p=none is the safest choice. This lets you collect aggregate reports and build your sending reputation without risking any deliverability hits from enforcement. Once warm-up is complete and your aggregate reports consistently show clean DMARC passes, consider moving to p=quarantine.
Cold email should always go through separate domains from your primary business domain. This is non-negotiable. If a cold email domain gets flagged, throttled, or blacklisted, you want that impact contained to the cold outreach domain — not bleeding into your company's main domain where client communications, invoices, and transactional email live. Each cold email domain needs its own SPF, DKIM, and DMARC records.
Make sure you also have a valid SPF record, DKIM signing enabled (use our DKIM key generator), and proper MX records for receiving replies and bounce notifications. The full stack needs to be in place before you start sending.
Use our Blacklist Checker and Reputation Checker to monitor your sending domains regularly. Catching a reputation issue early — before it cascades into widespread deliverability failure — can save an entire campaign.
ScaledMail handles this automatically for every domain. SPF, DKIM, and DMARC are configured from day one — no DNS headaches, no authentication gaps, no configuration mistakes.
Get Started with ScaledMailThese are the errors we see most often. Some are minor inconveniences; others can completely break your email delivery. Avoid all of them.
The most common and most damaging mistake. Publishing p=reject without monitoring first means any legitimate sender that fails DMARC — a marketing platform you forgot to configure DKIM for, a CRM sending on your behalf without SPF authorization — gets their email silently blocked. You won't even know it's happening until someone complains.
Fix: Always start with p=none. Monitor for at least 2 to 4 weeks. Then escalate through quarantine before reaching reject.
DMARC report addresses must use the mailto: prefix. Writing rua=dmarc@example.com instead of rua=mailto:dmarc@example.com is a syntax error that means you never receive reports.
Fix: Our generator at the top of this page handles the mailto: prefix automatically. If you're writing the record manually, always include it.
DMARC checks alignment against SPF and DKIM results. If neither one is configured, every single email from your domain will fail DMARC. Publishing a DMARC record with a quarantine or reject policy on a domain with no SPF or DKIM is effectively telling receiving servers to spam or block all your mail.
Fix: Verify your SPF record is configured correctly and generate DKIM keys for your domain before publishing any DMARC policy above p=none.
A DMARC record without an rua= tag is technically valid but practically useless during the monitoring phase. You're telling servers to check authentication but never finding out what the results are. You're flying blind.
Fix: Always include an rua= address. Create a dedicated email address like dmarc-reports@yourdomain.com and add it to your record.
If your rua= address is at a different domain (e.g., your DMARC record is for example.com but reports go to reports@dmarcanalyzer.com), the receiving domain needs a DNS record authorizing it. Without this authorization record, many providers will silently discard the reports.
Fix: The receiving domain must publish a TXT record at example.com._report._dmarc.dmarcanalyzer.com with the value v=DMARC1.
Your DMARC record must be published at _dmarc.yourdomain.com, not at the root domain. If you add it as a regular TXT record on yourdomain.com, receiving servers won't find it when they perform the DMARC lookup.
Fix: When adding the TXT record in your DNS panel, set the Host/Name to _dmarc (your registrar will append your domain automatically).
Here are practical DMARC records for common scenarios. You can use these as starting points or generate a custom record with the tool above.
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.comThe minimum viable DMARC record. Monitor-only with aggregate reports. No email is blocked or quarantined. Use this when you're first setting up DMARC and need to discover all your sending sources.
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.comSends failing messages to spam with both aggregate and forensic reporting. A solid middle-ground for domains that have completed the monitoring phase and fixed all authentication gaps.
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; adkim=s; aspf=sMaximum protection. Unauthorized messages are rejected entirely. Strict alignment means only exact domain matches pass -- no subdomain matching allowed.
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comFor cold email domains, p=none is the most common starting point. New domains with limited sending history benefit from monitoring first before enforcing any policy.
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com; fo=1Quarantines 25% of failing messages while delivering the rest normally. The fo=1 tag generates forensic reports for any authentication failure, giving you granular debugging data.
A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com that tells receiving mail servers how to handle emails that fail SPF and DKIM authentication checks. It specifies a policy (monitor, quarantine, or reject) and can include email addresses for receiving authentication reports.
Use the DMARC generator at the top of this page. Select your policy, add your reporting email addresses, configure alignment and percentage settings, then click Generate. Copy the generated record and add it to your DNS as a TXT record with the host/name set to _dmarc.
Start with p=none. This is monitor-only mode -- no email is blocked or quarantined, but you receive reports showing how your domain's email is being authenticated. Review these reports for 2 to 4 weeks before moving to p=quarantine, and eventually p=reject.
Yes. Major email providers including Gmail, Microsoft, and Yahoo now require DMARC for bulk senders. Even for smaller senders, DMARC improves deliverability, protects against domain spoofing, and gives you visibility into who is sending email from your domain. There is no good reason not to have one.
p=none is monitor mode -- emails are delivered normally regardless of authentication results, and you receive reports. p=reject is full enforcement -- emails that fail DMARC authentication are blocked and never delivered to the recipient. The gap between them is significant, which is why a gradual rollout through p=quarantine is recommended.
Log in to your DNS provider or domain registrar. Add a new TXT record with the host/name set to _dmarc and the value set to your generated DMARC record. Set the TTL to 3600 (1 hour). Save and wait for DNS propagation, which typically takes minutes to an hour.
Technically yes, but it's not recommended. DMARC checks alignment against both SPF and DKIM -- a message passes DMARC if either one passes and aligns. So DMARC can work with SPF alone. However, DKIM provides stronger authentication because it survives email forwarding, which SPF does not. For the best deliverability and protection, configure both SPF and DKIM before deploying DMARC.
Your DMARC record becomes active as soon as DNS propagation completes, usually within an hour. However, the full DMARC deployment process -- from initial monitoring through full enforcement -- typically takes 6 to 12 weeks if done properly. Reports start arriving within 24 to 48 hours of publishing your record.
Your DMARC record is just one piece of the email authentication puzzle. Make sure everything else is dialed in:
ScaledMail configures SPF, DKIM, and DMARC correctly for every inbox from day one. No DNS headaches, no authentication gaps, no configuration mistakes. You focus on writing emails that get replies.
Get Started with ScaledMail