Your DMARC rollout checklist Find every service using your domain

Look beyond the services managed by IT

Asking colleagues which services have SPF and DKIM configured may not get you far. They know their tools, but not necessarily the servers behind them. Ask when a customer receives an email in the company's name.

Seoyeon in Marketing mentions that the CRM also sends consultation reminders. Minsu in Finance initially leaves out the invoice service because he thinks of it as separate from company email. Reviewing recent customer messages together catches gaps that a list of product names would miss.

Compare the answers with subscriptions, service accounts, and sending logs. A paid tool may never use your domain, while a free tool or old agency server may not appear in purchasing records. Existing SPF entries and DKIM records are clues too, but a record still in DNS does not establish that a service is still used.

Give each distinct sending route its own row

A store might send order confirmations through an email provider but password resets through an older web server. Split rows when the From address or sending method differs, even within the same product. Identify both the person who can change the configuration and the person who understands the business impact. For an outsourced service, designate an internal contact.

Do not make colleagues guess technical values. “Password resets / Engineering / sending domain unverified” is a useful starting entry. IT can fill in the domain from a test message later. Google likewise advises checking authentication for third parties that send on your behalf before deploying DMARC. Google's preparation guidance ↗

Complete one inventory row from a real received message

Seoyeon's newsletter shows pass for both SPF and DKIM. A closer look reveals that both results belong to the provider's mailer.example.net. Customers see news@example.com, so neither result connects to the company domain.

This is why you need authentication and alignment together. MAIL FROM is the envelope address used for delivery failure notices. DKIM's d= identifies the signing domain. DMARC requires at least one method to pass with a domain that aligns with From. DMARC domain alignment ↗

Jiyoon publishes the DNS values issued by the newsletter provider's domain authentication feature and enables signing. Once verification completes, she sends a fresh campaign test. Reopening an old message would only show its original authentication results.

From: Gaon Trading <news@example.com>
Return-Path: <bounce@mailer.example.net>
Authentication-Results: mx.recipient.example;
  spf=pass smtp.mailfrom=bounce@mailer.example.net;
  dkim=pass header.d=example.com header.s=news2026;
  dmarc=pass header.from=example.com

SPF still passes for the provider's domain. DKIM now passes for the company's example.com, and DMARC passes through that signature. news2026 is the selector used to locate the signing key. Use the actual selector and records issued by your service; these example values are not a configuration to copy.

Read the authentication results recorded by the receiving service. If the original contains several Authentication-Results fields, use the results trusted by that receiver rather than choosing the first line. Forwarded messages may include observations from intermediaries as well. Trusting authentication headers ↗

Download the sender inventory CSV ↓

The next administrator can see which method the route relies on, who checked it, and what remains to review. That is much more useful than “newsletter OK.” A different From address or sending route in the same service needs its own verification.

The CSV does not need every customer address or complete message. Keep recipients, message identifiers, original headers, and related configuration changes in a restricted internal test record. Put its reference in “Next action.” Mark anything not yet checked as Unverified, so a blank cannot be mistaken for a pass.

Test the business process, not just the send-test button

Gaon's store dashboard sends a successful test message, but its password-reset function uses another server. A general test button does not necessarily exercise every production route.

Agree on a test scope with the business owner so you do not send a test invoice to a customer or create an unintended payment. If you use a separate test environment, record how it differs from production. A passing test server does not verify the production server.

Distinguish DNS setup, sending, and authentication

If DNS is published but no message has been sent, the route is not yet tested. If the send button was clicked but the message remains queued, it may not have been sent. If it was sent but never arrived, inspect the delivery log and bounce response. Labeling all three “DMARC failure” sends the investigation in the wrong direction.

Once a received message shows dmarc=fail, investigate authentication and alignment. If it shows dmarc=pass but lands in spam, record authentication and mailbox placement separately. Test receiving services commonly used by your customers, while recognizing that success there is not a guarantee for every destination.

Check forwarded mail at its final destination

Forwarding changes the connecting IP seen by the final receiver. SPF may fail, or pass for the forwarder's domain without aligning with the company From address. A mailing list that changes the subject or body may affect DKIM too. Passing direct delivery does not verify forwarded delivery. Authentication problems with forwarding and mailing lists ↗

Arrival alone is not proof of DMARC PASS; the receiver may have accepted the message through an exception. Work with the intermediary's administrator to understand a failure and preserve the legitimate business route, then retest. Avoid treating a blanket addition of forwarding servers to SPF as the solution.

Check whether a domain really sends no mail

Gaon also owns example.org for a new brand. It hosts a website but has no employee mailboxes. Before marking it “non-sending,” check website replies, administrator alerts, and any send-as addresses in existing mail accounts.

Look for use in From, MAIL FROM, and DKIM signatures. Domain administrators, mailbox administrators, website owners, and agencies may each know a different part of the picture. No employee accounts does not necessarily mean no outbound mail.

example.org          TXT  v=spf1 -all
_dmarc.example.org   TXT  v=DMARC1; p=reject

v=spf1 -all says no servers are authorized by SPF for this domain. p=reject requests rejection of messages using the domain in From that fail DMARC. When entering the host name, check whether your DNS provider automatically appends the domain. Microsoft also recommends rejection policies for non-sending domains. Microsoft's guidance for parked domains ↗

The np= DMARC tag applies to subdomains that do not exist in DNS. It does not mean “a domain that sends no mail,” and it does not replace the configuration above for an existing brand domain. DMARC subdomain policy tags ↗

A receive-only domain may still need its MX records; this work does not call for removing them. Also remember that a valid, aligned company DKIM signature can make DMARC pass even when SPF fails. Check whether retired services still have accounts or signing authority that allow them to send.

Every checked box should point to evidence

Gaon has fixed the newsletter, but Minsu's month-end billing service remains untested. A high overall pass rate will not help if customers miss every invoice. Jiyoon schedules the billing test and keeps enforcement on hold.

Use these eight items to revisit the gaps. Check an item when the inventory or an internal record supports the decision.

Items 1–4: Does the inventory connect to real tests?

A list of service names does not complete the first item. Business owners should confirm the list, and configuration owners should be identified. The second item needs domain values read from real mail. The third needs the tested process, recipient, time, and authentication results including alignment.

The fourth is easy to overlook when the past few days look good. A quarterly notice that has not run yet would naturally be absent from reports. Test it through the same production route or schedule verification of the actual send. An important route that has not been checked is still unverified.

Items 5–6: Are failures understood and policy scope checked?

RUA reports aggregate the source IPs and authentication results observed by receiving servers. Set rua= to a working reporting destination and assign someone to review the reports. Compare legitimate failures with business logs. After the newsletter fix, Jiyoon also checks reports covering new mail for the company-domain signature. Because the data is aggregated, it is not a one-to-one record of a particular test message. The scope of DMARC aggregate reports ↗

An unfamiliar IP is not automatically an attacker, and absence from RUA does not establish that a service is unused. Check the inventory and ask its owners. Complete item six only after reviewing policies for subdomains, delegated operations, and the evidence that a domain does not send mail.

Items 7–8: Who responds if the change causes trouble?

Save the previous DNS value and TTL, the domain and policy being changed, and the scheduled time. Define a concrete rollback condition, such as a reproduced authentication failure in legitimate invoices. Both the person who can restore DNS and the person who can verify business impact should be reachable. DNS caching means a rollback will not take effect everywhere immediately.

Gaon schedules enforcement after checking invoices and the remaining forwarding routes. Immediately after the change, it retests important processes; afterward, it reviews reports alongside bounces and support tickets. Judge observation coverage by actual monthly and quarterly sending cycles, as well as elapsed time. Checking sending cycles before enforcement ↗

The interactive checklist resets when the page is refreshed. Keep the evidence and remaining actions in the downloaded CSV or your internal change record. For choosing a policy and planning the transition, continue with the DMARC policy guide.

Update the inventory when a service starts or stops sending

When Gaon changes CRM a few months later, the same checks apply. Assign an owner and add the new route to the inventory. Complete company-domain authentication, exercise the real workflow, and inspect received headers before customer sending begins. Keep both routes listed during any overlap with the old service.

When retiring a service, first check for scheduled campaigns, automation rules, queued retries, and recurring invoices. Compare the date someone says it is no longer used with the actual last-send record. Test that the affected business processes have moved to the replacement service.

Then remove unused SPF authorizations, DKIM keys or CNAME delegations, service accounts, and API access. Another process may share an include or sending account, so do not remove it on name alone. Confirm what still depends on it and retest the remaining routes after the change.

A new service is only one reason to revisit the inventory. Changes to From addresses, domains, DKIM keys, and forwarding arrangements also deserve an entry. Leave enough evidence for the next person to explain how each route sends with the company's address. That record makes the next policy change much easier to judge.