Domains you inherit

An acquired domain arrives with mail you did not configure, senders nobody can list, and frequently a DMARC record that says something the previous owner did not intend either. The order of work is the same every time and starts with looking rather than changing.

The order

1. Publish p=none with rua, if there is no record.
   If there is one, leave the policy alone and add your rua
   alongside theirs.

2. Read a full month. Longer if the business is seasonal.

3. Classify: does this domain send at all?
   no  -> the non-sending set: -all, p=reject, null MX,
          wildcard DKIM revocation. Done.
   yes -> continue

4. Inventory the senders from the reports. Align them.

5. Enforce, against the same criteria as any other domain.

What not to do on day one

• Do not copy the parent organisation’s SPF record. It authorises platforms this domain has never used and spends its lookup budget on senders that may be divested again.
• Do not set p=reject because the domain is unfamiliar. Unfamiliar to you is not the same as inactive, and you will find out which from a customer.
• Do not remove the previous owner’s ruaimmediately. Add yours; take theirs out once you have your own history. Losing continuity of evidence during a transition is worse than a vendor seeing one more month of counts.
• Do not assume the record is doing what it says. An inherited p=reject with no rua has been enforcing blind, possibly for years, and nobody has seen what it rejects.

What you will probably find

Inherited domains skew heavily towards two states. Either the domain sends nothing and can go straight to the strict non-sending set after a fortnight of confirmation — which is most of them — or it sends from two or three platforms nobody at the acquiring company has heard of, at least one of which is still being paid for on someone’s card.