Email Domain Not Protected Against Impersonation

Vulnerability Explanation

The domain's DMARC record uses p=none, which instructs receiving mail servers to take no action on emails that fail SPF and DKIM authentication checks. While aggregate reports are generated (if rua= is configured), unauthenticated emails claiming to originate from this domain are delivered normally to recipients' inboxes. This means the DMARC record provides visibility but zero enforcement — a spoofed email using this domain will pass through to the inbox of any recipient whose mail server honors the p=none policy.

Root Cause

DMARC's p=none mode is intentionally designed as a monitoring-only phase for initial deployment. The root cause of this finding is that the policy was never graduated to an enforcement mode (p=quarantine or p=reject) after the monitoring phase. This is extremely common — as of 2024, the majority of domains with DMARC records remain stuck at p=none.

Technical Impact

An attacker can send emails with a forged From: header using this domain. With p=none, receiving mail servers will deliver these messages to the inbox without any DMARC-triggered filtering. This enables phishing attacks against customers, partners, and employees; Business Email Compromise (BEC) fraud; and brand impersonation campaigns. The attacker requires no access to the target's infrastructure — only a mail server and a spoofed From: address.

Severity Justification

Network-accessible, no authentication required, and no user interaction needed by the attacker. However, exploitability depends on recipient mail server behavior and the presence of other anti-spam controls. Many modern mail providers apply heuristic spam filtering that may catch some spoofed emails even without DMARC enforcement, reducing real-world impact somewhat. Rated medium rather than high due to these mitigating factors.

Affected Components

• DMARC DNS TXT record — all versions with p=none

Remediation Steps

1. Confirm your DMARC aggregate reports (rua=) are being received and review them to identify all legitimate sending sources (your ESP, CRM, marketing tools, etc.). Tools like MXToolbox, dmarcian, or Google Postmaster Tools can help parse these reports.
2. Verify that all legitimate senders are correctly configured with SPF and DKIM alignment for your domain. Third-party senders like Mailchimp, HubSpot, or Salesforce must authenticate using your domain, not their own.
3. Update your DMARC DNS TXT record to p=quarantine with a low percentage (pct=10) to begin enforcement gradually: v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; sp=quarantine
4. Monitor reports for 2–4 weeks. If no legitimate mail is being quarantined, increase pct to 50, then 100.
5. Once pct=100 with p=quarantine is stable, upgrade to p=reject for maximum enforcement: v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; sp=reject

Verification Steps

1. Run a DNS lookup to confirm the updated record: dig TXT _dmarc.yourdomain.com or use https://mxtoolbox.com/dmarc.aspx
2. Use an online DMARC validator (e.g., https://dmarcian.com/dmarc-inspector/) to confirm the policy value is quarantine or reject
3. Send a test email from an unauthorized source and verify it is quarantined or rejected by the receiving server
4. Check DMARC aggregate reports 24–48 hours after the change to confirm the new policy is being applied and no legitimate mail streams are failing

Code Examples (dns)

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

# Step 1 — Gradual enforcement (start here)
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.com; sp=quarantine

# Step 2 — Full quarantine (after 2-4 weeks of monitoring)
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourdomain.com; sp=quarantine

# Step 3 — Maximum enforcement (target state)
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; sp=reject

Best Practices

• Always configure the rua= tag to receive aggregate reports — you cannot safely enforce DMARC without visibility into your sending sources.
• Set the sp= (subdomain policy) tag explicitly to match your main policy, otherwise subdomains may default to p=none and remain unprotected.
• Use the pct= tag to roll out enforcement gradually — this reduces the risk of blocking legitimate mail during the transition.
• Rotate DKIM keys periodically and audit your SPF record to remove stale or unused sending sources.

References

• powerdmarc.com/what-is-dmarc-policy/
• www.valimail.com/resources/guides/email-security-best-practices/how-to-configure-dmarc-policy-to-reject-or-quarantine/
• www.mimecast.com/blog/guide-to-google-dmarc-setup/
• dmarcian.com/yahoo-and-google-dmarc-required/