VulWall Team February 18, 2026 4 min read

Missing Email Protection Lets Anyone Impersonate Your Domain

Your domain account.roamler.com is missing a security record that tells email providers how to handle messages that pretend to be from you. Without it, someone could send emails that appear to come from your domain — like a fake invoice or login request — and many recipients' inboxes would accept them as legitimate. This is a configuration gap, not an active attack, but it's worth closing.

OWASP A05 Effort: small Exploitable
dmarc email-security spoofing dns subdomain phishing misconfiguration

Business Impact And Actions

medium urgency

Business Impact

If someone were to impersonate your domain in an email, it could damage customer trust, expose your users to fraud, and create compliance headaches — particularly if you handle payment data or operate under privacy regulations. Major email providers like Gmail and Yahoo now require this type of record for reliable email delivery, so its absence can also cause your own legitimate emails to land in spam.

What To Do

  1. Ask your developer or IT person to check whether your main domain (roamler.com) already has a DMARC record — if it does, this subdomain may be covered automatically and just needs verification.
  2. If no record exists on the parent domain, ask your developer to add a DMARC DNS record — it's a short text entry in your domain settings and typically takes under an hour.
  3. Start with a 'monitoring only' policy so you can see what email is being sent from your domain before enforcing any blocking rules.
  4. After a few weeks of reviewing the reports, ask your developer to tighten the policy to quarantine or reject to actively block spoofed emails.

Missing DMARC TXT Record on Subdomain account.roamler.com

medium severity CVSS 5.3-6.5

Vulnerability Explanation

No DMARC record exists at _dmarc.account.roamler.com. DMARC (Domain-based Message Authentication, Reporting & Conformance) is a DNS TXT record that instructs receiving mail servers on how to handle messages that fail SPF or DKIM authentication checks. Without it, receiving servers have no policy to enforce when a spoofed email claims to originate from this domain — meaning spoofed messages may be delivered to recipients' inboxes. Note that this is a subdomain: if roamler.com already has a DMARC record with an enforced policy (p=quarantine or p=reject) and no sp= tag override, the subdomain may already inherit that policy. This should be verified before adding a redundant record.

Root Cause

No _dmarc TXT record has been published in DNS for account.roamler.com, and either the parent domain (roamler.com) has no DMARC record, has a p=none monitoring-only policy, or uses an sp= tag that downgrades subdomain enforcement. SMTP was designed without authentication in mind, so without explicit DNS-published policies, receiving servers default to delivering mail regardless of whether the From address is genuine.

Technical Impact

An attacker can craft emails with a From address of any user@account.roamler.com and send them from arbitrary infrastructure. Without a DMARC policy, many receiving mail servers will deliver these messages to inboxes. This enables phishing, business email compromise (BEC), and brand impersonation attacks targeting customers, partners, or employees who trust the domain.

Severity Justification

Email spoofing via a missing DMARC record is technically feasible and the tooling to exploit it is widely available, but it requires an attacker to specifically target this subdomain and craft a convincing phishing campaign. The subdomain (account.roamler.com) likely carries user-trust weight as an account-related domain, increasing phishing plausibility. Severity is medium rather than high because exploitation requires attacker intent and social engineering — there is no direct system compromise.

Affected Components

  • account.roamler.com — no DMARC record (all versions/configurations)

Remediation Steps

  1. First, check whether the parent domain already has DMARC: run `dig TXT _dmarc.roamler.com` or use https://mxtoolbox.com/dmarc.aspx. If roamler.com has p=quarantine or p=reject with no sp= tag, the subdomain already inherits that policy — verify with `dig TXT _dmarc.account.roamler.com` and confirm the subdomain record is absent but the parent policy is enforced.
  2. If the parent domain has no DMARC record or uses p=none, add a DMARC TXT record to the parent domain first. Start with a monitoring policy: `v=DMARC1; p=none; rua=mailto:dmarc-reports@roamler.com`
  3. If account.roamler.com requires its own dedicated record (e.g., different reporting destination or policy), add a TXT record at the DNS host/registrar: Host: `_dmarc.account.roamler.com` | Value: `v=DMARC1; p=none; rua=mailto:dmarc-reports@roamler.com`
  4. Monitor aggregate reports (rua) for 2–4 weeks to identify all legitimate sending sources and confirm SPF and DKIM are passing for them.
  5. Escalate the policy to quarantine, then reject: `v=DMARC1; p=reject; rua=mailto:dmarc-reports@roamler.com`

Verification Steps

  1. Run: `dig TXT _dmarc.account.roamler.com` — a valid record should return a string beginning with `v=DMARC1;`
  2. If relying on parent inheritance, run: `dig TXT _dmarc.roamler.com` and confirm p=quarantine or p=reject is set with no sp=none override
  3. Use the MXToolbox DMARC checker: https://mxtoolbox.com/dmarc.aspx — enter account.roamler.com and confirm the record is found and policy is enforced
  4. Send a test email from the domain and inspect the Authentication-Results header in the received message to confirm DMARC=pass

Code Examples (dns)

Vulnerable
; No record exists at:
_dmarc.account.roamler.com  (missing)
Fixed
; Option A — Add to parent domain (covers all subdomains via inheritance):
_dmarc.roamler.com.  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@roamler.com"

; Option B — Add a dedicated subdomain record:
_dmarc.account.roamler.com.  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@roamler.com"

; Start with p=none for monitoring, then escalate to p=quarantine, then p=reject

Best Practices

  • Always ensure SPF and DKIM are correctly configured and passing before escalating DMARC to p=quarantine or p=reject — jumping straight to reject without verified alignment will cause legitimate email to be blocked.
  • Use the rua= tag to receive aggregate reports and monitor authentication results across all sending sources before enforcing a strict policy.
  • For subdomains that never send email, publish p=reject immediately — there is no risk of blocking legitimate mail and it closes the impersonation vector entirely.
  • Prefer managing DMARC at the organizational domain level (roamler.com) using inheritance rather than maintaining separate records per subdomain, unless subdomain-specific policies or reporting are required.

References

Found this in your infrastructure?

VulWall scans for this and dozens of other issues automatically.

Scan Your Domain Free
Back to Knowledge Base