Use a separate subdomain for marketing email than for the mail your product depends on. This is the cheapest deliverability decision available, and it is nearly impossible to make retroactively.
Receivers score senders, and the domain is one of the strongest signals. Complaints, spam-folder placements and bounces accumulate against the domain that sent them.
Your two kinds of mail behave completely differently:
Share one domain and those complaint rates average together. A campaign that draws an ordinary number of complaints drags down the reputation that your password resets depend on.
The failure is not dramatic. It shows up as reset emails arriving in spam, and support tickets from people who cannot get back into their accounts.
Two subdomains of the domain you already own:
mail.yourcompany.com password resets, receipts, alerts
news.yourcompany.com newsletters, announcements
Each gets its own DKIM key and its own SPF record. Reputation is then tracked separately, and a bad campaign is contained to the subdomain that sent it.
Send from subdomains rather than the bare domain, too. Keeping yourcompany.com out of bulk sending protects it, which matters because it is also the domain your invoices and your staff's mail come from.
Moving marketing mail to a new subdomain after a year means starting from zero reputation for that stream, exactly when you have volume. New domains get throttled, so the first campaigns from the new subdomain deliver worse than the ones you were trying to fix.
Splitting on day one costs one extra DNS setup.
Separate domains only help if the mail is genuinely separated. Sending a "product update" newsletter from your transactional subdomain because it is "not really marketing" puts you back where you started.
The test is not what you call it. It is whether a recipient might reasonably report it as spam. If yes, it belongs on the marketing subdomain.
If your domain publishes two DMARC records, it has no DMARC policy. Not a merged one, not the first one, not the stricter one. None.
RFC 7489 is explicit: a receiver that finds more than one DMARC record for a domain treats the result as if no record were published.
A domain with no DMARC record is honestly unprotected, and anyone checking can see it. A domain with two looks protected. It passes a glance at your DNS. Someone on your team ticked it off a launch checklist. And you get no aggregate reports, so the mechanism that would have told you something is wrong is the exact thing that stopped working.
Almost always the same way: two vendors, each with correct instructions.
Your email provider tells you to add a DMARC record. Later a marketing platform, a helpdesk or a website builder tells you the same thing. Both instructions are right on their own. Neither tells you to check whether one already exists, because from where they stand there is no way to know.
Then it sits there for months.
dig +short TXT _dmarc.yourcompany.com
You want exactly one line beginning v=DMARC1. Two lines is the problem. Zero means you have no DMARC, which is a different conversation.
Note that DMARC lives on the organisational domain. If you send from mail.yourcompany.com, the record still belongs at _dmarc.yourcompany.com.
Merge into one record. DMARC takes multiple reporting addresses, comma-separated:
v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com,mailto:reports@vendor.example
Delete the other record entirely — do not leave it "just in case". Two records is the failure.
If the two disagreed on policy, take the weaker one and tighten later after reading reports. Going from an accidental no-policy straight to p=reject will find every system quietly sending as your domain, all at once, in production.
Most explanations of these three start with what they stand for. That is the least useful part. What matters is which one is failing when your mail lands in spam, and they fail in different ways.
SPF is a DNS record listing the servers allowed to send for your domain. A receiver checks the connecting server against that list.
How it silently fails: SPF checks the domain in the envelope sender — the MAIL FROM — not the From: header your recipient sees. If you send through a provider that uses its own bounce domain, SPF passes for the provider's domain, and your domain has authenticated nothing. Everything looks fine in a header dump. DMARC still fails, because SPF did not align.
This is why a proper setup gives you a bounce subdomain of your own, like bounce.mail.yourcompany.com, with its own SPF record. Then SPF passes and aligns.
The other one that catches people: SPF allows ten DNS lookups. Each include: counts, and each include: inside those counts too. Add a fourth or fifth vendor and you quietly cross the limit; receivers then treat SPF as permanently failing. Nothing tells you.
DKIM signs the message with a private key. The matching public key sits in your DNS, and the receiver verifies the signature.
How it silently fails: a 2048-bit key does not fit in one DNS character-string, so it is always published split across several. Tools that read only the first chunk see a truncated key and report a mismatch, even though the record is correct. If you are debugging a DKIM failure and the key "looks wrong", check that whatever is reading it joins the parts.
The second failure mode is anything that modifies the message in flight. A mailing list that appends a footer breaks the signature it was signed with. So does a tracking system that rewrites links after signing rather than before.
DMARC ties SPF and DKIM to the From: header your recipient actually reads, and tells receivers what to do when neither aligns: nothing (p=none), quarantine, or reject.
How it silently fails: publishing two DMARC records. It happens when two vendors each tell you to add one. Per RFC 7489, a receiver that finds more than one record treats the domain as having no DMARC policy at all. Both records are ignored. The domain looks configured, reports nothing, and enforces nothing.
If you use more than one sending service, you get one record with both reporting addresses:
v=DMARC1; p=none; rua=mailto:you@yourcompany.com,mailto:reports@vendor.example
p=none, and read the reports for a couple of weeks before tightening.Going straight to p=reject is how people discover, in production, the one system that was sending as their domain and that nobody remembered.