SPF, DKIM and DMARC, explained

SPF is checked against the envelope sender, not the visible From address, which is why it alone cannot stop a convincing forgery. It also breaks when mail is forwarded, because the forwarding server is not on your list. Two live SPF records at one name is a hard failure rather than a merge: receivers treat the result as permanently erroneous and apply neither. The record also has a hard limit of ten DNS lookups, and stacking several providers' include statements quietly exceeds it.

This is the commonest way a correct-looking SPF record stops working, and it happens by accumulation rather than by mistake. Every include, a, mx, ptr and redirect costs one lookup, and each included record's own includes count too, so adding a fourth sending platform can push a record over a limit it was comfortably inside last year. Nothing warns you: mail keeps sending, receivers keep evaluating, and the verdict quietly becomes an error that DMARC then treats as a fail. The fixes are to drop providers you no longer send through, replace an include with the ip4 and ip6 ranges it resolves to where the provider publishes stable ones, or put the record through a flattening service and accept the maintenance that comes with it.

DKIM survives forwarding, which is exactly where SPF fails, so the two are complements rather than alternatives. Each sending platform publishes its own key under its own selector, so a domain sending through several services carries several DKIM records. The usual failure is silent: a key rotated at the provider and never updated in the zone leaves every message failing verification while sending continues normally.

The selector is why DKIM cannot be checked the way SPF and DMARC can: those records sit at a name you can guess, and a DKIM key does not. You either read the selector out of a message header or you already know what your provider uses. It also explains how one domain signs for several platforms at once, since each provider publishes its own key under its own selector and they never collide. Rotating a key means publishing a new selector, switching the sending platform to it, and leaving the old record in place until no mail signed with the old key is still in flight.

DMARC is what turns the other two records into enforcement, and it is the one that requires the visible From address to match, which is what actually stops look-alike forgeries. Its policy runs from none, which only reports, through quarantine to reject. Publishing none is a real and useful first step: you see who is sending as you before you risk blocking anything. Two DMARC records at _dmarc is a total failure, not a conflict to be resolved, because receivers are required to apply no policy at all when they find more than one.

There are three answers and they are a ladder, not a preference. p=none enforces nothing and only asks for reports, which is where every domain should start, because the reports show you the sending sources you had forgotten. p=quarantine asks receivers to file failures as spam. p=reject asks them to refuse the message outright, and is the only value that actually stops someone sending as you. The reason most domains stall at none is that moving up without reading the reports first blocks your own mail: a marketing platform nobody told you about fails alignment and disappears. Note that a policy applies to alignment failures, so a message can pass SPF at the envelope level and still be rejected because the visible From address belongs to your domain and the passing check did not.