Your mail works until the tenth sender

The call usually starts with one example. An invoice did not arrive, the customer swears it was never sent, and somebody found it in a junk folder a week later. Then a second example surfaces: the payroll notification nobody got. Then somebody mentions that the new marketing platform was connected about a month ago, which is roughly when this started, and everyone agrees that is probably a coincidence.

It is usually not a coincidence. There is a specific, countable limit in the standard that decides whether your domain's mail is authorized, most organizations pass it without any signal that they have, and the thing that pushes them over is nearly always the most recent tool somebody connected.

What the three records each claim¶

Three DNS records carry the whole of mail authentication, and they answer different questions. Keeping them straight is most of the work, because the common failure is a company that has all three and believes that is the same as being protected.

The limit, and why it is spent faster than you think¶

SPF is a list of terms, and some of those terms make the receiver perform a DNS lookup to resolve them. RFC 7208 (opens in a new tab) is unambiguous about how many are allowed: implementations must limit the total number of those terms to ten during evaluation, and must return a permanent error if that limit is exceeded. Six kinds of term count against it, and the one that matters commercially is include, because that is the term every vendor hands you when they ask you to authorize them.

The arithmetic is worse than the count in your own record suggests. A vendor's include is not one lookup. It resolves to that vendor's own record, which frequently contains includes of its own, and each of those is charged to your budget rather than theirs. A record with five entries in it can be spending nine or eleven, and there is nothing in the text of your own record that says so. You cannot audit this by reading it. You have to resolve it.

One term costs nothing, and it is the escape route people reach for: an ip4 or ip6 term is an address, not a name, so it causes no lookup and is not charged. Replacing a vendor's include with the addresses it currently resolves to is called flattening, and it does fix the count. It also quietly converts an arithmetic problem into a maintenance problem, because the vendor will change those addresses on their schedule and will not tell you. Flatten if you must, and then own the consequence: something has to re-resolve those records on a cadence, and if that something is a person remembering, it is nothing.

Alignment is the part that surprises people¶

The question a reader asks at this point is reasonable: the mail passed SPF, so why did it fail anyway? Because SPF authenticates the envelope, the address the sending server gives during the SMTP conversation, and a recipient never sees that. What they see is the From header, and those two are routinely different, which is exactly how a vendor sends on your behalf.

That gap is the entire reason DMARC exists. RFC 9989 (opens in a new tab) requires the From domain to align with a domain that SPF or DKIM actually authenticated, in either a relaxed mode that accepts the same organizational domain or a strict mode that demands an identical one. A message can therefore pass SPF cleanly and fail DMARC, because what passed was a domain the reader will never be shown.

Two things about that document are worth knowing before you act on anything you read elsewhere about DMARC. It was published in May 2026, it obsoletes the RFC 7489 that almost every guide still cites, and it moved DMARC from informational to the standards track for the first time. It also removed the pct tag, the percentage lever that a great deal of published advice still recommends you ramp a policy with. Advice built on the older document is not merely dated; part of it describes a mechanism the current standard no longer defines.

What p=none is honestly saying¶

A DMARC record whose policy is none asks receivers to take no specific action. In the current standard's own framing it is monitoring mode: you receive aggregate reports and use them to fix your authentication before you ask anyone to enforce anything. It is the correct place to start and it is not a control.

The pattern we find is a domain that has been at p=none since someone set it up, with reports arriving at a mailbox nobody has opened, described in a customer security questionnaire as DMARC enabled. That answer is true and it is not the answer the questionnaire was asking for. If nothing has moved off none in two years, the honest reading is that the monitoring phase never ended because nobody owned the thing it was supposed to inform.

The order to do this in¶

1. 1.Resolve your own SPF record rather than reading it, and count what the includes actually expand to. If you are at or over ten, you have already found the reason something stopped arriving.
2. 2.List the senders you find and match each one to a tool somebody is still using. Authorized senders outlive the projects that introduced them, and the cheapest way under the limit is nearly always deleting two you no longer use.
3. 3.Confirm DKIM signing is on for every sender you kept, not just the mail platform. This is the record that survives forwarding, and it is the one that keeps working when SPF has been thrown away.
4. 4.Read the DMARC aggregate reports you are already receiving before changing the policy. The purpose of monitoring is to find the legitimate sender you forgot, so that enforcement does not delete your own invoices.
5. 5.Then move the policy, and put a name against who reads the reports afterwards. A policy that tightened once and is watched by nobody is the same failure as p=none, arriving later and with more consequences.

None of this is difficult and none of it is expensive. It is unowned, which is a different problem, and it is why it is usually discovered by a customer telling you they never got the invoice.