No DMARC Record: How to Fix This Site AI Audit Finding

Short answer: “No DMARC record” is a critical finding in the e-mail area of a Site AI Audit report. It means your domain does not publish a DMARC policy, so receiving mail servers have no instruction about what to do with messages that pretend to come from you. To fix it, add one TXT record named _dmarc with a starting policy of p=none and a reporting address, read the reports for a couple of weeks and then tighten the policy.

What the finding says

In the report the finding appears as “No DMARC record”, with a critical severity. The explanation is short: Gmail and Yahoo require DMARC for bulk senders, and without it, spoofed mail in your name is not blocked. The suggested fix is to publish a TXT record at _dmarc with the value “v=DMARC1; p=none; rua=mailto:you@yourdomain” and to move to a stricter policy later.

The home page of Site AI Audit shows the same finding as an example of how a report reads, with the fix described as adding a TXT record called _dmarc with v=DMARC1; p=none and then tightening it after two weeks. This guide expands that advice into steps you can follow.

What DMARC does in plain words

E-mail was designed without a reliable way to prove who sent a message. SPF and DKIM add two proofs: SPF lists the servers allowed to send for your domain, and DKIM signs each message with a key published in your DNS. DMARC sits on top of both. It tells receiving servers two things: what to do when a message fails those checks, and where to send reports about what they saw.

Without DMARC, a receiver that sees a failing message must guess. Some will deliver it, some will put it in spam and some will reject it. With DMARC, you decide. That protects your customers from fake invoices sent in your name and protects your real mail from being treated with suspicion. If you want the full picture of the three records together, the article on what the e-mail checks in the audit cover explains how they fit.

Before you add the record

A DMARC record is only useful when SPF and DKIM already work for the mail you really send. Spend ten minutes on a short inventory:

List every service that sends mail as your domain. That includes your mailbox provider, your website’s contact forms and order e-mails, a newsletter tool, an invoicing system and any helpdesk.
Check that SPF includes them. If the audit also shows an SPF finding, fix it first. The SPF record examples cover common setups.
Check that each service signs with DKIM for your domain, if it supports it.

This inventory is the step people skip, and it is the one that prevents a strict policy from blocking your own invoices later.

The record to add

Create a TXT record in your DNS with these parts:

Name (host): _dmarc. Some DNS panels want the full name, _dmarc.yourdomain.com.
Type: TXT.
Value: v=DMARC1; p=none; rua=mailto:[email protected]

The policy p=none means “monitor only”. Nothing changes for your mail, and nothing is blocked, but receivers start sending you aggregate reports to the address in rua. Use a mailbox you actually read, or a service that processes the reports for you; raw reports are XML files that are hard to read by eye. The guide to DMARC monitoring tools explains what to look for in a reporting service.

DNS changes can take time to spread. After saving the record, wait a short while and run the check again; the finding should disappear and may be replaced by a lower one, discussed next.

The findings that follow

Once a record exists, the audit looks at how it is set up. You may see these in the next report:

DMARC is in monitoring mode only (p=none): a warning. Spoofed e-mails in your name are still delivered. The advice is to change the policy to p=quarantine and later to p=reject after you have checked the reports.
DMARC reports are not collected: a notice when the record has no rua address. Without it you cannot see who sends mail using your domain.

This sequence is normal. The critical finding is replaced by a warning, and the warning stays until you have moved beyond monitoring. It is a sign that you are on the right path, not that you did something wrong.

How to tighten the policy safely

Leave p=none in place for about two weeks while the reports arrive. Look for legitimate senders that fail, such as a newsletter tool that is not in your SPF record. Fix them one by one. When the reports show that all your real mail passes, move to p=quarantine, which asks receivers to treat failing mail as suspicious, usually by delivering it to spam. Watch for another week or two. Only then consider p=reject, which asks receivers to refuse failing mail. The article on moving from p=none to reject safely walks through each stage and the mistakes to avoid.

Take your time with the last step. Many businesses stay at quarantine for good, and that is a reasonable choice when mail comes from many tools that are hard to align.

Common mistakes with the DMARC record

Most failed attempts come from a handful of slips, and the audit will keep showing the finding until they are fixed:

The record is in the wrong place. It must be a TXT record on the name _dmarc, not on the bare domain. A record on the root of your domain is not a DMARC record.
There are two DMARC records. A domain should publish exactly one. Merge them into a single record.
The value has a typo. The record must start with v=DMARC1, and the tags are separated by semicolons. A missing semicolon or a space in the wrong place can make a receiver ignore the record.
Quotation marks were added twice. Some DNS panels add quotes automatically. If you paste a value that already has quotes, you can end up with a broken record.
The policy was set to reject on day one. That blocks any legitimate service that you forgot to include in SPF or DKIM, often an invoicing or newsletter tool.

If you are unsure, look the record up with any DNS lookup tool after saving it. You should see your value exactly once.

Why it matters more than it used to

Large mail providers now expect domains that send in bulk to authenticate their mail, and a domain without DMARC looks careless to them. The audit’s explanation says it directly: Gmail and Yahoo require DMARC for bulk senders. Even if you send only a few messages a day, the same domain can be used by criminals to send thousands of fake messages. Those messages damage your reputation, and the people who receive them blame you. A DMARC record does not remove that risk on its own, but it is the first step, and without it the later steps are impossible.

It also helps with an everyday problem: your own mail landing in spam. Receivers trust domains that are properly authenticated, and the reports tell you which of your own systems send unauthenticated mail. That is a clear, practical reason to publish the record even if you have never been spoofed.

A worked example

A small accounting firm runs its mail through a business mailbox provider and sends invoices from a separate invoicing tool. The audit report shows “No DMARC record” as critical. The owner lists her senders and finds the invoicing tool is missing from SPF. She adds it, then publishes the _dmarc record with p=none and a reporting address. After a re-check, the critical finding is gone and the report shows the warning for monitoring mode. Two weeks of reports show everything passing, so she changes the policy to p=quarantine. A month later a client tells her that a scam e-mail pretending to be her firm went to his spam folder. That is DMARC doing its job.

Your report shows the DMARC result together with SPF, DKIM and MX. To see where your domain stands, check your website with Site AI Audit. The check needs a free account; the plans unlock the full report and re-checks, so you can confirm each change in DNS.

The bottom line

A missing DMARC record leaves your domain open to spoofing and weakens your real mail. Add a _dmarc TXT record with p=none and a reporting address, check that your genuine senders pass, and then tighten the policy step by step. Run the audit again after each change to confirm the result.

FAQ

Will adding DMARC with p=none stop my mail from being delivered?

No. The policy p=none only asks receivers to send you reports. It does not change how your messages are handled.

Do I need SPF and DKIM before DMARC?

DMARC relies on at least one of them passing and aligning with your domain. Set up SPF and DKIM for every service that sends mail for you first.

What address should I use in rua?

Use a mailbox on your own domain that someone reads, or the address a reporting service gives you. Reports arrive daily from large mail providers.

How long does it take for the finding to disappear?

Once the record is published and DNS has updated, run a new check. The finding should be gone, though a monitoring-mode warning may take its place.

Does a domain that sends no mail need DMARC?

If the domain sends no mail, a restrictive record can still stop others from pretending to be it. The audit also mentions publishing “v=spf1 -all” for domains that do not use mail.