Rolling Out DMARC: p=none to Reject Without Mail Loss

The safe way to set up DMARC is to publish a monitoring-only record first (p=none), use the reports to find every system that sends mail as your domain, fix the ones that fail, and only then move to p=quarantine and p=reject in controlled steps. The DNS record itself is one line. The work is in knowing, before enforcement, where your newsletter, order emails and contact-form notifications actually come from. This applies to newsletter publishers, bloggers and online store owners who send email from their own domain.

What DMARC adds

SPF and DKIM each verify one thing. SPF checks whether the sending server is authorized for a domain, and DKIM checks a signature added to the message. Neither one tells the receiving server what to do when the check fails, and neither is required to match the domain a reader sees in the From line. DMARC adds both missing pieces. According to RFC 7489 (Opens in a new tab), a domain owner publishes its DMARC preferences as a DNS TXT record under a _dmarc subdomain, for example _dmarc.example.com.

Alignment is the idea to grasp first

A message passes DMARC when SPF or DKIM passes and the domain that passed lines up with the From domain. Google's Workspace instructions (Opens in a new tab) put it this way: a message passes DMARC if it passes SPF with alignment, or DKIM with alignment. One aligned pass is enough; both are not required.

RFC 7489 defines two alignment modes, relaxed and strict, and relaxed is the default for both SPF and DKIM. In relaxed mode the organizational domains must match, so a message signed by a subdomain can still align with the parent domain. In strict mode the fully qualified names must match exactly. The adkim and aspf tags set these modes. Google warns that strict alignment can cause messages from related subdomains to be rejected or sent to spam, so it is a deliberate choice, not a default to reach for.

The two jobs of a DMARC record

The record does two things. It states a policy, which is what you ask receivers to do with mail that fails. It also asks receivers to send you reports about mail they saw using your domain. For anyone starting out, the reports are the more valuable half. A policy cannot protect legitimate mail you do not know about, and reports are the only place those unknown senders show up. That is why the first stage of any rollout is observation, not enforcement.

Sender inventory and readiness

Publishing the record takes minutes. Making it safe takes preparation, and the preparation has an order that Google's Workspace page spells out: SPF and/or DKIM must be turned on for the domain before you use DMARC, and the page advises allowing 48 hours after setting them up before you set up DMARC. Skipping that step, the page warns, will probably lead to delivery issues.

Build a sender inventory

List every system that sends email using your domain in the From address. For a publisher or small shop, the list often includes the newsletter service, the store platform that sends order and shipping notices, the contact form on the website, a help desk tool, an invoicing tool, your own mailbox and any forwarding set up at the domain host. Google's guidance for third-party senders is to confirm with each provider that SPF and DKIM are configured correctly, to make sure the provider's envelope sender domain matches your domain, and to add the provider's sending IP addresses to your SPF record where needed.

Practical suggestion: keep the inventory in a simple table with one row per system. Columns: system name, what it sends, which domain it signs with, whether SPF or DKIM is aligned, and who owns the account. Any row where "aligned" is empty is a task for the next stage.

Decide where reports will land

Google recommends a dedicated group or mailbox for reports instead of a personal address, because large organizations can receive hundreds or even thousands of reports a day. The page says reports normally go to an address on the same domain as the record, and that a different domain requires an extra DNS record there. Even a small site benefits from the same habit: reports are machine-readable files, and a separate inbox keeps them out of your day-to-day mail.

Readiness checklist

1. SPF and/or DKIM have been active for the domain for at least 48 hours.
2. Every sender is listed, with an owner.
3. Third-party senders have been checked for alignment with your domain.
4. A non-personal report mailbox exists.
5. You have checked whether a DMARC record already exists at the domain host.
6. Someone is named to make DNS changes, and someone is named to approve them.

The first record, tag by tag

The first record is for observation. Google's instructions recommend setting the policy tag to none at the start and moving to quarantine or reject later. Under RFC 7489, p=none means the domain owner requests no specific action, and receivers should not alter normal handling of the message. No legitimate mail is lost because of DMARC at this stage, while reports begin to arrive.

What each tag does

A first record can be as short as the version, the policy and a report address. Extra tags add room for mistakes without adding insight at this stage.

Where the record goes

Create a TXT record whose host name is _dmarc.example.com, with your own domain in place of example.com. Google's page notes that some hosts append the domain automatically, so check the final record name for a doubled domain. After saving, verify the result with a free online DMARC checker, as the page suggests. If a DMARC record already exists, read the current reports before replacing anything, and keep one record per domain instead of adding a second.

Report addresses, Gmail and bulk sending

Sending reports to a different domain

If the report address is on a different domain than the one publishing the record, receivers will not simply trust it. Section 7.1 of RFC 7489 describes a check: the receiver queries a TXT record at a constructed name made of the policy domain, then _report, then _dmarc, then the report host. If no matching DMARC1 record is found there, the receiver must ignore that address. This is the usual reason a setup with an outside reporting service produces no reports. Using a mailbox on the same domain avoids the issue.

Gmail and bulk sending

Gmail's sender guidelines (Opens in a new tab) require SPF, DKIM and DMARC for senders above the bulk threshold, which the page tied to February 1, 2024, and it states that the DMARC enforcement policy can be set to none. The page words the threshold slightly differently in its heading and its body, so check the current page if your volume is near the limit. In practice that means a p=none record is not only a starting point; for some senders it is the documented minimum.

Reading reports

Once the record is live, reports arrive. RFC 7489 describes aggregate reports as daily or more frequent feedback from receivers, listing the policy they found, what they did with the mail, and SPF and DKIM results with alignment. They are summaries grouped by sending source, not copies of individual messages.

Three questions for every source

For each sending source in a report, ask whether it is on your inventory, whether it passes with an aligned SPF or DKIM result, and, if not, why. A known system that fails goes on the fix list. An unknown source that fails is either a forgotten legitimate system or someone else using your domain.

Forwarded mail and mailing lists

Not every failure is abuse. RFC 7489 section 9.1 notes that where message forwarding arrangements exist, domain owners requesting reports will also receive data about mail forwarded to domains they do not recognize. Section 3.1.1 adds that a message can carry a valid signature from any domain, including the domain of a mailing list, so a valid signature alone does not prove authenticity. RFC 7489 gives no detailed fix for forwarded mail in these sections. Knowing that such rows exist keeps you from blocking a legitimate service because of a false alarm.

Example: a travel newsletter with a small book shop

Example scenario: an independent travel newsletter with a small book shop

Example scenario: a writer publishes a travel newsletter through a newsletter service and sells signed books through a store platform, both on the same domain. After a week of p=none reports, three sources appear. The newsletter service passes with an aligned DKIM signature. The store platform sends order confirmations that pass SPF only for the platform's own domain, which does not align with the writer's domain. A third source is an IP address nobody recognizes. The writer enables domain authentication in the store platform so its mail is signed with the writer's domain, and notes the unknown IP address as unauthorized for now. At the next review, the store platform shows an aligned pass and the unknown source is unchanged. That is the signal that the policy can start moving.

The consent and subscription side of a newsletter is a separate matter from DMARC. For that, see the article on email consent and privacy-compliant newsletter subscriptions. DMARC only answers whether a message really came from the domain it claims.

Moving to quarantine and reject

RFC 7489 describes quarantine as the domain owner asking that failing mail be treated as suspicious, for example by placing it in a spam folder. Reject asks the receiver to refuse the message, and the RFC says rejection should occur during the SMTP transaction. Quarantine leaves the message recoverable for the recipient; reject stops delivery.

A rule based on conditions, not a number of days

Google's page gives no monitoring period for p=none. It says to update the policy as you learn how messages from your domain are authenticated, and it refers readers to a separate rollout page. Because no fixed waiting time is stated, the decision belongs to conditions.

Practical suggestion: treat each stage change as a gate with three outcomes.

For rare flows, a test message is often quicker than waiting for the next natural send. Any time you add a new sending tool, the inventory is incomplete again and the gate closes until that tool is aligned.

Using pct to move in steps

Google's page recommends the pct tag during rollout. It sets the percentage of failing mail the policy applies to, from 1 to 100, and you raise it over time until you reach 100. If pct is omitted, the policy applies to all messages. RFC 7489 states that pct must not be applied to the DMARC-generated reports themselves.

A sensible pattern is to start quarantine at a low percentage, watch the reports for a legitimate sender landing in spam, and raise the number only when none does. Once quarantine at 100 percent is quiet, repeat the same ladder for reject. Practical suggestion: no page requires this exact ladder, but the use of pct for rollout is what Google's page describes.

Subdomains, BIMI and the RFC note

Subdomains and BIMI

The sp tag applies only to subdomains of the queried domain, not to the domain itself, according to RFC 7489, and p covers subdomains when sp is absent. If a newsletter service or another team sends from a subdomain, read its reports before you raise p. Google also notes that if you use BIMI, p must be quarantine or reject and pct must be 100, so a brand logo in the inbox is not available on p=none.

A note on the RFC itself

The RFC Editor page for RFC 7489 marks it as obsolete and points to RFC 9989, RFC 9990 and RFC 9991 as replacements. The tags and policy values described below match RFC 7489 and the Google Workspace instructions. Before you change anything in production, check the current documentation of your DNS host and your email service, because tag support and limits can change.

Rollback and change log

If a legitimate message goes missing after you tighten the policy, deleting the record is the wrong response, because it also removes reporting. Step back one stage instead: reject to quarantine, quarantine to none, or lower pct. It is a single edit to the p or pct value, and it takes effect as DNS caches expire.

A rollback routine

• Identify the affected sender and recipient, and find the matching row in the latest report if you can.
• Move the policy back one stage, or reduce pct if the problem is narrow.
• Fix the sender: enable DKIM on your own domain, or add the provider to SPF.
• Confirm the fix with a test message and a new report row.
• Re-run the gate table before tightening again.

Keep a change log

Write down the date, the old and new p and pct values, the reason and the approver for every change. When two people can edit DNS, this log prevents overlapping edits, and it answers the question "why is it at this percentage" faster than digging through report archives.

Outside flows and after enforcement

Flows outside your own tools

Aggregate reports only show what receivers choose to send, and no document promises that every receiver reports. Partners may send on your behalf: a sponsor sending a notice with your domain in the From line, a guest author using a personal tool, or a partner adding a reminder to your list. If you work with sponsors, the article on sponsored content disclosure covers the editorial side. For email, ask partners directly whether they send as your domain. Your media kit also lists a contact address, so make sure replies to that address come from an aligned system.

After enforcement

Reaching reject is not the end. Review reports on a regular schedule, update the inventory when tools change, and confirm the DMARC record survives any DNS provider change. If you track email-driven traffic, pair UTM tagging with UTM, GA4 and Search Console reporting; DMARC reports are a separate, deliverability-side signal.

A monthly review can use four questions. Is there a new sender? Has the share of failing aligned mail grown? Did a provider rotate its DKIM key? Is anyone still reading the report mailbox? If the last answer is no, the record may be strict but nobody is watching it.

Order of operations and mistakes

For a one-person newsletter or a small store, the following order keeps the rollout manageable. It gives conditions, not durations, because Google's page gives no fixed period.

1. Write the inventory.
2. Check SPF and DKIM for each sender and fix alignment gaps that you already know about.
3. Publish p=none with a report address.
4. Compare the first reports with the inventory and fix every known failing sender.
5. Explain every unknown source, even if the explanation is simply "unauthorized".
6. Start p=quarantine with a low pct; watch for legitimate mail in spam.
7. Raise pct step by step to 100.
8. Move to reject using the same ladder, with a written rollback.
9. Schedule recurring report review.

Mistakes to avoid

• Tightening policy before SPF and DKIM are in place; Google's page warns about delivery issues.
• Pointing reports at a personal inbox that fills up.
• Forgetting the extra DNS record when the report address sits on another domain.
• Not updating the inventory when a new newsletter, form or help desk tool arrives.
• Choosing strict alignment without a reason, since Google notes it can cause related-subdomain mail to be rejected or sent to spam.
• Raising pct once and then ignoring the reports.

Each item above follows from a warning or definition in RFC 7489 or Google's page. None of them guarantees an outcome. The reports are what let you see a mistake early, which is the main value DMARC gives a small sender.

Frequently Asked Questions

Where does a DMARC record go, and what does it look like?

A DMARC record is a TXT record in your domain's DNS with the host name _dmarc.example.com, using your own domain in place of example.com. The shortest useful version contains the DMARC1 version tag, a p policy and a rua tag with a mailto address for reports. Some DNS hosts append the domain automatically, so check the saved name and confirm it with a DMARC checker.

Do I need both SPF and DKIM before DMARC?

Google's Workspace page says SPF and/or DKIM must be on before you use DMARC, and that a message passes DMARC with an aligned pass from either one. Setting up both gives you more room for an aligned result. The page also advises waiting 48 hours after SPF or DKIM setup before enabling DMARC.

How long should I stay on p=none?

Google's page gives no fixed period. It says to update the policy as you learn how messages from your domain are authenticated. Use conditions instead of days: all legitimate senders show an aligned pass, unknown sources are explained, and your regular sending flows appear in the reports.

Can I jump straight to p=reject?

You can publish it, but any legitimate sender without aligned authentication will have its mail rejected. Google's page recommends the pct tag during rollout, raising the percentage until it reaches 100. Starting with p=none and reading reports first, then quarantine, then reject reduces that risk.

Why am I not receiving DMARC reports?

Under RFC 7489, receivers must not generate aggregate reports if the record has no rua tag. If the report address is on a different domain, that domain needs its own DMARC verification record, or the receiver ignores the address. Reports can arrive daily or more often, but no document promises that every receiver sends them.

My newsletter service fails DMARC. What now?

Enable DKIM signing with your own domain in the service settings, and check that the provider's envelope sender domain matches yours. If that is not possible, add the provider's sending IP addresses to your SPF record. Confirm the change with a new report row before tightening the policy.

Conclusion

A DMARC rollout stays safe when the order is respected: SPF and DKIM first, then p=none with a report address, then fixes driven by the reports, and finally quarantine and reject in steps once the conditions are met. At every stage, write down the condition for the next step, keep a rollback ready and make sure a named person reads the report mailbox. Limits, tag support and the RFC status can change, so check current documentation before you edit DNS.

Once your own mail is authenticated, you may want more visibility for your publication. At Akua Adforce, you can browse guest post listings; scope and terms are on the product page.