DMARC Enforcement: From p=none to p=reject

Publishing a DMARC record is a useful first step. It is not the same as enforcing protection.

Many organisations begin with a monitoring policy, see reports arriving and consider the project complete. Others know they need to move further but hesitate for a practical reason: what happens to invoices, marketing campaigns and customer notifications if legitimate messages fail authentication?

Moving to DMARC enforcement means identifying your legitimate sending services, correcting their authentication and alignment, then introducing a quarantine or rejection policy while monitoring delivery. The objective is to reduce unauthorised use of your domain without interrupting the email your business depends on.

The difficult part is rarely editing the DNS record. It is knowing whether your organisation is ready for that change.

‍

What is DMARC enforcement?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It connects email authentication results to the domain recipients see in the message’s From address.

A domain owner publishes a policy requesting how receiving systems should treat messages that fail DMARC. Enforcement refers to using p=quarantine or p=reject, rather than a monitoring-only p=none policy.

The receiving system still determines the final handling of a message using its own policies. DMARC is not a universal delivery guarantee or an instruction every receiver will apply identically. Read the DMARC specification.

‍

p=none vs p=quarantine vs p=reject

A p=none policy does not switch off a recipient’s existing spam or phishing protection. It simply does not request quarantine or rejection because of DMARC failure. Likewise, a DMARC pass does not guarantee inbox placement. Microsoft explains the policy options and receiver behaviour.

‍

Why SPF and DKIM need alignment

SPF and DKIM provide the authentication foundations, but DMARC adds an important check: alignment.

• SPF checks whether the sending server is authorised for the envelope sender domain, also commonly associated with the Return-Path.
• DKIM verifies a cryptographic signature associated with a signing domain.
• DMARC checks whether a passing SPF or DKIM result aligns with the domain in the visible From address.

A message needs at least one aligned authentication pass: SPF or DKIM. It does not need both to pass DMARC, although configuring both where supported improves resilience.

For example, a marketing platform might authenticate successfully using its own domain while displaying your company’s address in the From field. Authentication alone is not enough if neither result aligns with your domain. Google explains DMARC alignment and setup.

‍

Start with the senders your IT team may not know about

Your primary email platform is only part of the picture.

A useful sender inventory should include:

• Employee email through Microsoft 365 or Google Workspace.
• CRM and sales outreach platforms.
• Marketing and newsletter services.
• Finance, invoicing and payment systems.
• Customer support and ticketing platforms.
• Website forms and transactional notifications.
• Recruitment systems and external agencies.
• Legacy applications, monitoring tools and devices that send alerts.

Ask each department which services send email using company addresses. Record a business owner for every service.

This is where a technically simple project becomes an operational one. IT may manage DNS, but marketing knows which campaign platform is still active, and finance knows which system sends statements at month-end.

‍

A practical six-step DMARC rollout

‍

1. Define scope and ownership

List the domains and subdomains your organisation uses, including secondary brands and domains that no longer send email.

For each active sending service, record:

• The domain shown to recipients.
• The platform responsible for sending.
• The business and technical owners.
• The current authentication configuration.
• The importance and frequency of its messages.

Agree who can approve DNS changes and who will investigate delivery problems. A rollout should not depend on one person recognising every sender.

2. Establish monitoring

If the domain is not already enforcing DMARC, begin with a monitoring policy and a working aggregate-report destination. Use a dedicated reporting service or mailbox rather than collecting reports in someone’s personal inbox.

Check that reports actually arrive. If an external service receives them, follow its instructions for any required reporting authorisation. Google’s setup guidance covers reporting destinations.

Observe a representative business cycle. A few quiet days may not reveal a monthly billing run or an occasional recruitment campaign. Supplement reports with your departmental inventory and controlled test messages.

The question to answer: Have we identified the important legitimate senders, including infrequent ones?

3. Investigate failures and correct legitimate senders

Classify unfamiliar traffic before changing authentication settings. An unknown source may be an overlooked business service, a forwarding path or unauthorised activity. Do not authorise a sender simply to make a warning disappear. For approved platforms, follow the provider’s domain-authentication instructions and verify actual messages after configuration. Check alignment, not just whether a dashboard says SPF or DKIM is enabled.

Keep a record of what changed and why. That documentation becomes useful when an agency leaves, a platform is replaced or someone asks why a service can send using your domain.

4. Introduce enforcement in controlled stages

Once legitimate sources are validated, introduce an enforcement policy and review the results before expanding. Google recommends a gradual rollout from monitoring towards quarantine or rejection, with continuing report review. A quarantine stage can provide a useful checkpoint, although it is not mandatory for every environment. See Google’s recommended DMARC rollout.

Schedule changes when the relevant teams are available. Test business-critical messages and have a response plan for unexpected failures. Do not assume that reversing a DNS change takes effect everywhere immediately. Account for caching when planning recovery.

5. Move to p=reject when the evidence supports it

Readiness should be based on validated mail flows, not a deadline alone.

Before moving to rejection, confirm that:

• Critical sending services have been tested.
• Unexplained failures affecting legitimate mail have been investigated.
• Relevant subdomain policies have been reviewed.
• Business owners know how to report delivery issues.
• Someone is responsible for monitoring after the change.

Avoid using the overall authentication pass rate as your only measure. Spoofing attempts can fail in large numbers without indicating a problem with legitimate mail. Conversely, a low-volume but critical billing service can fail while the overall rate looks healthy.

6. Make monitoring part of normal operations

Reaching p=reject is a milestone, not the end of the work. Add email authentication to the approval process for new sending platforms. When a team adopts a new CRM, newsletter service or ticketing system, validate its configuration before it sends production messages.

When services are retired, review and remove obsolete authorisations carefully. Keep the sender inventory current and assign ongoing ownership of report review.

‍

Common mistakes that disrupt business email

Assuming Microsoft 365 covers every sender

Configuring your Microsoft 365 email does not automatically authenticate a separate marketing, billing or support platform. Each service sending with your domain needs appropriate configuration.

Custom-domain DMARC records are managed through your DNS provider, not simply by enabling a mailbox security feature. Microsoft’s guidance explains custom domains and third-party sending considerations.

Moving to rejection before testing occasional messages

Daily employee email may work perfectly while quarterly statements fail. Include infrequent but important communications in your validation plan.

Confusing unknown senders with approved senders

Authentication changes should follow business approval. Otherwise, the process intended to restrict unauthorised sending can end up legitimising it.

Treating DNS publication as proof of success

A correctly published record proves that a policy exists. It does not prove that every business service is aligned or that every recipient received its message.

Ignoring forwarding and message modification

Forwarding and mailing-list processing can complicate authentication. Investigate these paths rather than assuming every failure is malicious or weakening the entire domain policy to accommodate one unexplained issue. The DMARC specification discusses these interoperability challenges. Read the specification.

‍

What DMARC does not protect against

DMARC helps address unauthorised use of your domain in the visible From address. It does not solve every form of email impersonation.

An attacker may use a lookalike domain, imitate an executive’s display name or send from a compromised legitimate account. Such messages can fall outside what your domain’s DMARC policy prevents.

DMARC therefore belongs alongside account protection, phishing-resistant authentication, email filtering and payment-verification procedures—not in place of them. Its scope is domain authentication, not a judgement that a message’s content or request is trustworthy. The DMARC specification sets out its scope and limitations.

‍

How Skysnag and The Kernel help

Skysnag provides a platform for managing email authentication and progressing towards DMARC enforcement. Its capabilities include sender visibility, reporting and automation intended to reduce the manual work involved in managing authentication across domains. Explore Skysnag.

The Kernel supports organisations with domain assessment, Skysnag setup, third-party sender configuration and a guided transition towards enforcement. Our role is to connect the technical changes with the legitimate mail flows that need to keep working. Explore Skysnag through The Kernel.

For a business with multiple brands, agencies or regional offices, that coordination matters as much as the policy itself. A shared sender inventory and clear approval process help keep protection consistent as the organisation changes.

Automation can support the work, but it does not remove the need to confirm which senders are authorised and test important communications.

‍

Frequently asked questions

Is having a DMARC record enough?

Not by itself. A monitoring policy provides visibility but does not request quarantine or rejection of failing messages. Effective operation also requires correct authentication, appropriate enforcement and ongoing review.

Can DMARC block legitimate emails?

Yes. Legitimate messages that fail DMARC may be quarantined or rejected under an enforcement policy. Discovering and correcting approved sending services before tightening the policy reduces that risk.

Do SPF and DKIM both need to pass?

No. DMARC requires a passing, aligned result from at least one of them. Configure both where supported, but verify alignment with the visible From domain rather than checking authentication alone.

How long does DMARC enforcement take?

There is no reliable deadline for every organisation. The work depends on the number of sending services, existing configuration issues, access to DNS and the time needed to observe important mail flows. Set milestones around validated coverage rather than promising a fixed completion date.

Does p=reject stop all phishing?

No. It requests rejection of messages that fail DMARC for the protected domain. It does not prevent every lookalike-domain attack, display-name impersonation or malicious message sent through a compromised account.

‍

Find out whether your domain is ready for enforcement

The useful question is not simply, “Do we have a DMARC record?”

It is, “Do we know which services send as our domain, and have we verified that legitimate messages will continue to authenticate when we enforce the policy?”

Start with that assessment. It gives your team a clear view of what is working, what needs correction and what must be tested before moving forward.

Want help moving from DMARC monitoring to enforcement?

Talk to The Kernel about a domain assessment.

‍