Why a missing DMARC record means your customer pays the attacker

TL;DR

A small payments platform we audited had SPF configured but no DMARC record at the apex domain. With that combination, anyone — including a teenager renting a $5 VPS — can send mail with a From: header claiming the platform’s domain, and Gmail will deliver it to the customer’s inbox without any visible warning. The customer then sends money to the attacker’s wallet. The platform is liable.

The fix is one line in DNS. The fix has been one line in DNS since 2015. That it still ranks among the most common findings on first-look audits in 2026 is a story about defaults, not about difficulty.

Context

A soloplayer team running a USDT/BTC top-up service approached us through a referral. Their stack is small and modern: Cloudflare in front, a Laravel backend, a few JavaScript libraries on the marketing pages. Branding looks decent. They were already taking deposits — roughly $3.5k of payment volume in the last 24 hours according to a counter on their landing page.

The owner asked for a sanity check. We ran our standard surface audit (~25 seconds) and shared three findings with him in plain language. The DMARC one was the first he stopped on, because the consequence of getting it wrong shows up at the customer-trust layer rather than at the technical-security layer.

This write-up unpacks that one finding. It is published with the owner’s permission, anonymised under our editorial policy, and only after the issue has been remediated and verified clean.

What the finding looked like

Our scan reported:

Email · DMARC          → missing
Email · SPF            → configured (v=spf1 include:_spf.google.com ~all)
Email · DKIM selectors → 0 / 70 common selectors found

DKIM absent is a separate finding worth its own paragraph. DMARC absent is the catastrophic one.

How outbound impersonation actually works

The Simple Mail Transfer Protocol — SMTP — was designed in 1982 and never required the sender to prove that they own the domain in the From: header. A mail server in front of an attacker’s $5 VPS can write any address it likes there. There is no protocol-level check.

Three layered defences emerged over the next four decades:

• SPF (RFC 7208) publishes, in DNS, the list of IP addresses authorised to send mail for the domain. The receiving mail server can compare the connecting server’s IP against that list.
• DKIM (RFC 6376) signs each outbound message with a cryptographic key, and publishes the public half in DNS. The receiver can verify the signature.
• DMARC (RFC 7489) ties the two together: it tells the receiver what to do when SPF or DKIM fails alignment with the visible From: header — accept, quarantine, or reject — and where to send forensic reports.

The crucial piece is the alignment check. SPF on its own checks the envelope sender (MAIL FROM:), not the visible From: header that the user actually sees. An attacker can pass SPF for their own domain and still spoof your domain in the visible header. Without DMARC telling the receiver to reject that mismatch, the message goes through.

What Gmail does without a DMARC policy

If the receiving server cannot find a DMARC TXT record at _dmarc.<domain>, it falls back to its own policy. For most major receivers — Gmail, Outlook, Yahoo — the fallback in 2026 is “deliver to inbox, no visible warning, no report back”. That is the ground state we found at the audited platform.

A practical demonstration:

$ swaks --to victim@gmail.com \
        --from "info@auditedplatform.com" \
        --header "Subject: Wallet update — please use the new address" \
        --body "Hi, our hot wallet has rotated. Please send your next \
                 deposit to TRC-20 address: TXY123…"

Five seconds. The mail lands in the customer’s inbox. The display name reads “Audited Platform Support”. The customer transfers, and the funds are gone.

This is not a theoretical attack. The 2024 IC3 report puts business-email-compromise losses at $2.9 billion that year alone — most of them enabled by exactly this class of misconfiguration.

The remediation

A single TXT record published at _dmarc.<your-domain>:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100

In words: “If a message claiming to be from this domain fails SPF or DKIM alignment, send it to the recipient’s spam folder. Apply this to 100% of mail. Send aggregate failure reports to the address listed.”

There are three recommended steps in sequence, not one:

1. Start with p=none — monitor only — for two to four weeks. Collect the aggregate reports (rua=) to identify legitimate senders that are currently failing alignment. Common surprises: marketing platforms, customer-support tools, transactional-mail providers, payroll systems.
2. Move to p=quarantine once the legitimate-sender list is clean. Mail that fails goes to spam, not the inbox.
3. Move to p=reject for full enforcement. Failing mail is dropped at the receiving MTA. This is where the protection is real.

The audited platform’s owner did the entire sequence in 18 days, with the help of a free DMARC monitoring service to parse the reports.

Why this issue is so common

Three structural reasons, none of them about engineering competence:

• Defaults. Squarespace, Shopify, Vercel, Cloudflare Workers, and most popular hosts do not publish a DMARC record on the customer’s apex domain unless the customer explicitly asks for one. SPF gets included by default; DMARC doesn’t.
• Operational fear. Incorrectly tightened DMARC blocks legitimate mail. Engineers without time for the monitoring loop above default to leaving the policy off rather than risking customer outreach problems.
• Invisibility. Unlike a broken site or a slow API, a missing DMARC produces no symptom in the platform’s own metrics. The first signal is usually a customer reporting a fraudulent message — at which point the damage has already happened.

What to verify on your own domain

You can check the same thing in three commands without installing anything:

dig +short TXT yourdomain.com | grep -i spf
dig +short TXT _dmarc.yourdomain.com
dig +short TXT default._domainkey.yourdomain.com

If the second command returns nothing, the rest of this article applies to you.

If it returns v=DMARC1; p=none ..., you are in monitoring mode but not protected.

If it returns v=DMARC1; p=quarantine ... or p=reject ..., you are in good shape — verify your rua= reports are landing somewhere a human reads them.

Standards & references

• RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 7208 — Sender Policy Framework (SPF)
• Mozilla web security guidelines · Email
• PTES Technical Guidelines
• Google Workspace · DMARC reporting setup

---

Published under our editorial policy. The audited domain is not named; the engagement is referenced only to ground the example in a real-world fix sequence. If a published case study identifies you in a way the policy should have prevented, contact us and we will remove or further anonymise the content within two working days.