Your DMARC record can pass a syntax check while your password-reset emails fail authentication. If you move to enforcement before finding that gap, your customers could struggle to access their accounts.
You’re ready for DMARC enforcement when you know your legitimate senders, have verified their aligned authentication, understand the remaining failures, and have tested your critical email workflows. You also need people responsible for the rollout and ongoing monitoring.
These 15 checks will help you find what needs attention and turn those gaps into a practical action plan.
What changes when you enforce DMARC?
DMARC connects email authentication to the domain recipients see in the From address. Your published policy tells receiving systems how you’d like them to handle messages that fail DMARC:
- p=none: Requests no change to message handling based on DMARC. With reporting configured, it supports monitoring.
- p=quarantine: Requests suspicious treatment of failing messages, often placing them in spam or junk.
- p=reject: Requests rejection of messages that fail DMARC.
Quarantine and reject are enforcement policies. Either can affect legitimate email that fails authentication.
Receiving systems make the final delivery decision, and a DMARC pass doesn’t guarantee inbox placement. Before changing policy, establish which legitimate messages could be affected.
1. Your sender inventory stops at Microsoft 365 or Google Workspace
Your main email provider is only part of the picture. Invoices, support replies, recruitment messages, website notifications, and marketing campaigns may travel through different services.For example, an older billing application could send renewal notices through a route your IT team rarely sees.
Compare observed sending activity with application records and input from departments, and be sure to include tools that agencies and outsourced teams manage. For each legitimate service, record its sending domains and message types. Investigate unfamiliar activity before deciding whether to authorize it.
2. Some sending services don’t have an owner
You’ve found an event platform in your reports. IT recognizes the vendor, but nobody knows whether marketing still uses it or an agency controls the account. Without an owner, confirming or changing its setup becomes much harder.
To avoid situations like this, give every approved service a business owner and a technical contact. They should be able to confirm:
- Which account the organization uses
- What messages it sends and from which domains
- Who can change its authentication settings
- How to reach the vendor’s support team
Resolve those ownership gaps before you need someone to troubleshoot a failed campaign.
3. You’ve published a record, but useful reports aren’t reaching your team
A DNS checker can confirm that your DMARC record exists, but it can’t tell you whether anyone has reviewed the sending activity behind it.
Check the aggregate reporting destination in your record’s rua tag. Confirm that reports reach your analysis platform and that any required authorization for an external reporting destination is in place, then assign someone to review them. Valimail’s guide to reading a DMARC report explains where to start.
Aggregate reports cover activity that participating receivers report they aren’t a complete, immediate delivery log. You’ll still want to fill important gaps with sender logs and controlled tests.
4. Your monitoring window missed important sending cycles
A quiet week can hide a busy month’s problems.
If you start reviewing reports just after monthly invoices go out, that sending activity might not appear again until after your planned policy change. Quarterly statements, annual notices, and recovery emails can create similar blind spots.
Ask service owners when their systems send. For important messages missing from your observation period, run controlled tests through the actual production sending route.
Choose your monitoring window around business activity, and document how you’ve checked services that send infrequently.
5. Your overall pass rate hides critical failures
Imagine 999,000 marketing messages pass DMARC while 1,000 password-reset messages fail. Your overall pass rate is 99.9%, but every password reset has a problem.
That hypothetical example shows why a single percentage can’t establish readiness.
Review results by sending service, domain, and business purpose. Pay particular attention to low-volume messages that customers depend on.
Separate legitimate failures from spoofing attempts, too. Unauthorized traffic can lower the overall pass rate without indicating a problem with your own systems.
Investigate unexplained failures affecting legitimate senders before approving the rollout.
6. SPF and DKIM pass, but you haven’t checked alignment
A vendor dashboard can say “authenticated” while its messages still fail DMARC.
A message needs at least one successful authentication result that aligns with the visible From domain:
- SPF: The authenticated envelope-sender domain—the domain used for the message’s return path—must align.
- DKIM: A valid signature’s signing domain must align.
Suppose a message shows accounts@example.com in From, but SPF and DKIM authenticate only an unrelated vendor domain. Those passing results don’t establish alignment with example.com.
Relaxed alignment allows domains that share the same organizational domain, while strict alignment requires an exact match. Valimail’s alignment guide explains the distinction.
Check received messages from each service to confirm that at least one passing result aligns.
7. Your SPF configuration has errors nobody has resolved
SPF can become harder to maintain as services come and go.
The standard limits an evaluation to ten DNS-lookup-causing terms, including those evaluated through nested records. Exceeding that limit produces a permanent error, usually shown as permerror. Counting only the visible include entries can miss the problem.Check the SPF record for the envelope-sender domain each service actually uses. Look for obsolete authorizations and vendor-managed records that add unexpected lookups.
An SPF error doesn’t automatically cause DMARC failure if aligned DKIM passes, but it still needs attention. Test the full evaluation and remove only authorizations you’ve confirmed are unnecessary.
8. You’ve published a DKIM key without checking live messages
A DKIM record in DNS doesn’t prove that a service signs its messages correctly.
Some platforms require you to enable signing separately. Different message types may also use different signing domains or selectors—the labels that identify verification keys.
Inspect representative received messages and confirm that the signature validates and the signing domain aligns with the visible From domain.
If you plan to publish p=reject, this check is essential: Current DMARC guidance requires valid DKIM signing and says you shouldn’t rely solely on SPF. Document who maintains signing and how they’ll test future key changes.
9. You don’t know which policy applies to each subdomain
Changing a main domain’s policy can affect email from its subdomains. A subdomain can inherit a policy unless an applicable record or policy setting gives it different treatment.
The sp tag can specify a subdomain policy, and a subdomain’s own record can affect the outcome. Valimail explains these relationships in our guide to DMARC policies and subdomains.
Check every domain that appears in a legitimate From address, including those used for billing, marketing, and support. Map the effective policy alongside sender activity so you know which messages a proposed change could affect.
10. You haven’t tested forwarding and mailing lists
A message can authenticate on its first delivery and fail after someone forwards it.
Forwarding can break SPF or its alignment. DKIM may survive, but intermediaries that change signed content can invalidate the signature.
Employee correspondence needs particular attention because people send through mailing lists and other indirect routes. Current DMARC guidance advises against p=reject for domains whose users might post to Internet mailing lists because of the disruption it can cause.Test the indirect routes your users rely on and document the policy decision for each domain. Avoid authorizing unfamiliar forwarding infrastructure just to eliminate failures from a report.
11. Business teams haven’t tested their actual workflows
An IT test message won’t tell you whether a customer can receive a password reset or an invoice.
Ask application owners to run representative processes through their production sending routes using controlled test accounts. Useful checks include:
- Creating an account and receiving its confirmation
- Requesting a password reset
- Sending an invoice or renewal notice
- Opening a support ticket and receiving a reply
Check authentication results as well as delivery. Receivers sometimes accept messages that fail DMARC, so arrival alone doesn’t prove readiness.
Record the service, sending domain, recipient environment, date, and outcome. Resolve unexplained failures before tightening the policy.
12. Your rollout plan consists of “change the record”
The DNS edit may take minutes. Preparing the people and processes around it takes more thought.
Specify the domains involved, the intended policy, who approves the change, and what evidence allows the rollout to proceed. Where appropriate, stage changes across domains or subdomains with independently controlled policies. A domain-level policy doesn’t provide a separate exemption for each application.
Treat p=quarantine as a change with real consequences: An invoice in a junk folder can still interrupt business.
Give each stage review points, success criteria, and escalation contacts. Assign an owner and review date to any temporary exception.
13. Your recovery plan assumes an instant DNS rollback
“We’ll change it back” leaves several questions unanswered. Receivers may continue using cached DNS records after you publish an update. Reversing a policy also won’t retrieve messages that receivers have already rejected.
Keep the previous configuration and confirm who can make authorized changes. Decide how your team will investigate delivery complaints, notify affected departments, and verify recovery.
Where practical, fix the affected sender directly. If you need a temporary policy change, document its scope and review date.
Include a way to identify important failed messages and arrange resending once you’ve resolved the underlying issue.
14. Teams can launch new email tools without an authentication check
Your current senders might work perfectly, and then a new campaign platform can introduce failures the following week.
Give teams a straightforward approval process before a service starts sending. Require a service owner, an approved sending domain, working authentication, and representative testing.
Apply the same process when agencies change tools, applications move to new providers, or existing services introduce another sending route. Remove unnecessary authorizations when a service retires.
Make the process easy to find and use. Teams should know who to contact before their first campaign goes out.
15. Ongoing monitoring doesn’t have an owner
Someone needs to notice when an approved service starts failing or an unfamiliar sender appears.
Assign an operational owner and a backup. Give them a clear route for escalating issues to application owners, DNS administrators, and vendor support.
Use aggregate reports alongside available sender logs, rejection information, and workflow tests. Each can answer questions the others can’t.
Valimail Enforce’s configurable alerts can help your teams track relevant changes.
Set a review schedule for the rollout, then adjust it to your environment. Keep responsibilities documented so monitoring continues through holidays, staff changes, and project handovers.
Turn the gaps into a rollout decision
Don’t judge readiness by counting completed boxes. One unresolved password-reset service can matter more than several minor documentation gaps.
For each issue, record:
- Owner: Who will resolve it?
- Action: What needs to change?
- Evidence: How will you confirm the fix works?
- Target date: When will you review it?
Prioritize the gaps that could interrupt important communications. Approve a rollout when you can explain which domains it covers, show that critical sending routes work, and identify who will monitor and respond after the change.
Get a clearer view of what needs fixing
A readiness gap gives you a specific next step: Identify a sender, correct its authentication, or test a business process.
Valimail Monitor helps you identify sending services and review authentication results. Valimail Enforce adds automation for configuration, updates, and alerts, with tools to simplify sender authorization.
Start with the gaps you’ve identified. If you need help resolving them and maintaining enforcement, request a Valimail Enforce demo.
FAQs about DMARC enforcement readiness
How do I know if I’m ready for DMARC enforcement?
You should be able to show that legitimate senders authenticate correctly, critical email workflows work, and someone owns every unresolved issue. Confirm which policy applies to each domain and who will handle monitoring and recovery. A valid record or high overall pass rate alone doesn’t establish readiness.
How long should I stay at p=none?
Use a period that covers your sending cycles and testing needs. For domains whose users might post to Internet mailing lists but that still intend to adopt p=reject, RFC 9989 recommends at least a month at p=none, followed by an equally long period at p=quarantine, comparing results. Read the rollout guidance.
Do both SPF and DKIM have to pass for a message to pass DMARC?
No. One passing, aligned authentication method is sufficient for an individual message. For a p=reject deployment, configure valid, aligned DKIM signingcurrent guidance prohibits relying on SPF alone and setting up both methods also improves resilience. See the DKIM requirement.
Should every domain move directly to p=reject?
No. Choose a policy based on the domain’s purpose, validated sending routes, and forwarding or mailing-list risks. Assess employee correspondence separately from tightly controlled notification traffic. Remember that p=quarantine can also disrupt business when legitimate messages land in junk.
What if a legitimate vendor can’t support aligned authentication?
Ask whether it supports a custom DKIM signing domain or an aligned envelope-sender domain. If it can’t meet your rollout requirements, investigate an approved sending route or a replacement service. Give any temporary accommodation an owner and review date, and verify aligned DKIM before adopting p=reject.
