A DMARC record helps protect your domain from email spoofing and helps receiving mail systems decide how to handle messages that claim to come from your business. Checking the record is simple. Understanding the result takes a little more care. A DMARC record can exist while still providing little protection. A strict policy can look secure while accidentally affecting legitimate mail from a forgotten service. The goal is not simply to publish a record. The goal is to make sure your legitimate senders are configured correctly and unauthorized senders are not trusted.
What DMARC does
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It builds on two other email-authentication systems:
- SPF, which checks whether a sending server is authorized.
- DKIM, which checks a cryptographic signature on the message.
DMARC then asks an additional question: Does a passing SPF or DKIM result align with the domain the recipient sees in the From address? That alignment check matters because a message could pass SPF or DKIM using a vendor's domain while still claiming to be from your business. DMARC also tells receiving systems what to do when a message fails those checks.
Where to find a DMARC record
A DMARC record is a DNS TXT record published at this location:
_dmarc.yourdomain.comFor example, the DMARC record for example.com belongs at:
_dmarc.example.comA basic record begins with:
v=DMARC1If no DMARC record exists, mailbox providers do not have a DMARC policy from your domain to follow. That does not automatically mean all of your email will fail. It means your domain has less control over how unauthenticated mail claiming to be from it is handled.
Run the actual DNS lookup
In a terminal with dig installed, replace yourdomain.com with your sending domain:
dig +short TXT _dmarc.yourdomain.comOn Windows, you can use:
nslookup -type=TXT _dmarc.yourdomain.comLook for one TXT policy starting with v=DMARC1. An empty answer needs investigation: confirm spelling, DNS publication, and whether a subdomain inherits policy from its organizational domain. A timeout is not proof that the record is absent. Save the result before making changes.
Read the policy first
The most important part of a DMARC record is usually the policy, shown with p=. The common options are:
p=none
p=quarantine
p=rejectp=none
This is usually the monitoring stage. It asks receivers to send reports about DMARC failures without asking them to quarantine or reject those messages. It is useful when you are still discovering the email platforms that send mail for your business. p=none is not a strong enforcement policy. It gives visibility, not much protection.
p=quarantine
This asks receiving systems to treat messages that fail DMARC as suspicious. In practice, a receiver may place them in spam or junk. It can be a sensible intermediate step after you understand your legitimate senders but before you move to full rejection.
p=reject
This asks receiving systems to reject messages that fail DMARC. It is the strongest of the three policies, but it should not be used blindly. If an active CRM, support platform, or ecommerce tool is not properly aligned, a reject policy can cause legitimate business mail to fail. Read DMARC policy: p=none vs quarantine vs reject before changing policy.
Check whether your SPF or DKIM results align
This is the part that surprises many businesses. A message can pass SPF and still fail DMARC. A message can pass DKIM and still fail DMARC. That happens when the authenticated domain does not align with the visible From domain. For example:
- Visible From address:
news@yourbusiness.com - SPF passes for:
mail.vendor-example.com
The SPF result may be valid, but it may not align with yourbusiness.com. The same principle applies to DKIM. Look at a sent message's headers for the DKIM signature. The d= value identifies the signing domain. If that domain is not appropriately related to your visible From domain, DKIM may pass without satisfying DMARC alignment. Many providers support custom-domain authentication to solve this. They give you DNS records that allow them to send and sign mail using your domain.
Check a real sent message
A public DNS check is the right starting point, but it cannot tell you everything about your actual mail flow. Send a test message from each platform that sends as your domain:
- Employee mailbox provider
- Newsletter platform
- CRM
- Support desk
- Website form tool
- Ecommerce or billing service
- Transactional-email provider
Open the message headers and look for an Authentication-Results section. You want to see:
spf=pass
dkim=pass
dmarc=passThen compare:
- The visible From domain
- The Return-Path or envelope-from domain
- The DKIM
d=domain - The DKIM
s=selector
This identifies whether the message passes and whether it aligns.
Understand DMARC reports
DMARC reports show how receiving systems saw mail claiming to come from your domain. Aggregate reports typically summarize:
- Source IP address
- Number of messages
- SPF result
- DKIM result
- DMARC result
- Policy applied by the receiver
They can help you identify:
- A legitimate service that was not configured correctly
- A retired service still sending mail
- A new system someone added without updating DNS
- Suspicious sources trying to use your domain
Reports can be difficult to read in raw XML form. The important part is using them to build a reliable sender inventory. Read what a DMARC report is and how to read a DMARC aggregate report.
Common DMARC mistakes
Publishing a record without reviewing senders
A record is not the end of the job. You need to know which systems legitimately send mail using your domain.
Moving to reject too early
A strict policy is valuable only after legitimate mail is properly authenticated and aligned.
Assuming SPF or DKIM pass guarantees DMARC pass
DMARC requires alignment with the visible From domain.
Forgetting a transactional sender
A business may remember its newsletter platform but forget its invoice sender, password-reset service, or support desk.
Treating unknown sources as legitimate
An unfamiliar source in a DMARC report is not automatically a service you should authorize. Investigate it before adding anything to SPF or DKIM.
Leaving the record unmonitored
A DMARC record can be removed or weakened during a DNS cleanup, provider migration, or accidental edit.
A safe DMARC rollout process
Use this sequence:
- List all services that send email for your domain.
- Check SPF and DKIM for each service.
- Publish a valid DMARC record with reporting enabled.
- Start with a monitoring policy if you are still discovering senders.
- Review reports and real message headers.
- Fix alignment for legitimate senders.
- Move to quarantine or reject gradually when the evidence supports it.
- Keep monitoring the record and sender changes.
This is safer than treating DMARC as a single DNS setting.
Frequently asked questions
Does DMARC stop every phishing email? No. It helps receivers identify and handle unauthenticated mail using your exact domain. It does not stop every lookalike domain, compromised mailbox, or social-engineering attempt. Can I use DMARC without SPF and DKIM? You can publish a record, but DMARC depends on SPF and/or DKIM authentication and alignment to pass. A complete setup needs all three. Should every small business use p=reject? Not immediately. A small business should first identify and configure its legitimate senders. A reject policy is useful after that work is complete. How often should I check DMARC? Check it whenever you add or migrate a sending service. It is also worth monitoring because an unexpected DNS change can reduce your domain protection.
The practical next step
Run a free check to see whether a DMARC record is publicly visible for your domain. Then send test messages from every platform your business uses. The public record tells you the policy; the message headers and reports tell you whether your real mail is meeting that policy. Once your setup is correct, monitor it. That helps ensure a future vendor change does not quietly undo the protection you worked to build. Run a free Beacon domain check →