We run continuous security assessments at breka.ai. Fintech, crypto exchanges, insurance platforms, SaaS tools. Every engagement is different, but one finding shows up so often that we have stopped being surprised by it.
The application is hardened. The API rejects unauthenticated requests. The cloud buckets are locked down. And then their email domain says this:
v=DMARC1; p=none
In our latest batch of assessments, 6 out of 13 domains we checked, 46 percent, published DMARC with p=none or had no DMARC record at all. That means an attacker can send email that looks exactly like it came from the company, and receiving mail servers are told to deliver it.
What the issue is
Every company that sends email relies on three DNS records to prove its mail is real.
SPF lists the servers that are allowed to send mail for the domain. DKIM signs each message with a key. DMARC is the policy that says what happens when those two checks fail.
Here is the part most people miss. SPF and DKIM only produce a pass or fail verdict. DMARC is the only mechanism that does anything with that verdict.
p=none tells receiving servers to do nothing. p=quarantine sends failures to spam. p=reject blocks them entirely.
A domain with p=none usually has working SPF and working DKIM, and a policy that says ignore both of them.
What an attacker does with it
Sending a spoofed email is not complicated. The attacker runs any mail server, or uses any free SMTP service, and sets the From header to your domain.
The receiving server checks SPF. The attacker's server is not on the list. Fail. It checks DKIM. No valid signature. Fail. Then it checks DMARC, sees p=none, and delivers the message.
No exploit. No stolen credentials. No code. Just a DNS record that refuses to enforce the protection that is already there.
Why this is a real problem
The consequences depend on what the company does, and they are worst for the companies that have the most to lose.
For a payments company, a spoofed email from billing@ can redirect invoices or payment details. For a fund or an investment firm, spoofed wire instructions can move real money. For an insurance or benefits platform, a fake message from claims@ is a shortcut into someone's personal data. For a startup accelerator, spoofing the exact address that sends application invites gives an attacker a trusted channel into every founder.
Email is still the channel where people click first and ask questions later. A spoofed message that lands in the primary inbox with the right From address is hard to tell apart from the real thing. That is why attackers keep using it.
Why companies leave it on p=none
The reason is not laziness. It is fear of breaking mail.
Flipping a domain straight to p=reject will bounce any legitimate email that goes through a misconfigured sender. Marketing platforms, ticketing systems, and vendor tools often send on a company's behalf. If one of those is not in SPF or does not sign with DKIM, turning on enforcement cuts it off.
That fear is valid. What we usually find, though, is that the company's own mail already passes SPF and DKIM. We check the DKIM selectors. They are there. Their real mail would survive p=reject. Only forged mail would be blocked. They are leaving the door open for no reason.
How to fix it properly
The fix is a DNS change, but it should be done in steps.
Step one. Publish DMARC with p=none and an rua address. The rua is where aggregate reports go. This gives you a picture of everything that is sending mail as your domain before you change anything.
Step two. Read the reports. Find every legitimate sender that is not passing SPF and DKIM. Add them to SPF. Fix their DKIM signing. This is the step most teams skip, and it is the reason enforcement later breaks mail.
Step three. Move to p=quarantine. Watch the reports again. If legitimate mail starts going to spam, you will see it in the reports before customers complain.
Step four. Move to p=reject. If you want the same enforcement on subdomains, set sp=reject as well.
A complete record looks something like this:
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@yourcompany.com; ruf=mailto:dmarc-forensic@yourcompany.com; fo=1; adkim=s; aspf=s
A few notes. adkim=s and aspf=s require strict alignment, which is safer, but relaxed alignment with r works too if you use subdomains heavily. ruf is optional and sends forensic copies of failed messages. Keep pct=100 so the policy applies to all mail, not a fraction of it.
If you are not ready for reject, quarantine is still a meaningful step up from none. Any enforcement is better than telling the world to deliver forged mail.
The point
We keep reporting this finding because it is cheap to fix and expensive to ignore. One DNS record stands between a company and an attacker sending email in its name.
If you are not sure what your domain publishes, check it. It takes thirty seconds. Query _dmarc.yourdomain.com for a TXT record. If the answer is p=none, or there is no answer at all, that is the finding.