SPF, DKIM and DMARC: Configure Email Authentication Properly

Email authentication helps receiving systems decide whether a message is authorised to use a domain. It matters for ordinary business correspondence as well as newsletters: your invoicing system, website forms and online-shop receipts may all send using the same brand.

SPF, DKIM and DMARC work together, but they are not interchangeable switches. Setting them correctly requires an inventory of real senders, DNS access and testing of actual messages. None guarantees inbox placement or prevents every form of phishing.

Start with a sender inventory

List every platform sending as your domain: employee email, customer support, order notifications, payment receipts, accounting software and marketing tools. Identify the technical owner and whether each platform can use a custom authenticated sending domain.

Include forgotten services before enforcing a restrictive policy. A website may still send directly from its hosting server while staff mail uses a separate cloud platform. If you authorise only the cloud platform, website notifications may fail authentication.

Keep transactional and marketing streams organised. Separate subdomains can make ownership and policies easier to manage, but they do not remove the need for consent, good list practices or provider-specific sending requirements.

SPF: authorise sending infrastructure

Sender Policy Framework publishes which systems may send using a particular envelope-sender or HELO domain. Receivers compare the sending host with that policy. SPF does not by itself authenticate the visible From address your customer reads.

The policy is normally published as TXT. Use the instructions from your authorised sending services rather than adding their names as arbitrary text. A domain should have one applicable SPF policy at a given owner name, not several competing records beginning with v=spf1.

When adding another service, update the existing policy carefully. SPF evaluation has limits, including a limit on DNS-querying terms. Nested provider includes can contribute to those limits, so a short-looking policy is not necessarily a simple one. Use an SPF-aware checker and remove services you no longer authorise.

Do not use an unrestricted pass-all ending to make errors disappear. Equally, do not copy a strict ending without first checking all genuine senders. Policy correctness depends on your actual infrastructure, not on finding a universally correct string online.

DKIM: sign messages at the sending service

DomainKeys Identified Mail uses a cryptographic signature added to a message by a sending platform. The receiver obtains the matching public key from DNS and checks the signature. The private key stays with the system performing the signing.

Your provider will supply a selector and either a TXT public-key value or a CNAME that points to its managed key. The record name typically contains selector._domainkey, but the selector is provider-specific. Publish exactly what the setup workflow supplies.

Adding the DNS key does not necessarily enable signing. Some platforms require a separate activation step after verification. Send a real message and inspect its authentication results before considering the job complete.

DKIM is signing, not message encryption. It can help detect changes to signed content, but it does not hide the message from intermediaries. Use the provider's current supported key settings and rotation process rather than creating an unmanaged private key in a general-purpose online generator.

DMARC: connect authentication to the visible identity

DMARC evaluates whether the domain in the visible From header aligns with a passing SPF domain or a passing DKIM signing domain. One aligned passing method can satisfy DMARC; it does not require both methods to pass in every message.

Publish the policy at the appropriate _dmarc name. Its handling preference can request observation, quarantine or rejection for failing messages, and it can request aggregate reporting. Receivers still apply their own handling decisions.

An illustrative monitoring policy might contain v=DMARC1; p=none, with an authorised reporting destination added through your deployment plan. Do not copy a reporting address you do not control. External report destinations can require additional authorisation.

Alignment is the detail many setups miss. A marketing platform can produce a technically valid DKIM signature using its own unrelated domain while the visible From uses your business domain. That does not establish the aligned authentication your DMARC policy needs.

Deploy in stages

1. Confirm who controls the authoritative DNS zone and export the existing records.
2. Configure SPF for every legitimate sending stream without creating duplicate policies.
3. Enable DKIM signing at each provider and publish its exact selector records.
4. Publish a monitoring DMARC policy with a reporting destination you manage.
5. Send test messages from staff mail, forms, receipts, support and marketing tools.
6. Review reports and message headers, fix unexpected legitimate failures, then plan enforcement.
7. Continue monitoring after moving towards quarantine or rejection.

There is no useful universal waiting period before enforcement. You need enough observation to include infrequent legitimate senders, such as a monthly invoicing run or a seasonal campaign. A quiet weekend's reports may miss both.

Read the evidence in a message

Use the receiving service's original-message or header view. Look for Authentication-Results showing SPF, DKIM and DMARC outcomes, then identify which domains were checked. A bare “pass” for a provider's unrelated domain does not answer the alignment question.

Compare successful and failed examples from the same sending platform. Forwarding can affect SPF because the forwarding server is not the original sender. Mailing-list transformations can affect DKIM signatures. These cases need a considered routing or platform solution, not random changes to the public policy.

DNS query tools can confirm that a record is visible, but only a real signed message can show whether the sender is signing correctly. Keep both types of evidence in your deployment notes.

Diagnose common mistakes

Duplicate SPF records, missing selector suffixes, truncated DKIM keys and publishing a record in an inactive zone are common causes of failure. DNS editors may split long TXT values into quoted chunks; use the provider's required format rather than adding visible quotation marks arbitrarily.

Check whether the editor appends your domain to the record name. A full selector pasted into a short-name field can become duplicated. Compare the public answer at the exact required hostname.

After changing records, account for TTL and cached answers. Repeated edits while old answers remain cached make diagnosis harder. Record the intended configuration and query authoritative nameservers before changing it again.

Keep authentication current

When onboarding a new sender, make authentication part of approval. When retiring one, remove its authorisation and unused domain connection after the service is no longer needed. Rotate signing keys using the platform's supported overlap process so delayed legitimate messages can still be checked.

Restrict DNS access, use multi-factor authentication and review account recovery arrangements. A compromised authorised sender can still pass authentication. Staff should continue independently verifying unexpected bank-detail changes and sensitive requests.

Google's current sender rules distinguish ordinary senders from bulk senders to personal Gmail accounts. Review the actual provider requirements for authentication, unsubscribe and sending practices rather than assuming one rule applies identically to every receiver.

Treat reporting data as operational information. Restrict access, choose a trustworthy processing service and understand what the reports contain before forwarding them widely. Domain-verification TXT tokens also deserve an inventory: removing an apparently unrelated token during “DNS cleanup” can disconnect a legitimate platform. Record its purpose and owner, then remove it through the platform's offboarding process when that relationship ends. Email policy and domain verification share a record type, but their lifecycles are different.

If your mail is with telaHosting, obtain its account-specific settings and include all external senders in the review. Correct authentication is a maintained business process, not a one-off promise that every future message will reach an inbox.