Establish the limited eRecruiter configuration scope
This guide covers the provider-mail-server SPF route described in eRecruiter's official SPF-Record article. The source distinguishes provider delivery from customer-operated mail servers and on-premises installations. Its documented two-part route check uses Administration → Miscellaneous: Mandatorsettings → SMTP & EMail-Settings, where tenant SMTP-Host is empty, and Administration (system-wide) → Current static settings, where SmtpHost is shown as “epunkt-smtp...” or “er-mail...”. These are the source’s legacy displayed patterns, not a new executable hostname-matching rule. Confirm the current console, full setting values and route applicability with the authorized administrator. It specifies a:er-mail.erecruiter.net, expressly not include. Customer-server delivery does not require that provider authorization.
The supported implementation scope is therefore narrow: identify the documented route, review the appropriate SPF authorization and plan verification. This article does not establish a current eRecruiter DKIM workflow, issued selector, signing key or end-to-end DMARC-ready deployment. Keep that broader scope unresolved rather than filling it with a generic recipe. The catalogue title is retained, but its full implementation requirement still needs additional current product and operational evidence.
Before any change, obtain the actual account's configuration from an authorized administrator. Record the environment, mail-server ownership and message categories without exposing applicant information. Recruitment correspondence can contain resumes, interview details and personal contact data; none of that is needed to decide which system is responsible for the outbound mail path. Use configuration references and harmless test content instead of copying a real hiring conversation into a diagnostic worksheet.
Treat route identification as an evidence gate
An application can generate a message while a different system performs the final SMTP delivery. The relevant question is not simply whether the user clicked Send inside eRecruiter. It is which service transmits the message, which envelope identity is used and who controls that sender's authorization. Record the actual transport configuration and its observation date before choosing an SPF change. A previous migration plan or remembered setting is not current evidence.
For a customer-controlled route, assign responsibility to that mail service's operator rather than assuming the application vendor's authorization belongs in every domain policy. For a provider-controlled route, establish the exact domain and configuration to which the documented instruction applies. If the available account information does not distinguish those routes, stop at that uncertainty. Adding authorization “just in case” expands the policy without proving that it is needed.
A route inventory should distinguish production, test and any separately managed organizational units. Do not copy production DNS into a test environment automatically, or treat a test account's behavior as evidence for production. Record any exception that uses a different mail server. These are proposed review steps, not claims that the current product exposes particular additional controls or that such exceptions exist in a real account.
Understand the a mechanism before editing policy
RFC 7208, section 5.3 defines the a mechanism. It tests the sending IP against address records for the mechanism's domain, with the relevant address family and any specified prefix rules. It is not interchangeable with include, which evaluates another SPF policy and applies its own result mapping under section 5.2. Changing the mechanism type because includes look more familiar can fundamentally change the authorization being evaluated.
The provider hostname is a dependency, not a literal IP address copied permanently into the policy. Record why the mechanism is present and which application route needs it. Do not flatten it into an address list without a separately reviewed maintenance plan. A current address observation alone does not establish how that dependency will be maintained when the service changes infrastructure. This manuscript has not resolved or measured the hostname and supplies no observed IP addresses.
The provider's old example includes both TXT and dedicated SPF resource-record forms. Current SPF publication uses TXT: RFC 7208, section 3.1 discontinues the dedicated SPF RR type. Correct that legacy instruction explicitly rather than duplicating obsolete record types to imitate the example. The protocol correction does not, by itself, confirm that the provider's deployment-specific hostname remains appropriate for a current account; that applicability remains a separate gate.
Preserve the full authorization policy and evaluation budget
An existing domain may authorize employee mail, website notices and other applications. Review the intended eRecruiter authorization within that complete inventory rather than replacing the policy with a single-service example. RFC 7208, section 3.2 prohibits multiple SPF records that would be selected for the same owner. Keep one coherent policy and document the effect of each proposed change.
An a mechanism is one of the DNS-dependent terms counted under RFC 7208, section 4.6.4. The relevant limit is based on evaluated terms, including nested work where applicable, not simply a count of network packets or cache misses. Review plausible evaluation paths through the complete policy. Adding one apparently small mechanism can still matter if the existing path is already near a limit.
Keep syntax errors, excessive evaluation budget, missing DNS data and a valid nonmatching sender result separate. They require different remedies. Do not remove legitimate authorizations arbitrarily to make a checker display green, and do not weaken the terminal qualifier as a substitute for identifying the actual sender. An SPF pass is an authorization result for the evaluated identity, not a guarantee of delivery or a judgment about a candidate's message content.
Verify the envelope identity and retain the DKIM hold
RFC 7208, section 2.4 identifies MAIL FROM as an SPF identity. Compare the actual envelope domain with the domain where the proposed policy is published. The visible author address alone does not establish that relationship. A policy can be syntactically valid and include the intended mechanism yet be irrelevant to a message evaluated under a different envelope identity.
A separately authorized acceptance exercise should record the selected route, sending identity and trusted receiver result using harmless recruitment-style test content. It should not involve a real applicant's resume, interview schedule or personal details. Avoid uploading messages to an external checker unless the data-sharing decision is authorized. No DNS query, test message or external upload was performed for this guide.
RFC 9989, section 4.4 explains the additional alignment relationship needed for DMARC. A passing SPF result for an unrelated domain does not establish alignment with the visible author. This guide has no product-specific evidence establishing the account's DKIM setup, so it cannot close that part of authentication acceptance. Obtain current provider instructions and actual permitted message evidence before asserting complete sender readiness.
Fictional diagnosis and blank acceptance worksheet
A fictional recruitment team, Ash Grove Careers, copies a provider authorization into its domain policy after seeing the application name on a message. Its administrator later finds that the configured route uses the organization's own mail service. The added mechanism was therefore not evidence of the real sender's configuration. The proposed correction is to map the route, review which authorization is actually required and obtain a harmless receiver sample before marking the application ready. No real account, applicant or DNS observation is represented by this example.
- Environment and observed mail-server ownership: ______
- Route evidence and current product applicability: ______
- Tenant SMTP-Host empty and system-wide SmtpHost legacy pattern, with both console locations and current confirmation: ______
- Actual envelope domain and visible author domain: ______
- Complete TXT SPF policy and justified mechanism change: ______
- Evaluated-term budget and error-state review: ______
- Legacy dedicated-SPF-record correction, if relevant: ______
- Trusted receiver evidence from an authorized harmless test: ______
- Unresolved DKIM workflow and broader authentication evidence: ______
- Change owner, rollback plan and release decision: ______
Original implementation evidence, human subject-matter review, current applicability, production routes, visual accessibility and owner release remain open. This is an SPF-route-scoped documentary guide, not a completed eRecruiter authentication implementation. No account, DNS or mail-system change was made.