If your domain has no DMARC record, anyone on the internet can send email that appears to come from your address. That is not a theoretical risk. It is a straightforward consequence of how SMTP was designed, and it is one of the cheapest, highest-impact gaps to close in your email security posture.
What DMARC Actually Does
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a DNS record that tells receiving mail servers what to do when an incoming message fails authentication checks. It works on top of two other records you should already have:
- SPF (Sender Policy Framework): A DNS TXT record that lists the IP addresses authorized to send mail for your domain.
- DKIM (DomainKeys Identified Mail): A cryptographic signature attached to outgoing messages, verified against a public key published in DNS.
DMARC ties those two together and adds a policy. When a message fails SPF or DKIM alignment, DMARC tells the receiving server to either do nothing (p=none), quarantine the message (p=quarantine), or reject it outright (p=reject). It also gives you a reporting mechanism so you can see who is sending mail on behalf of your domain.
Without a DMARC record, receiving servers have no instruction from you. They fall back on their own heuristics, which vary widely. Some will pass spoofed messages through. Many will.
The Actual Threat: Domain Spoofing
When an attacker spoofs your domain, they craft a message where the From: header shows your address. To the recipient, it looks exactly like mail from you. This is the mechanism behind a large portion of business email compromise (BEC) attacks, where an attacker impersonates an executive or vendor to redirect payments or extract credentials.
The spoofed domain does not have to be yours specifically. Attackers also register lookalike domains (e.g., tekna-byte.com instead of teknabyte.com) and send from those. DMARC does not stop lookalike domains, but it does stop direct spoofing of your exact domain. That distinction matters because direct spoofing carries the most inherent trust.
For defense contractors and organizations handling Controlled Unclassified Information (CUI), this is not just a security concern. NIST SP 800-171 requires protecting the confidentiality of CUI and controlling access to systems. A spoofed email that tricks an employee into handing over credentials or wiring funds is a direct path to a CUI breach.
Why p=none Is Not Enough
A lot of organizations publish a DMARC record with p=none and consider the job done. That policy does exactly one useful thing: it enables reporting. It does not block or quarantine anything. Spoofed messages still reach inboxes.
p=none is a legitimate starting point when you are first inventorying your mail senders and do not yet know everything that sends on your behalf (marketing platforms, ticketing systems, payroll providers, and so on). The reporting data helps you find those senders so you can add them to SPF or get them DKIM-signing. But p=none is a diagnostic mode, not a protective one. Leaving it there indefinitely is a common mistake.
The goal is p=reject. Getting there requires:
- Publishing
p=noneand collecting aggregate reports (theruatag in your DMARC record). - Reviewing those reports to identify all legitimate sending sources.
- Ensuring every legitimate source passes SPF or DKIM alignment.
- Moving to
p=quarantineand monitoring for legitimate mail being caught. - Moving to
p=rejectonce you are confident legitimate mail is passing cleanly.
This process typically takes a few weeks to a few months depending on how many third-party senders you have. It is not complicated, but it requires someone to actually work through the reports.
Checking Your Current State
You can check your DMARC record right now with any DNS lookup tool. Query the TXT record for _dmarc.yourdomain.com. If nothing comes back, you have no DMARC record. If you get a record back, look at the p= value to see what policy is actually in effect.
Also check:
- SPF: Query the TXT record on your root domain. Make sure it covers all your sending sources and does not exceed the 10 DNS lookup limit.
- DKIM: This one is harder to spot-check manually because the selector varies by mail provider. Your email platform’s admin console should show you whether DKIM signing is enabled and what selector is in use.
What to Do If You Have No Record
Start today. Publishing a p=none record with a reporting address takes about five minutes and has zero risk of breaking mail flow. Here is a minimal starting record:
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"Set up a mailbox or use a DMARC reporting aggregator to collect and parse the XML reports. Give it two to four weeks of data, then start working through what you find.
If you are a Microsoft 365 shop, DKIM signing is available in the Defender portal under Email Authentication Settings. SPF for M365 is a single include statement. Neither requires advanced DNS expertise to configure.
The Bottom Line
No DMARC record means your domain is an open invitation for spoofing. The fix is not expensive or technically complex. It requires attention and follow-through. If your organization sends email, which is every organization, this belongs on your security checklist above most other items. The gap is real, the exploit is trivial, and the remediation is within reach of any IT team.