Third-Party Senders and SPF Sprawl

A real client domain rarely sends mail from one place. CRM, helpdesk, marketing platform, payroll, calendar invites, a billing system – each one may be sending as the client's domain, and each one is a dependency your rollout plan has to account for before tightening enforcement.

Two ways to authorize a sender – they aren't equal

• SPF include – adds that vendor's servers to the domain's SPF record. Counts against the 10-DNS-lookup limit covered in Course 1 – every additional vendor include (often nested several includes deep on its own) pushes you closer to permerror.
• DKIM alignment – the vendor signs outgoing mail with a key aligned to the client's domain instead. No SPF lookup cost at all, and it scales to far more vendors without ever hitting a hard limit.

For an MSP managing enforcement across a real vendor list, preferring DKIM alignment over piling on SPF includes is the difference between a rollout that scales and one that silently breaks at vendor number six.

The forwarding problem

A mailing list, or a legitimate internal forwarder, relays mail without SPF surviving the hop – the envelope sender changes at each relay, breaking SPF alignment even though nothing malicious happened. This is exactly why DMARC only requires either SPF or DKIM to align, not both: a forwarded message can still pass DMARC on DKIM alone, if the original signature survives the forward (which SPF never does). For real forwarding-heavy environments, ARC (Authenticated Received Chain) exists specifically to preserve authentication results across hops – worth knowing the name exists even if it's a deeper topic than this course covers.

The practical MSP move

Audit every legitimate sending vendor a client actually uses before tightening policy, not after discovering the gap from a support ticket. Use ActiScan's raw SPF checker to see the real lookup count of a proposed record before publishing it – catching a permerror-risking record on paper is a lot cheaper than catching it in production.