Abstract representation of email security configuration with network nodes, shields, and documents on a modern desk.

A Step-by-Step Guide to Configuring Spf, Dkim, and Dmarc for Small Agencies with Multiple Domains

If your agency uses more than one domain, email security can get messy fast. One domain may send client email through Microsoft 365, another may send invoices through a billing platform, and a third may be used for marketing or support. When those sending systems are not documented and aligned, you can end up with spoofing risk, confusing DNS records, and avoidable deliverability problems.

SPF, DKIM, and DMARC work together to help receiving mail systems decide whether a message is really allowed to come from your domain. Standards referenced by NIST and the relevant RFCs describe SPF as a way to authorize sending servers, DKIM as a way to sign messages, and DMARC as the policy layer that ties those checks to the visible sender domain.

For small agencies, this matters for everyday operations and for broader small business cybersecurity readiness. Email is often the path for invoice fraud, impersonation, and account compromise. It can also come up during a cyber insurance application checklist or cyber insurance renewal checklist, especially when insurers ask about business email security and MFA requirements for cyber insurance.

This guide walks through a practical setup process for multiple domains. It focuses on what to inventory, what to publish in DNS, how to avoid common mistakes, and how to monitor results without assuming you have an internal IT team.

Understanding SPF: Preventing Unauthorized Email Sending

SPF tells the internet which mail servers are allowed to send email for your domain. You publish that authorization as a DNS TXT record. When a receiving server gets a message, it can check whether the sending server is on your approved list.

That sounds simple, but multi-domain agencies often run into two problems: they forget about a sending service, or they create conflicting SPF records. Both can cause issues. An incomplete record may cause legitimate email to fail authentication. Multiple SPF records on the same domain can also break validation.

A practical way to start is to build one inventory for each domain.

  1. List every domain and subdomain that sends email.
  2. List every platform that sends on behalf of each domain.
  3. Separate human email from system email, such as invoicing, forms, newsletters, and support tools.
  4. Confirm whether each service provides SPF include instructions.
  5. Remove old services that no longer send mail.

For SPF record setup, keep the goal narrow: one valid SPF record per sending domain that includes all authorized senders. Implementation guidance commonly stresses that SPF should be complete but not cluttered.

Here is a simple planning table you can use before editing DNS.

Domain Sends employee email? Sends system email? Services to include SPF updated?
example.com Yes Yes Microsoft 365, billing tool No
exampleagency.net No Yes newsletter platform No
clientmail.example Yes No Google Workspace No

A few practical rules help avoid trouble.

  • Keep only one SPF TXT record per domain.
  • Add only services that truly send mail for that domain.
  • Review SPF whenever you add or remove an email tool.
  • Check whether the visible From domain matches the domain you intended to protect.

SPF becomes more useful when it aligns with DMARC. On its own, SPF checks the sending path. With DMARC, the receiving system can also compare that result with the domain the recipient sees in the From address. That alignment step is important when you want a more consistent anti-spoofing setup across multiple domains.

Setting Up DKIM: Adding Digital Signatures to Emails

DKIM adds a digital signature to outgoing messages. The sending system signs the email with a private key, and the receiving system checks that signature against a public key published in your DNS. If the signature verifies, the message is more trustworthy because the receiving side can confirm it was signed by an authorized system for that domain.

For agencies with multiple domains, the main point is this: each domain and each sending provider may need its own DKIM setup. That is where selectors come in. A selector is a label that tells the receiving server which public key to look up. This allows more than one DKIM configuration to exist without conflict.

Use this sequence for DKIM key generation and setup.

  1. For each domain, list every approved sending provider.
  2. In each provider, enable DKIM or request DKIM setup instructions.
  3. Generate or obtain the DKIM key pair according to the provider's process.
  4. Note the selector name for that provider and domain.
  5. Publish the public key in DNS as the required TXT or CNAME record.
  6. Send a test message and confirm the DKIM signature passes.
  7. Document which selector belongs to which provider.

Many implementation guides recommend using unique selectors for each domain-provider combination. That reduces confusion and makes future changes easier, especially if you rotate keys or retire a service.

This is a simple documentation format that works well for small teams.

Domain Provider Selector DNS added? Test passed? Notes
example.com Microsoft 365 selector1 Yes Yes Main staff email
example.com billing tool bill2024 Yes Pending Invoice messages
exampleagency.net newsletter platform news1 Yes Yes Marketing only

A few mistakes are common.

  • Reusing one selector label without tracking which service it belongs to.
  • Forgetting that a second provider also needs DKIM for the same domain.
  • Publishing the DNS record but not enabling signing inside the email service.
  • Leaving old selectors in place without knowing whether they are still active.

DKIM is especially helpful in a multi-domain setup because it can authenticate messages even when the sending path is more complex. But it still needs alignment with DMARC to support a stronger policy. Think of DKIM as one verified signal, not a complete email security program by itself.

Configuring DMARC: Defining Email Handling Policies

DMARC builds on SPF and DKIM. It tells receiving servers what to do when a message fails authentication checks, and it can send reports back to the domain owner. This is the part that helps you move from basic setup to active oversight.

A DMARC record is published in DNS. It usually starts with a policy value that tells receiving servers how to handle failures.

  • p=none means monitor only.
  • p=quarantine means treat failing mail as suspicious.
  • p=reject means do not accept failing mail.

For small agencies, the safest rollout is usually staged. Start with monitoring, review reports, fix alignment issues, and only then consider a stricter policy. That approach is more practical than jumping straight to reject and accidentally blocking legitimate mail from one of your own tools.

Use this implementation sequence.

  1. Publish a DMARC record with a reporting address.
  2. Start with a monitoring policy.
  3. Review aggregate reports to see which systems are sending mail for each domain.
  4. Fix SPF or DKIM gaps for legitimate services.
  5. Confirm alignment between the visible From domain and your authentication setup.
  6. Move to a stricter policy only after repeated clean testing.

DMARC reporting is one of the most useful parts of the setup. Reports can reveal unknown senders, stale tools, forwarding issues, and spoofing attempts. Many businesses use a report analysis service because raw XML reports are not easy to read.

Here is a simple policy progression table.

Stage DMARC policy When to use it Main goal
1 none Initial rollout See what is happening
2 quarantine After fixing known issues Reduce suspicious mail acceptance
3 reject After stable alignment Block failing unauthenticated mail more aggressively

DMARC also matters for business process risk. If your agency sends proposals, invoices, or client updates, domain impersonation can create real confusion. A documented DMARC rollout supports business email security and may strengthen your overall cyber insurance readiness, even though it does not by itself satisfy every insurer requirement.

Managing Multiple Domains: Best Practices for Consistency

The hardest part is usually not creating one record. It is keeping several domains consistent over time. Agencies often inherit old domains, microsites, campaign domains, and parked brands. Some still send mail. Some should not send mail at all. Without a clear process, records drift and no one is sure what is active.

A good operating model is to treat each domain as an asset with an owner, an approved sender list, and a review schedule.

Use this checklist for ongoing management.

  • Keep a domain inventory with registrar, DNS host, and business owner.
  • Mark whether each domain sends email, receives email, both, or neither.
  • Track SPF, DKIM, and DMARC status for every domain.
  • Use unique DKIM selectors for each provider and domain.
  • Review DNS records whenever you add a new tool.
  • Remove old email services from SPF and DKIM documentation.
  • Review DMARC reports on a regular schedule.
  • Test after migrations, rebrands, or provider changes.

It also helps to separate domains by purpose.

Domain type Recommended approach
Main business domain Full SPF, DKIM, and DMARC with active monitoring
Marketing-only domain Authenticate all sending tools and monitor closely
Parked domain that should not send mail Publish restrictive records where appropriate and document no approved senders
Subdomain for a specific tool Keep records scoped to that use and document ownership

If you manage several domains, documentation matters almost as much as DNS. A simple spreadsheet or internal checklist is often enough. The key is that someone can answer these questions quickly:

  • Which systems are allowed to send from this domain?
  • Which selectors are active?
  • What DMARC policy is live?
  • Who reviews reports?
  • When was this domain last tested?

This kind of discipline supports small business cybersecurity in a practical way. It also helps when filling out insurer questionnaires, because many applications ask about email controls, MFA, backups, endpoint protection, and documented security practices. Email authentication is only one control, but it fits into a broader, more credible security baseline.

Conclusion

For small agencies with multiple domains, SPF, DKIM, and DMARC are easier to manage when you treat them as a repeatable process instead of a one-time technical task. Start by inventorying domains and sending services. Build one clean SPF record per domain. Set up DKIM with clear selectors and documentation. Then roll out DMARC in stages so you can monitor first and tighten policy later.

This will not guarantee deliverability or stop every phishing attempt. It also does not replace other controls such as MFA, endpoint protection, backups, staff training, and documented response procedures. But it does reduce avoidable email risk and gives your team a clearer, more defensible setup.

If your agency has limited IT support, the most practical next step is simple: choose one domain, document every sender, and work through SPF, DKIM, and DMARC in order. Once that workflow is clear, repeat it across the rest of your domain list.