How to set up DMARC From your first DNS record to verified email

Find the sending routes before editing DNS

DMARC is a policy the domain owner publishes in DNS, the system used to look up domain information. Receiving servers retrieve it there. Even if Google hosts employee email, the record normally belongs in the control panel of the company actually hosting the domain's DNS.

Confirm the current nameservers and DNS host first. A registrar account may still show an old zone that no longer answers publicly. Saving a record there can appear successful while changing nothing for receivers.

List the actual From addresses, not just the provider names

Ask each department which services use the company's address. Website notifications and billing systems are easy to miss if you only look at employee accounts. Gaon asks for a recent sample message and a named owner for each route.

These messages share a From domain but use different sending systems and signatures. One successful employee test does not verify the other two. Include any service using a subdomain such as news.example.com.

Why SPF and DKIM come first

SPF authenticates the domain used in MAIL FROM, the transfer address. DKIM authenticates the signing domain in d=. DMARC then checks whether a passing domain aligns with the visible From domain. At least one method must both pass and align.

Configure both SPF and DKIM where the sending service supports them. For outside services, specifically check whether they sign with your company's domain. A pass for the provider's own domain may not be enough. Microsoft: configuring DMARC and alignment ↗

Publish a monitoring record for a new deployment

Gaon has no existing DMARC record, so it starts by collecting evidence about legitimate mail. p=none asks for no quarantine or rejection on the basis of DMARC failure. It does not instruct receivers to accept every message.

Type: TXT
Name: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r
TTL: Your DNS provider's default or your operational standard

The rua value is the destination for aggregate reports. Gaon creates a dedicated mailbox and assigns someone to review it. Putting an address in DNS does not create the mailbox.

1. Open the active DNS zone for the domain

   Check for an existing _dmarc record and preserve any previous value before editing.

2. Choose TXT and enter the record name

   Use _dmarc or the complete name, as required by the DNS host. Confirm the final name is _dmarc.example.com.

3. Enter only the policy string in the value field

   Start with v=DMARC1 and separate settings with semicolons. Do not include the labels Type, Name, or Value. Check the reporting address and mailto: prefix.

4. Save, then verify through public DNS

   Record the change time. Cached answers can remain until their TTL expires, so visibility will not change everywhere at once.

The host/name field is a common source of mistakes. A panel that appends the domain may turn a full name into _dmarc.example.com.example.com. Another panel may require the full name. Judge the result by the final DNS name, not by the appearance of the input field. Google: adding the DMARC DNS record ↗

DMARC has its own TXT record. Do not append it to an SPF value beginning v=spf1 or replace a DKIM public key with it. The three records have different names and jobs.

Understand the settings before adding more options

Start with the policy, report destination, and alignment modes. Add other options only when you have a reason and understand their effect. The starting points below assume a new deployment still identifying its senders.

Strict alignment is a design choice, not an automatic upgrade

Suppose From uses example.com and a legitimate service signs with d=mail.example.com. In an ordinary shared organizational-domain setup, relaxed alignment can accept that relationship. Strict s requires identical domain names, so the DKIM path would no longer align.

Relaxed alignment does not mean that lookalike domains are accepted. Strict mode can be appropriate when a company needs tighter boundaries, for example around delegated subdomains. Before changing it, verify that every important sender retains an aligned passing path.

Omitting sp and np does not automatically exempt subdomains

A subdomain using the organizational domain's policy is affected by p when no applicable override is supplied. Check legitimate sending from news.example.com before changing the parent policy. If a valid record is found at _dmarc.news.example.com for that From domain, its own policy takes precedence. SPF, by contrast, does not inherit the parent's authorized-sender list.

For np, “non-existent” is a DNS condition. A website-only shop.example.com that exists in DNS does not become non-existent merely because it sends no email. Where np is absent, an applicable sp is used, or otherwise p.

ruf and fo concern per-message failure reports, not RUA aggregates. fo=0 requests reporting when no authentication mechanism produces an aligned pass; fo=1 requests it when any mechanism fails to produce one. The default is 0, and the option has no effect without ruf. Since these reports can expose message-level information and support is limited, establish aggregate reporting first. DMARC tag definitions ↗

Choose both a report destination and a person to review it

RUA reports summarize sending sources, counts, and authentication results observed by receiving systems. They use XML and may arrive as compressed attachments. Analysis tools can group the records into a more useful view than a mailbox full of individual files.

Gaon checks that the dedicated mailbox accepts external email and attachments, then assigns IT to compare reports with the sender inventory each week. If you use a group address, confirm that its settings allow mail from outside the organization. Collecting files without reviewing them will not tell you whether a policy change is appropriate. Google: receiving and analyzing reports ↗

An outside reporting destination must authorize the reports

When reports go to a domain belonging to another organization, that destination needs DNS authorization. This prevents a domain owner from using arbitrary reporting addresses to direct unwanted report traffic at someone else.

Company domain: example.com
RUA address: aggregate@reports.example.net

In the company's _dmarc.example.com policy:
rua=mailto:aggregate@reports.example.net

TXT name published by the REPORT RECIPIENT:
example.com._report._dmarc.reports.example.net
TXT value: v=DMARC1

The long authorization name belongs in DNS controlled by the operator of reports.example.net. It is not another string to add unchanged to your company's DNS. Providers may authorize customer domains individually or through a broader arrangement. Use the RUA value issued during onboarding and verify that the reporting connection is active. External report destination verification ↗

Reports are not real-time notifications. Daily aggregation is common, but generation and delivery vary and some receivers do not report. An empty mailbox immediately after setup is not proof of failure. If reports remain absent, check the address, external mail acceptance, destination authorization, and whether relevant mail was actually sent during the period.

Test the record and the actual mail separately

A green result from a DNS checker mainly tells you that a policy can be found and read. It does not prove that the company's messages meet that policy.

1. Confirm that one policy exists at the expected name

# macOS / Linux
dig +short TXT _dmarc.example.com

# Windows or another environment with nslookup
nslookup -type=TXT _dmarc.example.com

# Example expected TXT answer
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

Read the name, policy, and reporting address in the result. An empty answer warrants checking spelling, automatic domain suffixes, and the active DNS host. A stale answer warrants checking caches and the change history. Repeatedly adding the record can create duplicates instead of solving either issue.

Two separate TXT records beginning v=DMARC1 must be consolidated into one intended policy. Receivers do not choose between them. A single TXT record displayed as "v=DMARC1; p=none; " "rua=mailto:…" is different: its string segments are joined. Check record boundaries and the complete joined value.

2. Send a new message from each actual service

Gaon tests employee mail and the newsletter through an external mailbox. It reads authentication results recorded by that receiving service, using a feature such as Gmail's Show original. PASS text in a message body is not evidence.

Employee mail passes, but the newsletter produces these illustrative results:

From: Gaon News <news@example.com>
Authentication-Results: receiver.example.org;
  spf=pass smtp.mailfrom=bounce.mailer.example.net;
  dkim=pass header.d=mailer.example.net;
  dmarc=fail header.from=example.com

The passing domains belong under example.net, not the From domain example.com. Before adding more IPs to SPF, Gaon checks the newsletter platform's company-domain authentication and signing settings.

The administrator registers example.com in the provider's sending-domain configuration, publishes the TXT or CNAME values it issues, and confirms that signing is active after DNS verification. An arbitrary DKIM record will not substitute for that provider's key. A new newsletter test now produces:

From: Gaon News <news@example.com>
Authentication-Results: receiver.example.org;
  spf=pass smtp.mailfrom=bounce.mailer.example.net;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

The SPF domain has not changed. DMARC passes because the company's DKIM signature now passes and aligns. The solution was correcting the sending service's authentication, not changing p=none. If DKIM itself fails, investigate the key, selector, signing activation, and message changes before discussing alignment. Google: authentication and alignment troubleshooting ↗

3. Check reports covering the period after the change

Read the report's time window first. A file arriving after your change can still contain earlier failures. Compare the provider's sending times and source information with the report. Treat unfamiliar IPs as items to investigate rather than automatically classifying them as attackers.

Reports cover only the observations that reporting receivers supply. A service absent from a report may still exist, and a passing count is not an inbox-placement count. Keep actual receipt tests and provider bounce records alongside aggregate results. Aggregate report periods and observations ↗

Choose a policy from the domain's use and the evidence

Gaon has verified employee mail and newsletters, but has not yet tested the month-end invoice service. Thousands of passing newsletters would not compensate for a few blocked invoices. The inventory still has an unresolved row.

For each important route, record its owner, From address, aligned passing method, and the date of a fresh test. Include password resets, support replies, infrequent billing runs, and indirect routes used in real work. Resolve unexplained legitimate failures before changing the requested handling.

Rejection is not the right destination for every domain

RFC 9989 recommends against p=reject for domains used for general-purpose email. Forwarding, mailing lists, and other indirect uses can break authentication even when the mail is legitimate. Testing a few forwarding routes does not turn a general-purpose domain into a controlled transactional one.

A dedicated domain for a controlled sending purpose, such as a defined notification stream, has a different use profile. Assess policy choices for that domain separately. Depending on the legitimate paths and interoperability needs, monitoring or quarantine may be appropriate; rejection requires a justified scope and a clear understanding of the consequences. The receiver still makes its own final handling decision. DMARC interoperability and general-purpose email ↗

Domains publishing p=reject must apply valid DKIM signatures and cannot rely solely on SPF for DMARC. Controlled messages may still reach forwarding addresses. The updated standard also forbids receivers from rejecting solely because of a published reject policy: other knowledge and analysis must support that decision, or the failure must be treated as quarantine.

Provider rollout guidance can help structure the observation and correction work, but the decision should rest on verified senders and intended use, not “a week has passed” or a single overall percentage. Google: planning a DMARC rollout ↗

Gaon's first setup found a missing newsletter signature and an untested billing route. Keeping that evidence with the sender inventory gives the next administrator a useful starting point. Apply the same checks whenever a service is added, replaced, or retired.