HighAuthentication

No DMARC record found

The domain publishes no DMARC record, so receivers have no instruction about what to do with mail that claims to be from you but fails authentication. Without DMARC, SPF and DKIM check individual identifiers that a recipient never sees, and nothing ties either of them to the From: address displayed in the mail client, which is the address a person actually reads and trusts.

Check your own domainDMARC checker

What causes this

DMARC is a TXT record at _dmarc.yourdomain.com. It does two things: it tells receivers what to do with mail that fails both SPF and DKIM alignment, and it asks them to send you aggregate reports about who is sending mail as your domain. Without it, receivers have no instruction from you and you have no visibility into how your domain is being used. Google, Yahoo and Microsoft all require bulk senders to publish at least p=none.

What it breaks

Nobody is told what to do with forged mail claiming to be your domain, and you receive no reports showing which systems send on your behalf. Anyone can send mail that appears to come from your domain without a policy standing in the way.

What the receiving server does

A receiver looks for a TXT record at _dmarc.yourdomain.com. Finding none, it has no policy to apply and falls back to its own heuristics. Crucially it also has no alignment requirement, so a message can pass SPF for a domain the sender owns while displaying your domain in the From: header, and nothing in that message is technically wrong. You also receive no reports, which means you have no visibility of who is sending as you: the absence of DMARC is as much an intelligence problem as a policy one.

What the record says, tag by tag

A first DMARC record should be a monitoring record: it asks for reports without changing how any mail is treated. Publish this before anything else, because the reports are what tell you whether it is safe to enforce later.

vv=DMARC1version, must be first
pp=nonepolicy: take no action, just report (the safe starting point)
ruarua=mailto:dmarc@example.comwhere aggregate reports are sent
name_dmarc.example.comthe record name (not the apex, and not dmarc without the underscore)

How to fix it

Publish a monitoring-only DMARC record first, then tighten it once the reports are clean.

  1. Create a TXT record at _dmarc.yourdomain.com.
  2. Start with p=none and a reporting address so you collect data without affecting delivery.
  3. Read the aggregate reports for two to four weeks and confirm every legitimate sender passes SPF or DKIM with alignment.
  4. Move to p=quarantine, then to p=reject once the reports show no legitimate mail would be affected.
TXT · _dmarc
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Replace the reporting address with a mailbox you actually monitor, or a DMARC reporting service.

If you send with

Before you publish anything else
Publish p=none with a reporting address first, and leave it for two to four weeks. Aggregate reports will tell you every source sending as your domain, including the invoicing tool nobody remembered and the server a former employee configured. Enforcing before you have that list is how legitimate mail gets rejected.
Where to send the reports
Aggregate reports are XML and arrive daily from every major receiver, so a personal inbox is the wrong destination. Use a dedicated address or a DMARC reporting service. If you send the reports to an address at a different domain from the one being reported on, that domain must publish an authorisation record. See the external reporting page.

Confirming the fix worked

  1. Publish the TXT record at _dmarc.yourdomain.com, not at the apex. The underscore is part of the name.
  2. Confirm exactly one DMARC record exists at that name. Two is a permanent error and both are ignored.
  3. Wait 24 to 48 hours and confirm aggregate reports begin arriving at the rua address.
  4. Read the reports before changing p. The decision to enforce should be based on what they show, not on a calendar.

Common questions

Do I need SPF and DKIM before publishing DMARC?
You need at least one of them working and aligned, and in practice you want both. DMARC passes when SPF or DKIM passes and the domain it authenticated aligns with the From: domain. Publishing DMARC at p=none is safe regardless, because it changes nothing about how mail is handled.
Where does the DMARC record go?
In a TXT record at _dmarc followed by your domain, so _dmarc.example.com. It does not go at the apex like SPF, and the leading underscore is required.
Does DMARC apply to my subdomains?
Yes by default, which is the opposite of SPF. The organisational domain's policy covers subdomains unless you publish a separate policy for a subdomain, or override it with the sp tag.
Is p=none pointless if it does not block anything?
No. p=none is what makes the reporting flow start, and those reports are the only reliable way to discover everything sending as your domain. It is a necessary stage, but it is a stage: a record left at p=none indefinitely provides visibility and no protection.
Will publishing DMARC break my email?
Not at p=none, which explicitly asks receivers to take no action. Mail is only affected when you move to quarantine or reject, which is why the reporting period before that matters.