You set up your domain. Connect your inboxes. Launched your campaign.<\/p>\n\n\n\n
Only for your emails to land in spam.<\/p>\n\n\n\n
You check your content. You check your sending volume. Everything looks clean. But you never set up DMARC.<\/p>\n\n\n\n
Here’s the thing most senders miss.<\/p>\n\n\n\n
\nSPF and DKIM get all the attention, but DMARC is the protocol that ties everything together.<\/em><\/strong><\/p>\n\n\n\n
Without it, receiving servers have no instruction set for handling your email.<\/em><\/strong><\/p>\n<\/blockquote>\n\n\n\n
And since 2024, it is no longer optional. Gmail, Yahoo, and Microsoft now require DMARC for bulk senders. Even low-volume cold emailers feel the impact of its absence.<\/p>\n\n\n\n
I run TrulyInbox, an email warm-up tool, and I see domains with broken or missing DMARC records every week.<\/p>\n\n\n\n
\nThe pattern is consistent: no DMARC, poor inbox placement, wasted warm-up cycles.<\/strong><\/em><\/p>\n<\/blockquote>\n\n\n\n
This post covers what DMARC is, how it works under the hood, and the three policy levels you need to know. You will also learn how it impacts your deliverability, the common mistakes that break it, and how to set yours up correctly.<\/p>\n\n\n\n
TL;DR: What DMARC Is and Why You Need It<\/h2>\n\n\n\n
DMARC is an email authentication protocol.<\/p>\n\n\n\n
It tells receiving servers what to do when an email fails SPF or DKIM checks.<\/em><\/strong><\/p>\n\n\n\n
You publish a DMARC policy on your domain’s DNS, and every receiving server in the world follows that instruction. The three policies are simple: none (monitor only), quarantine (send failures to spam), and reject (block failures entirely).<\/p>\n\n\n\n
Gmail, Yahoo, and Microsoft now require DMARC.<\/strong> The February 2024 mandate made it non-negotiable for bulk senders.<\/p>\n\n\n\n
But even if you send fewer than 5,000 emails per day, your inbox placement suffers without it.<\/em><\/strong><\/p>\n\n\n\n
Here is what I recommend.<\/p>\n\n\n\n
\n
- Start with p=none so you can monitor your authentication results.<\/li>\n\n\n\n
- Review your aggregate reports for 2 to 4 weeks, then move to p=quarantine.<\/li>\n\n\n\n
- Only switch to p=reject after you confirm every legitimate sending tool passes authentication.<\/li>\n<\/ol>\n\n\n\n
If you want to skip the manual work, you can use our free DMARC record generator<\/a> to create a properly formatted record in seconds.<\/p>\n\n\n\n
One more thing before we dive in. Most DMARC failures do not come from missing records. They come from alignment issues. I will explain exactly what that means in the sections below.<\/p>\n\n\n\n
What Is DMARC?<\/h2>\n\n\n\n
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance.<\/p>\n\n\n\n
It is an email authentication protocol published as RFC 7489 in March 2015.<\/p>\n\n\n\n
But let me simplify that.<\/p>\n\n\n\n
DMARC is a policy layer that sits on top of SPF and DKIM. It does not authenticate emails on its own. Instead, it tells receiving servers what to do when authentication fails.<\/p>\n\n\n\n
You publish a DMARC record as a DNS TXT record at _dmarc.yourdomain.com. Every email server that receives mail from your domain checks this record and follows your instructions.<\/p>\n\n\n\n
Think of it this way. SPF and DKIM are the ID checks at the door. DMARC is the policy that tells the bouncer what to do when the ID fails.<\/strong><\/p>\n\n\n\n
DMARC was designed to solve three problems:<\/p>\n\n\n\n
\n
- Domain spoofing, where someone sends emails pretending to be you<\/li>\n\n\n\n
- Phishing attacks that exploit your brand’s domain reputation<\/li>\n\n\n\n
- Unauthorized email use by third parties you never approved<\/li>\n<\/ul>\n\n\n\n
Every domain owner who sends email needs DMARC. That includes cold emailers, marketing teams, transactional senders, and agencies managing client domains.<\/p>\n\n\n\n
As of 2026, three major email providers require it:<\/p>\n\n\n\n
\n
- Google Gmail<\/strong> required DMARC for bulk senders starting February 2024<\/li>\n\n\n\n
- Yahoo Mail<\/strong> enforced the same requirement at the same time<\/li>\n\n\n\n
- Microsoft Outlook<\/strong> made DMARC mandatory starting May 2025<\/li>\n<\/ol>\n\n\n\n
I verified these requirements against the current sender guidelines from all three providers, April 2026.<\/p>\n\n\n\n
DMARC vs. SPF vs. DKIM: Quick Distinction<\/h3>\n\n\n\n
These three protocols work as layers. Each one does a different job.<\/p>\n\n\n\n
SPF (Sender Policy Framework)<\/strong> specifies which servers can send email on behalf of your domain. It is a DNS record that lists every approved sending IP.<\/p>\n\n\n\n
DKIM (DomainKeys Identified Mail)<\/strong> adds a cryptographic signature to each email. This signature proves the message was not altered during transit.<\/p>\n\n\n\n
DMARC<\/strong> connects both protocols and adds a policy layer. It tells receiving servers what action to take when SPF or DKIM checks fail.<\/p>\n\n\n\n
Each protocol has a different DNS record type. You need all three for proper authentication.<\/p>\n\n\n\n
If you want a full walkthrough on setting up all three, check out our guide on how to set up SPF, DKIM, and DMARC<\/a>.<\/p>\n\n\n\n
How Does DMARC Work? (Step-by-Step)<\/h2>\n\n\n\n
DMARC follows a specific authentication flow every time someone sends an email from your domain. Here is how the process works from start to finish.<\/p>\n\n\n\n
\n
- You publish a DMARC record in your domain’s DNS settings<\/li>\n\n\n\n
- An email goes out from your domain (or from someone spoofing it)<\/li>\n\n\n\n
- The receiving server looks up your DMARC record<\/li>\n\n\n\n
- The server runs SPF and DKIM checks on the email<\/li>\n\n\n\n
- The server checks DMARC alignment, which I will explain in detail below<\/li>\n\n\n\n
- Based on your policy (none, quarantine, or reject), the server takes action on the email<\/li>\n\n\n\n
- The server sends an aggregate report back to the email address you specified in your DMARC record<\/li>\n<\/ol>\n\n\n\n
The most important step in that flow is step five. This is where most senders get tripped up.<\/p>\n\n\n\n
DMARC alignment is why your emails can fail DMARC even when SPF and DKIM individually pass.<\/em> This is the single most confusing concept for senders who use third-party tools.<\/p>\n\n\n\n
Let me give you a concrete example.<\/p>\n\n\n\n
You send from yourname@yourdomain.com using a cold email tool. SPF passes because you added the tool’s IP to your SPF record. DKIM passes because the tool signs the email with its own domain.<\/p>\n\n\n\n
But DMARC fails. Why?<\/p>\n\n\n\n
Because the DKIM signing domain does not match your From: domain. That is an alignment failure, and it is the number one cause of DMARC failures I see among senders using TrulyInbox for warm-up.<\/p>\n\n\n\n
What Is DMARC Alignment?<\/h3>\n\n\n\n
Alignment is the check that verifies whether the domain in your visible “From:” address matches the domain validated by SPF or DKIM.<\/p>\n\n\n\n
Without alignment, DMARC will fail even when both SPF and DKIM individually pass.<\/p>\n\n\n\n
DMARC supports two alignment modes:<\/p>\n\n\n\n
\n
- Relaxed alignment<\/strong> allows subdomains to count as a match. For example, mail.yourdomain.com passes for yourdomain.com. This is the default mode, and it works for most senders.<\/li>\n\n\n\n
- Strict alignment<\/strong> requires an exact domain match. The From: domain must match the SPF or DKIM domain character for character. No subdomain flexibility is allowed.<\/li>\n<\/ul>\n\n\n\n
Most domains should use relaxed alignment. Strict alignment makes sense only for large enterprises that manage many subdomains and want tighter control.<\/p>\n\n\n\n
If you send cold emails or marketing campaigns through third-party tools, relaxed alignment gives you the flexibility you need.<\/p>\n\n\n\n
Just make sure you configure custom DKIM signing for your domain in every tool you use.<\/p>\n\n\n\n
What Are DMARC Reports?<\/h3>\n\n\n\n
DMARC generates two types of reports that help you monitor your email authentication.<\/p>\n\n\n\n
\n
- Aggregate reports (RUA)<\/strong> arrive as daily XML summaries. They show all email traffic from your domain, including pass and fail rates, source IPs, and which emails failed alignment. You specify where to receive these reports using the rua= tag in your DMARC record.<\/li>\n\n\n\n
- Forensic reports (RUF)<\/strong> provide individual message failure details. However, most email providers no longer send forensic reports due to privacy concerns. So aggregate reports are your primary monitoring tool.<\/li>\n<\/ul>\n\n\n\n
Here is the problem. Raw aggregate reports come as XML files. They are nearly unreadable without a parsing tool.<\/p>\n\n\n\n
I recommend using a free DMARC report analyzer like Postmark’s DMARC Digests or dmarcian.<\/p>\n\n\n\n
These tools turn raw XML data into visual dashboards that show you exactly what is happening with your email authentication.<\/p>\n\n\n\n
For cold email senders, DMARC reports answer one critical question: are your outreach tools passing authentication? If your cold email platform or your warm-up tool shows up in reports with DMARC failures, you know exactly what to fix.<\/p>\n\n\n\n
You can also use Google Postmaster Tools<\/a> to monitor your authentication status and domain reputation alongside your DMARC reports.<\/p>\n\n\n\n
The Three DMARC Policies Explained<\/h2>\n\n\n\n
Your DMARC record includes a policy tag (p=) that tells receiving servers how to handle emails that fail authentication.<\/p>\n\n\n\n
You have three options.<\/p>\n\n\n\n
p=none (Monitor Only)<\/h3>\n\n\n\n
This policy delivers all emails normally, regardless of whether they pass or fail authentication. You still receive aggregate reports, so you can see what is happening.<\/p>\n\n\n\n
But no emails get blocked or sent to spam because of DMARC.<\/p>\n\n\n\n
This is where every domain should start. No exceptions.<\/p>\n\n\n\n
p=quarantine (Send to Spam)<\/h3>\n\n\n\n
This policy routes emails that fail DMARC checks to the recipient’s spam or junk folder. Legitimate emails that pass authentication still reach the inbox.<\/p>\n\n\n\n
This is the intermediate enforcement step.<\/em><\/strong><\/p>\n\n\n\n
Only move to quarantine after you review your aggregate reports and confirm that all your legitimate sending tools pass SPF, DKIM, and alignment checks.<\/p>\n\n\n\n
p=reject (Block Entirely)<\/h3>\n\n\n\n
This policy blocks emails that fail DMARC checks completely. The receiving server does not deliver them at all.<\/p>\n\n\n\n
This provides maximum protection against spoofing, but it is dangerous if you misconfigure it.<\/p>\n\n\n\n
If you move to reject before all your tools are properly authenticated, you will block your own legitimate email. That includes warm-up emails, transactional messages, and outreach campaigns.<\/p>\n\n\n\n
Here is the recommended progression timeline:<\/p>\n\n\n\n
\n
- Start with p=none and monitor for 2 to 4 weeks minimum<\/li>\n\n\n\n
- Review aggregate reports to confirm all legitimate senders pass authentication<\/li>\n\n\n\n
- Move to p=quarantine and monitor for another 2 to 4 weeks<\/li>\n\n\n\n
- Check reports again to verify no legitimate email is landing in spam<\/li>\n\n\n\n
- Move to p=reject only after full confidence in your authentication setup<\/li>\n<\/ol>\n\n\n\n
The entire progression typically takes 4 to 8 weeks.<\/strong> Rushing it is the most common mistake I see.<\/p>\n\n\n\n
Which DMARC Policy Should You Start With?<\/h3>\n\n\n\n
Always start with p=none. Always.<\/p>\n\n\n\n
The only exception is a brand-new domain with zero existing email traffic. In that case, you can move through the progression faster because there are no existing sending tools to worry about.<\/p>\n\n\n\n
For cold email senders, starting with p=none is critical. If you jump straight to reject, you risk blocking your own warm-up emails and outreach messages.<\/p>\n\n\n\n
Third-party tool alignment needs to be verified first, and you can only do that by monitoring reports at the p=none level.<\/p>\n\n\n\n
I recommend starting at p=none for at least 2 to 4 weeks.<\/em><\/strong><\/p>\n\n\n\n
Review your aggregate reports to confirm every tool you use, including your ESP, your outreach platform, and your warm-up tool<\/a>, passes authentication before moving to quarantine.<\/p>\n\n\n\n
How DMARC Impacts Email Deliverability<\/h2>\n\n\n\n
Most blogs frame DMARC as a security protocol. That is only half the story.<\/p>\n\n\n\n
DMARC is deliverability infrastructure.<\/strong> It directly affects whether your emails reach the inbox or land in spam.<\/p>\n\n\n\n
Gmail, Yahoo, and Microsoft use DMARC status as a signal in their spam filtering algorithms. A domain with a published DMARC policy signals to these providers that you take authentication seriously.<\/p>\n\n\n\n
A domain without DMARC gives them no confidence in your email.<\/p>\n\n\n\n
Even a p=none policy is better than no DMARC record at all. But p=quarantine or p=reject signals stronger commitment and can improve your inbox placement over time.<\/p>\n\n\n\n
Here is the part that matters for cold emailers and outreach teams.<\/p>\n\n\n\n
Without DMARC, your email warm-up<\/a> effectiveness is capped. Warm-up builds sender reputation, but reputation gets undermined when your authentication is incomplete. I have seen this pattern across thousands of domains using TrulyInbox.<\/p>\n\n\n\n
\nDomains with full authentication (SPF + DKIM + DMARC) consistently see stronger inbox placement during warm-up than domains with incomplete records.<\/em><\/p>\n<\/blockquote>\n\n\n\n
Now, let me clarify the bulk sender mandate.<\/p>\n\n\n\n
The 5,000 emails per day threshold from Gmail and Yahoo applies primarily to email marketers sending at high volume. Cold email senders should keep daily volume much lower, typically 50 per day on shared infrastructure and up to 100 per day on private infrastructure.<\/p>\n\n\n\n
But DMARC is still required for all senders. The mandate adds extra requirements for bulk senders, but every domain benefits from having it in place.<\/p>\n\n\n\n
If your emails are landing in spam<\/a> and you have not set up DMARC, start there. It is the most overlooked fix for deliverability problems.<\/p>\n\n\n\n
For a full walkthrough on authentication setup, check out our guide on how to set up SPF, DKIM, and DMARC<\/a>.<\/p>\n\n\n\n
DMARC, SPF, and DKIM: How They Work Together<\/h2>\n\n\n\n
SPF, DKIM, and DMARC are not three separate protocols. They form a unified authentication stack, and they work as a sequence.<\/p>\n\n\n\n
Here is what happens when an email arrives at a receiving server:<\/p>\n\n\n\n
\n
- The server checks the SPF record to verify if the sending IP is authorized for the sender’s domain<\/li>\n\n\n\n
- The server checks the DKIM signature to confirm the email has not been tampered with in transit<\/li>\n\n\n\n
- The server checks the DMARC record to see the domain owner’s policy<\/li>\n\n\n\n
- The server evaluates DMARC alignment to confirm the From: domain matches the domains validated by SPF or DKIM<\/li>\n\n\n\n
- Based on the DMARC policy, the server delivers, quarantines, or rejects the email<\/li>\n<\/ol>\n\n\n\n
For DMARC to pass, you need at least one of SPF or DKIM to both pass and align with the From: domain. However, best practice is to have both SPF and DKIM passing and aligned.<\/strong> Do not rely on just one.<\/p>\n\n\n\n
Here is the important part about setup order. You should always set up these protocols in this sequence:<\/p>\n\n\n\n
\n
- SPF first, because it authorizes your sending servers<\/li>\n\n\n\n
- DKIM second, because it adds cryptographic signatures to your email<\/li>\n\n\n\n
- DMARC last, because it depends on the other two<\/li>\n<\/ol>\n\n\n\n
If you set up DMARC before SPF and DKIM are in place, every email will fail authentication. DMARC cannot function without the protocols it relies on.<\/p>\n\n\n\n
When I set up a new domain for testing, I always verify all three records are in place and passing before connecting it to any warm-up or outreach tool.<\/p>\n\n\n\n
This is a non-negotiable step in building your cold email infrastructure<\/a>.<\/p>\n\n\n\n
What Does a DMARC Record Look Like?<\/h2>\n\n\n\n
A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. Let me break down every tag you will encounter.<\/p>\n\n\n\n
Here is an example record:<\/p>\n\n\n\n
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100; adkim=r; aspf=r<\/p>\n\n\n\n
Each tag controls a specific part of your DMARC configuration:<\/p>\n\n\n\n
\n
- v=DMARC1<\/strong> is the version tag. It is always DMARC1. This is required.<\/li>\n\n\n\n
- p=<\/strong> sets your policy: none, quarantine, or reject. This is also required.<\/li>\n\n\n\n
- rua=<\/strong> specifies the email address for aggregate reports. Use the mailto: format.<\/li>\n\n\n\n
- ruf=<\/strong> specifies the email address for forensic reports (optional, rarely supported).<\/li>\n\n\n\n
- pct=<\/strong> defines the percentage of emails the policy applies to. Use this for gradual rollout.<\/li>\n\n\n\n
- adkim=<\/strong> sets the DKIM alignment mode: r for relaxed, s for strict.<\/li>\n\n\n\n
- aspf=<\/strong> sets the SPF alignment mode: r for relaxed, s for strict.<\/li>\n\n\n\n
- sp=<\/strong> sets the subdomain policy. It inherits from the main policy by default.<\/li>\n\n\n\n
- fo=<\/strong> controls failure reporting options. Set to 1 to generate reports on any authentication failure.<\/li>\n<\/ul>\n\n\n\n
Now let me show you three example records for different stages of deployment.<\/p>\n\n\n\n
Stage 1: Monitoring (Starter)<\/h3>\n\n\n\n
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1<\/p>\n\n\n\n
This record monitors all email traffic and sends you reports. No emails get blocked. Use this for the first 2 to 4 weeks.<\/p>\n\n\n\n
Stage 2: Quarantine (Intermediate)<\/h3>\n\n\n\n
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=50; adkim=r; aspf=r<\/p>\n\n\n\n
This record sends 50% of failed emails to spam while you monitor the impact. Once you confirm no legitimate email is affected, increase pct to 100.<\/p>\n\n\n\n
Stage 3: Reject (Full Enforcement)<\/h3>\n\n\n\n
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=r; aspf=r<\/p>\n\n\n\n
This record blocks all emails that fail DMARC. Use this only after full confidence in your authentication setup.<\/p>\n\n\n\n
If you want to skip the manual syntax, you can use our free DMARC record generator<\/a> to create a properly formatted record in seconds.<\/p>\n\n\n\n
Verified against the current DMARC specification and Google’s sender guidelines, April 2026.<\/p>\n\n\n\n
Common DMARC Mistakes That Break Your Email<\/h2>\n\n\n\n
This is the section that saves you from real damage. Every mistake below comes from patterns I see when troubleshooting deliverability problems for senders using TrulyInbox.<\/p>\n\n\n\n
Mistake 1: Jumping straight to p=reject without monitoring first.<\/h3>\n\n\n\n
This is the most dangerous mistake. When you enforce reject before verifying all your legitimate senders, you block your own email. Warm-up emails, outreach messages, transactional receipts, and marketing campaigns can all get rejected.<\/p>\n\n\n\n
The fix: Always start with p=none. Monitor for at least 2 to 4 weeks before moving to quarantine.<\/p>\n\n\n\n
Mistake 2: Setting up DMARC without SPF or DKIM in place.<\/h3>\n\n\n\n
DMARC depends entirely on SPF and DKIM. If neither protocol is set up and passing, every email from your domain will fail DMARC. You will see 100% failure in your reports.<\/p>\n\n\n\n
The fix: Set up SPF and DKIM first. Verify both pass. Then add your DMARC record.<\/p>\n\n\n\n
Mistake 3: Forgetting to add third-party sending tools to your SPF record.<\/h3>\n\n\n\n
Your cold email tool, your marketing platform, and your transactional email service all send mail from your domain. If you do not include their sending IPs in your SPF record, those emails fail SPF checks.<\/p>\n\n\n\n
The fix: List every tool that sends email on your behalf and add their include: entries to your SPF record.<\/p>\n\n\n\n
Mistake 4: Using a third-party tool’s default DKIM signature instead of configuring custom DKIM.<\/h3>\n\n\n\n
This is by far the most common issue I see. Your cold email platform signs emails with its own domain by default.<\/p>\n\n\n\n
DKIM technically passes, but alignment fails because the signing domain does not match your From: domain.<\/p>\n\n\n\n
The fix: Configure custom DKIM signing for your domain in every third-party tool you use.<\/p>\n\n\n\n
Mistake 5: Not setting up an rua reporting address.<\/h3>\n\n\n\n
Without reports, you have zero visibility into who is sending email from your domain. You cannot identify spoofing attempts, misconfigured tools, or alignment failures.<\/p>\n\n\n\n
The fix: Always include an rua= tag in your DMARC record with a valid email address you actually monitor.<\/p>\n\n\n\n
Mistake 6: Forgetting about subdomains.<\/h3>\n\n\n\n
DMARC covers the exact domain in your record by default.<\/p>\n\n\n\n
If you send email from mail.yourdomain.com but only have a DMARC record for yourdomain.com, the subdomain traffic may not be covered unless you set an sp= subdomain policy.<\/p>\n\n\n\n
The fix: Add an sp= tag to your main DMARC record, or publish a separate DMARC record for each subdomain you use.<\/p>\n\n\n\n
Mistake 7: Publishing multiple DMARC records for the same domain.<\/h3>\n\n\n\n
You can only have one DMARC record per domain. If you publish two records, most receiving servers ignore both. Your domain effectively has no DMARC policy at all.<\/p>\n\n\n\n
The fix: Check your DNS for duplicate records. Remove any extras and keep only one.<\/p>\n\n\n\n
If you suspect any of these issues, run a full email deliverability audit<\/a> to catch problems before they compound.<\/p>\n\n\n\n
Mistake number 4, the DKIM alignment failure from third-party tools, is the one I encounter most often.<\/em><\/p>\n\n\n\n
If you use any outreach or warm-up tool, verify your custom DKIM is configured before anything else.<\/p>\n\n\n\n
How to Set Up DMARC for Your Domain<\/h2>\n\n\n\n
This section gives you the quick-start path. For a full walkthrough with screenshots, see our complete guide on how to set up SPF, DKIM, and DMARC<\/a>.<\/p>\n\n\n\n
Follow these seven steps:<\/p>\n\n\n\n
Step 1: Verify your SPF and DKIM are set up and passing.<\/h3>\n\n\n\n
Send a test email to yourself and check the email headers<\/a>. Look for “spf=pass” and “dkim=pass” in the authentication results. If either one fails, fix it before proceeding.<\/p>\n\n\n\n
Step 2: Create your DMARC record.<\/h3>\n\n\n\n
Start with a monitoring-only record:<\/p>\n\n\n\n
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1<\/p>\n\n\n\n