Start with the real sending systems
Your business may send through employee mailboxes, website forms, CRM, invoicing, marketing and support tools. The same visible From domain can be used in different ways by these services. Before editing DNS, identify the business owner, provider configuration, sending domain and test route for each legitimate source. Forgotten senders are a common reason for a policy change to disrupt operations.
A mailbox provider is not automatically responsible for every system that sends using the domain. Work begins with the authoritative DNS access, provider permissions and a list of functions that must keep working. Do not email us credentials or customer messages in an initial enquiry. If a provider or sender cannot be inspected, record the gap and agree how to resolve it.
What SPF, DKIM and DMARC each establish
SPF evaluates authorization for the sending server against the relevant envelope domain. DKIM verifies a signature associated with its signing domain. DMARC relates authentication to the domain the recipient sees in From. A passing aligned SPF result or a passing aligned DKIM result can satisfy DMARC; every legitimate route does not universally have to pass both.
These checks do not establish that the message content is honest or that the individual requesting a payment is authorized. A compromised legitimate mailbox may send authenticated messages. A lookalike domain is a separate problem. Scope should distinguish authentication configuration from mailbox security, delivery troubleshooting and fraud-response decisions.
| Mechanism | What to check | What a pass does not prove |
|---|---|---|
| SPF | Authorized sources and relevant evaluation path | That the visible From identity is independently authenticated |
| DKIM | A valid signature from the expected signing domain | Message confidentiality or the sender person's authority |
| DMARC | A passing aligned authentication route | Inbox placement or absence of mailbox compromise |
Configure with provider-specific evidence
SPF changes need a current inventory and an understanding of its DNS-dependent evaluation limits, including nested dependencies. DKIM setup needs the provider's signing configuration as well as the correct selector and key publication. A DNS record that exists is not evidence that the production service is signing the messages you care about.
For each sender, agree an authorized test message, its expected visible domain and the receiving evidence used to assess it. Distinguish a DNS observation, a provider setting and a result in a delivered message. Use headers from a trusted receiving path and redact unnecessary addresses, content and identifiers before sharing evidence.
Move toward enforcement using acceptance gates
A monitoring policy helps gather information before enforcement, but reports require interpretation and follow-up. Link observed sources to a real business function, resolve authentication or alignment failures and check periodic senders such as monthly billing. An observed source is not automatically legitimate, and one successful message is not coverage of an entire business cycle.
RFC 9989, published in May 2026, supersedes RFC 7489. Do not treat the older pct tag as a current guaranteed way to phase deployment. Choose a rollout and rollback method supported by the providers and applicable policy, test agreed routes and retain a decision-maker for exceptions. A calendar deadline alone is not evidence that enforcement is ready.
Define the deliverables before changing policy
Useful deliverables include the sending inventory, configuration changes, test evidence, chosen policy, unresolved routes and the owner who will review new senders. If a reporting product or licence is needed, state who owns it and whether its ongoing management is in scope. Implementation and ongoing monitoring are separate responsibilities even when they use the same dashboard.
The handover should make future changes manageable. A new marketing tool or replacement CRM can introduce another sending path. Record what the business must check before enabling it and which supplier will handle faults. We do not label a domain fully protected merely because a reject policy appears in DNS.
Israeli specialization, worldwide service and clear limits
CyberFixCrew is an Israeli cybersecurity company focused on business websites and digital infrastructure. Email authentication is handled together with the site and other sending systems that depend on it. Remote coordination specifies authority, DNS ownership, time zones and supplier participation. The engagement identifies who can approve each change and who will maintain the sending configuration afterwards.
DMARC configuration does not guarantee Gmail or Microsoft inbox placement. Reputation, content, recipient policy and other factors can affect delivery. It does not secure every mailbox or prevent every display-name impersonation. Google and Microsoft publish their own sender guidance; the checks must fit the provider and sending pattern in use rather than a single record pasted into every domain.
What affects the quote and what to send first
The scope depends on domains, subdomains, sending platforms, access, unresolved legacy configuration and the amount of implementation and monitoring required. Third-party subscriptions and any separate mailbox investigation should be explicit. The project is quoted after mapping the systems and acceptance criteria.
Send the domain, mail platform if known, a list of business senders and the reason for the request. If you suspect actual account compromise or a fraudulent payment request, say so without forwarding secrets or payment details. Those situations need an appropriate incident or financial response alongside authentication work.