Sign In
In this module

AD2.7 DMARC: Enforcing Email Authentication

5-6 hours · Module 2 · Free
Operational Objective
SPF tells receiving servers who can send as your domain. DKIM proves the message wasn't tampered with. But neither one tells the receiving server what to DO when validation fails. Should the server reject the email? Deliver it to spam? Deliver it normally and hope for the best? DMARC (Domain-based Message Authentication, Reporting, and Conformance) answers this question. It tells receiving servers: "If an email claims to be from our domain and fails both SPF and DKIM, here's what you should do with it." DMARC also provides aggregate and forensic reports — daily data from major email providers showing how many emails pass and fail authentication for your domain. This subsection deploys DMARC in three stages: monitoring (p=none), quarantine (p=quarantine), and reject (p=reject) — with the data analysis at each stage that ensures you don't block legitimate email.
Deliverable: A DMARC record deployed at monitoring level (p=none), with a reporting email address configured, and a plan to progress to quarantine and reject after verifying no legitimate email fails authentication.
Estimated completion: 30 minutes
DMARC DEPLOYMENT — THREE STAGES STAGE 1: MONITOR p=none No action on failures Receive reports showing pass/fail Identify legitimate senders failing Fix SPF/DKIM before enforcing Deploy this first · Run 2-4 weeks START HERE STAGE 2: QUARANTINE p=quarantine Failed emails go to spam/junk Users can still find them if needed Low risk — junk is recoverable Continue monitoring reports After Stage 1 shows all legit email passes Run 2-4 weeks · Verify no issues STAGE 3: REJECT p=reject Failed emails are blocked entirely Never reach recipient's mailbox Full domain spoofing protection Strongest anti-spoofing enforcement After Stage 2 confirms zero legit failures THE GOAL

Figure AD2.7 — DMARC deployment in three stages. Start with monitoring (p=none) to collect data without affecting email delivery. Progress to quarantine (p=quarantine) when reports show all legitimate email passes. Reach reject (p=reject) when you're confident no legitimate email will be blocked. Each stage reduces domain spoofing progressively.

Creating the DMARC record — Stage 1

DMARC is a single TXT record in your DNS. For Stage 1 (monitoring), create this record:

Type: TXT Name: _dmarc (or _dmarc.northgateeng.com depending on your DNS provider) Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@northgateeng.com; ruf=mailto:dmarc-forensics@northgateeng.com; pct=100

Breaking down each part: v=DMARC1 identifies this as a DMARC record. p=none is the policy — "don't take any action on failures, just report." rua=mailto:... is where aggregate reports are sent — daily XML files from receiving servers showing how many emails from your domain passed or failed SPF/DKIM. ruf=mailto:... is where forensic reports are sent — individual failure reports with message details (not all providers send these). pct=100 means apply the policy to 100% of email.

Create a mailbox or distribution group for the report addresses before publishing the record. DMARC reports are machine-readable XML — you won't read them manually. Use a free DMARC reporting service (dmarcian.com free tier, MXToolbox DMARC monitoring, or EasyDMARC) to parse the XML into readable dashboards. The service ingests the XML reports and shows you: which servers are sending email as your domain, which pass SPF/DKIM, and which fail.

Reading DMARC reports

After publishing the record with p=none, receiving servers start sending aggregate reports within 24-48 hours. The reports arrive as XML files to your rua address. Without a parsing service, they're nearly unreadable. With a parsing tool, they show you a dashboard with: total emails sent from your domain (as seen by receiving servers), pass/fail rates for SPF and DKIM, and the sending servers grouped by IP address.

What you're looking for in the reports: legitimate email sources that fail authentication. If you see failures from M365 servers (which should be in your SPF and DKIM), your SPF or DKIM configuration has an error. If you see failures from a marketing platform or CRM, you need to add that service to your SPF record. If you see failures from IPs you don't recognize, those are either spoofed emails (attackers impersonating your domain) or a legitimate service you forgot to authorize.

Run Stage 1 for 2-4 weeks. During this time, no email is affected — p=none means receiving servers don't take any action on failures. The only output is the reports. Review the reports weekly. When you see zero failures from legitimate sources (all your authorized senders pass SPF or DKIM), you're ready for Stage 2.

Understanding DMARC alignment

DMARC doesn't just check whether SPF or DKIM passes — it checks whether they pass with alignment. Alignment means the domain in the SPF or DKIM validation matches the domain in the visible FROM address that users see.

For SPF alignment: the domain in the envelope MAIL FROM must match (or be a subdomain of) the domain in the header FROM. If the header FROM is northgateeng.com but the envelope MAIL FROM is bounces.mailchimp.com, SPF passes for Mailchimp's domain but fails DMARC alignment because the domains don't match.

For DKIM alignment: the domain in the DKIM signature (d= tag) must match (or be a subdomain of) the header FROM domain. If the header FROM is northgateeng.com and the DKIM signature uses d=northgateeng.com, DKIM alignment passes. If the DKIM signature uses d=mailchimp.com, DKIM passes but DMARC alignment fails.

DMARC passes if EITHER SPF or DKIM passes with alignment. This is why both are important — they provide redundancy. Understanding alignment helps you debug DMARC failures: a service may pass SPF (its servers are in your SPF record) but fail DMARC alignment (its envelope MAIL FROM uses a different domain). The fix is usually configuring DKIM for that service through your domain, which provides aligned authentication.

Protecting subdomains

By default, DMARC only applies to the exact domain in the record. If you publish _dmarc.northgateeng.com, it protects northgateeng.com but not marketing.northgateeng.com or support.northgateeng.com. Attackers know this — they spoof subdomains that don't have their own DMARC records.

Add a subdomain policy to your DMARC record using the sp= tag:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@northgateeng.com; pct=100

The sp=reject tells receiving servers to reject spoofed email from ANY subdomain of northgateeng.com. If you don't use subdomains for email (most organizations don't), set sp=reject alongside your main policy. If you DO use subdomains for email (marketing.northgateeng.com for newsletters), publish a separate DMARC record for that subdomain with the appropriate policy.

Reading DMARC aggregate reports in practice

DMARC aggregate reports arrive as XML files. Without a parsing tool, they look like this (simplified):

<record>
  <row>
    <source_ip>40.107.22.54</source_ip>
    <count>847</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

This tells you: 847 emails were sent from IP 40.107.22.54, both DKIM and SPF passed, and the policy disposition was "none" (because you're at p=none). The IP 40.107.22.54 is a Microsoft Exchange Online server — this is your legitimate M365 email.

What you're watching for is records where dkim or spf shows "fail" — these are either spoofed emails (from unknown IPs) or legitimate services that need SPF/DKIM configuration (from recognized IPs). A free DMARC reporting service parses these XML files into a dashboard that shows pass/fail rates by source IP, making the analysis visual rather than requiring you to read XML.

Progressing to Stage 2 and Stage 3

Stage 2 — Quarantine: Change the DMARC record to v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@northgateeng.com; pct=100. Now, emails that fail both SPF and DKIM are delivered to the recipient's junk folder instead of their inbox. This is a soft enforcement — the email is still accessible if it's legitimate, but spoofed emails don't reach the inbox. Run this for 2-4 weeks and monitor for any user reports of legitimate email going to junk.

Stage 3 — Reject: Change to v=DMARC1; p=reject; rua=mailto:dmarc-reports@northgateeng.com; pct=100. Now, emails that fail both SPF and DKIM are rejected entirely — they never reach the recipient's mailbox. This is full enforcement. Any attacker trying to spoof your domain gets their email bounced. This is the target state — but only after Stages 1 and 2 confirm no legitimate email will be affected.

The progression typically takes 6-8 weeks total: 2-4 weeks at p=none, 2-4 weeks at p=quarantine, then p=reject. Don't rush this — a premature move to p=reject that blocks legitimate email from a forgotten sending service is a production incident that undermines confidence in email security controls.

DMARC stage progression criteria

Before moving from one stage to the next, verify these specific criteria:

From p=none to p=quarantine — checklist:

  • DMARC reports show 95%+ of your email volume passing both SPF and DKIM alignment
  • Every legitimate sending service is identified and authorized in SPF
  • DKIM is configured for M365 and all major third-party senders
  • Remaining failures are from unrecognized IPs (likely spoofing) or low-volume internal services
  • No user complaints about legitimate email being marked as spam (which would worsen at quarantine)

Update the DNS record:

v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc@northgateeng.com; pct=100

From p=quarantine to p=reject — checklist:

  • 2+ weeks at p=quarantine with no legitimate email landing in junk due to DMARC failures
  • DMARC reports show 98%+ pass rate with alignment
  • All third-party senders have custom DKIM configured (AD2.6)
  • Zero user reports of missing email from known external senders
  • Spoofed email attempts visible in reports are being quarantined (confirming enforcement works)

Update the DNS record:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@northgateeng.com; pct=100

After reaching p=reject, your domain is fully protected against spoofing at every major email provider. Monitor the DMARC reports monthly — a drop in pass rate indicates a new sending service was added without authentication, or an existing service changed its infrastructure. The reports are your ongoing validation that email authentication is healthy.

Compliance Myth: "DMARC is only needed if you're worried about your domain being spoofed by external attackers"
DMARC is increasingly a deliverability requirement, not just a security control. Google and Yahoo both require DMARC for bulk senders as of 2024. Many enterprise email systems boost the trust rating of emails from domains with DMARC at p=reject. Without DMARC, your legitimate outbound email may be more likely to land in spam folders — regardless of whether you're being spoofed. DMARC at p=reject is becoming the baseline for professional email communication, not an optional security enhancement.
Decision point

You've been running DMARC at p=none for 3 weeks. Your reports show that 98% of email from your domain passes both SPF and DKIM. The 2% that fails comes from an IP address you don't recognize. The failing emails have subjects like "Invoice Payment Confirmation" and "Urgent: Account Verification Required." What does this tell you, and what do you do?

Option A: Add the unknown IP to your SPF record to fix the failures.

Option B: The 2% failures are likely spoofed emails from attackers impersonating your domain — move to p=quarantine to start blocking them.

Option C: Investigate the IP address further before making any change.

The correct answer is Option B (with the investigation in Option C as a parallel step). Email subjects like "Invoice Payment Confirmation" and "Account Verification Required" from unknown IPs are classic spoofing patterns — attackers sending phishing emails as your domain to your clients or vendors. A 98% pass rate with the 2% coming from unrecognized IPs is exactly what you want to see before moving to quarantine. Never add unknown IPs to your SPF record — that authorizes the attacker's server to send as your domain. Do look up the IP (using whois or an IP reputation service) to confirm it's not a legitimate service you forgot — but if it resolves to a cloud hosting provider or residential ISP with no connection to your organization, it's spoofing. Move to p=quarantine.

nslookup -type=txt _dmarc.yourdomain.com
Try it: Deploy DMARC monitoring

Check your current DMARC status:

If you get "Non-existent domain," you have no DMARC record. Create one at p=none with your reporting address. If you already have a DMARC record, check the policy level (p=none, p=quarantine, or p=reject) and whether reporting is configured (rua= address).

If starting from scratch: create the TXT record _dmarc with value v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100. Wait 24-48 hours for reports to start arriving. Sign up for a free DMARC reporting service to parse the XML reports into readable dashboards.

After 2 weeks, review the reports. If all legitimate email passes, progress to p=quarantine. After another 2 weeks with no issues, progress to p=reject.

Your DMARC record is `v=DMARC1; p=reject; rua=mailto:dmarc@northgateeng.com; pct=100`. An attacker sends an email spoofing ceo@northgateeng.com to a client's Gmail address. SPF fails (attacker's server not in your SPF). DKIM fails (no valid signature). What happens at the client's Gmail?
Gmail delivers the email to the client's inbox because Gmail doesn't check DMARC — No. Gmail is one of the most rigorous DMARC enforcers. Gmail checks DMARC for every inbound email.
Gmail delivers the email to spam/junk — No. Your DMARC policy is p=reject, not p=quarantine. Gmail respects p=reject and will not deliver the email at all.
Gmail rejects the email entirely — the client never sees it in any folder — Correct. With p=reject, Gmail bounces the email before it reaches any folder. The attacker gets a delivery failure. The client never sees the spoofed email. This is the full protection that DMARC at p=reject provides — complete prevention of domain spoofing at receiving servers that honor DMARC (which includes all major email providers).
Gmail delivers the email with a warning banner — No. Warning banners are for soft failures (p=none or p=quarantine in some implementations). p=reject means reject, not warn.
Operational Artifact — DMARC Deployment Roadmap
DMARC deployment: Stage 1 (p=none, 2-4 weeks) → Stage 2 (p=quarantine, 2-4 weeks) → Stage 3 (p=reject, permanent). Prerequisites: SPF record correct and verified (AD2.5), DKIM enabled and verified (AD2.6). Reporting: use a DMARC parsing service for readable dashboards — don't try to read raw XML. Review reports weekly during Stages 1 and 2, monthly after reaching p=reject. The target state is p=reject — anything less than reject means attackers can still spoof your domain at receiving servers that only take action on reject policies.
© 2026 Ridgeline Cyber Defence™ Ltd. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.

You're reading the free modules of M365 Security: From Admin to Defender

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts.

View Pricing See Full Syllabus
← Previous Next →