DMARC Record Enforcement: How to Move Safely to Quarantine and Reject

DMARC record enforcement is the process of changing your domain’s DMARC policy from monitoring (p=none) to an active request to quarantine or reject mail that fails DMARC. Done correctly, it makes it substantially harder for attackers to impersonate your visible From domain without breaking legitimate mail from your own tools, teams, and vendors.

The key word is request. A DMARC record publishes the handling preference of the domain owner; each receiving mail system ultimately makes its own delivery decision. That is still valuable: major mailbox providers use DMARC as part of their authentication and anti-abuse systems, while DMARC reports give you the evidence needed to find mail streams you did not know existed. (rfc-editor.org)

What DMARC record enforcement means

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It connects the domain a recipient sees in the visible From: header with SPF and DKIM authentication results.

A DMARC policy has three common modes:

• p=none — monitor only. Receivers can still evaluate DMARC, but the record requests no specific enforcement action for failing mail.
• p=quarantine — ask receivers to treat failing mail suspiciously, commonly by routing it to spam or junk.
• p=reject — ask receivers to refuse failing mail during delivery.

In practical terms, DMARC record enforcement begins at p=quarantine and reaches its strongest standard policy at p=reject. Google describes the available policy actions as delivery, quarantine, or rejection; its setup guidance also recommends reviewing authentication and reporting before applying an active policy. (support.google.com)

A policy is not an inbox-placement guarantee. DMARC does not grant authenticated mail a special right to reach the inbox, bypass spam filters, or overcome poor sender reputation. It protects the identity represented by your From domain; content quality, recipient engagement, complaint rates, IP reputation, and other signals still affect delivery. (rfc-editor.org)

How DMARC decides whether a message passes

DMARC does not require both SPF and DKIM to pass. A message passes DMARC when at least one of these conditions is true:

1. SPF passes and the SPF-authenticated domain aligns with the visible From domain.
2. DKIM passes and the DKIM signing domain aligns with the visible From domain.

The visible From domain is the domain after @ in the address recipients see. In this message:

From: Acme Updates <news@acme.example>

The DMARC Author Domain is acme.example.

SPF alignment: the common misunderstanding

SPF evaluates the envelope sender, often called MAIL FROM, Return-Path, or bounce domain. It does not authenticate the visible From header by itself.

For example, this can pass SPF but fail DMARC alignment:

From: Acme <billing@acme.example>
Return-Path: bounces@mailer.vendor-example.net

If mailer.vendor-example.net is authorized by SPF, SPF may pass. But it is not aligned with acme.example under a normal relaxed-alignment comparison, so SPF does not create a DMARC pass for this message.

This is why a branded custom return-path or a correctly aligned DKIM signature matters when you use a third-party email platform.

DKIM alignment: often the resilient route

DKIM adds a cryptographic signature to a message. The d= value in its DKIM-Signature header identifies the signing domain.

This example can produce an aligned DKIM pass:

From: Acme <billing@acme.example>
DKIM-Signature: v=1; d=acme.example; s=s1; ...

If the signature validates and d=acme.example aligns with the visible From domain, DMARC passes even if SPF fails or is unaligned. That makes aligned DKIM especially important for services that cannot offer a custom envelope sender, and for mail that may be forwarded.

Relaxed versus strict alignment

The adkim and aspf tags control alignment mode:

• r means relaxed alignment.
• s means strict alignment.

With relaxed alignment, a subdomain can align with its organizational domain. For example, mail.acme.example can align with acme.example in the usual parent-domain relationship. With strict alignment, the domains must match exactly.

A safe initial enforcement configuration normally uses relaxed alignment:

adkim=r; aspf=r

Strict alignment is appropriate only after you understand every authorized sender and intentionally want exact-domain matching. It can be useful for highly controlled domains, but it is not a default setting to copy blindly. Yahoo explicitly accepts relaxed alignment for bulk senders, provided that the visible From domain aligns with either the SPF or DKIM domain. (senders.yahooinc.com)

The DNS record you actually publish

A DMARC record is a DNS TXT record. For acme.example, publish it at this hostname:

_dmarc.acme.example

Not at the root of the domain. Not at dmarc.acme.example. Not as a CNAME unless your DNS and DMARC design specifically support that arrangement.

A conservative monitoring record looks like this:

Type: TXT
Host/Name: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@acme.example; adkim=r; aspf=r

An enforced record at the final stage looks like this:

Type: TXT
Host/Name: _dmarc
Value: v=DMARC1; p=reject; rua=mailto:dmarc-reports@acme.example; adkim=r; aspf=r

The essential syntax rules are straightforward:

• v=DMARC1 must be present and should be first.
• p= defines the requested policy for the domain.
• Tags are separated with semicolons.
• rua= requests aggregate reports at one or more mailto: addresses.
• Add only one DMARC TXT record at a given _dmarc hostname. Multiple competing DMARC records can cause receivers to treat the policy as invalid.

Google’s DMARC example includes v=DMARC1, a reject policy, aggregate-report addresses, pct=100, and strict alignment tags, but those optional choices should reflect your own rollout and mail architecture rather than be treated as universal defaults. (support.google.com)

What sp= does for subdomains

The sp= tag sets a requested policy for subdomains when they do not have their own DMARC record.

For example:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@acme.example; adkim=r; aspf=r

This asks receivers to reject failing mail using acme.example while asking them to quarantine failing mail using subdomains such as news.acme.example, unless those subdomains publish their own policy.

This can be a useful transition control. It is also an area where teams get surprised: a subdomain used by a forgotten product, support platform, or acquisition may begin failing under the parent domain’s inherited policy. Inventory subdomain senders before assuming sp=reject is safe.

Why p=none is not DMARC enforcement

A p=none record is a real DMARC deployment. It enables DMARC evaluation and can request aggregate reports. It is often required for sender compliance programs because it proves you have published a valid policy.

For example, Gmail’s bulk-sender requirements specify SPF, DKIM, and DMARC for senders that send more than 5,000 messages per day to personal Gmail accounts, while allowing the DMARC enforcement policy to remain p=none. Yahoo’s bulk-sender guidance similarly requires a valid DMARC policy of at least p=none and says DMARC must pass. (support.google.com)

But monitoring is not the same as brand protection. If a criminal sends a message that visibly claims to be from ceo@acme.example, and the message fails DMARC, a p=none record does not ask the receiver to quarantine or reject it. The receiver may still filter it based on its own systems, but your domain is not publishing an enforcement request.

Think of the stages this way:

The goal is not to remain at monitoring forever. The goal is to use monitoring long enough to identify legitimate senders, then safely enforce.

Audit every system that can send as your domain

The hardest part of DMARC record enforcement is not adding a TXT record. It is finding all the systems that send mail with your domain in the visible From address.

Create a sender inventory before changing policy. Include systems that are obvious, but also systems that send only occasionally: invoice tools, form notifications, applicant tracking systems, calendar tools, help desks, incident platforms, product alerts, and staff using a legacy SMTP relay.

Your inventory should include at least these fields:

Do not limit the audit to vendors listed in your procurement system. Aggregate reports often reveal unknown SaaS platforms, old agencies, and unauthorized infrastructure. They can also reveal direct domain spoofing: mail sent from IP addresses that no approved vendor owns.

If you operate application email, make the sending-domain configuration part of your deployment checklist. Your team should be able to identify the From domain, envelope domain, DKIM selector, and DMARC result for every production stream. That discipline is as important as the record itself; use your provider’s email API setup guides to document DNS ownership and sender authentication alongside your application configuration.

Read DMARC aggregate reports before enforcing

The rua tag asks participating receivers to send aggregate feedback reports. These are usually machine-readable XML files, often compressed, rather than readable email summaries.

A report normally groups messages by source IP, authentication result, policy result, and header From domain. That lets you answer questions such as:

• Which IPs claim to send as our domain?
• Which mail streams pass DKIM and SPF?
• Is a legitimate vendor failing alignment?
• Is anyone spoofing our domain directly?
• Are subdomains generating traffic we did not expect?

Use either a DMARC reporting service or an internal parser and dashboard. The choice is operational, not protocol-driven: a reporting platform reduces XML handling and offers source classification, while an internal approach can suit organizations that need direct control over security data.

The report pattern that matters

Do not judge readiness by a single global “DMARC pass rate.” A 99% pass rate can still hide a broken payroll sender, a low-volume executive communications service, or an incident-alert channel.

Instead, investigate every legitimate source that fails. For each source, decide whether it is:

1. An approved sender that needs aligned DKIM or SPF.
2. A sender using the wrong From domain and needing a domain or configuration change.
3. A retired service that should be shut down.
4. An unauthorized source or direct spoofing attempt.

Only the first two are authentication projects. The others are governance and security actions.

Google recommends a dedicated mailbox or group for DMARC reports because report volume varies with sending volume and destination diversity; large organizations can receive hundreds or thousands of reports each day. (support.google.com)

A safe DMARC enforcement rollout

There is no universal number of days to monitor because every domain has a different sender inventory, mail volume, and vendor landscape. Move based on evidence, not on an arbitrary calendar deadline.

Phase 1: Publish monitoring

Start with:

v=DMARC1; p=none; rua=mailto:dmarc-reports@acme.example; adkim=r; aspf=r

Confirm that the record resolves publicly and that the report mailbox or service receives data. Then classify all meaningful sources in the reports.

Do not move on merely because the record exists. A syntactically correct record with no reporting workflow gives you little operational confidence.

Phase 2: Fix aligned authentication

For each approved sender, configure one or both of the following:

• Aligned DKIM: Prefer the vendor’s custom-domain DKIM feature so its d= domain is your domain or an aligned subdomain.
• Aligned SPF: Configure a custom bounce or return-path domain when the service supports it, then authorize the service through the appropriate SPF design.

Avoid trying to solve every vendor problem by endlessly adding SPF includes. SPF has DNS-lookup constraints, and a sprawling SPF record becomes fragile. Aligned DKIM is frequently the cleaner option for third-party platforms because it can authenticate the visible brand domain without depending on the vendor’s default return-path domain.

Phase 3: Move to quarantine

After approved mail is consistently passing DMARC, publish:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@acme.example; adkim=r; aspf=r

Continue watching reports, delivery logs, and support tickets. Quarantine is not harmless: some receivers may route a failing but legitimate message to spam rather than accept it normally. Treat it as enforcement, not as a test mode that requires no preparation.

Phase 4: Move to reject

When failures attributable to legitimate mail have been corrected or consciously retired, publish:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@acme.example; adkim=r; aspf=r

Keep reports enabled after reaching reject. Enforcement is not a one-time project. New marketing tools, acquired domains, product teams, and agency campaigns can introduce a non-aligned sender months later.

Worked example: enforcing DMARC for a SaaS company

Assume northstar.example uses three legitimate outbound systems:

1. Google Workspace for employee mail from @northstar.example.
2. An email API provider for receipts and password resets from notify@northstar.example.
3. A marketing platform for newsletters from news@northstar.example.

The company publishes this monitoring record:

_dmarc.northstar.example TXT
v=DMARC1; p=none; rua=mailto:dmarc-reports@northstar.example; adkim=r; aspf=r

After reports arrive, the team finds these results:

The email API provider is the risk. Its SPF pass is not useful for DMARC because the return-path belongs to the provider. Its DKIM signature also fails alignment because provider.example is unrelated to northstar.example.

The team uses the provider’s domain-authentication flow to publish the DKIM selector records it supplies. After propagation, test messages contain a header similar to:

Authentication-Results: recipient.example;
  dkim=pass header.d=northstar.example;
  spf=pass smtp.mailfrom=bounces.provider.example;
  dmarc=pass header.from=northstar.example

SPF remains unaligned, but DMARC now passes because aligned DKIM passes. Once reports show the three approved sources consistently passing and the unknown source continues to fail, the company changes its policy to:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@northstar.example; adkim=r; aspf=r

After continued monitoring confirms no legitimate failures, it changes the record again:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@northstar.example; adkim=r; aspf=r

The unknown cloud IP can still send messages that display northstar.example in From, but participating receivers now have Northstar’s explicit request to reject messages that fail DMARC. That is the practical result of enforcement.

How to verify that enforcement works

Verification has three layers: DNS, message authentication, and observed policy behavior.

1. Verify public DNS

Use a DNS lookup from a command line:

dig +short TXT _dmarc.northstar.example

You should see one DMARC TXT value containing the policy you intended. Some DNS tools display quoted strings or split long TXT records into multiple quoted chunks; that presentation can be normal if the combined value is correct.

Check for these mistakes:

• The record exists at northstar.example rather than _dmarc.northstar.example.
• There are two DMARC TXT records.
• The value contains malformed tags or a typo in v=DMARC1.
• The report address is misspelled or unmonitored.
• DNS changes were made in the wrong provider account or zone.

2. Verify a real message header

Send a message from each approved stream to a mailbox where you can inspect full headers. Find Authentication-Results and look for a line similar to:

dmarc=pass header.from=northstar.example

Also inspect the individual mechanisms:

spf=pass smtp.mailfrom=...
dkim=pass header.d=...

A message can show spf=pass and dkim=pass yet still fail DMARC if neither passing domain aligns with the visible From domain. Always verify the dmarc= result, not just the SPF and DKIM labels.

3. Verify report outcomes and controlled failure behavior

Aggregate reports should show the approved mail streams with DMARC pass results. The exact report format and timing differ by receiver, so do not expect every destination to provide identical data.

For a controlled test, use a non-production test domain or a carefully isolated test sender. Do not deliberately send spoofed messages to customers, partners, or broad mailing lists. The objective is to confirm that an intentionally misaligned message is evaluated as a DMARC failure and that your policy is published, not to create a phishing-like incident.

Google Postmaster Tools can also help eligible senders monitor authentication, reputation, spam rates, and delivery errors for mail sent to personal Gmail accounts. (support.google.com)

What commonly breaks after enforcement

The most frequent failures are predictable. They usually come from an untracked sender, an assumption that SPF pass equals DMARC pass, or a change made by a vendor after the original setup.

A vendor uses its own DKIM domain

A platform signs with d=vendor.example while your visible From address uses @yourdomain.example. DKIM passes, but it is not aligned.

Fix: Enable custom DKIM/domain authentication in the vendor account, or use an aligned sending subdomain that the platform supports.

The return-path is unaligned

A service sends From @yourdomain.example but uses a bounce domain under its own domain. SPF can pass but will not align.

Fix: Configure a custom return-path domain if available, or rely on aligned DKIM.

Forwarding breaks SPF

Forwarding can cause SPF failure because the receiving system sees the forwarder’s IP address instead of the original sender’s IP. This is one reason aligned DKIM is important: a valid, aligned DKIM signature can preserve DMARC pass when SPF no longer succeeds.

Mailing lists alter the message

Mailing lists may add footers, modify subject lines, or resend the message in ways that invalidate DKIM. They may also use their own envelope sender, making SPF unaligned.

Fix: Configure list behavior for DMARC compatibility where possible, use an appropriate list-specific sending domain, or accept that certain third-party redistribution patterns need separate design. Do not discover this for the first time after applying p=reject to a widely used corporate domain.

A subdomain inherits a policy unexpectedly

A parent domain moves to reject and a product subdomain without its own DMARC record starts failing. The subdomain may be used by an old platform or by a business unit outside the central email team.

Fix: Publish an explicit DMARC record for the subdomain while you remediate it, or use sp= deliberately during the transition.

Someone changes SPF and forgets DMARC

A new service is added to SPF, but its visible From domain and envelope sender still do not align. Or the SPF record becomes too complex and stops evaluating as expected.

Fix: Treat email authentication as a release requirement. Test the complete DMARC result whenever a sending service, sender domain, return-path, or DKIM selector changes.

Practical policy choices for different teams

A single policy design does not fit every organization, but the following approaches are generally defensible.

Small business with one mailbox provider and one application sender

Use a monitoring record with rua, set up DKIM for the mailbox provider and application sender, verify both through message headers, then progress to p=reject. The simpler the sender inventory, the faster the evidence-gathering stage can be.

SaaS company with transactional and marketing mail

Keep transactional and marketing streams documented separately, even if they share the same root domain. Transactional email has a higher operational impact: an authentication failure can block password resets, invoices, alerts, or receipts. A subdomain strategy such as mail.example.com or news.example.com can make ownership and vendor boundaries clearer, provided you configure alignment intentionally.

Enterprise with many business units and acquisitions

Begin with centralized reporting and sender ownership. Consider a phased policy using explicit subdomain records rather than treating the root domain as the only control point. The priority is to avoid breaking critical legacy mail while still preventing direct spoofing of the most recognizable corporate domain.

Brand with no legitimate outbound email

You may be able to reach p=reject quickly because there are no approved senders to preserve. Still publish rua and monitor afterward: the reports can reveal spoofing attempts and unexpected systems that have begun using the domain.

DMARC enforcement is a security control, not the whole email program

A reject policy protects recipients against messages that falsely use your exact protected domain in the visible From field and fail aligned authentication. It does not prevent every phishing technique.

Attackers can register lookalike domains, abuse display names, compromise legitimate mailboxes, send from other domains, or use web channels instead of email. DMARC also does not replace mailbox-provider requirements around TLS, reverse DNS, complaint rates, list-unsubscribe handling, and message formatting. Gmail and Yahoo both publish sender requirements beyond authentication, particularly for higher-volume senders. (support.google.com)

That limitation is not a reason to skip enforcement. It is a reason to set the right expectation: DMARC is a precise control for domain impersonation, and it works best as part of a broader sender-security and deliverability program.

Conclusion

DMARC record enforcement is successful when legitimate mail continues to pass DMARC and unauthorized mail using your domain fails under a published quarantine or reject policy. The path is simple in concept: discover senders, configure aligned SPF or DKIM, monitor aggregate reports, move to quarantine, then move to reject.

The DNS change takes minutes. The work that protects your business is the sender inventory, alignment verification, report review, and ongoing change management behind it. Treat p=reject as the end state for a domain whose identity matters, not as a record to paste in before you know how your mail is sent.

FAQ

What is DMARC record enforcement?

DMARC record enforcement means publishing p=quarantine or p=reject in your DMARC TXT record. These policies ask receiving systems to treat mail that fails DMARC as suspicious or reject it, rather than merely monitor the failure.

Should I go directly to p=reject?

Only if you have strong evidence that every legitimate sender already passes aligned SPF or DKIM. Most organizations should begin at p=none, use reports to identify all senders, fix failures, and then move through p=quarantine before p=reject.

Does DMARC require both SPF and DKIM?

No. DMARC passes when either SPF passes and aligns with the visible From domain, or DKIM passes and aligns with that domain. Using both remains best practice because different mail flows can affect SPF and DKIM differently.

Does p=reject guarantee spoofed messages never arrive?

No. DMARC publishes a requested policy, and receivers make their own final handling decisions. It also does not stop lookalike domains or phishing that does not use your protected From domain. It does provide the strongest standard DMARC policy signal for unauthenticated use of your domain.

How do I know my DMARC record is working?

Confirm the TXT record at _dmarc.yourdomain, inspect real message headers for dmarc=pass, and review aggregate reports for all authorized senders. After enforcement, keep monitoring for new legitimate failures and unauthorized sources.