SPF, DKIM and DMARC: a practical guide for sales teams

Know the three questions authentication asks

SPF authorizes sending hosts for an envelope-domain identity. DKIM adds a domain-associated cryptographic signature that a receiver can verify. DMARC checks whether a successfully authenticated SPF or DKIM identity aligns with the domain in the visible From address and communicates domain-owner policy and reporting information. These are complementary mechanisms; the visible sender name is not itself proof of authentication.

For a sales operator, the practical consequence is that 'our provider says SPF passes' is an incomplete answer. Which domain passed? Which domain appears in From? Is DKIM signing enabled for this particular sending service? Does the receiver report DMARC pass? Ask those questions for the actual message stream rather than assuming one successful mailbox test covers every application.

Keep the explanation tied to responsibilities. The administrator manages DNS and provider configuration. The sales operations owner maintains the sending inventory and campaign controls. The sender confirms that the intended identity and reply handling are correct. These roles can belong to one person in a small business, but each responsibility still needs to be performed.

References: RFC 7208: Sender Policy Framework ↗ · RFC 6376: DomainKeys Identified Mail Signatures ↗ · RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance ↗

Inventory every service that sends as your organization

List ordinary employee mail, CRM messages, marketing platforms, support systems, billing notices, website forms, product notifications, and any agency-managed service. Include occasional senders such as webinar tools or event software. An enforcement change made without this inventory can affect legitimate messages that the sales team never sees in its own outbox.

For each service, record the business owner, technical owner, visible From domain, reply destination, envelope domain where known, DKIM signing domain, provider account, purpose, and last verified date. Add the person who can disable sending if the stream behaves incorrectly. Do not put passwords, private keys, or full message contents in the inventory.

Ask owners to demonstrate a real message sent through the normal workflow. A provider's generic setup guide may describe a different sending mode from the one your account uses. For example, a CRM can send through a connected mailbox or through its own infrastructure. The inventory should describe the configured path, because that is the path the receiver evaluates.

Review SPF as a controlled authorization change

SPF is published in DNS for the relevant domain and evaluated using the sending host and the envelope identity. The specification limits DNS-querying mechanisms and modifiers during evaluation; complex nested includes can therefore create problems even when the text looks plausible. Do not add a second independent SPF policy simply because another provider supplies an example. Ask the administrator to integrate the authorized service into the existing policy correctly.

The sales team's job is to provide the business evidence: which service is being added, why it must send, which account uses it, and when it should be retired. The administrator should review the current record, the provider's exact requirements, the resulting evaluation, and the rollback plan. A copied record from another company is not a safe shortcut.

After the change, send a controlled test through the affected service and inspect the receiver's result. Also test an existing important stream so the change has not broken unrelated mail. Record the change date and the services checked. When a tool is no longer used, remove its authorization through the same controlled process rather than leaving a growing collection of obsolete senders.

References: RFC 7208: Sender Policy Framework ↗

Confirm DKIM for the actual sending service

DKIM verification uses the signing domain and selector in the message to locate the public key. The sending service controls the private signing key. A DNS record alone does not prove that a service is signing outbound mail correctly; inspect a message produced by the normal workflow and confirm the receiver's result.

During setup, record the service, selector, signing domain, and configuration owner. Use the provider's current instructions for its supported key and DNS configuration. If a provider rotates selectors, coordinate the timing so legitimate in-flight messages remain verifiable as intended. The sales team should know who owns the rotation and how a failure will be detected, without needing access to private keys.

If a message fails DKIM, preserve a representative header and the sending path for the administrator. Message modification, incorrect DNS, a mismatched selector, or a configuration problem may require different repairs. Avoid guessing from the fact that one provider accepts a message while another rejects it. Compare the actual authentication result and the relevant service configuration before changing records.

References: RFC 6376: DomainKeys Identified Mail Signatures ↗

Use the current DMARC standard and inspect alignment

RFC 9989, published in May 2026, is the current DMARC specification and obsoletes RFC 7489 and RFC 9091. It describes validation of the author's domain, domain-owner handling preferences, and reporting. Older implementation articles may still be useful background, but configuration decisions should be checked against current standards and the receiving provider's current guidance.

For day-to-day troubleshooting, ask whether a passing SPF or DKIM identity aligns with the visible From domain under the applicable alignment mode. A message can pass SPF for a provider-controlled domain while failing to establish the necessary relationship with the organization's From domain. The administrator should inspect the complete result rather than treating the word 'pass' anywhere in the header as sufficient.

Use reporting to understand legitimate streams and unexpected use before tightening enforcement. Decide who reads the reports, how anomalies are investigated, and how a business owner confirms a legitimate service. A policy record with no operational owner can create the appearance of control while important evidence is ignored. Keep changes reviewable and coordinate them across all known senders.

References: RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance ↗

Worked example: SPF passes but the team still has a problem

This fictional example uses the reserved domain northstar.example. A salesperson sends through a new application with visible From address alex@northstar.example. The receiver reports that SPF passed for a provider-controlled envelope domain. The application is not signing with an aligned organizational domain, and the message does not pass DMARC. The team initially assumes authentication is correct because the application's setup screen shows a green SPF indicator.

The operator records the actual sending service, visible From domain, envelope domain, DKIM result, and DMARC result. The administrator compares them with the service's supported configuration and finds that the custom domain setup was not completed. The affected stream is paused while the configuration is corrected. Ordinary employee mail remains a separate stream and is tested independently.

After the repair, the team sends another controlled message and checks the receiver's reported result for that exact path. It records the verified configuration in the inventory and adds a launch gate for future tools. The lesson is not that a particular provider is unreliable. It is that a status indicator must be interpreted in relation to the identity and message stream it describes.

Collect a useful test message and header record

Send a controlled message from each configured stream to mailboxes your team controls or has permission to use for testing. Use a harmless subject and body that identify the stream and test time. Do not use a real prospect as a diagnostic instrument. The test should follow the same path as ordinary messages, including the application and sender identity.

Use the receiving mailbox's message-source or header view to inspect authentication results. Preserve the relevant header excerpt, date, destination provider, sender identity, and application. Avoid circulating full headers broadly if they contain unnecessary personal or infrastructure details. A concise diagnostic record should give the administrator enough information to reproduce the issue.

Repeat the test after material changes such as a new sending service, domain configuration, provider migration, or signing-key rotation. A passing result from months ago does not establish the current state. Store the evidence with the inventory so the next reviewer can see what was tested, when it was tested, and whether the test represented the actual production workflow.

Check recipient-provider requirements separately

Authentication standards and mailbox-provider sending requirements are related but not identical. Google's sender guidance includes authentication, transport and DNS expectations, spam-rate controls, and unsubscribe requirements for relevant traffic, with additional requirements for bulk senders. Microsoft documents authentication-related rejection behavior for Outlook.com consumer services. Review the applicable provider pages before launch rather than relying on a generic checklist remembered from a previous year.

Do not treat a volume threshold as permission to send unwanted mail below it. The team's decision about audience, preferences, and appropriate contact remains necessary at every volume. Likewise, using a third-party application does not transfer responsibility for the organization's domain configuration or the messages sent under its identity.

Keep a provider-review date in the launch checklist and name the person responsible for updates. If a requirement affects headers or unsubscribe behavior, verify what the actual application produces. A visible unsubscribe sentence and an implemented one-click mechanism are different things. The sales operations owner should coordinate with the sending provider to confirm the required behavior for the message category being sent.

References: Google: Email sender guidelines ↗ · Microsoft: Fix NDR error 550 5.7.515 in Outlook.com ↗

Worked example: an enforcement change exposes a forgotten sender

In this fictional scenario, Ridge Consulting has configured ordinary employee mail correctly and plans a stricter DMARC policy. Its inventory initially lists only the employee mail service and the main marketing platform. During review, the finance team identifies an invoicing system that sends from the organization's domain, and the support team identifies a ticketing service.

The administrator asks each owner for a representative message and checks the sending configuration. One service needs additional setup before the policy change. The team records its owner, purpose, and verified path, then retests the important streams. The change is scheduled with an explicit rollback plan and an owner available to inspect unexpected failures.

The sales team contributes by identifying a rarely used event tool and by pausing a planned campaign during the change window. It does not attempt to repair DNS independently. The example shows why authentication work crosses departments. A sales-only inventory may miss legitimate traffic, and a technically valid policy can still disrupt the business if the inventory and change process are incomplete.

Triage failures by evidence instead of folklore

When messages fail, classify the symptom before choosing a fix. Is the message rejected with an authentication code, temporarily deferred, accepted but placed in spam, or missing without a clear result? Preserve the exact response and affected sending path. These situations may have different causes, and a subject-line rewrite is not a general remedy.

For a clear authentication failure, pause the affected stream and involve the configuration owner. For broader placement or reputation concerns, review audience quality, preferences, complaint signals, content accuracy, and sending behavior alongside technical configuration. Do not replace domains or identities to bypass a provider's controls. Repair the underlying issue and use the provider's documented support or remediation process where appropriate.

Maintain an incident record with start time, affected services, observed errors, suspected cause, changes made, and verification results. This helps prevent repeated trial-and-error changes that make the system harder to understand. Resume normal work only after the relevant failure is resolved and a controlled test shows that the intended sending path behaves as expected.

Interpret a prospect's authentication signals cautiously

Public DNS can provide evidence about published records, but it does not reveal every sending path or establish how a company manages its email program. A missing record at one queried name may reflect an incomplete query, a different sending domain, or a service configuration that needs further investigation. A detected record does not prove that every message authenticates correctly.

If authentication observations inform prospect research, store exactly what was observed, where, when, and with what limitation. Keep the observation separate from a claim that the company has a deliverability problem. An outreach message should not announce that the recipient's email is broken based on a shallow scan. A more responsible use is to ask whether a relevant operational review would be useful, if the offer and contact are appropriate.

When using StackShortlist criteria, treat technology and authentication findings as research signals rather than buying intent. The scope you select is what you pay for at checkout. The catalogue describes supported criteria and technologies, not a live count of companies currently matching every combination. A source-backed observation can help frame a question; it cannot establish private infrastructure, urgency, or budget.

Keep authentication separate from permission and relevance

A correctly authenticated message can still be unwanted, misleading, or inappropriate. Before sending, confirm the business reason for contact, the relevance of the role, applicable communication requirements, and any recorded preference. A purchased business address does not itself demonstrate that the recipient requested your messages. The campaign owner must make a separate eligibility decision.

Make stopping easy and operationally reliable. A reply asking for no further contact should update suppression and cancel inappropriate queued follow-ups. If the message category requires specific unsubscribe functionality under provider rules, verify that functionality in the actual sending system. Do not rely on a salesperson remembering to remove the contact manually from several tools.

Use authentic sender information and a clear purpose. Avoid pretending to continue a conversation that never happened or making technical claims that the research does not support. Authentication helps protect domain identity; the content and workflow should be equally honest about who is contacting the recipient and why.

Assign ongoing owners and change triggers

Create three ongoing responsibilities: an inventory owner, a configuration owner, and a campaign approval owner. The inventory owner tracks services and business purposes. The configuration owner controls DNS and technical changes. The campaign owner verifies that the intended stream is approved and that audience and preference checks are complete. In a small team, record the names even if one person fills several roles.

Define events that trigger a new review: adding a tool, changing a From domain, moving providers, enabling a new application sending mode, retiring a service, changing signing keys, or observing new authentication failures. A recurring calendar check can help, but event-driven review catches changes when they occur.

Keep a compact evidence trail. The latest inventory, change record, test result, and incident owner should be easy to find. Avoid collecting large quantities of reports that nobody reviews. The useful output is an understood sending system with clear accountability, not a folder full of technical artifacts.

Use a launch and change acceptance checklist

Before approving a new sending path, have the operator describe the normal workflow and the administrator confirm the relevant authentication evidence. Test replies and preference handling as well as outbound authentication. The team should know how to stop the stream promptly if an issue appears.

After a change, verify the changed stream and a representative set of existing important streams. Record what was checked and any unresolved limitation. Do not convert an incomplete test into a general claim that the entire domain is healthy. A precise, limited conclusion is more useful than a broad green status with no supporting detail.

• Every legitimate sending service has a named business and technical owner.
• The actual visible From, envelope, and signing identities are recorded for each stream.
• A representative received message has been inspected after material configuration changes.
• DMARC guidance is checked against RFC 9989 and current provider requirements.
• Suppression, reply handling, and required unsubscribe behavior work in the sending application.
• Failures have a pause, escalation, repair, retest, and documented resumption process.