DMARC Deployment Guide: From p=none to p=reject

Why Deploy DMARC

Deploying DMARC is the single most effective step to stop email spoofing and protect your domain's sending reputation. Without a DMARC record, anyone can send email as your domain, and receivers have no policy to act on — the spoofed message gets delivered. DMARC deployment gives you visibility into who sends email as your domain and, at enforcement, blocks unauthorized senders entirely.

As of 2026, DMARC is no longer optional. Bulk and high-volume sender requirements from Gmail, Yahoo, and Microsoft make a published DMARC record effectively mandatory for many email programs; enforcement scope differs by provider. The bulk sender requirements formalized what was already happening: receivers penalize unauthenticated domains.

Beyond compliance, DMARC gives you visibility. Aggregate reports reveal every IP address sending email as your domain — legitimate services you've authorized, shadow IT services you didn't know about, and attackers spoofing your domain for phishing campaigns. This visibility alone justifies deployment, even before enforcement provides active protection.

The goal is p=reject. The path there requires careful preparation to avoid blocking legitimate email. This guide walks through each phase.

DMARC Deployment Prerequisites

Before publishing a DMARC record, verify that your authentication infrastructure is in place. DMARC builds on SPF and DKIM — deploying it without these foundations produces misleading reports and risks blocking legitimate email when you move to enforcement.

Valid SPF Record

Run the mxio SPF Checker on your domain. Confirm:

• A single valid SPF record exists (no duplicate records)
• All services authorized to send email as your domain are included
• The total lookup count is under the 10-lookup limit
• The record uses an appropriate qualifier (~all or -all)

If your SPF record exceeds the lookup limit, address that first. A PermError from too many DNS lookups means SPF evaluation fails entirely, which cascades into DMARC failures. SPF flattening reduces lookup count; mxio's Managed SPF handles this automatically. See What Is SPF Flattening? for the full explanation.

DKIM Signing for All Legitimate Senders

Run the mxio DKIM Checker for each service that sends email as your domain. Every sending source should have DKIM configured with your domain in the d= tag.

DKIM alignment is more reliable than SPF alignment for DMARC purposes. SPF breaks when email is forwarded (the forwarding server's IP isn't in your SPF record). DKIM survives forwarding as long as the message body isn't modified. Configuring DKIM for every sender is the single most impactful step for a successful DMARC deployment.

Complete Sender Inventory

Build a list of every service, server, and application that sends email using your domain in the From: header. This inventory is critical — missing a legitimate sender means their email gets blocked when you move to enforcement.

Common sources that administrators overlook:

Ask every department. Marketing, sales, support, HR, engineering, and finance all may have services sending email as your domain without your knowledge.

DNS Management Access

You need the ability to create and modify TXT records at _dmarc.yourdomain.com. Confirm you have access to your DNS hosting provider before starting.

Phase 1: DMARC Monitoring with p=none

Start with a monitoring-only policy. This collects data about your email ecosystem without affecting delivery.

Publish the DMARC Record

Add a TXT record at _dmarc.yourdomain.com:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1"

Breaking down each tag:

The p=none policy tells receivers: "If DMARC fails, deliver the message anyway, but send me a report." No legitimate email is affected. You are purely observing.

Set Up the DMARC Reporting Mailbox

The rua= address receives DMARC aggregate reports — XML files sent daily by major receivers (Gmail, Microsoft, Yahoo, and others). These reports contain authentication results for every message sent using your domain.

Use a dedicated mailbox (dmarc-reports@yourdomain.com or dmarc@yourdomain.com). For domains with significant email volume, aggregate reports can be large. Avoid sending them to a personal inbox.

Warning: If the reporting address is at a different domain than the one being protected (e.g., DMARC for example.com sends reports to reports@monitoring.com), the receiving domain must publish an authorization record. Without it, receivers silently discard the reports. The authorization record is a TXT record at example.com._report._dmarc.monitoring.com containing v=DMARC1.

Verify the DMARC Record

After publishing, run the mxio DMARC Checker to confirm:

• The record is found at _dmarc.yourdomain.com
• The syntax is valid
• The reporting address is correctly formatted
• No conflicting records exist

How Long to Monitor

Stay on p=none for a minimum of 2-4 weeks. Ideally, monitor for a full business cycle — long enough to capture monthly newsletters, billing cycle emails, quarterly reports, and any seasonal sending patterns.

The goal during this phase is complete coverage: every legitimate sender must appear in your aggregate reports and pass DMARC. Do not rush to enforcement. A missed sender discovered after enforcement causes delivery failures that take time to diagnose and fix.

Phase 2: Analyze DMARC Aggregate Reports

After 24-48 hours on p=none, aggregate reports start arriving. These are the foundation of your deployment — they tell you exactly what is happening with email sent as your domain.

Aggregate Report Structure

Aggregate reports are XML files (often gzip-compressed) conforming to the format defined in RFC 7489, Appendix C. Each report covers a reporting period (typically 24 hours) and contains:

• Report metadata — Reporter identity (e.g., google.com), date range, your DMARC policy
• Policy published — Your DMARC record as the receiver saw it
• Records — One entry per unique combination of source IP, SPF result, DKIM result, and disposition

Key Fields to Examine

For each record in the report, examine:

The most important question for each record: Is this source IP legitimate? If yes, does it have at least one aligned pass (SPF or DKIM)? Configuring both is ideal for resilience. If it fails both, you have a gap to fix before enforcement.

Identifying What Is in Your Reports

Reports typically contain three categories of senders:

Legitimate senders passing authentication. These are your correctly configured services — mail servers, ESPs, and applications that pass SPF and/or DKIM with alignment. No action needed. Confirm these match your sender inventory.

Legitimate senders failing authentication. These are authorized services that are not properly configured for DMARC. The source IP belongs to a service you recognize, but SPF fails (missing include), DKIM fails (not configured or wrong selector), or alignment fails (authenticating as the vendor's domain instead of yours). These must be fixed before enforcement.

Unauthorized senders. These are IP addresses you do not recognize sending email as your domain. They could be spammers, phishers, or compromised systems. These are the messages DMARC enforcement will block. If you are not sure whether a source is legitimate, look up the IP — reverse DNS, ASN information, and geolocation can help identify the owner.

Common Report Findings

Phase 3: Fix DMARC Authentication Gaps

Every legitimate sender that fails DMARC in your reports must be fixed before moving to enforcement. Work through your report findings systematically.

Missing SPF Include

If a legitimate service's sending IP is not covered by your SPF record, add the appropriate include: mechanism. Each provider publishes their SPF include domain in their documentation:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net ~all

Run the mxio SPF Checker after each change to verify the record is still valid and within the 10-lookup limit. If adding another include pushes you over the limit, use mxio's Managed SPF to flatten your record automatically. See What Is SPF Flattening? for the full technique explanation.

Missing DKIM Configuration

For each service that does not have DKIM signing configured with your domain, follow the provider's DKIM setup process. This typically involves adding CNAME or TXT records to your DNS:

selector1._domainkey.yourdomain.com  CNAME  selector1-yourdomain-com._domainkey.provider.com
selector2._domainkey.yourdomain.com  CNAME  selector2-yourdomain-com._domainkey.provider.com

After publishing the DNS records, enable DKIM signing in the provider's admin panel. Send a test email and verify the DKIM signature with the mxio DKIM Checker.

Alignment Issues

If SPF and DKIM both pass but DMARC still fails, the problem is alignment. The authenticated domains do not match the From: header domain. This is the most common issue with third-party senders.

SPF alignment fix: Configure the third-party service to use a custom Return-Path (bounce domain) under your domain. SendGrid calls this "domain authentication," Amazon SES calls it "custom MAIL FROM domain."

DKIM alignment fix: Configure the service to sign with d=yourdomain.com instead of their default domain. This is the more reliable fix because DKIM alignment survives forwarding.

See DMARC Alignment Failure for detailed scenarios and fixes.

Forwarding Services

Mailing lists, email forwarding rules (.forward), and university alumni forwarding break SPF by design — the forwarding server's IP is not in the original sender's SPF record. This is expected and not something you can fix by modifying your SPF record.

The solution is DKIM. A valid DKIM signature with d=yourdomain.com survives forwarding as long as the forwarding server does not modify the message body. Major forwarding services preserve DKIM signatures. Some that add footers or rewrite URLs may break the signature — in those cases, ARC (Authenticated Received Chain) provides a chain of custody that major receivers like Gmail and Microsoft honor.

Ensure DKIM is configured for all senders. Do not rely on SPF alone for DMARC alignment.

Phase 4: DMARC Quarantine Enforcement (p=quarantine)

Once your aggregate reports show that all legitimate senders consistently pass DMARC, begin enforcement with the quarantine policy. Use the pct= tag to limit the blast radius.

Start at 10%

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@yourdomain.com; fo=1"

The pct=10 tag instructs receivers to apply the quarantine policy to only 10% of messages that fail DMARC. The remaining 90% are treated as if the policy were still p=none. This limits the impact if a legitimate sender was missed during the monitoring phase.

"Quarantine" means the receiver should treat the failing message as suspicious. In practice, this almost always means routing the message to the recipient's spam or junk folder rather than the inbox.

Increase Gradually

After 1-2 weeks at each level with no reports of legitimate email going to spam, increase the percentage:

At each step:

• Review aggregate reports. Look for any new legitimate sources failing DMARC. New services get added by other teams without warning — this is the most common cause of enforcement problems.
• Check with stakeholders. Ask marketing, sales, and support teams if they have noticed any delivery issues or customer complaints about missing email.
• Monitor bounce rates. A spike in bounces from quarantined messages can indicate a misconfigured sender.

When to Pause

If aggregate reports reveal a legitimate sender failing DMARC that you missed, pause the rollout:

1. Fix the sender's authentication (add SPF include, configure DKIM, fix alignment)
2. Verify the fix by checking the next day's aggregate reports
3. Resume the percentage increase

Do not reduce the pct= value unless you are seeing widespread legitimate email going to spam. A single missed sender is a fix-and-continue situation, not a rollback.

Phase 5: Full DMARC Enforcement (p=reject)

After running p=quarantine at 100% for at least 2-4 weeks with clean reports, move to the final enforcement level.

Deploy p=reject

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; fo=1"

With p=reject, receiving servers bounce messages that fail DMARC. The email is never delivered — not to the inbox, not to spam. The sender receives a bounce notification (if their server processes bounces).

You can use the same pct= ramp-up approach here for additional caution:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=reject; pct=25; rua=mailto:dmarc-reports@yourdomain.com; fo=1"

At pct=25, 25% of failing messages are rejected outright. The remaining 75% fall back to the quarantine behavior from your previous policy level.

After Reaching p=reject

Keep rua= in your record permanently. DMARC is not set-and-forget — ongoing monitoring is essential. New sending services, infrastructure changes, and DKIM key rotations all require continued attention.

Run the mxio DMARC Checker periodically to confirm your record is still properly configured and no DNS issues have appeared.

Common DMARC Deployment Pitfalls

Jumping Straight to p=reject

The most destructive DMARC mistake is deploying p=reject without a monitoring phase. Organizations that do this invariably block legitimate email they did not know about — a CRM system sending appointment confirmations, an HR platform sending onboarding emails, a monitoring service sending alerts. The damage is immediate (email bounces) and the diagnosis takes time (identifying which service was blocked, contacting its owner, configuring authentication).

Always start with p=none. Always monitor for at least 2-4 weeks. There are no shortcuts.

Forgetting Third-Party Senders

The most commonly missed senders during DMARC deployment are third-party services that departments set up independently:

• Marketing signed up for a new campaign tool and configured it to send as your domain
• Support integrated a new helpdesk that sends ticket notifications
• Engineering set up a staging environment that sends email with production From: addresses
• Finance uses an invoicing service that sends payment receipts as your domain

Each of these services needs SPF authorization and DKIM signing configured for your domain. The p=none monitoring phase exists specifically to catch these.

Mailing List Breakage

Mailing lists (Listserv, Google Groups, Mailman) receive email from your users and redistribute it to list subscribers. The redistributed message keeps the original From: header (your user's address), but it is now sent from the mailing list server's IP. SPF fails because the list server is not in your SPF record.

Some mailing lists also modify the message body (adding footers, subject tag prefixes), which breaks DKIM signatures.

This is a known limitation of DMARC, documented in RFC 7960. The mitigations:

• DKIM without body modification: If the list does not modify the body, DKIM alignment still works. This is the ideal case.
• ARC: Lists that support ARC (Authenticated Received Chain) preserve the original authentication results across the forwarding hop. Gmail and Microsoft validate ARC chains.
• List-specific configurations: Some lists rewrite the From: header to use the list's domain, avoiding the alignment problem entirely. This changes the user experience but eliminates DMARC failures.

Accept that some mailing list messages from your users will fail DMARC at p=reject. This is a trade-off: protecting your domain from spoofing versus compatibility with legacy mailing lists. For most organizations, the protection outweighs the mailing list inconvenience.

Subdomain Policy

By default, subdomains inherit the parent domain's DMARC policy. If your record is p=reject at _dmarc.yourdomain.com, then sub.yourdomain.com is also subject to p=reject — unless the subdomain has its own DMARC record.

The sp= tag lets you set a separate policy for subdomains:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=reject; sp=none; rua=mailto:dmarc-reports@yourdomain.com"

This enforces p=reject on the organizational domain but p=none on all subdomains. This is useful during deployment — you can enforce the parent domain while still monitoring subdomains.

Warning: Without sp= or individual subdomain DMARC records, attackers can spoof subdomains that do not send email (e.g., fake.yourdomain.com). If your parent domain is at p=reject but subdomains lack explicit subdomain-level controls, consider setting sp=reject to block subdomain spoofing, or publish individual _dmarc.subdomain.yourdomain.com records for subdomains that need different policies.

Strict vs Relaxed Alignment

DMARC supports two alignment modes, controlled by adkim= (DKIM) and aspf= (SPF) tags:

• Relaxed (r, the default): The authenticated domain and the From: domain share the same organizational domain. mail.yourdomain.com aligns with yourdomain.com.
• Strict (s): The authenticated domain must exactly match the From: domain. mail.yourdomain.com does not align with yourdomain.com.

Use relaxed alignment unless you have a specific security requirement for strict matching. Strict alignment breaks legitimate email from subdomains and makes third-party sender configuration more difficult. Most organizations never need strict alignment.

See DMARC Alignment Failure for detailed alignment troubleshooting.

DMARC Record Reference

All DMARC tags as defined in RFC 7489:

Why Missing ruf= Is Not a Problem

The ruf= tag requests forensic (failure) reports — per-message details sent when DMARC authentication fails. In theory, these reports help diagnose individual failures. In practice, they are largely unsupported.

Most major mailbox providers do not send forensic reports. Gmail, Microsoft 365, and Yahoo stopped sending them years ago, citing privacy concerns. Forensic reports can contain message headers with personally identifiable information (PII), and RFC 7489 §7.2 explicitly flags this risk. GDPR and similar privacy regulations make it even less likely that receivers will share message-level data with third parties.

Aggregate reports (rua=) are the reliable data source. They provide daily summaries of authentication results across all messages from your domain — which IPs sent email, whether SPF and DKIM passed, and whether DMARC alignment succeeded. This is the data you actually need for monitoring and enforcement decisions.

Because forensic reports are unreliable and not required by the DMARC specification, mxio treats a missing ruf= tag as informational — it will not lower your health score or trigger a warning. If you do configure ruf=, we validate the address, but omitting it entirely is a perfectly valid configuration.

Example Records for Each Phase

Phase 1 -- Monitoring:

"v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1"

Phase 4 -- Quarantine with ramp-up:

"v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com; fo=1"

Phase 5 -- Full enforcement with subdomain policy:

"v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@yourdomain.com; fo=1"

Ongoing DMARC Monitoring and Maintenance

DMARC deployment does not end at p=reject. The policy requires ongoing attention to remain effective and avoid blocking legitimate email as your sending infrastructure evolves. Use the mxio Domain Health tool to monitor your DMARC, SPF, and DKIM records continuously and get alerts when something changes.

Review Reports Regularly

Check aggregate reports at least monthly, even after reaching p=reject. Look for:

• New legitimate senders failing DMARC. Teams add new services without informing the email administrator. A new marketing tool, a new ticketing system, or a new notification service — any of these can start failing DMARC if authentication is not configured.
• Spikes in unauthorized sending. A sudden increase in failing messages from unknown IPs may indicate an active phishing campaign targeting your domain. While p=reject blocks these messages, the reports give you visibility into the attack.
• Changes in volume patterns. Significant changes in message volume from known sources may indicate configuration changes, compromised accounts, or service migrations.

Rotate DKIM Keys

DKIM keys should be rotated periodically — annually at minimum, quarterly for high-security environments. The rotation process:

1. Generate a new key pair and publish the new public key under a new selector
2. Configure the mail server to sign with the new selector
3. Keep the old public key published for 1-2 weeks (to validate messages still in transit)
4. Remove the old public key

After rotation, verify the new key with the mxio DKIM Checker and confirm DMARC reports show continued pass results.

Update When Adding New Services

Before any new service begins sending email as your domain:

1. Add the service's sending IPs or include to your SPF record
2. Configure DKIM signing with your domain
3. Send test messages and verify DMARC passes in the headers
4. Confirm the service appears in the next aggregate report with passing results

Establish a process for this. Make DMARC verification part of the onboarding checklist for any new tool or platform that sends email.

Document Your Configuration

Maintain a record of:

• Every service authorized to send email as your domain
• The SPF include mechanism for each service
• The DKIM selector and key details for each service
• When each configuration was last verified
• When DKIM keys were last rotated

This document is invaluable when diagnosing DMARC failures and onboarding new team members who manage email infrastructure.

Related Articles

• Why Is DMARC Failing? -- Diagnosing DMARC authentication failures
• DMARC Alignment Failure -- When SPF and DKIM pass but DMARC fails
• DMARC p=none: Why You Should Enforce -- Risks of staying on monitoring mode
• No DMARC Record Found -- Setting up DMARC from scratch
• Gmail Error 550 5.7.26 -- Gmail rejecting email due to DMARC enforcement
• Bulk Sender Requirements -- Gmail, Yahoo, and Microsoft authentication requirements
• SPF Flattening Explained -- Reducing SPF lookup count for DMARC compliance
• Email Authentication Guide -- How SPF, DKIM, and DMARC work together