.svg)
Overview
SPF authorizes your sending servers. DKIM signs your messages. DMARC is the policy layer that ties them together and tells receiving servers what to do when authentication fails. Without DMARC, inbox providers make their own decisions about unauthenticated email, and those decisions are unpredictable. With DMARC, you control the outcome: monitor, quarantine, or reject. For GTM Engineers managing cold outbound, DMARC is the difference between hoping your emails reach the inbox and knowing they do.
Domain-based Message Authentication, Reporting, and Conformance is not just a security standard. It is a deliverability lever. Google and Yahoo made DMARC a hard requirement for bulk senders in 2024, and Microsoft followed suit. If you are sending cold email at any meaningful volume without DMARC configured on your sending domains, you are leaving deliverability on the table and exposing your domains to spoofing. This guide covers DMARC policy mechanics, the phased enforcement approach GTM Engineers should follow, reporting infrastructure, and the alignment details that determine whether your authentication actually works.
How DMARC Works
DMARC is a DNS TXT record published on your domain that does two things: it sets a policy for how receiving servers should handle email that fails SPF and DKIM authentication, and it specifies where to send aggregate and forensic reports about authentication results.
When a receiving server gets an email claiming to be from your domain, it performs SPF and DKIM checks, then looks up your DMARC record. DMARC asks two questions: (1) did SPF or DKIM pass, and (2) does the passing mechanism's domain align with the From header domain? If at least one mechanism passes and aligns, DMARC passes. If both fail or neither aligns, DMARC fails, and the receiving server applies your stated policy.
The DMARC Record
A DMARC record is a TXT record published at _dmarc.yourdomain.com. Here is a typical configuration for a team that has completed their authentication setup:
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; adkim=r; aspf=r; pct=100;
| Tag | Value | What It Does |
|---|---|---|
v=DMARC1 | Required | Identifies this as a DMARC record |
p= | none / quarantine / reject | Policy for failed authentication |
rua= | mailto: address | Where to send aggregate reports (daily summaries) |
ruf= | mailto: address | Where to send forensic reports (individual failures) |
adkim= | r (relaxed) / s (strict) | DKIM alignment mode |
aspf= | r (relaxed) / s (strict) | SPF alignment mode |
pct= | 1-100 | Percentage of failing messages to apply policy to |
The Three DMARC Policies: None, Quarantine, Reject
DMARC offers three policy levels, and each serves a specific purpose in the lifecycle of your authentication deployment. Jumping straight to reject on day one is a recipe for blocking your own legitimate email.
p=none (Monitor Only)
This is where every domain should start. The none policy tells receiving servers to deliver the email regardless of whether DMARC passes or fails, but to send you reports about the results. It changes nothing about your deliverability. What it gives you is visibility: you can see every source that sends email using your domain, whether SPF and DKIM pass for each source, and whether alignment is correct.
Stay at p=none for 2-4 weeks while you review aggregate reports and fix any authentication gaps. Common findings during this phase: a SaaS tool you forgot about that sends notifications using your domain, a sequencer integration that is not configured with custom DKIM, or an SPF record that is missing an include for a sending service.
p=quarantine
Once your reports show clean authentication across all legitimate sending sources, move to quarantine. This policy tells receiving servers to send DMARC-failing email to spam or junk folders rather than delivering it to the inbox. It is an intermediate enforcement step that catches spoofing and misconfigured sources without the risk of outright rejection.
Use the pct= tag to phase in quarantine gradually. Start with pct=10 to apply the policy to only 10% of failing messages, then increase over 2-3 weeks as you verify no legitimate email is being quarantined.
p=reject
Full enforcement. The reject policy tells receiving servers to drop DMARC-failing email entirely. It is never delivered, not even to spam. This is the ultimate goal for domain protection: anyone spoofing your domain will have their email rejected by every receiving server that supports DMARC.
For cold outbound domains specifically, p=reject is the right long-term policy because it maximizes trust signals. Receiving servers see a domain with full DMARC enforcement and treat it as more trustworthy. However, you should only move to reject after confirming that every legitimate sending source passes authentication consistently.
The recommended path for any sending domain: start with p=none for 2-4 weeks, move to p=quarantine; pct=25, increase to pct=50, then pct=100, and finally switch to p=reject. This entire process typically takes 6-8 weeks. Rushing it risks blocking your own outbound email, which is worse than having no DMARC at all.
Understanding DMARC Alignment
Alignment is the concept that makes DMARC more than just an SPF-plus-DKIM check. Even if SPF passes and DKIM passes, DMARC can still fail if neither result aligns with the From domain. This is the part that trips up most GTM Engineers managing multi-tool outbound stacks.
SPF Alignment
SPF alignment checks whether the domain in the Return-Path header (also called the envelope sender or bounce address) matches the domain in the visible From header. Many cold email platforms use their own domain for the Return-Path to handle bounces on their infrastructure. When they do, SPF passes for their domain but fails alignment with your From domain.
Example: Your email shows From: rep@try-acme.com, but the Return-Path is bounce@coldemailtool.com. SPF passes for coldemailtool.com but does not align with try-acme.com. For DMARC purposes, the SPF result is useless.
DKIM Alignment
DKIM alignment checks whether the d= domain in the DKIM-Signature header matches the From domain. If your cold email platform signs with d=try-acme.com (custom DKIM), alignment succeeds. If it signs with d=platformdomain.com (default signing), alignment fails.
Why Both Matter
DMARC passes if either SPF or DKIM passes with alignment. In practice for cold outbound, DKIM alignment is usually the one that carries the load because SPF alignment often fails when platforms use their own Return-Path domains. This is why configuring custom DKIM on every sending platform is critical, not optional. Without it, you are relying entirely on SPF alignment, which most cold email platforms break by design.
| Authentication Scenario | SPF | SPF Aligned | DKIM | DKIM Aligned | DMARC Result |
|---|---|---|---|---|---|
| Fully configured | Pass | Yes | Pass | Yes | Pass |
| Custom DKIM only | Fail | No | Pass | Yes | Pass |
| SPF pass, no custom DKIM | Pass | Yes | Pass | No | Pass (SPF carries) |
| Platform defaults only | Pass | No | Pass | No | Fail |
| No authentication | Fail | No | Fail | No | Fail |
DMARC Reporting: Your Authentication Visibility Layer
DMARC's reporting capability is arguably its most valuable feature for GTM Engineers. The reports tell you exactly what is happening with every email sent using your domain, including sources you might not even know about.
Aggregate Reports (RUA)
Aggregate reports are XML files sent daily by receiving servers to the address specified in your rua= tag. They contain summary data: which IPs sent email using your domain, how many messages, whether SPF and DKIM passed, and whether alignment succeeded. Raw XML reports are not human-readable. Use a DMARC reporting tool (dmarcian, Postmark, Valimail, or EasyDMARC) to parse and visualize them.
What to look for in aggregate reports:
- Unknown sending sources — IPs that send email using your domain but are not in your SPF record. These could be legitimate services you forgot to authorize or actual spoofing attempts.
- Authentication failures on known sources — Your own sending platforms failing SPF or DKIM. This indicates a misconfiguration that needs immediate attention.
- Alignment failures — SPF or DKIM passing but not aligning with the From domain. This is the most common issue in multi-tool outbound setups.
- Volume anomalies — Sudden spikes in sending volume from unknown IPs can indicate your domain is being spoofed.
Forensic Reports (RUF)
Forensic reports provide individual message-level detail about authentication failures. They include the email headers and sometimes the body of failing messages. Not all receiving servers send forensic reports (Gmail notably does not), and they can contain sensitive information. For most GTM teams, aggregate reports provide sufficient visibility. Enable forensic reports if you are actively investigating a spoofing incident or a persistent alignment issue.
Do not try to process DMARC XML reports manually. Even a single domain generating moderate volume will produce thousands of data points per week. Services like dmarcian, Valimail, and EasyDMARC parse reports into dashboards that show authentication health over time, flag anomalies, and recommend configuration fixes. Most offer free tiers that support a few domains, which is sufficient for teams managing dedicated outbound domains.
DMARC Implementation Checklist for GTM Engineers
Here is the practical checklist for getting DMARC right across your outbound infrastructure:
rua= to receive aggregate reports. Use a DMARC reporting service for visualization.FAQ
Technically yes, but it is pointless. DMARC evaluates SPF and DKIM results. Without either, every DMARC check will fail, and if your policy is quarantine or reject, you will be blocking your own email. Always configure SPF and DKIM before publishing a DMARC record.
By default, if a subdomain does not have its own DMARC record, it inherits the parent domain's policy. However, you can set a separate subdomain policy using the sp= tag in the parent's DMARC record (e.g., sp=reject applies reject to all subdomains). For GTM teams using subdomains for outbound, it is cleaner to publish separate DMARC records on each subdomain so you can manage policies independently.
At least 2 weeks, ideally 4. The goal is to receive enough aggregate reports to identify every legitimate sending source and fix any authentication gaps. If your outbound infrastructure is simple (one domain, one sending platform), 2 weeks may be sufficient. If you are managing multiple domains and platforms, take the full 4 weeks. Rushing to enforcement risks blocking legitimate email.
Nothing changes in terms of delivery. The p=none policy is purely observational. The email is delivered normally, and the failure is recorded in aggregate reports. This is why p=none is safe to deploy immediately. It provides visibility without any delivery risk.
What Changes at Scale
DMARC on a single outbound domain is manageable. At scale, with 10-20 sending domains each going through different stages of the none-to-reject enforcement lifecycle, the operational complexity grows quickly. Each domain generates its own DMARC reports, which need separate monitoring. Policy changes need to be phased across domains without accidentally blocking email. And every time you add a new sending tool to any domain, the authentication configuration needs verification before the next campaign goes out.
The real challenge is not the initial setup. It is maintaining authentication integrity over time as your stack evolves. A new SDR onboarding triggers new mailbox provisioning, which means DKIM keys need generating. A cold email platform changes its infrastructure, which means SPF records need updating. And nobody is monitoring the DMARC reports from the domain you set up six months ago that has quietly drifted into alignment failures.
Octave helps teams maintain DMARC compliance at scale by managing outbound execution across properly authenticated domains. The Sequence Agent routes outbound playbooks through sending infrastructure that meets your authentication requirements, and Runtime Context maintains awareness of each domain's compliance status. For GTM teams adding new sending tools or onboarding new SDRs, Octave's Playbooks ensure that every outbound sequence uses domains with valid SPF, DKIM, and DMARC configurations rather than relying on reps to manually verify authentication before launching campaigns.
Conclusion
DMARC is the policy enforcement layer that makes SPF and DKIM actionable. Without it, authentication failures are suggestions that receiving servers can ignore. With DMARC, you define what happens to unauthenticated email, and you get reporting that shows you exactly what is happening with every message sent using your domain.
The implementation path is straightforward: confirm SPF and DKIM are working, publish DMARC at p=none, review reports, fix alignment issues, and phase toward p=reject over 6-8 weeks. The ongoing work is monitoring: reviewing aggregate reports regularly, verifying authentication when you add or change sending tools, and catching alignment drift before it degrades deliverability.
For GTM Engineers, DMARC is the capstone of email authentication. It is what turns SPF and DKIM from passive checks into active domain protection and deliverability optimization. Skip it and you are leaving your domain's reputation to chance. Configure it properly and you have a provable, monitorable trust layer that inbox providers reward with better placement.