An email can display your company’s name without being sent by your company. SPF, DKIM and DMARC help receiving systems check the sending identity behind a message. They work together, but they answer different questions.
You do not need to memorise DNS syntax to oversee your business email. You do need a list of legitimate senders, someone responsible for the records, and evidence that the messages your business sends are authenticating correctly.
SPF: is this server authorised to send?
Sender Policy Framework lets a domain publish which systems may send using that domain in the SMTP envelope sender—the address involved in handling delivery failures. The receiving system compares the sending server with that policy. This is not necessarily the same domain a person sees in the From line.
Your mailbox provider is only one possible sender. An invoicing service or website may need its own authorised configuration. Ask your administrator to maintain one SPF policy per domain being checked, avoid duplicate SPF records and stay within the protocol’s DNS-lookup limit.
- List every service that legitimately sends for the business.
- Ask which envelope-sender domain each service uses.
- Remove obsolete authorisations after confirming that the service is no longer needed.
DKIM: does the message have a valid signature?
DomainKeys Identified Mail adds a digital signature to a message. A receiving system uses a public key in DNS to check the signed headers and body. The signing system keeps the corresponding private key.
A selector tells the receiver where to find the public key. It is a provider-supplied identifier, not a password. A business can use different selectors for different sending platforms. Publishing a key is only part of setup: the platform must actually sign outgoing mail with the matching key.
A valid signature is evidence about the signer and signed content. It does not prove that a message is honest, harmless or written by a particular employee.
DMARC: does authentication match the visible From domain?
DMARC connects authentication to the domain recipients see in the From address. A message passes when SPF or DKIM passes and the domain used by that successful check aligns with the visible From domain. It does not require both mechanisms to pass, although configuring both gives legitimate mail more resilience.
For example, an invoicing service might pass SPF using its own domain while displaying yours in the From line. That SPF result alone may not satisfy DMARC for your company. The service may need aligned DKIM signing or an aligned envelope-sender configuration.
A DMARC policy can request monitoring, quarantine or rejection for failing messages and can request aggregate reports. Receiving systems still apply their own handling decisions. Review legitimate traffic before strengthening a policy; an immediate move to rejection can disrupt a forgotten but legitimate sender.
What these controls do not do
Authentication is one part of email security. It does not encrypt message contents, replace account security or guarantee inbox placement. A compromised authorised account can still send harmful mail, and an attacker can register a similar-looking domain.
Forwarding can affect SPF, and changes to a message after signing can affect DKIM. When a message fails, inspect the actual route and receiving-system results before changing the domain’s policy. Avoid weakening a working policy simply to make a dashboard indicator turn green.
Five questions to ask your administrator
Ask for a short explanation and a controlled test, rather than a screenshot showing that DNS records exist. For each important sending service, a received test message should help establish whether authentication passes and whether it aligns with your domain.
- Have we inventoried employee mail, website forms, billing software and marketing senders?
- Which domain does each service use for SPF, and who maintains that policy?
- Does every important service sign with DKIM using the intended domain and selector?
- Who reviews DMARC reports and investigates unexpected sources?
- What evidence will we check before changing a provider or strengthening the policy?
Start with a domain check, then test real mail
Envelaro’s Email Health tool can help you review public DNS evidence and identify questions to investigate. If you supply a DKIM selector, use the one provided by your actual sending service rather than guessing.
A public DNS check cannot inspect private keys, read every message or prove that all business systems authenticate correctly. Pair the result with controlled message-header tests and, where configured, DMARC aggregate reports. The detailed DKIM and DMARC guides below explain the next steps.
Primary sources
Provider interfaces and requirements change. Check the linked source before applying a production change.