A business changes the service that sends its invoices, but the next batch of emails produces an unexpected problem. Some recipients receive the invoices normally, while others see warnings or find the messages in their spam folders. The new provider says its system is working, and the company’s email addresses have not changed. The problem may lie in how the company’s domain identifies and authorises its outgoing messages.
Email authentication depends on more than the address printed in an email’s From field. Receiving servers can examine the sending system’s authorisation, verify a cryptographic signature, and compare authenticated domain identities with the address presented to the recipient. Three standards support these checks: SPF, DKIM, and DMARC. Although these standards work together, they do not perform the same job. Understanding their individual roles helps website owners and administrators configure business email correctly, investigate failures, and introduce stricter policies without accidentally blocking legitimate messages.
The Identity Problem Behind Business Email
An email has multiple layers of identity. The recipient usually sees a ‘From’ address such as accounts@northstar.example. Behind that address, the delivery process uses an SMTP envelope containing information about where the message is coming from and where delivery failures may be reported.
These identities can differ. A business might display its own domain in the From field while using an external provider to deliver the message. That arrangement is common, but receiving systems need a way to distinguish an authorised arrangement from an unrelated sender attempting to use the same visible address.
SPF, DKIM, and DMARC address this problem from different directions.
- SPF (Sender Policy Framework) checks whether the connecting server is authorised for the relevant envelope-sender domain.
- DKIM (DomainKeys Identified Mail) verifies a digital signature associated with a domain and checks the integrity of the message components covered by that signature.
- DMARC (Domain-based Message Authentication, Reporting, and Conformance) evaluates whether SPF or DKIM authenticates a domain aligned with the visible ‘From’ domain, then communicates a policy and reporting preferences.
Together, these standards provide evidence that receiving systems can use when evaluating a message. They do not certify the sender’s honesty, inspect every possible threat, or guarantee that the email will reach the inbox. Reputation, content, recipient settings, and other filtering signals still influence delivery decisions.
SPF: Checking Whether The Sending System Is Authorised
SPF, documented in RFC 7208, lets a domain owner publish a policy identifying which systems may send email using the domain in the relevant SMTP envelope-sender identity.
Why The Envelope Sender Matters
The envelope sender is supplied during SMTP delivery through the MAIL FROM command. It is distinct from the ‘From’ header that normally appears in an email application. The envelope identity is also associated with the return path used for delivery failure notifications. SPF evaluates the connecting IP address against the policy for the relevant envelope-sender domain. Consequently, a message can display a business address while SPF evaluates a different domain.
Imagine that Northstar Supplies sends an invoice from accounts@northstar.example. Its email provider uses an envelope sender under a provider-managed domain. The provider’s SPF policy may authorise the sending IP address, producing an SPF pass for that provider-managed identity. That result does not automatically mean SPF has authenticated northstar.example. This distinction becomes important when DMARC checks domain alignment.
What An SPF Record Actually Does
A domain publishes its SPF policy in DNS as a TXT record. The policy can authorise particular IP addresses, identify approved mail infrastructure through supported mechanisms, or reference other domains’ policies.
The receiving server evaluates the policy according to SPF’s rules. If the connecting IP address matches an authorised mechanism, the result may be pass. If the policy explicitly excludes the address, the result may be fail. Other outcomes, including softfail, ‘and’, have different meanings and should not be treated as interchangeable.
Common configuration errors include:
- Forgetting to authorise a newly introduced sending provider.
- Removing an existing provider’s authorisation before all systems have migrated.
- Publishing multiple SPF records for the same domain.
- Exceeding the specification’s DNS lookup limit.
- Copying a provider’s example without checking the domain and mechanisms to which it applies.
- Assuming that authorising a server automatically authenticates the visible From address.
SPF is therefore a statement about sending authorisation for a particular identity, not a universal certificate of message legitimacy.
DKIM: Verifying A Message’s Digital Signature
SPF evaluates the sending IP address. DKIM approaches the problem differently by attaching a cryptographic signature to an email. A sending system configured for DKIM adds a DKIM-Signature header. Among its fields are the signing domain, identified by d=, and a selector, identified by s=. The selector tells the receiving server which public key to locate for verification.
From Signature To Verification Result
The receiving server retrieves the corresponding public key, commonly published in DNS under a name derived from the selector and signing domain. It then verifies the signature against the message components specified by the signature.
These components include a selected set of headers and a body hash. The precise coverage depends on the signature’s parameters. A valid result indicates that the signed components pass the specified cryptographic checks; it does not mean that every part of the message was signed or that every subsequent change would be detectable.
This is useful when email passes through several systems. If the relevant signed content remains intact, a DKIM signature may continue to verify even when the message travels through a server that is not authorised under the original sender’s SPF policy.
Why A DKIM Signature Might Fail
A failed signature can result from a missing or incorrect public key, an incorrect selector, a signing configuration error, or changes to signed message components. A mailing list that modifies a signed subject or body, for example, may invalidate the signature. The failure must be interpreted alongside the delivery path. It does not automatically establish that someone forged the message.
Likewise, a valid signature does not prove that a message is safe. The signing domain might belong to an external service, or an authorised account might be misused. DKIM establishes a cryptographic relationship between the signing domain and the covered message components, not the truthfulness of the message’s claims.
DMARC: Connecting Authentication to the Visible Sender
SPF and DKIM can each succeed without establishing that the domain is visible. The address is the one being authenticated. DMARC addresses this gap through domain alignment.
A DMARC policy is published in DNS as a TXT record at the appropriate _dmarc name. It specifies how the domain owner wants receiving systems to handle messages that fail DMARC and can identify an address for aggregate reporting.
How Alignment Works
DMARC compares the domain in the visible ‘From’ header with the domain authenticated by SPF or DKIM. For SPF, the comparison uses the domain associated with the SPF-authenticated envelope sender. For DKIM, it uses the signing domain in the signature’s d= tag.
DMARC supports two alignment modes:
- Relaxed alignment allows related domains to align under the specification’s organisational-domain comparison rules. This is the default mode for SPF and DKIM unless the domain owner configures otherwise.
- Strict alignment requires the authenticated domain to match the visible ‘from’ domain exactly. This provides a narrower identity match, but it can cause legitimate messages to fail alignment when they use separately configured subdomains.
The critical rule is that DMARC requires at least one aligned authentication path to pass. SPF does not have to pass if DKIM passes and aligns. Similarly, an aligned SPF pass can satisfy DMARC even if DKIM fails. A message fails DMARC when neither SPF nor DKIM provides a successful result with the required alignment.
What The DMARC Policy Requests
Three principal policy settings control the domain owner’s requested treatment of DMARC failures.
| Policy | Requested Treatment |
|---|---|
p=none |
Monitor authentication results without requesting a DMARC-specific delivery restriction. |
p=quarantine |
Ask receiving systems to treat failing messages as suspicious, potentially placing them in spam. |
p=reject |
Ask receiving systems to reject messages that fail DMARC. |
These settings do not dictate every receiver’s final action. Receiving systems make their own delivery decisions, and actual handling can vary. For administrators, the policy is also a way to introduce enforcement gradually. Monitoring first can reveal legitimate senders that have not yet been configured correctly, reducing the risk of blocking invoices, password-reset messages, or customer notifications.
A Message’s Journey Through All Three Standards
Consider a hypothetical online business, Northstar Supplies, that sends messages through two services: a business email provider for staff and a separate invoicing platform for customer bills. Both services are legitimate, but their authentication settings differ.
When the invoicing platform sends a message displaying accounts@northstar.example, the receiving server evaluates the message as follows.
- First, it checks SPF. The server evaluates the connecting IP address against the SPF policy for the envelope-sender domain. Suppose the check passes for the invoicing platform’s own bounce domain. This establishes authorisation for that identity, but the domain does not align with it.
- Next, it checks DKIM. The message contains a signature with
d=northstar.example. The receiving server retrieves the appropriate public key and verifies the signed components. Assume verification succeeds. - Then, it evaluates DMARC. SPF has passed, but its authenticated domain does not align with the visible From domain. DKIM has passed, and its signing domain does align. DMARC therefore passes through DKIM.
Now imagine that the invoicing platform loses its DKIM configuration during a provider change. The signature no longer verifies, while SPF continues to pass only for the unrelated bounce domain. Neither method now provides a successful aligned result, so DMARC fails. The lesson is not that every email must pass both SPF and DKIM. It is that a domain needs at least one properly aligned authentication method for DMARC to pass.
Why Legitimate Email Can Fail Authentication
Authentication failures often appear after an operational change rather than because a business has deliberately altered its identity.
- A new email provider may use different sending IP addresses, envelope-sender domains, DKIM selectors, or signing domains. Existing records may not authorize or align with the new configuration.
- Forwarding can affect SPF because the receiving server may see the forwarding server’s IP address instead of the original sender’s IP address. The original SPF policy might not authorize that address. DKIM may still pass if the signed content remains intact.
- Mailing-list processing can modify message headers or bodies, potentially invalidating DKIM signatures. Changes to sender identities can also affect alignment.
- Third-party applications may send notifications using a business’s visible From address while authenticating only their own domains. If neither SPF nor DKIM provides a passing, aligned result, DMARC fails.
- DNS mistakes can cause problems across multiple services. An incorrect selector, missing public key, malformed SPF policy, or conflicting SPF records can invalidate an otherwise reasonable configuration.
These cases should be investigated individually. Changing every authentication record in response to one failure can introduce additional problems without addressing the original cause.
A Practical Method For Configuring Domain Authentication
A reliable implementation starts with understanding the organization’s real sending activity. Publishing a stricter policy before identifying all legitimate senders can cause avoidable delivery failures.
Step 1: Build A Complete Sender Inventory
List every application and service that sends email using the domain. Include employee mailboxes, website forms, billing platforms, support systems, monitoring alerts, and automated account notifications.
For each source, record:
- The visible From domain.
- The envelope-sender domain used during delivery.
- The DKIM signing domain and selector, where applicable.
- The provider’s required SPF and DKIM configuration.
- The business process that depends on the messages.
This inventory is especially important for systems that send only occasionally. A forgotten service may remain unnoticed until a customer needs a password reset or an invoice is due.
Step 2: Review Existing DNS Settings
Inspect the current SPF, DKIM, and DMARC records before making edits. Confirm that each record belongs to the intended domain and that the configured values match the provider’s instructions.
One important SPF rule is that a domain should publish only one SPF record applicable to a given name. Publishing two separate SPF policies for the same domain can produce a permerror result. If several providers need authorization under the same envelope-sender domain, their requirements generally need to be incorporated into a single valid policy.
Do not simply paste together provider examples. SPF has a limit of ten DNS-query-causing terms during evaluation, including applicable uses of include, a, and mx, as well as redirect. Nested references can contribute to the total. Other DNS mechanisms and modifiers have different counting rules, so administrators should check RFC 7208 and validate the complete policy rather than counting only the visible terms.
Step 3: Configure Each Provider Correctly
Authorize legitimate sending infrastructure through SPF where appropriate. Enable DKIM signing for each service that supports it, publish the correct public key, and confirm that the signature uses a domain suitable for DMARC alignment.
Do not assume that a provider’s default settings will automatically align with the business’s visible From domain. Check the provider’s documentation and inspect actual message headers to establish which identities it uses.
Step 4: Start With DMARC Monitoring
After verifying SPF and DKIM, publish a monitoring policy and configure aggregate reporting.
The following is an illustrative record, not a universal configuration:
v=DMARC1; p=none; rua=mailto:dmarc-reports@northstar.example
This example assumes that the domain owner controls northstar.example and has configured the reporting mailbox to receive the reports. A real deployment must use the correct domain and reporting address and account for any requirements associated with an external reporting service.
Step 5: Correct Failures Before Enforcing Stricter Policies
Review reports and test messages from every legitimate source. Investigate unexplained failures, correct missing authorizations or signing settings, and verify alignment. Once the organization has sufficient evidence that legitimate messages are authenticating correctly, it can consider p=quarantine and later p=reject. Make enforcement changes in stages, monitoring the effect after each change.
Reading Authentication Results Without Misdiagnosing Them
Authentication results are most useful when examined as a group rather than as isolated pass-or-fail indicators.
| Observed Result | What It Means | Next Action |
|---|---|---|
| SPF passes, DMARC fails | SPF may have passed for a domain that does not align with From. | Compare the envelope-sender domain with the visible From domain and inspect DKIM. |
| DKIM fails after forwarding | The message may have changed, or the signature configuration may be incorrect. | Examine the signature, signed components, and forwarding path. |
SPF returns permerror |
The policy may contain invalid syntax, conflicting SPF records, or an evaluation-limit problem. | Validate the complete SPF policy and its referenced records. |
DKIM returns temperror |
A temporary verification or DNS problem may have occurred. | Check DNS availability and retry before treating it as a persistent configuration failure. |
| Both SPF and DKIM pass, but DMARC fails | Neither successful result may align with the visible From domain, or the receiver may have evaluated a different identity. | Inspect the full authentication results and the relevant domain settings. |
| DMARC passes, but the message enters spam | Authentication has passed, but other delivery signals may be unfavorable. | Investigate reputation, content, receiver policies, and delivery diagnostics separately. |
The complete headers of an affected message often reveal the identities used during the actual delivery. Results such as spf=pass, dkim=pass, and dmarc=pass should be read alongside their associated domains, not merely as three independent status labels.
What Aggregate Reports Reveal
DMARC aggregate reports provide a broader view of how receiving systems evaluate messages associated with a domain. They can summarize message volumes, source IP addresses, SPF and DKIM results, alignment outcomes, and reported policy dispositions.
These summaries can help administrators identify a forgotten sending service, distinguish known providers from unfamiliar sources, and assess whether configuration changes are improving authentication.
They also have limitations. Reports do not normally include complete message contents, prove who controlled a sending IP address, or establish whether a message was safe. Reporting coverage varies, and a report may not identify the exact application responsible for a message. Individual delivery investigations may therefore require full headers, provider logs, and additional diagnostics.
Final Domain-Authentication Review Checklist
Before strengthening a domain’s DMARC policy, confirm that:
- Every legitimate email-sending service has been identified.
- The SPF policy is valid and does not conflict with another SPF record at the same name.
- SPF evaluation stays within the applicable DNS lookup limits.
- DKIM selectors and public keys match the signing configuration.
- Actual test messages have been checked using their complete headers.
- Each legitimate sending service has at least one authentication method that passes with the required DMARC alignment.
- Aggregate reports are arriving and being reviewed.
- Forwarding, mailing-list modifications, and third-party sender issues have been investigated.
- The likely effect of quarantine or rejection on business-critical email has been assessed.
- Authentication results are monitored after changes.
Make DNS changes carefully, allow for caching and propagation, and test messages from each sending service before increasing enforcement. Keep a record of the previous configuration so that an incorrect change can be reversed promptly.
The objective is a consistent, verifiable relationship between the business’s domain and the systems sending email on its behalf. SPF checks sending authorization, DKIM verifies signed message components, and DMARC connects successful authentication to the visible sender identity. When configured and monitored together, these standards give receiving servers better evidence for evaluating business email without confusing authentication with a guarantee of trust or successful delivery.