Eploy ATS SPF, DKIM and DMARC setup, step by step

For an existing Eploy account already approved to use Option 1A Amazon AWS (London) or Option 1B Amazon AWS (Ireland), retrieve the domain’s DNS instructions from Admin > Security Settings > Validate Emails > Configure AWS > Configure. Publish the three account-issued DKIM CNAMEs and SPF TXT at their issued owners. Publish the required MX at the specified eploymail subdomain, never your main domain’s MX. Then check AWS configuration, MAIL FROM and DKIM statuses separately, and test controlled internal and external recipients.

Use the exact record owners, targets, MX priority and SPF content supplied for your account and approved region. Do not derive tenant values from this guide, copy another organization’s records or move an existing London configuration to Ireland to make a test pass.

This is a documentary guide for Eploy’s native Option 1 route. It does not configure SMTP relay, migrate the legacy IIS method, activate Reply To options, or connect an Office 365 mailbox through EployMail. No customer DNS changes or messages were sent.

Confirm the sending method before touching DNS

Eploy supports materially different email routes. Its method-selection guide distinguishes Option 1A London and Option 1B Ireland, which send using the configured user/system address, from SMTP relay and the Basic/Advanced Reply To methods. The regional choice is an organizational policy decision, not a DNS troubleshooting technique.

The authentication overview explains that implementation can initially use the Basic Reply To route. That means having an Eploy account does not prove Option 1 is active or approved. Before using this guide, confirm the actual method, approved region and intended user/system sender domains with the account owner. If that information is uncertain, stop and obtain the current configuration from your authorized Eploy contact.

This guide assumes the native Option 1 route has already been chosen and approved. It does not authorize a route change, new data-processing region or mailbox integration. Eploy’s separate EployMail feature provides mailbox access and correspondence indexing; its OAuth/IMAP setup is not a prerequisite for the native AWS DNS workflow.

Prepare an approved record and routing plan

You need existing authorized access to the Eploy Core System’s email-validation controls, authoritative DNS for the relevant domains, and controlled test mailboxes. The public setup pages do not establish a universal subscription tier for this workflow; confirm account eligibility instead of assuming a plan or granting yourself additional permissions.

Before publication:

• List the approved Agency Details domain and any additional user/system domains that actually send email. Do not authenticate every listed domain automatically, particularly domains your organization does not own.
• Save the existing relevant TXT, CNAME, MX and NS records. Identify direct and inherited DMARC policies and authorized report recipients.
• Obtain owner approval for the exact account-issued records and the effect of satisfying validation for the existing route.
• Approve the specific MX owner, destination and priority. This record affects incoming mail routing at that owner, even though the larger task is outbound authentication. If the issued eploymail subdomain is already used to receive mail, resolve that conflict before editing it.
• Confirm the region and destination identities against the authorized configuration. A provider screenshot is not permission to route mail to a new destination.

Do not replace corporate MX records, change parent nameservers, remove NS delegations, disable DNSSEC or alter credentials. Do not implement blanket allowlisting merely because a vendor checklist mentions it. Security controls need their own assessment, as explained below.

1. Open the domain’s configuration in Eploy

In the Core System, go to Admin > Security Settings > Validate Emails. Eploy’s testing instructions call the middle menu System/Security Settings; use the corresponding current control in your account rather than guessing another settings page.

The tool lists an Agency Details domain in the upper section and other domains below. For each approved domain in scope, select Configure under Configure AWS. Retrieve the actual DNS packet for the existing approved Option 1A or 1B route. If the screen does not expose every required owner, type and complete value, obtain that missing information from your authorized Eploy contact before publishing. The public instructions do not supply enough information to reconstruct missing tenant records.

The configuration instructions specify these DNS components:

The public screenshots show configuration and status controls, not a reusable tenant DNS packet. No universal selector, CNAME target, SPF owner or MX priority is supplied here. If the live packet differs from the documented components, resolve that difference with Eploy before making changes.

One general domain-validation page refers broadly to validation through a DNS TXT entry. The more specific Option 1 configuration page explicitly requires three DKIM CNAMEs. Follow the actual issued record types and the specific procedure; do not convert the three CNAMEs into a guessed TXT verification record.

2. Put each record in the authoritative zone

Use the full owner from the account packet. Some DNS editors accept a full name, while others append the zone name or use @ for its root. Confirm the final published name; an apparently correct text field can produce a duplicated suffix.

For illustration, if an issued DKIM owner were SELECTOR._domainkey.recruit.example.com:

• In the parent example.com zone, a suffix-appending editor would use SELECTOR._domainkey.recruit.
• If recruit.example.com is separately delegated, its authoritative child zone would use SELECTOR._domainkey.
• If _domainkey.recruit.example.com is itself delegated, edit that authoritative namespace using SELECTOR as the relative owner.

SELECTOR and these domains are placeholders, not Eploy-issued values. For an issued MX owner such as eploymail.recruit.example.com, the relative label would be eploymail.recruit in the parent zone or eploymail in the delegated recruitment zone. If that exact eploymail owner is itself a delegated zone, its root is @. Preserve the delegation and edit the actual authority.

Apply the same full-owner mapping to SPF. Do not assume the SPF owner from the MX owner’s name: obtain it from the packet. Never delete another service’s selectors or shared delegations merely to make a new record fit.

3. Publish DKIM, SPF and the scoped MX

DKIM: three exact CNAME aliases

Publish every issued DKIM CNAME with its exact owner and destination. These point the verifier to public signing-key information; you do not need a private signing key. Do not create a local key pair or paste a sample key into DNS.

A CNAME owner cannot also hold conflicting TXT, A, AAAA, MX or another CNAME. If any owner is occupied, stop for an approved supported resolution. Do not silently omit one of the three records.

Keep the required literal CNAME answer visible. Use DNS-only rather than an HTTP proxy for these aliases. Where a per-record flattening control exists and hides the required CNAME, turn it off for the relevant record after approval. Also check applicable zone-wide, apex and same-zone behavior; do not disable a whole zone’s behavior casually. If mandatory flattening prevents the required alias answer, coordinate a supported configuration rather than inventing a switch. See Cloudflare’s current flattening controls and exceptions when that is your DNS host.

SPF: one policy at the issued owner

SPF evaluates the actual SMTP MAIL FROM domain, or HELO where relevant, not simply the visible From address. The validation tool’s separate MAIL FROM status is useful context, but the received message establishes which identity was actually used.

At the issued SPF owner, inspect any existing v=spf1 TXT policy. If one exists, reconcile the approved Eploy authorization into that one policy while preserving legitimate senders and policy semantics. If none exists, publish the approved issued policy there. “Add a new TXT entry” is not permission to add a second SPF policy at an already configured owner or replace the main domain’s working SPF.

Check the entire evaluated policy against the ten DNS-dependent-term limit, including nested mechanisms. This is not just a count of include strings. An all mechanism causes redirect to be ignored; do not use a redirect after all as an assumed extension. Preserve intended qualifiers and do not promise inbox placement or deterministic rejection from them. SPF standard: RFC 7208.

MX: only the issued eploymail host

Eploy expressly says the MX belongs at an eploymail host, not the main domain. Use the exact full owner, priority and target in the account packet, and compare them with the approved inbound-routing plan before publication.

Do not change the corporate root MX, redirect existing mailboxes, or invent a regional AWS endpoint. If the owner already has an MX or another dependency, stop and establish whether the proposed routing is acceptable. A successful outbound validation would not prove that existing inbound mail remained intact.

4. Check the three provider-side statuses

After publishing and inspecting the records, return to Validate Emails. The testing instructions distinguish Success or Failed for:

1. Configuration of AWS.
2. MAIL from Status.
3. DKIM Status.

Check all three for each approved domain. If a check fails, compare the actual account packet with authoritative DNS and correct only the approved discrepancy. Inspect the full owner, record type, target/value, delegation, CNAME visibility, SPF validity and MX location. Allow relevant caches to expire; waiting does not repair a wrong record.

The documented procedure uses the configured AWS route and these validation statuses. It does not establish a separate customer “Start DKIM signing” switch. Do not invent one, infer signing from DNS alone, or switch email methods to hide a failure. When the route or activation state is unclear, obtain confirmation from the authorized Eploy contact before testing real workflows.

5. Test controlled internal and external delivery

Once configuration succeeds, use the native per-domain tests in Validate Emails, not a candidate registration, interview invitation, vacancy approval or contract workflow.

For each approved domain:

1. Select its Test control for the intended internal or external check. Prefer individual domain tests over the bulk Test Domains Internally/Externally buttons so the scope stays explicit.
2. Select the intended Test Email Domain and an approved Test Email Recipient. Use controlled organizational and external test mailboxes, not candidates or unrelated employees.
3. Confirm the sender/domain and recipient, then select Send only under authorization for that test.
4. At the controlled mailbox, retain the original message and inspect its sender identities and authentication results. The recipient should open the expected test email and follow its confirmation link only after checking that it is the requested Eploy test.
5. Refresh the tool to see the receipt test result. Repeat the separately approved internal/external check where needed.

Eploy’s confirmation link establishes receipt confirmation in its tool. It does not itself prove aligned DKIM, and a successful external test does not prove internal filters accept the same route. Record provider configuration, receipt confirmation and message authentication as separate findings.

For final acceptance, also examine an approved harmless message through the exact user/system sending path you intend to rely on. A validation test cannot certify every recruitment automation. If testing a production workflow would notify candidates or alter records, do not trigger it without separate authorization; retain that path as untested instead.

Require the intended signature, not just a green result

Use Authentication-Results generated inside the known receiving service’s processing boundary, with its documented handling of externally supplied result headers. A matching authserv-id string, familiar hostname or header position alone is not a trust guarantee. Ignore attacker-supplied or otherwise untrusted result fields.

For this newly configured branded DKIM route, verify that:

• The intended Eploy AWS signature has dkim=pass, keeping its d= signing domain and s= selector together. An unrelated passing signature is insufficient.
• Its signing domain aligns with the intended visible From under the effective adkim setting. Relaxed alignment compares Organizational Domains; strict alignment requires exact domain equality.
• The trusted receiver reports dmarc=pass for that intended From. An SPF-only DMARC pass does not prove DKIM works.

Inspect SPF independently against the actual MAIL FROM identity. Relaxed aspf compares Organizational Domains, while strict aspf requires an exact match with From. A child envelope domain does not guarantee strict SPF alignment. Do not infer a universal Return-Path from the eploymail MX or treat a provider-owned rewritten From as successful authentication of your original brand.

See raw DKIM versus aligned policy results, RFC 6376 and the current DMARC standard, RFC 9989.

Handle internal filtering without weakening security

Eploy’s setup checklist calls for allowlisting supplied server IPs/ranges. Treat this as a separate security-owner review, not an automatic DNS step or a blanket instruction to bypass spam, phishing or spoofing checks.

First inspect the internal delivery diagnostic and trusted authentication results. If policy blocks an otherwise authorized route, have the security owner assess the exact current source ranges, scope, necessary controls and effect on spoofing protection. Do not broadly trust a visible From domain, disable security checks, or apply an exception to external recipient systems you do not control. If an approved safe configuration cannot be established, keep internal acceptance blocked and discuss it with Eploy.

Do not fall back to anonymous, unencrypted SMTP relay defaults to solve an Option 1 failure. Relay and EployMail/OAuth are different routes with their own security decisions, outside this guide.

Preserve DMARC and reporting choices

Keep existing direct and applicable inherited DMARC policies and authorized reporting destinations. Do not lower enforcement, duplicate a policy, or copy a report recipient from an example just to onboard Eploy.

Only when no applicable direct or inherited policy exists, the domain owner approves an initial monitoring policy, and someone will assess the results, this minimal example may be appropriate:

Full owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none

This is illustrative, not Eploy’s required record. A direct policy for recruit.example.com would use _dmarc.recruit.example.com, normally _dmarc in that child zone’s suffix-appending editor. Check inherited policy rather than assuming an empty direct lookup means none applies. The example has no report destination; add one only under an approved monitoring and data-sharing plan.

When a report destination’s Organizational Domain differs from the Organizational Domain of the domain where the policy was found, the report-generating receiver must check DNS authorization. A destination within that same Organizational Domain is excepted. See RFC 9990, section 4. Protocol authorization does not replace the owner’s privacy decision about sharing reports.

Troubleshooting by evidence layer

Share only approved, appropriately redacted diagnostics with support. Do not send candidate records, employment documents, credentials or whole sensitive messages by default.