# Email Authentication for Agency Website Teams

> Email authentication protects client domains from spoofing and improves delivery. Learn how agencies monitor SPF, DKIM and DMARC across every site at scale.

A client calls to say their customers have received a convincing invoice from their domain. The website may be secure, the SSL certificate current and the brand guidelines intact, yet trust has already been damaged. Email authentication is the control that helps prevent this scenario by proving which services are allowed to send as a domain and telling receiving mail systems what to do with impostors.

For an agency managing dozens or hundreds of domains, this is not a one-off DNS task. It is an operational responsibility that changes whenever a client adds a CRM, replaces an email platform, launches a recruitment tool or sends transactional messages from an e-commerce site. A record that was correct six months ago can become incomplete overnight.

## Why email authentication belongs in website operations

Email is part of a client's digital estate, just like [their DNS](https://www.tldtrack.com/blog/dns-records-explained), website hosting and certificates. It is often managed by a different person, a different supplier and a different login, which is precisely why gaps go unnoticed. A website team may deploy a new contact form integration without realising it sends confirmation messages from the client's domain. A marketing team may add a new platform and ask for a DNS record late on Friday afternoon. Both can affect delivery and domain reputation.

Poorly configured authentication creates two business risks. First, legitimate campaigns, password resets and order updates may land in spam or be rejected. Secondly, an attacker can spoof the visible From address, making phishing emails appear to come from the client. The latter is not merely a technical issue. It creates support work, reputational harm and difficult conversations about why the issue was not identified sooner.

The practical goal is straightforward: know every authorised sending service, validate the records that support it and spot changes before they affect recipients.

## The three controls that work together

Email authentication is usually discussed as SPF, DKIM and DMARC. Each addresses a different part of the problem. Treating any one record as a complete solution is a common and costly mistake.

### SPF authorises sending infrastructure

Sender Policy Framework, or SPF, is a DNS TXT record listing the servers and services permitted to send mail on behalf of a domain. Receiving servers compare the sender's IP address with that policy.

SPF is useful, but it is easy to overestimate. It does not reliably protect the visible From address on its own, and it can break when a message is forwarded. It also has a strict limit of ten DNS lookups. Agencies often hit that limit when a domain accumulates includes from Microsoft 365, Google Workspace, mailing platforms, CRMs and legacy suppliers. Once SPF exceeds the lookup limit, the record can return a permanent error and undermine legitimate delivery.

A shorter SPF record is not automatically a better one. The right record reflects the services actively sending mail. The operational challenge is maintaining that truth as suppliers change.

### DKIM signs each message

DomainKeys Identified Mail, or DKIM, adds a cryptographic signature to outgoing email. The public key is published in DNS, normally under a selector chosen by the sending platform. A receiving server uses that key to verify that the message was authorised and has not been changed in transit.

DKIM is generally more resilient than SPF when messages are forwarded, but it still needs maintenance. Keys can be mispublished, selectors can be removed during DNS housekeeping and older keys may remain after a platform migration. Key length matters too. Modern 2048-bit keys are generally preferable where a provider supports them, although some DNS providers create practical constraints around long records.

Each sender may use its own selector. That means a domain can have several legitimate DKIM records. The question is not whether there is one DKIM record, but whether every important sending service signs correctly with aligned domains.

### DMARC applies the policy

Domain-based Message Authentication, Reporting and Conformance, or DMARC, connects SPF and DKIM to the visible From domain. It allows a domain owner to publish a policy: monitor failures, send suspicious messages to spam, or reject them outright. It also produces reports showing who is attempting to send as the domain.

DMARC alignment is where many configurations succeed or fail. A message can pass SPF or DKIM while still failing DMARC if the authenticated domain does not align with the domain recipients see in the From field. This is especially relevant for marketing platforms and transactional email suppliers that use their own default domains until custom authentication is configured.

A policy of `p=none` is valuable for gathering intelligence, but it does not instruct receiving systems to block spoofed mail. It is a starting point, not the finish line. Moving to `quarantine` or `reject` provides meaningful protection, but only after the agency has identified legitimate senders and tested them carefully.

## A sensible rollout for a client portfolio

The safest way to implement DMARC is staged. Start by building an inventory of every sending source: corporate mailbox providers, newsletters, CRM sequences, e-commerce receipts, helpdesk notifications, invoicing systems, website forms and any outsourced communications platform. Ask the client about systems that may not sit with the web team. Payroll, recruitment and franchise tools are frequent omissions.

Next, validate the DNS records against that inventory. Confirm SPF does not exceed its lookup limit, inspect DKIM selectors and ensure each legitimate sender is aligned where possible. It is also worth checking the organisational domain and active subdomains. A forgotten subdomain can become an easy route for impersonation.

Publish DMARC in monitoring mode and review the aggregate reports over a meaningful period. Thirty days is often a practical minimum, but it depends on the client's send frequency. A seasonal retailer or organisation that sends monthly statements may need a longer observation window. Look for unfamiliar senders, failed alignment, unexpected third-party services and legitimate systems that are using a non-aligned domain.

Once the data is understood, move gradually to enforcement. Some teams choose a partial percentage policy first, applying quarantine or rejection to a proportion of mail while they continue to observe results. This reduces the risk of disrupting a genuine but previously unknown workflow. It does not remove the need for accountability: someone must own the review and act on findings.

## The agency failure points to watch

The most damaging problems tend to appear after the initial project is marked complete. DNS is changed during a domain migration. A new platform is connected by a marketing contractor. An old provider is removed from the client stack but its authorisation remains in SPF. The records become a historical archive rather than an accurate policy.

Pay particular attention to these situations:

- a provider migration involving Microsoft 365, Google Workspace or an email security gateway;
- new e-commerce, booking, CRM or marketing automation software;
- website rebuilds that alter form delivery or transactional email routing;
- DNS consolidation, registrar moves and changes to nameservers;
- acquisitions, rebrands and newly launched subdomains;
- a sudden rise in spam complaints, bounces or support queries about missing emails.

These are change-management events, not just email events. Add email authentication checks to the same release and handover process used for SSL, redirects and analytics. If a supplier needs DNS access or asks a client to add a TXT or CNAME record, that request should be recorded against the domain and reviewed after deployment.

## Monitoring turns configuration into a service

A technically correct record today offers little reassurance if no one notices when it disappears, becomes malformed or changes policy. Continuous monitoring provides the operational layer: validate SPF, DKIM and DMARC records, detect unauthorised DNS changes and alert the responsible team while there is time to respond.

For [larger portfolios](https://www.tldtrack.com/blog/agency-client-website-monitoring), the checks need to be visible alongside the rest of the site's health. [A client report](https://www.tldtrack.com/blog/client-reporting-for-web-agencies) is stronger when it can show that uptime, certificate expiry, DNS posture, security exposure and deliverability controls are being watched in one place. TLDTrack can help teams bring those checks into a single portfolio view rather than relying on manual DNS inspections and scattered reminders.

Monitoring should not create noise for its own sake. Define who receives an alert, what constitutes an approved change and how quickly it should be investigated. A new DKIM selector from a known platform may be expected. A DMARC policy downgraded from reject to none, or an SPF record suddenly authorising unfamiliar infrastructure, deserves immediate attention.

## Make ownership explicit

The technical work is only half the job. Clients need a clear answer to three questions: who owns the domain, who can approve sending services and who reviews reports? Without that agreement, agencies are asked to fix delivery problems but lack authority to maintain the records that prevent them.

Document the approved senders, the current DMARC policy and the escalation contact for each domain. Include authentication in onboarding, quarterly reviews and offboarding. When a client changes supplier, make the old sender's removal part of the closure checklist rather than an afterthought.

The payoff is not just better inbox placement. It is fewer surprises, clearer accountability and a credible proactive service clients can understand. The next time a sending platform is added or a DNS record changes, treat it as a signal to check the domain's identity before somebody else tries to use it.

---

Published: 2026-10-03  
Web version: https://www.tldtrack.com/blog/email-authentication-agency-website-teams