How DMARC works in practice: Records, alignment, and enforcement

Email is still the number one way attackers get in. Phishing accounts for around 16% of data breaches in 2025, making it one of the most common initial access vectors [1]. Yet many organizations still leave their domains open to spoofing and impersonation because email authentication feels complex and “too technical”.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the control layer that fixes this. It stops attackers using your domain, improves deliverability for legitimate email, and gives you clear visibility into who is sending on your behalf.

This guide is a technical deep dive into how DMARC actually works in practice:

• What DMARC is (in brief)
• How DMARC makes decisions using SPF and DKIM
• What’s inside a DMARC DNS record
• How domain alignment works (and why it matters)
• A practical, phased rollout to p=reject
• How OnDMARC simplifies the whole process

DMARC is an open email authentication protocol that protects your domain from spoofing, phishing, and Business Email Compromise (BEC).

It builds on two existing standards:

• SPF (Sender Policy Framework) – checks whether a sending server is allowed to send email for your domain.
• DKIM (DomainKeys Identified Mail) – uses a cryptographic signature to confirm the email really came from your domain and hasn’t been altered in transit [2].

DMARC sits on top of these and lets you:

1. Publish a policy in DNS that tells receiving servers what to do with email that fails checks (do nothing, quarantine, or reject).
2. Require alignment between the domain in the visible “From” address and the domains authenticated by SPF and/or DKIM.
3. Receive reports that show who is sending email using your domain and how those messages are performing from an authentication point of view.

In short: SPF and DKIM do the checking, DMARC makes the decision and reports back.

To understand DMARC, it helps to see the decision process that happens every time someone receives an email from your domain.

Before DMARC can do anything, SPF and/or DKIM need to be in place.

• You publish a DNS TXT record listing the IPs or hosts allowed to send mail for your domain.
• When a message arrives, the receiving server checks:
• “Is the sending server’s IP in the SPF record for this domain?”
• SPF answers: “Is this server allowed to send for this domain?”

• Your outbound mail server signs email with a private key.
• You publish the matching public key in DNS for your domain.
• The receiving server verifies the DKIM signature using that public key.
• DKIM answers: “Did this come from the right domain, and was it unchanged in transit?”

On their own, SPF and DKIM don’t control what happens when checks fail. That’s where DMARC steps in.

When an email that claims to be from user@yourdomain.com arrives, the receiving server effectively goes through this flow:

1. Look up the DMARC record for yourdomain.com at _dmarc.yourdomain.com.
2. Run SPF and DKIM checks for the message.

1. Does the domain in the visible From: header match (or align with)
2. the SPF envelope-from domain, and/or
3. the DKIM d= domain in the signature?

1. If checks fail and there’s no alignment, follow the policy in the DMARC record:
2. p=none → deliver but report.
3. p=quarantine → send to spam/junk.
4. p=reject → block the message.
5. Send reports back to the domain owner (if reporting is configured), showing what happened.

DMARC only considers an email “passing” if SPF or DKIM passes and that passing mechanism aligns with the visible From domain.

A DMARC record is a DNS TXT record published at:

_dmarc.yourdomain.com

It tells receiving email servers how to treat messages that claim to be from your domain.

A typical record might look like this:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; 
ruf=mailto:dmarc-forensics@example.com; pct=100; adkim=s; aspf=s;

You’ll use p, rua, and pct all the time. adkim and aspf become important when you want tighter control.

Domain alignment is what makes DMARC resistant to spoofing.

Without alignment, an attacker can:

• Send from their own infrastructure
• Pass SPF or DKIM for their domain
• Still put your domain in the visible “From” field

DMARC stops this by requiring that at least one of SPF or DKIM aligns with the visible From domain.

• A subdomain can align with its parent.
• Example:
• Visible From: user@brand.com
• DKIM d= domain: mail.brand.com → aligned

• Domains must match exactly.
• Example:
• Visible From: user@brand.com
• DKIM d= domain: mail.brand.com → not aligned

Most organizations:

1. Start with relaxed alignment (adkim=r; aspf=r) to avoid breaking legitimate flows.
2. Move to strict alignment once they fully understand and control all senders.

Alignment is the reason DMARC is effective against domain spoofing: attackers can’t simply authenticate their own domain and still pretend to be you in the From line.

Once you reach p=reject with good alignment, you get three big gains:

1. Spoofing and BEC protection
2. Receiving servers will block almost all direct spoofing attempts of your domain when they enforce your DMARC policy.
3. This helps reduce BEC attacks, which cost businesses billions each year, with average losses per incident well into six figures [3].
4. Better deliverability and engagement
5. Major inbox providers use authentication and reputation signals when deciding where to place email.
6. With DMARC properly enforced, legitimate email is more likely to hit the inbox rather than spam, boosting response and conversion rates across transactional, marketing, and sales email.
7. Visibility and control
8. DMARC reports highlight every source sending email as your domain:
9. ESPs, CRMs, ticketing tools, marketing platforms, legacy apps, and shadow IT.
10. You get an evidence-based view of who is using your brand in email, and whether they’re doing it safely.

If you want a deeper breakdown of the wider security and compliance benefits, that’s where the main Email Security Guide DMARC chapter comes in.

Start with a monitoring-only record, for example:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100;

What happens here:

• No mail is blocked or diverted because of DMARC.
• You begin receiving aggregate (RUA) reports: daily XML feeds showing:
• which IPs and services are sending as your domain
• whether SPF and/or DKIM pass
• whether they align

Your tasks in this phase:

• Identify all legitimate senders (marketing platforms, product systems, CRM, support, etc.).
• Fix SPF and DKIM for those senders.
• Clean up or cut off unauthorized services.

Stay in this phase until you’re confident that most legitimate email (ideally 95%+) passes and aligns.

Once you’re confident in your configuration, move to a soft enforcement mode:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100;

In this phase:

• Messages that fail DMARC and don’t align are sent to spam/junk instead of being delivered to the inbox.
• You continue to receive reports and watch for legitimate senders that still fail.

Your tasks:

• Monitor spam folders for any false positives (especially for key partners or customers).
• Fix configuration for any legitimate flows that are still ending up in quarantine.
• Keep an eye on spoofing attempts – you should start to see them diverted away from inboxes.

When you’re confident that only bad or misconfigured traffic is failing DMARC, move to full enforcement:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; pct=100;

At this point:

• Email that fails DMARC policy is rejected at the server level and never reaches recipients.
• Spoofing using your exact domain becomes very hard to pull off against servers that enforce DMARC.
• You continue to monitor reports to catch new services that start sending as your domain.

This is where you get the full security and reputation benefit of DMARC.

Doing all of this manually means:

• Parsing and interpreting thousands of XML reports.
• Working out which IPs belong to which services.
• Coordinating SPF and DKIM setup across multiple teams and vendors.
• Knowing when it’s safe to move from none → quarantine → reject.

Red Sift OnDMARC is designed to make that process fast and practical:

• Aggregates DMARC data into visual dashboards and timelines.
• Groups IPs into recognizable services so you can see “this is our CRM”, “this is our marketing platform”.

• Gives you clear, data-backed recommendations on when to tighten policy.
• Uses confidence scores so you know when you’re ready for quarantine or reject.

• Surfaces all services sending on your behalf, including legacy and shadow IT.
• Shows their authentication status and what needs fixing.

• Provides step-by-step instructions for common platforms.
• Helps you verify SPF, DKIM, and DMARC are configured correctly before you move policy.

• Flags new senders, authentication failures, or spikes in suspicious activity as they appear.
• Red Sift Radar, our powerful LLM, finds and fixes security issues faster, given you full visbility.

Most organizations using tools like OnDMARC can reach full enforcement in 6–8 weeks, depending on how complex their email landscape is. Manual projects often drag into months or longer because of the analysis and coordination overhead.

How long does DMARC implementation take? With a dedicated platform like OnDMARC, many organizations reach p=reject within 6–8 weeks, assuming they can move quickly with internal and vendor changes. Manual projects can take several months to a year, especially in large or federated environments.

Will DMARC block legitimate emails? DMARC only blocks mail that fails authentication and doesn’t align with your domain. The phased approach (none → quarantine → reject) is designed to protect you from accidentally blocking legitimate mail while you discover and fix all senders.

Does DMARC work with all email providers? Yes. DMARC operates at the DNS and SMTP layer, so it works across Microsoft 365, Google Workspace, on-prem Exchange, and essentially any email platform that respects open standards.

With BEC losses running into billions and inbox providers leaning heavily on authentication to make deliverability decisions, getting to DMARC enforcement is no longer optional for most organizations.

If you want to see how your domain looks today and what it would take to get to p=reject safely:

• Start a 14-day trial of OnDMARC and see your DMARC data visualized.
• Get a free assessment to understand your current exposure and next steps.

Properly configured DMARC, backed by clear visibility and guided enforcement, turns your domain from an easy target into a much harder one.

[1] Verizon 2025 Data Breach Investigations Report

[2] NIST Special Publication 800-177 Revision 1 – Trustworthy Email

[3] FBI IC3 Report – Business Email Compromise statistics