Why a client portfolio does not move to reject in one step
A single domain can be run by eye. A portfolio cannot: each client has tools the agency does not always know in full. The trigger is often external. Since February 1, 2024, Gmail asks for SPF, DKIM and DMARC from senders of more than 5,000 messages a day, Yahoo sets a similar requirement, and Outlook.com applies comparable rules to high volumes. At both Gmail and Yahoo the floor is a published DMARC record with p=none: these requirements do not ask you to move to reject. What pushes you there is spoofing: a client whose name is used to send fake invoices, or whose real invoices land in spam.
The risk runs both ways. A reject published too early refuses legitimate mail, and it is you the client will call. The DMARCbis standard (RFC 9989, published in May 2026, replacing RFC 7489) recommends a progression: p=none for at least a month, then p=quarantine for a similar period, comparing the results. The three policies are defined in our guide on DMARC p=quarantine, and what the new standard changes is in DMARCbis. Here we cover the work specific to a portfolio: inventory, calendar, communication.
Publish p=none with a report address, client by client
For each domain, the first write is a TXT record at _dmarc.your-domain.com: v=DMARC1; p=none; rua=mailto:[email protected]. p=none changes nothing about delivery; it asks receivers to send you aggregate reports, one compressed XML file per receiver per day. If you centralise the reports of all your clients on an agency address, for example [email protected], the domain of that address differs from the client's, and the receiver has to check that you agreed. The reporting standard (RFC 9990) provides a TXT record for that at client-example.com._report._dmarc.agency-example.com, containing at least v=DMARC1. Without it, the receiver ignores the address and you receive nothing. A wildcard record *._report._dmarc.agency-example.com authorises all domains at once.
Centralising gives an overview but mixes clients in the same mailbox. One address per client, or sorting by the domain in the header_from field, avoids reading one client's reports while looking for another's.
Reading a report row: the fields that matter
- source_ip — the address that delivered the message; a reverse lookup or the
Receivedheader of a test message reveals the provider behind it. - count — the number of messages in the row; it ranks the work, high volumes first.
- disposition — what the receiver applied:
none,quarantineorreject. Under p=none everything isnone; the column becomes useful at the next stages. - dkim and spf — the result evaluated for DMARC, so with alignment. A valid but unaligned DKIM shows up as
fail. - header_from — the domain visible in the From field, the one DMARC protects.
- envelope_from — the envelope domain (Return-Path) that SPF aligns on; a provider domain here explains an SPF failure.
- Rows with no owner — an unknown IP with a large
countis either a forgotten client tool or spoofing: ask the client before concluding.
Alignment: why a tool that passes SPF and DKIM still fails
DMARC requires SPF or DKIM to be aligned with the domain in the From field. SPF aligns on the envelope domain (Return-Path), not on the From; DKIM aligns on the d= domain of the signature. A newsletter service that sends with its own Return-Path and signs with its own d= passes SPF and DKIM on its side and fails DMARC for your client, because neither domain is the From domain. By default alignment is relaxed (aspf and adkim default to r): a subdomain of the same organizational domain is enough. In strict mode (s), the domain must be identical. Keep relaxed unless you have a specific need.
The fix is almost always the same: have the tool sign with the client's domain, by publishing the DKIM CNAME records the provider gives you. One alignment is enough, so the provider's own Return-Path is harmless if DKIM is aligned. When you add an SPF include:, count: RFC 7208 limits evaluation to 10 DNS lookups, and beyond that the result is a permanent error (permerror).
Matrix of third-party senders to align
Scroll the table
| Sender | What the provider supplies | What to publish for the client |
|---|---|---|
| Newsletter, bulk e-mailing | DKIM key and sending domain | DKIM CNAME; a dedicated sending subdomain is recommended |
| CRM, marketing automation | DKIM signature in the client's name | DKIM CNAME; SPF `include:` only if the provider requires it |
| Invoicing, online payment | Sending from its own servers | Provider's DKIM CNAME; otherwise, send from a dedicated sending subdomain |
| Helpdesk, tickets | Sending address to validate | DKIM CNAME and validation of the sending domain |
| Main mailbox provider | Documented SPF and DKIM records | SPF `include:` and DKIM key of the mail provider |
| Website (forms, shop) | Sending by the site server or a relay | Authenticated SMTP with the client's domain |
The standard calendar for one domain, stage by stage
Week 0: publish p=none
List the domain, then publish
v=DMARC1; p=none; rua=mailto:[email protected]. Check withdig +short TXT _dmarc.your-domain.com. The first reports arrive within 24 to 48 hours.Weeks 1 to 4: observe and review weekly
The standard recommends at least a month of p=none. Each week, group the rows by provider and fill in the tracking table: sender, volume, aligned or not, legitimate or not.
Fix every legitimate unaligned sender
Publish the provider's DKIM CNAMEs, send a test message to a Gmail mailbox and check for
dmarc=passin the header. An abandoned tool is not fixed: it is noted as to be refused.Weeks 5 to 8: set quarantine
Replace the record with
v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:[email protected], for a period comparable to the previous phase. Failures go to spam instead of being refused: thedispositioncolumn of the reports shows what would be lost.Do not rely on pct as a safety net
RFC 9989 removed the
pcttag, judged unreliable outside the values 0 and 100, and addedt=yto ask that the policy not be applied. Support fortby Gmail, Yahoo and Microsoft is not documented to date: do not build a stage on it.Weeks 9 to 12: move to reject
If quarantine revealed no legitimate sender failing, publish
v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]. Warn the client the day before, and watch the reports daily for a week.Keep the review going after reject
Every new tool the client adopts becomes a sender to align. Put it in the support agreement: any new sending tool is declared before it goes live, then added to the tracking table.
Subdomains: sp, np and a dedicated sending subdomain
A subdomain with no record of its own inherits the policy of the organizational domain. The sp tag sets the policy for existing subdomains, np for non-existent ones; without np it falls back to sp, then to p (RFC 9989, tag definitions). On a record published in a subdomain, sp is ignored. np is recent: a receiver that does not know it ignores it and applies sp.
The typical use is fake subdomains. A fraudster writing from invoice.client-example.com, a subdomain that does not exist, is stopped by np=reject with no risk to real mail, since nothing legitimate is sent from it. For third-party tools, prefer a dedicated sending subdomain, for example news.your-domain.com: the tool is aligned there in relaxed mode, its keys and SPF do not clutter the main domain, and you can tighten the main domain without waiting for that flow. A _dmarc record of its own on the subdomain even allows a separate calendar.
The flows that break: mailing lists, forwarding, aliases
Some legitimate messages fail DMARC by construction, because an intermediary relays them while keeping the original From. A list that adds a footer invalidates the DKIM signature; a redirect invalidates SPF, because the IP delivering the message is no longer the one the domain authorises. The standard says so plainly (RFC 9989, interoperability section): p=reject can be incompatible with these indirect flows, and domains whose users post to mailing lists should not publish it. ARC (RFC 8617) is cited as an attempted fix, but no method has become widely used. The standard also tells receivers not to reject solely on the basis of p=reject and, absent other analysis, to treat the message as with quarantine: reject is therefore not always applied to the letter, which is no reason to ignore it.
These cases can be spotted before switching. Look in the reports for rows whose IP belongs to a list relay or a forwarding service, where spf and dkim fail and the count is low but regular. Then ask the client: alumni aliases, an association, an address that redirects to a personal mailbox. For a domain whose addresses are used to post to public lists, stay on quarantine: it is a defensible choice, to be recorded in the tracking table.
Prove the result before warning the client
Send a test message from each tool to a Gmail mailbox, open "Show original" and look for the Authentication-Results line: it should contain dmarc=pass header.from=your-domain.com. After the move to reject, an SMTP refusal carries a 5.7.x code and a receiver-specific text. Keep a capture of the refusal message and the matching rua report line: they show the client that the faulty tool had been identified and flagged, not discovered afterwards.
The message to send the client before each stage
The client does not need to understand DMARC, but must know what changes, when, and what is expected of them. Four sentences are enough.
Subject: protecting your domain against e-mail spoofing
Hello, we are strengthening the protection of your domain your-domain.com against spoofing of your addresses. From [date], messages that claim to come from your domain without being authenticated will be placed in spam, then refused from [next date]. To avoid losing any legitimate mail, could you list for us before [date] every tool that sends e-mail in your name (newsletter, invoicing, CRM, support, website)? A risk remains for mailing lists and address redirections: tell us if you use any.
Keep the reply in the client file: it records who declared which tools, and when.
Portfolio tracking table
Scroll the table
| Domain | Current policy and next stage | Validated senders and client status |
|---|---|---|
| client-a-example.com | p=none, quarantine at W+4 | Mailbox and newsletter validated; invoicing to confirm |
| client-b-example.com | p=quarantine, reject at W+8 | Four senders aligned; no legitimate failure in reports |
| client-c-example.com | p=reject, weekly review | CRM added by the client, DKIM to publish |
| client-d-example.com | p=quarantine, no reject planned | Addresses used on lists; choice recorded |
| client-e-example.com | p=none, no stage planned | Client not answering; follow-up to schedule |
Troubleshooting: five common failures across a portfolio
On a portfolio, the same five incidents keep coming back. Here they are with their cause and the action that clears them.
Symptoms and remedies
- No report arrives — the
ruaaddress is on a different domain from the client's and the_report._dmarcauthorisation record is missing: publish it, otherwise the receiver ignores the address. - A tool passes SPF and DKIM but fails DMARC — its Return-Path and
d=are the provider's: publish the DKIM CNAMEs in the client's name to align DKIM. - SPF in permerror — more than 10 DNS lookups (RFC 7208): remove the
include:entries of abandoned tools or move the tool to a dedicated sending subdomain. - A new tool is refused after reject — the client adopted it without telling you: go back to quarantine while you align the tool, rather than loosening alignment.
- The client does not answer — stay on p=none or quarantine, record the follow-up and its date in the tracking table; a reject published without an inventory puts your responsibility at stake.
The official documentation
RFC 9989, DMARCbis (tags, subdomains, interoperability): https://www.rfc-editor.org/rfc/rfc9989.html
RFC 9990, DMARC aggregate reporting (external destinations): https://www.rfc-editor.org/rfc/rfc9990.html
RFC 7208, SPF (10 DNS lookup limit): https://www.rfc-editor.org/rfc/rfc7208.html
RFC 8617, ARC: https://www.rfc-editor.org/rfc/rfc8617.html
Gmail bulk sender requirements: https://support.google.com/a/answer/81126
Yahoo sender best practices: https://senders.yahooinc.com/best-practices/
Outlook requirements for high-volume senders: https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730
