Explains none vs quarantine vs reject policies with real world recommendations.
DMARC setup for cold email is the final piece of the email authentication stack, building on top of SPF and DKIM. DMARC stands for Domain based Message Authentication, Reporting, and Conformance. It tells receiving mail servers what to do when an email fails both SPF and DKIM checks. Without a DMARC record, each receiving server decides on its own how to handle unauthenticated emails from your domain. With DMARC, you set the policy and get visibility into who is sending email as your domain.
For cold email senders, DMARC is important for two reasons. First, it protects your domain from spoofing, which means no one else can send email pretending to be you and damage your reputation. Second, a properly configured DMARC record improves your standing with email providers like Gmail and Outlook, which check for DMARC as part of their filtering decisions. This guide covers the full DMARC record setup process with a focus on the policy choices that matter most for cold email.
DMARC relies on SPF and DKIM to function. Before adding a DMARC record, send a test email and check the authentication results to confirm that both SPF and DKIM show "pass." If either is failing, fix those records first. DMARC evaluates whether at least one of SPF or DKIM passes and aligns with your domain. If both are broken, DMARC has nothing to work with and every email will fail the DMARC check regardless of your policy.
The core of a DMARC record is the policy tag, written as p= followed by one of three values. The p=none policy is monitoring mode. It does not tell receiving servers to take any action on failing emails. It just collects reports so you can see what is happening. This is the right starting point if you are setting up DMARC for the first time and want to identify all the services sending email as your domain before enforcing a stricter policy.
The p=quarantine policy tells receiving servers to send failing emails to the spam folder rather than the inbox. This is a good middle ground for cold email senders who have confirmed their SPF and DKIM are working and want to protect their domain without the risk of outright rejection. Most cold email practitioners settle on quarantine as their long term policy.
The p=reject policy tells receiving servers to block failing emails entirely. This provides the strongest protection against spoofing but carries risk if you have any legitimate services that are not properly authenticated. If even one service sends email from your domain without passing SPF or DKIM alignment, those emails will be silently dropped.
A DMARC record is a TXT record added to your DNS at the _dmarc subdomain. Here is a recommended starting record for cold email senders:
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com
The v=DMARC1 declares the record version. The p=quarantine sets the policy for failing emails. The rua=mailto:dmarc@yourdomain.com tells receiving servers where to send aggregate DMARC reports. Replace the email address with one you control. These reports arrive as XML files and show you which servers are sending email as your domain, along with their SPF and DKIM pass rates.
In your DNS provider, create a new TXT record. Set the host to _dmarc (some providers require _dmarc.yourdomain.com as the full name). Paste your DMARC record as the value. Set TTL to 3600 seconds and save. DNS propagation typically takes between a few minutes and several hours.
After publishing your DMARC record, aggregate reports will start arriving at the email address you specified. Review these reports to confirm that your legitimate sending sources are passing DMARC. If you started with p=none, move to p=quarantine once you have confirmed all services are properly authenticated. If you are on quarantine and want maximum protection, you can later move to p=reject after thorough testing.
The most dangerous mistake is jumping straight to p=reject without monitoring first. If any legitimate service is not properly authenticated, those emails will be silently blocked with no bounce notification to the sender. Always start with none or quarantine and review your reports before moving to reject.
Another common issue is DMARC alignment failure. DMARC requires that the domain in either the SPF or DKIM check matches the From address domain in the email header. If you send from sales@yourdomain.com but your SPF record authorizes a different domain, SPF will pass but DMARC alignment will fail. This is a subtle issue that catches many senders who have technically correct SPF and DKIM records but wrong alignment.
Not setting up a reporting address is a missed opportunity. Without the rua tag, you get no visibility into who is sending email as your domain or whether your policy is working as intended. The reports are the primary value of DMARC during the monitoring phase, and skipping them means flying blind.
EmailQo runs inbox health checks before every send that include DNS authentication validation. If your DMARC record is missing, set to an overly permissive policy, or failing alignment checks, the pre send check surfaces the issue before your campaign goes out. This is especially valuable when setting up new sending domains where DMARC misconfigurations are most common.