How to set up a DMARC record (step-by-step guide for 2026)
A company I know spent three months wondering why their sales team's cold emails were not getting replies. They had hired a copywriter. They had tested subject lines. Nothing moved.
When someone finally checked their DNS, the problem was obvious in about 30 seconds. No DMARC record. Their SPF had a syntax error. DKIM had not been configured when they switched to Google Workspace six months earlier. Every email leaving their domain looked, to Gmail and Outlook, exactly like it might be forged.
DMARC is not complicated to set up. The syntax is a single line of text. The DNS change takes about two minutes. Most of the time and effort goes into the preparation: making sure SPF and DKIM are working first, monitoring the initial reports, and graduating the policy from monitoring-only to actual enforcement.
This guide walks through the whole process, in order, without skipping the parts that actually cause problems.
Key takeaways
- ✓DMARC is a DNS TXT record that tells receiving mail servers what to do when an email fails SPF or DKIM authentication checks
- ✓Google and Yahoo made DMARC mandatory for bulk senders (5,000+ emails/day) in February 2024; the absence of DMARC hurts inbox placement for all senders
- ✓You must have working SPF and DKIM before DMARC does anything useful; DMARC without them is an empty policy
- ✓Start at p=none to monitor before enforcing; jumping straight to p=reject on a misconfigured domain will block your own legitimate emails
- ✓DMARC generates reports that tell you who is sending email using your domain, which is the primary way you find out if someone is spoofing you
- ✓The typical implementation timeline is two to four weeks from initial setup to full enforcement
On this page
- 1.What is DMARC?
- 2.Why DMARC matters
- 3.How DMARC works
- 4.Understanding DMARC policies
- 5.DMARC record structure explained
- 6.Step 1: Verify SPF and DKIM first
- 7.Step 2: Create your DMARC record
- 8.Step 3: Add DMARC to DNS
- 9.Step 4: Validate the record
- 10.Common DMARC errors
- 11.DMARC for Google Workspace
- 12.DMARC for Microsoft 365
- 13.DMARC best practices for 2026
- 14.One-minute DMARC audit
- 15.Quick answers
- 16.Frequently asked questions
What is DMARC?
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a DNS record that tells receiving mail servers what to do when an email fails SPF or DKIM authentication. It also sends you reports about those failures.
SPF tells mail servers which IP addresses are allowed to send email for your domain. DKIM signs each email with a cryptographic signature that proves the content was not changed. DMARC is the policy layer that sits on top of both: if either check fails, what should the receiving server do?
Without DMARC, the receiving server makes its own decision based on its internal policies. That decision might be spam folder, it might be inbox, it might be delivery with a warning. With DMARC, you control the outcome.
A simple analogy: SPF is a list of approved delivery drivers for your address. DKIM is a tamper-evident seal on each package. DMARC is the instruction you leave at reception: “If the driver is not on the approved list or the seal is broken, refuse delivery and send me a report.”
DMARC also addresses a specific problem the other two records do not: domain spoofing. Anyone can send an email claiming to be from your domain. SPF only catches this if the attacker is not using an authorized sending IP. DKIM only catches it if the email was altered. DMARC with p=reject means that any email from your domain that fails authentication is blocked entirely, which closes the spoofing vector regardless of how the attack is attempted.
Why DMARC matters
DMARC matters for two distinct reasons: security and inbox placement. Most guides focus on one or the other. Both are real.
Direct answer: A domain with no DMARC is visible to spam filters as unmanaged and unverified, which depresses inbox placement. It is also vulnerable to phishing attacks that impersonate your brand to customers and partners.
| Without DMARC | With DMARC (p=quarantine or reject) |
|---|---|
| Domain can be spoofed freely | Spoofed emails are quarantined or rejected |
| No visibility into who sends from your domain | Aggregate reports show all sending sources |
| Spam filters treat domain as lower trust | Spam filters treat domain as actively managed |
| Inbox placement affected by unknown senders using your domain | Only authenticated senders can deliver |
| Google/Yahoo bulk sender requirements not met | Google/Yahoo requirements met |
| Phishing attacks using your brand harder to stop | Phishing attacks using your domain are blocked at delivery |
The phishing angle is the one that hits businesses unexpectedly. The Verizon 2024 Data Breach Investigations Report found phishing involved in 36% of breaches. A significant share of those phishing emails work because the sending domain lacks DMARC enforcement, which means the forged email gets delivered.
The deliverability angle is more immediately practical for most businesses. Google and Yahoo made DMARC mandatory for bulk senders in February 2024. Even for senders below the 5,000 emails/day threshold, the absence of DMARC is a negative signal to spam filters. Domains with DMARC at p=quarantine or p=reject have measurably better inbox placement than equivalent domains without it.
How DMARC works
DMARC runs four checks in sequence when an email arrives claiming to be from your domain.
Direct answer: When an email arrives, the receiving server checks SPF, then DKIM, then whether the results align with your “From” domain, then applies whatever policy your DMARC record specifies.
Step 1: SPF check
The receiving server looks up your SPF record and checks whether the sending IP is on your authorized list. If it is, SPF passes. If not, SPF fails.
Step 2: DKIM check
The receiving server looks up your DKIM public key in DNS and uses it to verify the cryptographic signature in the email header. If the signature is valid and the email was not altered, DKIM passes.
Step 3: Alignment check
This is the part DMARC adds. Passing SPF or DKIM is not enough on its own; the domain in your "From" header must align with the domain that passed the check. This alignment requirement is what prevents attackers from using a legitimate SPF record from one domain to send email appearing to come from another. Relaxed alignment (the default) allows subdomain matches. Strict alignment requires an exact match.
Step 4: Policy enforcement
If both SPF and DKIM fail alignment (or neither passes), DMARC applies the policy in your record: p=none (deliver normally and send a report), p=quarantine (send to spam folder), or p=reject (refuse delivery entirely).
Understanding DMARC policies
| Policy | Purpose | What happens to failing emails | When to use |
|---|---|---|---|
p=none | Monitoring only | Delivered normally, report sent to rua address | Starting out; need to see traffic before enforcing |
p=quarantine | Soft enforcement | Moved to spam/junk folder | After reviewing p=none reports and confirming legitimate email passes |
p=reject | Full enforcement | Refused by receiving server, not delivered | When confident all legitimate sending sources pass authentication |
p=none is where every DMARC implementation should start. Emails that fail authentication are still delivered, which means you are not blocking anything. The only thing p=none does is generate reports. You use those reports to understand your email traffic: which servers are sending using your domain, which are passing authentication, and whether anything is failing that should not be.
Most security guidance recommends staying at p=none for two to four weeks before moving to enforcement. Some organizations with complex email setups stay at p=none longer. The goal is to confirm that all legitimate email is passing before you start quarantining or rejecting anything.
p=quarantine is the first enforcement tier. Failing emails go to spam rather than the inbox. Recipients can still see them in their junk folder. This is a good middle stage: it stops most spoofing without the risk of losing legitimate emails that might have slipped through authentication setup.
p=reject is full enforcement. The receiving server refuses to accept emails that fail DMARC. They are not delivered at all. This is the correct final state once you are confident in your setup.
Google and Yahoo's bulk sender requirements specify a DMARC record must be present, but they do not require enforcement at p=quarantine or p=reject. Any policy, including p=none, satisfies the technical requirement. However, p=none provides no protection and no deliverability benefit beyond having the record present. Move to enforcement once your reports are clean.
DMARC record structure explained
A DMARC record is a TXT record published in your DNS at _dmarc.yourdomain.com. It is a semicolon-separated list of tag=value pairs.
Full example:
v=DMARC1; p=quarantine; rua=mailto:reports@yourdomain.com; ruf=mailto:reports@yourdomain.com; pct=100; fo=1;Tag breakdown:
v=DMARC1Required. Identifies this as a DMARC record. Must always be first. No variation.
p=Required. The policy: none, quarantine, or reject. This is the most important tag.
rua=Recommended. Email address to receive aggregate (summary) reports. These reports arrive daily and show you authentication results across all emails from your domain. Format: rua=mailto:reports@yourdomain.com. You can list multiple addresses separated by commas.
ruf=Optional. Email address to receive forensic (per-failure) reports. These are detailed reports on individual authentication failures. Not all providers send them due to privacy considerations. Many senders skip this or use a separate mailbox to avoid a flood of individual failure notifications.
pct=Optional. Percentage of failing emails the policy applies to, from 1 to 100. pct=100 applies the policy to all failures. pct=10 applies it to 10% and delivers the rest normally. Useful for gradual rollout when moving from p=none to p=quarantine or from p=quarantine to p=reject. Default is 100 if not specified.
fo=Optional. Controls which failures generate forensic reports. fo=0 (default) sends reports when both SPF and DKIM fail. fo=1 sends reports when either fails. fo=s sends reports on SPF failures only. fo=d sends reports on DKIM failures only. Most senders use fo=1 to get the most diagnostic data.
adkim=Optional. DKIM alignment mode. adkim=r is relaxed (default, allows subdomain matches). adkim=s is strict (exact domain match required).
aspf=Optional. SPF alignment mode. aspf=r is relaxed (default). aspf=s is strict.
sp=Optional. Policy for subdomains. If not specified, subdomains inherit the main domain policy. sp=none lets you enforce on the main domain but monitor on subdomains.
Step 1: Verify SPF and DKIM first
DMARC with missing or broken SPF and DKIM is worse than useless. If you publish a DMARC record before fixing SPF and DKIM, the only thing you will accomplish is generating reports that show everything failing.
Direct answer: Before adding DMARC, verify that SPF passes for all your sending sources and that DKIM is correctly configured with your email provider. If either is broken, fix that first.
Check both records right now at the Vortenza SPF DKIM DMARC Checker. Enter your domain and it checks all three records in real time, with color-coded results and plain-English descriptions of any issues found.
What a passing SPF record looks like:
v=spf1 include:_spf.google.com include:sendgrid.net ~allYour SPF record should include every tool and server currently sending email for your domain. Common inclusions: Google Workspace (_spf.google.com), Microsoft 365 (spf.protection.outlook.com), email marketing tools (Mailchimp, SendGrid, HubSpot), CRM email (Salesforce, HubSpot), and transactional email services.
DKIM does not have a standard visual format, but the record exists at selector._domainkey.yourdomain.com in DNS. Your email provider's documentation will tell you which selector name they use. Google Workspace uses google._domainkey. Most providers have a setup wizard in their admin console that generates the record for you.
If you are not sure whether DKIM is configured, the Vortenza SPF DKIM DMARC Checker will show you what is present and whether the signature is valid.
Common pre-DMARC fixes:
Only proceed to creating a DMARC record once both SPF and DKIM are passing cleanly.
Step 2: Create your DMARC record
Use the right record for your current situation, not the most aggressive one available.
Beginner (starting out, monitoring only):
v=DMARC1; p=none; rua=mailto:reports@yourdomain.com;Use this if you have just confirmed SPF and DKIM are passing and want to start collecting data before enforcing anything. Replace reports@yourdomain.com with a real mailbox you will actually check. DMARC reports are XML files that arrive daily; most people create a dedicated mailbox for them.
Intermediate (first enforcement, moving to soft blocking):
v=DMARC1; p=quarantine; rua=mailto:reports@yourdomain.com; pct=100;Use this after reviewing two to four weeks of p=none reports and confirming all legitimate email passes authentication. pct=100 applies the quarantine policy to all failing emails. If you want to roll it out gradually, start with pct=10 or pct=25.
Advanced (full enforcement):
v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; pct=100; fo=1;Use this only when you are confident every legitimate sending source is authenticated. fo=1 adds per-failure forensic reports to help you catch any remaining issues. This is the appropriate final state for most domains.
If you do not want to write the record manually, the Vortenza DMARC Record Generator builds a valid DMARC TXT record based on your inputs. Select your policy, enter your reporting email, and copy the finished record.
Step 3: Add DMARC to DNS
The record goes in your DNS as a TXT record at the hostname _dmarc.yourdomain.com. The exact steps depend on who manages your DNS.
Cloudflare
- Log in to Cloudflare and select your domain
- Go to DNS > Records
- Click Add record
- Type: TXT
- Name: _dmarc
- Content: paste your DMARC record (the full string starting with v=DMARC1)
- TTL: Auto
- Click Save
Cloudflare propagates DNS changes within a few minutes in most cases.
Namecheap
- Log in to Namecheap and go to Domain List
- Click Manage next to your domain
- Go to Advanced DNS
- Click Add New Record
- Type: TXT Record
- Host: _dmarc
- Value: paste your DMARC record
- TTL: Automatic
- Click the green checkmark to save
GoDaddy
- Log in to GoDaddy and go to My Products
- Select your domain and click DNS
- Click Add under Records
- Type: TXT
- Name: _dmarc
- Value: paste your DMARC record
- TTL: 1 Hour (default is fine)
- Click Save
Google Domains / Squarespace Domains
- Open Squarespace Domains (Google Domains merged into Squarespace in 2023)
- Select your domain and go to DNS
- Click Add record under Custom records
- Type: TXT
- Host name: _dmarc
- Data: paste your DMARC record
- TTL: 3600 (or leave default)
- Click Save
General note for any DNS provider
The hostname field should always be _dmarc (not _dmarc.yourdomain.com). Some providers append the domain automatically. Others require the full hostname. If the record does not validate after propagation, check whether the provider appended the domain to your hostname, resulting in _dmarc.yourdomain.com.yourdomain.com, which is a common mistake.
Step 4: Validate the record
After adding the record to DNS, verify it is published correctly before assuming it is working.
Direct answer: DNS changes typically propagate within 15 minutes to a few hours. Use the Vortenza SPF DKIM DMARC Checker to verify the record is live and correctly formatted.
What to verify:
Most DNS providers propagate TXT record changes within 15-60 minutes. Full global propagation can take up to 48 hours, though in practice it is usually much faster. If the record does not show up within an hour, check that you saved it correctly and that the hostname is exactly _dmarc (not @ or the full domain name).
Checking via command line (optional):
On a Mac or Linux terminal:
dig TXT _dmarc.yourdomain.comOn Windows Command Prompt:
nslookup -type=TXT _dmarc.yourdomain.comA correctly published record will show the full DMARC string in the response. No response or an error typically means the record is not yet propagated or was saved incorrectly.
After 24-48 hours at p=none, DMARC aggregate reports should start arriving at the rua email address. They arrive as XML attachments in a ZIP file. If you do not see any after 48 hours, verify the email address in your DMARC record is correct and accessible.
Common DMARC errors
| Error | Cause | Fix |
|---|---|---|
| No DMARC record found | Record not added or not propagated yet | Verify record was saved correctly in DNS, wait up to 48 hours for propagation |
| DMARC syntax error | Missing semicolons, invalid tag names, incorrect value format | Use DMARC Record Generator to rebuild valid record from scratch |
| Alignment failure: SPF passes but DMARC fails | "From" domain does not match SPF-authenticated domain | Use relaxed alignment (aspf=r) or configure your sending tool to use your domain for SPF |
| Alignment failure: DKIM passes but DMARC fails | DKIM signature domain does not match "From" domain | Configure DKIM on your sending tool to use your domain, not the tool's domain |
| Missing SPF before adding DMARC | DMARC added without SPF in place | Add SPF record first, verify it passes, then add DMARC |
| Missing DKIM before adding DMARC | DMARC added without DKIM configured | Configure DKIM with your email provider, verify signature, then add DMARC |
| No DMARC reports arriving | Incorrect or inaccessible rua email address | Verify the rua address is correct and the mailbox can receive external email |
| DMARC record at wrong hostname | Record added at yourdomain.com instead of _dmarc.yourdomain.com | Delete the record, re-add it at the correct hostname |
| Multiple DMARC records | More than one TXT record at _dmarc.yourdomain.com | Delete duplicates, keep exactly one DMARC record |
| Invalid pct value | Value outside 1-100 range or formatted incorrectly | Use a whole number between 1 and 100 |
| p=reject blocking own emails | Jumped to reject before confirming authentication | Drop back to p=quarantine, check which legitimate sources are failing, fix authentication, then return to p=reject |
The most dangerous error in that table is the last one. Jumping to p=reject on a domain where SPF or DKIM is incomplete or misconfigured will block your own legitimate emails. Receiving servers refuse delivery. The emails disappear. No bounce notification reaches the sender in many cases. If you have accidentally set p=reject and your emails are being blocked, change the policy to p=quarantine immediately and review your DMARC reports to identify which sending sources are failing.
DMARC for Google Workspace
Google Workspace generates a DKIM key during setup and walks you through publishing it in DNS via the Admin console. If you set up Workspace more than two years ago and never verified DKIM, it is worth checking whether the key is still valid and uses a 2048-bit key length.
Direct answer: Google Workspace supports all three DMARC policies. Google recommends starting at p=none, monitoring reports for at least one week, moving to p=quarantine, then upgrading to p=reject when reports show all legitimate email passing.
Google Workspace DMARC setup checklist
- ✓SPF includes include:_spf.google.com in your DNS record
- ✓DKIM configured in Admin console (Apps > Google Workspace > Gmail > Authenticate email)
- ✓DKIM key is 2048-bit (Admin console shows key length)
- ✓DMARC record published at _dmarc.yourdomain.com
- ✓DMARC reports arriving at rua address
- ✓Google Postmaster Tools configured for your sending domain
Google Postmaster Tools is worth setting up alongside DMARC. It is a free dashboard that shows your domain reputation, IP reputation, spam rate, and authentication pass rates specifically for Gmail delivery. Postmaster Tools data and your DMARC reports together give you a complete picture of how your domain performs at Gmail. When Google's bulk sender requirements were updated in February 2024, Google Workspace domains that already had DKIM and DMARC configured were unaffected. New domains or domains that had never completed authentication setup saw immediate deliverability improvements after adding DMARC.
DMARC for Microsoft 365
Microsoft 365 (formerly Office 365) includes DKIM signing in the admin center and supports DMARC at all policy levels.
Direct answer: Microsoft 365 enables DKIM signing through the Microsoft Defender portal (formerly Security and Compliance Center). Once DKIM is enabled, you configure DMARC the same way as any other domain: by publishing a TXT record at _dmarc.yourdomain.com.
Microsoft 365 DMARC setup checklist
- ✓SPF includes include:spf.protection.outlook.com in your DNS record
- ✓DKIM enabled in Microsoft Defender portal (Email & collaboration > Policies & rules > Threat policies > Email authentication settings)
- ✓Two CNAME records published in DNS as required by Microsoft for DKIM rotation
- ✓DMARC record published at _dmarc.yourdomain.com
- ✓DMARC reports arriving at rua address
- ✓Microsoft SNDS (Smart Network Data Services) configured for monitoring
One important Microsoft 365 difference: Microsoft uses rotating DKIM keys that require two CNAME records in DNS (not a TXT record like most providers). The admin center generates these records for you; you just need to publish them in your DNS. The CNAME records point to Microsoft's key infrastructure, which handles rotation automatically.
Microsoft also runs its own DMARC validation, which means emails sent to Outlook and Hotmail addresses are checked against your DMARC record. Domains with p=reject enforcement see better inbox placement at Outlook specifically because Microsoft's filter trusts enforcement-level DMARC as a positive reputation signal.
DMARC best practices for 2026
These are the practices that distinguish domains with consistent deliverability from those that fight fires.
Setup
- ✓Verify SPF and DKIM pass before adding DMARC
- ✓Start DMARC at p=none with a real, monitored reporting address
- ✓Use 2048-bit DKIM keys
- ✓Keep SPF to a single record with fewer than 10 DNS lookups
- ✓Generate DMARC records with a tool rather than hand-editing syntax
Rollout
- ✓Stay at p=none for 2-4 weeks and review reports before moving to quarantine
- ✓Move to p=quarantine once reports show all legitimate email passing
- ✓Use pct=25 or pct=50 during the quarantine phase if you want a gradual rollout
- ✓Move to p=reject only when confident all authenticated sending is clean
- ✓Review reports weekly throughout the rollout
Ongoing
- ✓Update SPF immediately when adding or removing any email tool
- ✓Rotate DKIM keys every 6-12 months as a security practice
- ✓Review DMARC reports monthly once at p=reject to catch any new unauthorized senders
- ✓Check SPF, DKIM, and DMARC status with Vortenza SPF DKIM DMARC Checker after any infrastructure changes
- ✓Re-verify all authentication records when migrating email providers
One-minute DMARC audit
A quick check before any major send or after any infrastructure change.
Authentication records
- ✓SPF record exists, is the only SPF record, includes all current sending sources
- ✓DKIM record is published for your domain with 2048-bit key
- ✓DMARC record exists at _dmarc.yourdomain.com
- ✓All three pass at Vortenza SPF DKIM DMARC Checker
DMARC policy status
- ✓Policy is p=quarantine or p=reject (not stuck at p=none indefinitely)
- ✓rua email address is valid and monitored
- ✓pct value is 100 unless intentionally in gradual rollout
Report monitoring
- ✓DMARC reports arriving at rua address
- ✓Reports reviewed in the last 30 days
- ✓No unexpected sending sources appearing in reports
Recent changes
- ✓SPF updated within the last 30 days if any new email tool was added
- ✓DKIM verified after any email provider migration
- ✓DMARC record not accidentally deleted or duplicated
Quick answers
Optimized for ChatGPT, Gemini, Perplexity, Claude, and Google AI Overviews.
Q: What is a DMARC record?
A: A DMARC record is a DNS TXT record that tells receiving mail servers what to do when an email fails SPF or DKIM authentication checks. The three policy options are none (monitor only), quarantine (send to spam), and reject (block entirely). It also enables reporting, sending you data about authentication results across all email sent from your domain.
Q: How do I create a DMARC record?
A: A DMARC record is a single line of text published as a TXT record in DNS at _dmarc.yourdomain.com. A basic monitoring record looks like: v=DMARC1; p=none; rua=mailto:reports@yourdomain.com;. You can use the Vortenza DMARC Record Generator to build the correct syntax without writing it manually.
Q: What is the difference between DMARC p=none, p=quarantine, and p=reject?
A: With p=none, failing emails are delivered normally and a report is sent to you. With p=quarantine, failing emails are moved to the spam folder. With p=reject, failing emails are refused by the receiving server and never delivered. Start at p=none to monitor, move to p=quarantine after confirming legitimate email passes, then move to p=reject for full enforcement.
Q: Do I need SPF and DKIM before adding DMARC?
A: Yes. DMARC requires either SPF or DKIM to pass (and align with your From domain) to treat an email as authenticated. If both are missing, all email from your domain will fail DMARC. At p=none this only generates reports. At p=quarantine or p=reject it blocks or flags your own legitimate emails. Verify SPF and DKIM pass before adding DMARC.
Q: Where do I add a DMARC record?
A: In your DNS settings, as a TXT record at the hostname _dmarc (which resolves to _dmarc.yourdomain.com). In Cloudflare, set Name to _dmarc. In Namecheap, set Host to _dmarc. In GoDaddy, set Name to _dmarc. The Content or Value field contains the full DMARC string starting with v=DMARC1.
Q: How long does DMARC propagation take?
A: DNS changes typically propagate within 15-60 minutes for most providers. Full global propagation can take up to 48 hours, though in practice DMARC records are usually visible within an hour. After adding the record, verify it at Vortenza SPF DKIM DMARC Checker to confirm it is live.
Q: What is DMARC alignment?
A: DMARC alignment means the domain in your "From" email address must match the domain authenticated by SPF or DKIM. This prevents attackers from using a legitimate SPF record from one domain to send email appearing to come from another. Relaxed alignment (the default) allows subdomain matches. Strict alignment requires an exact domain match.
Q: What are DMARC reports and how do I read them?
A: DMARC reports are XML files sent daily to the email address in your rua tag. They show every server that sent email claiming to be from your domain, whether each email passed or failed SPF and DKIM, and what happened to failures. Raw XML is hard to read; free tools like Dmarcian and Postmark's DMARC report viewer parse them into readable dashboards.
Q: Can DMARC stop all email spoofing?
A: DMARC with p=reject stops spoofing of your specific domain. An attacker cannot send an email that passes DMARC verification claiming to be from yourdomain.com without access to your SPF-authorized sending infrastructure or DKIM private key. However, attackers can still spoof look-alike domains (like yourdomaln.com or your-domain.com) that DMARC does not cover.
Q: Does DMARC affect cold email?
A: Yes, in both directions. A cold email sender with DMARC at p=quarantine or p=reject has better inbox placement than one without DMARC, because the policy signals to spam filters that the domain is actively managed. However, if your cold email tool sends via its own infrastructure and does not properly configure DKIM for your domain, you can fail DMARC alignment even with a valid DMARC record.
Q: What is DMARC rua vs ruf?
A: rua is the aggregate reporting address. You receive one XML summary report per day per sending domain showing overall authentication results. ruf is the forensic reporting address. You receive a report for each individual email that fails DMARC. Aggregate reports are essential for monitoring. Forensic reports provide more detail but generate high volume and not all providers send them.
Q: What happens if I set DMARC to p=reject too early?
A: If any of your legitimate email sources are not properly authenticated when you move to p=reject, those emails will be refused by receiving servers. They will not bounce back with a clear error in all cases, which means they can disappear silently. The fix is to drop back to p=quarantine immediately, review your DMARC reports to identify which sources are failing, fix their authentication, and then return to p=reject.
Q: Does DMARC work for subdomains?
A: By default, subdomains inherit the parent domain's DMARC policy. You can override this with the sp= tag. For example, if your main domain has p=reject but a subdomain sends marketing email that is not fully authenticated yet, you can set sp=quarantine or sp=none for subdomains while keeping p=reject on the main domain. Subdomains that send email should have their own SPF and DKIM records configured.
Q: What is DMARC pct and how should I use it?
A: The pct tag specifies what percentage of failing emails the policy applies to, from 1 to 100. If you set p=quarantine; pct=25, only 25% of failing emails get quarantined; the rest are delivered normally. This lets you roll out enforcement gradually to catch any unexpected failures before applying the policy to all traffic. Start at pct=25 or pct=50 when first moving to quarantine, then increase to pct=100 once you confirm no legitimate email is failing.
Q: How do I know if my DMARC is working?
A: Three ways. Check the DNS record directly at Vortenza SPF DKIM DMARC Checker to confirm it is published correctly. Wait 24-48 hours and verify DMARC reports are arriving at your rua address. Set up Google Postmaster Tools to see authentication pass rates for Gmail delivery. If all three confirm the record is present and reports are showing mostly passes, your DMARC is working.
Frequently asked questions
How long should I stay at p=none before moving to quarantine?+
Most email security guidance recommends two to four weeks at p=none. The goal is to collect enough report data to understand all the sources sending email from your domain and confirm that all legitimate sending is passing SPF or DKIM with proper alignment. For organizations with many third-party tools, subsidiaries, or shared sending infrastructure, the monitoring phase sometimes runs longer. Move to p=quarantine only when reports show no legitimate email failing. There is no value in rushing; the cost of accidentally blocking your own emails at p=reject outweighs the minor benefit of faster enforcement.
What is DMARC alignment and why does my email fail even though SPF passes?+
DMARC alignment requires the "From" domain in your email header to match the domain authenticated by SPF or DKIM. SPF can pass for the sending server's domain while the "From" address shows a different domain, which means SPF passes but DMARC alignment fails. This happens frequently when using third-party email tools that send via their own infrastructure. The fix is to either configure your domain's DKIM on the sending tool (so DKIM passes with your domain) or check whether the tool supports custom SPF alignment.
Can I have more than one DMARC record?+
No. Having more than one DMARC record at _dmarc.yourdomain.com is a configuration error. When receiving servers find multiple DMARC records, the behavior is undefined. Most will treat it as a policy failure and apply no DMARC enforcement. Check that you have exactly one DMARC TXT record at the correct hostname. If you accidentally published duplicates, delete all of them and republish a single correct record.
Do I need a separate DMARC record for each subdomain?+
Not necessarily. Subdomains inherit the parent domain's DMARC policy by default. However, if a subdomain sends email, it should have its own SPF and DKIM records. If you want different DMARC policies for specific subdomains, you can publish separate DMARC records at _dmarc.subdomain.yourdomain.com. This is most commonly done when a subdomain sends marketing email that is in a different authentication state than the main domain.
Why are my DMARC reports showing failures from sources I do not recognize?+
Unknown sources in your DMARC reports mean one of two things: either a third-party service is sending email on behalf of your domain without proper authentication (common with forgotten integrations, old CRM connections, or tools that send on your behalf without you realizing), or someone is actively attempting to spoof your domain. Review the IP addresses and sending infrastructure in the reports. Legitimate tools you forgot to authenticate can be fixed by adding them to your SPF record and configuring DKIM. Unrecognized IPs with no clear purpose may indicate spoofing.
What should I do if my emails start bouncing after setting DMARC to p=reject?+
Change the policy to p=quarantine immediately. Then review your DMARC reports to identify which sending sources are failing. Common causes: a third-party tool that sends email for your domain without DKIM configured for your domain; an email forwarding setup that breaks SPF; a subsidiary or team that sends from your domain via a different mail server. Fix the authentication on each failing source before returning to p=reject. Rushing to reject without monitoring is the most common DMARC mistake.
Does DMARC protect against look-alike domain phishing?+
No. DMARC protects your exact domain. It cannot stop someone from registering yourdomaln.com (with an L instead of an i) or your-domain.com and sending phishing emails from those domains. Those domains have no DMARC relationship with yours. The only defenses against look-alike domain attacks are proactive domain monitoring services and user education. DMARC is a necessary but not sufficient protection against all forms of email-based impersonation.
Can I set DMARC on a domain I do not send email from?+
Yes, and you should. Domains that do not send email are frequently spoofed in phishing attacks precisely because they have no authentication setup. The recommended DMARC record for a non-sending domain is v=DMARC1; p=reject; with no SPF or DKIM (since nothing legitimate should be sending from that domain anyway). This tells receiving servers to reject all email claiming to come from that domain.
How do DMARC reports work in practice?+
DMARC aggregate reports arrive once per day at your rua email address. Each report covers a 24-hour window and shows all email that claimed to come from your domain, broken down by sending source. The report includes: sending IP, domain used for SPF, domain used for DKIM, whether each passed or failed, and what the DMARC policy applied. The files are XML, which is readable but not user-friendly. Most people either use a free DMARC report viewer or set up a dedicated mailbox for reports and review them periodically.
What is the correct order for implementing email authentication?+
The correct order is SPF first, then DKIM, then DMARC. SPF is a prerequisite because DMARC needs at least one passing authentication check to work with. DKIM adds a second independent authentication path. DMARC then ties both together and adds policy enforcement. Implementing them out of order is possible but creates unnecessary risk: adding DMARC before SPF and DKIM are working results in DMARC reports that show everything failing, which is confusing and provides no useful data.
How does DMARC interact with email forwarding?+
Email forwarding breaks SPF because the forwarding server's IP is not on your authorized sender list, causing SPF to fail. DKIM usually survives forwarding as long as the email content is not modified. For DMARC to pass after forwarding, DKIM must pass with proper alignment. This is why DMARC with relaxed alignment (adkim=r) is important for domains that receive forwarded email: relaxed alignment allows DKIM from a subdomain to satisfy DMARC for the parent domain.
What does it mean when DMARC is at p=none but reports show no failures?+
Clean reports at p=none mean all email claiming to come from your domain is passing SPF or DKIM with proper alignment. This is the signal you want before moving to enforcement. However, there are two caveats. First, p=none only receives reports from providers that support DMARC reporting. Some smaller providers do not. Second, a period of clean reports followed by a new tool or sending source could reintroduce failures. After moving to p=quarantine or p=reject, continue monitoring reports regularly.
Final thoughts
Setting up DMARC takes about 30 minutes of actual work. The rest of the time is waiting for DNS propagation and reviewing reports before moving to enforcement.
The sequence that works without surprises:
- 1.Check current authentication status at Vortenza SPF DKIM DMARC Checker
- 2.Fix any SPF or DKIM issues before proceeding
- 3.Generate your DMARC record at Vortenza DMARC Record Generator, starting at p=none
- 4.Publish the record in DNS at _dmarc.yourdomain.com
- 5.Verify the record is live with the SPF DKIM DMARC Checker
- 6.Review reports for two to four weeks
- 7.Move to p=quarantine once reports are clean
- 8.Move to p=reject when all legitimate email is consistently passing
The guides that cover what DMARC is doing under the hood and why authentication matters for deliverability are worth reading if you want the deeper context. The SPF, DKIM, and DMARC explained guide covers the technical concepts, and the Email Deliverability Guide 2026 covers how authentication fits into the broader picture of inbox placement.
For cold email senders specifically, the Cold Email Deliverability Guide 2026 covers how DMARC interacts with cold outreach infrastructure and the alignment issues that show up most often with third-party sending tools.
The main thing to avoid is what most people do: add the record, set it to p=none, and forget about it for six months. DMARC at p=none indefinitely provides no protection and no deliverability benefit beyond having the record present. Monitor the reports and move to enforcement. That is where the actual value is.
About this guide
Published by the Vortenza Editorial Team. Google and Yahoo bulk sender requirements referenced from Google Gmail Sender Guidelines (February 2024) and Yahoo Mail Sender Requirements (February 2024). Verizon phishing statistics from the 2024 Data Breach Investigations Report. DMARC specification referenced from RFC 7489. DNS syntax examples verified against Cloudflare, Namecheap, GoDaddy, and Squarespace Domains DNS interfaces.
Tools used in this guide
DMARC Record Generator
Build a valid DMARC TXT record for your domain. Select policy, enter reporting email, copy the finished record. Free.
SPF DKIM DMARC Checker
Check all three authentication records for any domain with color-coded results and plain-English fix instructions. Free, no signup.
Email Deliverability Checker
Get a 0-100 deliverability score for your domain based on DNS authentication setup. Free, no signup.