VulWall Team February 23, 2026 5 min read

Email Domain Has No Active Spoofing Protection

Your domain has a DMARC record, but it's set to 'monitor only' mode — meaning it watches for suspicious emails but takes no action to stop them. Think of it like a smoke detector that logs every fire but never sounds the alarm. Anyone can send emails that appear to come from your domain, and those messages will land in recipients' inboxes unchallenged.

OWASP A05 Effort: small Exploitable
dmarc email-security spoofing phishing dns bec configuration

Business Impact And Actions

medium urgency

Business Impact

Without active enforcement, your domain can be impersonated by scammers to send phishing emails to your customers, partners, or employees — and those emails will look completely legitimate. This can damage your brand reputation, erode customer trust, and expose your business to compliance concerns under frameworks like PCI-DSS and GDPR that expect reasonable email security controls. Major email providers like Google and Yahoo also now require enforced DMARC policies for bulk senders, so staying at 'monitor only' can eventually affect your own email deliverability.

What To Do

  1. Ask your developer or IT provider to review your DMARC reports — these are already being collected and will show which email services send on your behalf (e.g., your newsletter tool, CRM, or support platform).
  2. Once you've confirmed all your legitimate email senders are accounted for, ask your developer to upgrade the DMARC policy from 'none' to 'quarantine' — this is a small DNS change that takes under 30 minutes.
  3. Plan to move to the strictest setting ('reject') within 1–3 months once you're confident no legitimate emails are being caught. This gives you the strongest protection against impersonation.
  4. If you use a third-party email tool (like Mailchimp, HubSpot, or Zendesk), check with your developer that those services are properly authenticated — otherwise they may be blocked when you tighten the policy.

DMARC Policy Set to p=none — No Enforcement Against Domain Spoofing

medium severity CVSS 5.3-6.5

Vulnerability Explanation

The domain's DMARC TXT record is configured with p=none, which instructs receiving mail servers to take no action on messages that fail SPF and DKIM alignment checks. While aggregate reports (rua) may be collected, unauthenticated emails claiming to originate from the domain are delivered normally to recipients' inboxes. This means the DMARC record provides visibility but zero enforcement — a spoofed email using the domain in the RFC5322 From header will pass through to the recipient without any quarantine or rejection signal.

Root Cause

p=none is the correct starting point during initial DMARC deployment — it allows operators to collect aggregate reports and identify all legitimate sending sources before applying enforcement. The vulnerability arises when the policy is never graduated to p=quarantine or p=reject after the monitoring phase is complete. This is a configuration maturity gap, not a software defect.

Technical Impact

An attacker can craft emails with the victim domain in the From header and send them from any mail server. Because p=none instructs receivers to take no action on DMARC failures, these spoofed messages are delivered directly to recipients' inboxes. This enables phishing attacks, business email compromise (BEC), and brand impersonation at scale. The domain owner receives DMARC aggregate reports about the failures but has no mechanism to prevent delivery.

Severity Justification

Network-accessible, no authentication required to exploit. The attacker needs only a mail server and the target domain name. However, exploitation depends on recipient mail servers not applying independent spam heuristics, and many providers add their own anti-spoofing signals. Rated medium rather than high because real-world deliverability of spoofed mail is partially mitigated by receiver-side filters even without DMARC enforcement.

Affected Components

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

Remediation Steps

  1. Review DMARC aggregate reports (rua) to identify all services sending email on behalf of the domain. Free tools like MXToolbox (mxtoolbox.com/dmarc) or dmarcian can parse these reports. Ensure SPF and DKIM are correctly configured for every legitimate sender before proceeding.
  2. Upgrade the DMARC policy from p=none to p=quarantine with a low enforcement percentage to begin enforcement safely. Update the _dmarc TXT record in DNS. Example: v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@yourdomain.com
  3. Monitor DMARC reports and email delivery for 2–4 weeks. Investigate any new failures — they may indicate legitimate senders (e.g., CRM, marketing tools, ticketing systems) that need SPF/DKIM alignment fixes.
  4. Gradually increase the pct value (e.g., 25 → 50 → 100) as confidence grows that all legitimate senders pass authentication.
  5. Once pct=100 with p=quarantine is stable, upgrade to p=reject for maximum enforcement: v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@yourdomain.com
  6. Ensure subdomains are also covered. If subdomains don't send email, add sp=reject to the root DMARC record to prevent subdomain spoofing.

Verification Steps

  1. Run a DNS lookup to confirm the updated record: dig TXT _dmarc.yourdomain.com or use MXToolbox DMARC lookup at mxtoolbox.com/dmarc
  2. Use mail-tester.com or a DMARC validator to send a test email and confirm the policy is being applied correctly.
  3. Check that DMARC aggregate reports are arriving at the rua address within 24–48 hours of the DNS change propagating.
  4. After upgrading to quarantine or reject, send a test email from an unauthorized server and verify it is quarantined or rejected by the receiving mail server.

Code Examples (dns)

Vulnerable
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
Fixed
# Step 1 — Start enforcement at low percentage:
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@yourdomain.com

# Step 2 — Full quarantine enforcement:
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@yourdomain.com

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

Best Practices

  • Always configure a rua= reporting address before upgrading policy — you need visibility into failures before enforcing.
  • Use the pct= tag to roll out enforcement gradually (start at 10%, increase over weeks) to avoid accidentally blocking legitimate mail.
  • Ensure all third-party senders (marketing platforms, CRMs, support tools) are authenticated via SPF includes or DKIM signing before moving to p=reject.
  • Apply sp=reject or sp=quarantine to prevent attackers from bypassing enforcement via subdomains.

References

Found this in your infrastructure?

VulWall scans for this and dozens of other issues automatically.

Scan Your Domain Free
Back to Knowledge Base