Start with three different questions
Business email authentication has three related but distinct jobs. SPF asks whether the sending system is permitted to send for the envelope domain. DKIM asks whether a verifiable cryptographic signature was applied by a domain associated with the message. DMARC asks whether a passing SPF or DKIM identity aligns with the domain that recipients see in the message's From field, then publishes a requested handling policy and reporting options. These checks reduce certain forms of domain impersonation, but none confirms that a human sender is trustworthy. A company should understand the three questions before copying records into DNS.
Separate the visible From address from the envelope sender
An email has more than one sender identity. The From header is usually the address shown to a person reading the message. SMTP also uses an envelope sender, often called MAIL FROM or return path, for transport and bounce handling. These domains can differ legitimately when a billing application or newsletter platform sends on behalf of a business. SPF normally checks the envelope identity, not the displayed From address. That distinction explains why an email can pass SPF but still fail DMARC alignment. During troubleshooting, examine the actual message headers instead of judging authentication only from the name visible in the inbox.
What SPF authorises
Sender Policy Framework is a DNS-published policy describing which hosts may send mail using a particular envelope domain. The receiving system checks the sending IP address against the domain's SPF mechanisms and produces a result such as pass, fail, softfail or permerror. SPF does not sign the message, prove the displayed author, or encrypt content. The domain owner must include all legitimate sending infrastructure, not just the provider used by employees. A website notification service, accounting application or marketing system can send messages independently of the normal mailbox host. An incomplete inventory can make genuine business messages fail checks.
Understand one SPF policy and its mechanisms
SPF is normally published as a DNS TXT value beginning with v=spf1. Mechanisms can authorise specific IPv4 or IPv6 ranges, reference sending hosts or include another domain's published policy. The final all mechanism expresses how unmatched senders should be evaluated, with different qualifiers indicating different results. These elements are not interchangeable, and a record copied from another business can authorise the wrong infrastructure. A domain should not publish multiple separate SPF policies at the same owner name; the evaluator may return a permanent error. Merge legitimate sources into one reviewed policy, subject to the specification's evaluation limits.
Respect SPF DNS lookup limits
RFC 7208 limits SPF evaluation to ten mechanisms or modifiers that trigger DNS lookups, including include, a, mx, ptr, exists and redirect. This is a limit on evaluation, not simply a count of text fragments visible in the record. Nested includes consume the same budget. Exceeding the limit produces permerror, so adding every vendor include without checking the full chain can undermine the policy. Some mechanisms, including ip4 and ip6, do not consume that lookup budget in the same way. Before approving a change, document each legitimate sender, calculate the effective lookup path and verify the resulting public record.
Why forwarding complicates SPF
When a recipient automatically forwards a message, the server delivering the forwarded copy may be different from the original sender. A receiver checking SPF against the original envelope domain can see an IP address that was never authorised by that domain. This is a known limitation, not necessarily evidence that the original email was malicious. Some forwarding systems use sender rewriting to mitigate the issue, but behaviour varies. DKIM may continue to verify if the forwarded message preserves signed content. When investigating forwarded mail, compare authentication results before and after the forwarding step instead of immediately weakening the domain's SPF policy.
How DKIM signatures work
DomainKeys Identified Mail uses a private signing key held by the sending service and a corresponding public key made available through DNS. The outgoing system adds a DKIM-Signature header describing the signing domain, selector and signed content. A receiving system retrieves the public key and checks whether the signature verifies. The result helps detect relevant modifications to signed headers and body content after signing. DKIM is not encryption and does not conceal the email from intermediaries. It also does not prove that the visible From domain matches the signing domain; DMARC addresses that alignment question separately.
Understand DKIM selectors and key ownership
A DKIM selector identifies which public key a verifier should retrieve, commonly under a selector._domainkey subdomain of the signing domain. A business may have several selectors because different services sign mail independently or because keys are being rotated. The private key should remain controlled by the authorised signing system; publishing it or forwarding it casually would compromise the authentication design. A DNS record containing the public key is expected, but the record must correspond to the actual active signer. When changing providers, identify which selectors remain in use before deleting old entries. Never assume a selector's presence proves the service is currently sending.
Why legitimate mail can fail DKIM
A mailing list, gateway or other intermediary may append a footer, rewrite subject lines or otherwise modify parts of a signed message. Depending on what was signed and how canonicalisation was applied, the signature may no longer verify. A missing public key, mismatched selector or signing configuration error can also cause failure. Do not interpret every DKIM failure as proof of fraud. Inspect the signature domain, selector, verification result and message path, and ask the responsible provider about any rewriting. If SPF passes with DMARC alignment, the message can still satisfy DMARC even when DKIM fails, subject to receiver handling.
DMARC connects authentication to the visible domain
DMARC evaluates the domain in the visible RFC5322.From field against authenticated identities. A message generally passes DMARC when at least one of SPF or DKIM passes and the passing identity aligns with that From domain. SPF passing for an unrelated bounce domain is insufficient on its own. A valid DKIM signature from a different unrelated domain is also insufficient on its own. This is why all three mechanisms complement one another. The domain owner publishes DMARC as a TXT policy under _dmarc for the relevant domain. The record communicates a requested disposition and can request reports from participating receivers.
Relaxed and strict alignment are different
DMARC supports relaxed and strict identifier alignment. Under relaxed alignment, a properly related subdomain may align with the organisational domain shown in From; strict alignment generally requires an exact domain match. These settings affect legitimate systems that send from a subdomain or sign with a related parent domain. Stricter is not automatically safer if it breaks approved mail flows without improving the business's actual risk posture. Review the sender's From, MAIL FROM and DKIM signing domains before choosing alignment modes. The RFC provides precise definitions; a visual comparison of two email addresses is not a substitute for evaluating their domain relationship.
What DMARC none, quarantine and reject mean
The DMARC p tag expresses a requested policy for messages that fail alignment checks. A none policy primarily supports observation and reporting without requesting special disposition. Quarantine requests suspicious treatment, while reject requests rejection of messages failing DMARC. Receiving systems retain their own operational policies, so a published value is not a universal guarantee of handling. Moving directly to reject before identifying legitimate senders can disrupt billing, notifications or other business correspondence. Plan a measured transition: establish baseline visibility, correct approved senders, assess reports and only then consider stronger enforcement with an authorised rollback plan.
DMARC reports are evidence, not automatic fixes
DMARC aggregate reports can provide information about sending sources and authentication outcomes observed by participating receivers. They may reveal an approved service that was forgotten during configuration or an unfamiliar source using the domain. Reporting is not necessarily complete across every receiver, and a source IP alone does not establish intent. Treat report interpretation as an investigation: compare sources against the approved sender inventory, identify alignment failures and document the proposed remedy. Report destinations can receive substantial data, so choose an authorised mailbox or service with appropriate access and retention. Reports do not themselves modify SPF, DKIM or DMARC records.
Inventory all legitimate sending services first
A small business may send from staff mailboxes, an accounting platform, a booking system, an enquiry form, a customer support tool and a newsletter provider. Each service can use a different technical path even if customers see the same company address. Before adjusting DNS, list the application owner, From domain, envelope domain, DKIM signing domain, required provider documentation and an approved test message. Confirm whether the service sends directly, relays through another host or merely creates a draft for an employee. Do not authorise a vendor's broad DNS instruction without checking whether it applies to the specific account and sending method.
Example: invoices sent through another platform
Imagine a hypothetical company whose employees use a normal mailbox service while an accounting platform sends invoice notifications with the same visible company domain. Employee messages authenticate correctly, but invoices fail DMARC because the accounting platform signs with its own unrelated domain and uses an unaligned return path. The correct response is not to disable all authentication. Identify the platform's supported custom-domain authentication options, verify its actual headers and arrange a reviewed configuration if the service supports it. If it cannot align, consider an approved alternative workflow. This is a hypothetical diagnostic example, not a claim about any specific accounting product.
Find the authoritative DNS location
DNS records must be published in the zone served by the domain's authoritative nameservers. The company that sold the domain, the web host and the email provider may be different organisations. Editing a convenient control panel that is not authoritative may have no effect on public authentication. cPanel's Email Deliverability documentation explicitly distinguishes local suggestions from records that must be published at the authoritative DNS service. Before a change, identify who controls the live zone, obtain a copy of the existing values and confirm which party has permission to edit them. This article is educational; it does not authorise changing any domain.
Read message headers to verify results
A DNS lookup showing a syntactically valid TXT record is only part of verification. An authorised test message should be sent through each actual service to a receiver that exposes authentication results. Inspect SPF, DKIM and DMARC outcomes, the domains used for alignment and any delivery error. Record the sender application, timestamp and destination without unnecessarily exposing customer content. If the result differs from expectation, inspect the envelope identity, DKIM selector and public DNS rather than repeatedly adding records. A test to one receiver cannot guarantee the same treatment everywhere, but it is stronger evidence than a configuration screenshot alone.
Interpret pass, fail and temporary errors carefully
An SPF pass means the sending IP satisfied the evaluated policy for the checked domain; it does not mean the message is safe. A DKIM pass means a particular signature verified; it does not guarantee that the signer matches the visible From domain. A DMARC pass requires the relevant alignment condition as well. Permanent errors may indicate malformed records or excessive SPF lookups, while temporary errors can arise from DNS availability problems. Review the exact error and the receiving system's explanation before changing policy. Authentication outcomes should be interpreted alongside reputation, content and the recipient's security controls.
Do not mistake authentication for inbox placement
Correct authentication supports responsible sending, but receiving providers also consider reputation, spam complaints, message content, sending patterns and their own policies. SPF, DKIM and DMARC do not guarantee that a message reaches the primary inbox or that every forged-looking email will be blocked. They also do not stop an attacker who controls a genuinely authenticated account. Businesses still need strong sign-in protection, account access reviews, user training and a procedure for suspicious messages. Present these records as one layer of protection rather than an email-delivery warranty. Record real sending outcomes before claiming an improvement.
Treat subdomains and unused domains deliberately
A business may send mail from its main domain, a support subdomain or a dedicated notification subdomain. Each identity needs review because SPF policies are evaluated for the domain actually used, and DKIM signing domains and DMARC organisational alignment can differ. Do not assume a parent-domain SPF record automatically authorises every subdomain. Conversely, unused domains and subdomains should not accidentally remain attractive impersonation targets through vague policies. Document which names are authorised for outbound mail and which are not. Review the relevant RFC and provider instructions before applying an aggressive policy, especially when older systems may still use a forgotten subdomain.
Plan provider migration as an overlap period
When moving from one email provider to another, old and new systems may both send legitimate mail during a controlled transition. Removing the previous SPF authorisation or DKIM public key too early can disrupt messages still in transit or generated by old applications. Keeping obsolete permissions indefinitely is also undesirable. Create a transition inventory identifying which service sends each type of message, the expected cutover, tests and a removal checkpoint. Verify records and signed messages before withdrawing unused entries. DNS propagation and caching can delay observations, so avoid declaring success from a single immediate lookup. Any real migration requires separate owner authorisation.
Define responsibility and a safe approval record
The domain owner should know who manages authoritative DNS, who controls the mail platform, who owns each third-party sender and who reviews authentication reports. Ask a provider to specify the exact record name, value, reason, affected sending path and rollback method in writing. Keep credentials and private DKIM keys out of ordinary editorial documents. Record the old configuration, intended change, authorised approver, verification results and follow-up date. A technical consultant can explain risks without gaining permission to alter production. The right outcome is a traceable decision and tested configuration, not merely a green badge in a hosting dashboard.
A practical decision checklist for small teams
Before requesting any configuration work, confirm the domain and its authoritative DNS provider, inventory every genuine sender, and obtain the relevant vendor's official instructions. Check that SPF is a single coherent policy within lookup limits, that DKIM signatures correspond to accessible public keys, and that at least one passing mechanism aligns with the visible From domain. Choose a DMARC monitoring and enforcement approach that the business can operate, with an approved report destination and rollback plan. Test each sending path and document exceptions. If any sender cannot be identified or tested, mark the change pending rather than making assumptions about invoices or customer notices.
Sources & further reading
Ready to explore a related service?
See the related OnHypp service and decide whether it fits your business needs.
Email & hostingWebsite CareDomains