dmarc.present Reviewed July 2026

Quick fix

Inventory every legitimate sending platform and verify SPF and DKIM alignment.

What this finding means

SecuTest queries `_dmarc.example.com` for a single record beginning with `v=DMARC1`. DMARC builds on SPF and DKIM alignment to tell receivers how to handle unauthenticated mail. Absence does not prove that spoofed messages will be accepted, but it removes the domain owner's explicit enforcement signal.

Interpretation boundary Use the exact evidence in your report. SecuTest reports externally observable conditions; it does not assume ownership, exploitability, compromise, or business intent when those cannot be proven remotely.

Associated attack or threat scenario

Threat type Direct-domain email spoofing and phishing

How the attack or failure scenario works

Direct-domain spoofing is the use of the organization's visible From domain in a forged message. DMARC checks whether SPF or DKIM passes and aligns with that visible domain. Without a DMARC record, receivers cannot apply the domain owner's requested quarantine or rejection policy.

Conditions and limitations

  • An attacker can submit mail with the protected domain in the visible From header.
  • The message lacks an aligned SPF or DKIM pass.
  • The receiver accepts or merely flags unauthenticated mail because no domain policy requests enforcement.

Why it matters

Security and business impact Without DMARC, the visible From domain has no published alignment and handling policy, increasing exposure to direct-domain spoofing and phishing.

Step-by-step fix

Where to make the change

  • The authoritative DNS zone for the registrable domain.
  • The outbound or inbound mail platform when sender authorization, signing, or routing is involved.
  • The DMARC reporting mailbox or reporting service when aggregate reports are required.

Remediation procedure

  1. Inventory every legitimate sending platform and verify SPF and DKIM alignment.
  2. Create a dedicated aggregate-report mailbox or reporting service.
  3. Publish one DMARC TXT record at `_dmarc.example.com`, initially using `p=none` only while collecting data.
  4. Analyze reports, remediate unauthenticated senders, then progress to `p=quarantine` and `p=reject`.

Commands and configuration examples

Replace example values with the hostname, selector, IP address, port, provider, or policy values shown in your SecuTest evidence. Review every example before production use.

Monitoring record
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Enforcing record
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@example.com"

Inspect DMARC
dig +short TXT _dmarc.example.com

Verify the fix

  1. Run `dig +short TXT _dmarc.example.com` and confirm one `v=DMARC1` record.
  2. Send messages through every production sender and inspect `Authentication-Results` for aligned SPF or DKIM.
  3. Review aggregate reports for unknown and legitimate sources.
  4. Test enforcement with a controlled unauthorized sender before moving to `p=reject`.
Confirm the externally visible result

After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.

Re-scan your domain

Common mistakes

  • Publishing DMARC before all legitimate senders have aligned SPF or DKIM.
  • Placing the record at the root domain instead of `_dmarc`.
  • Assuming SPF pass alone is enough when the envelope-from domain is not aligned with the visible From domain.

Authoritative references