Recruiting Email Authentication: A Practical Checklist

To test recruiting email authentication, send a synthetic candidate message through each service you actually use. Inspect the receiving mailbox’s SPF, DKIM, and DMARC results, check domain alignment, and confirm where replies arrive. A successful send does not prove inbox placement, reading, or a candidate response.

The Hacker News discussion of Mailfully’s authentication guide brings a familiar setup problem back into view. Your founder’s mailbox, ATS, and scheduling service can all display your company name while sending through different infrastructure. Making one work tells you little about the others.

Keep a small acceptance record for each path. Build it without replacing working DNS records or treating a green setup badge as proof of delivery.

Which services send recruiting email from your domain?

Inventory the services that send candidate messages before changing DNS. Each distinct sending path needs its own test, even when every message appears to come from [email protected].

Start with the mailbox your recruiter or founder normally uses. Then add the ATS path for application acknowledgments and candidate replies, the scheduler that sends interview invitations, and any separate service used for offers or assessments. Record who administers each service and which domain it should use.

This separation follows from how email authentication works. The standards evaluate sending infrastructure and domain identities, which can differ behind the same visible From address. It is an operational reason to test each path, not evidence that every ATS has a delivery problem.

Include enough detail to catch a wrong assumption:

Use invented applicant details and mailboxes your team controls. You can learn whether the reply reaches the right application without contacting a real candidate or sharing their conversation with a diagnostic service.

Keep this technical test separate from the human promise. Our Hacker News hiring reply plan covers who reviews applications and when applicants hear back. Authentication can support that process; it cannot assign a reviewer or make them respond.

What do SPF, DKIM, and DMARC actually verify?

SPF authorizes sending infrastructure for an envelope identity. DKIM verifies a signature associated with a signing domain. DMARC checks whether a passing result aligns with the domain in the From address the recipient sees.

These identities are easy to confuse because your email app usually shows just one address. The underlying message carries several:

SPF’s specification distinguishes the envelope identity from the visible From header. DKIM’s specification describes the domain signature. Neither a familiar display name nor a useful Reply-To address establishes DMARC alignment.

Consider this fictional direct message:

From: Hiring Team <[email protected]>
Envelope sender: [email protected]
DKIM signing domain: example.com

The vendor’s SPF result could pass for vendor.example.net while failing to align with example.com. A valid DKIM signature for example.com can still provide the aligned passing result DMARC needs. DMARC does not require both mechanisms to pass and align; at least one aligned passing mechanism can satisfy its authentication test. RFC 9989 explains this rule.

Alignment also has a mode. Relaxed alignment can accept domains sharing an organizational domain; strict alignment requires an exact match. A sending subdomain is therefore not automatically a failure. Record the actual domains and policy instead of flagging every difference as a defect.

This verifies domain use, not the legitimacy of a job offer or the intentions of whoever sent it. For that separate problem, see our article on recruiter impersonation and candidate trust.

How do you add a sender without breaking existing email?

Get the new service’s current domain instructions, then reconcile them with the records already published. Treat sample DNS values as explanations, not settings for your own domain.

First establish whether you are configuring outbound authentication, inbound routing, or both. An MX record directs incoming mail. Changing it can move employee or candidate replies to a different service; it does not authorize outbound sending. If your main domain already receives employee email elsewhere, a dedicated recruiting mail subdomain can keep that routing decision separate.

For SPF, preserve your legitimate existing senders. Adding an ATS should not silently remove the authorization your employee mailbox needs. Publishing a second SPF policy is not a safe way to avoid editing the first: SPF record selection produces a permanent error when it finds multiple selectable records.

SPF also limits the evaluated mechanisms and modifiers that cause DNS lookups. The limit is ten such terms, including contributions from nested includes. It is not a count of every DNS request your resolver makes. If your policy accumulates providers, inspect its evaluation rather than counting the words in the TXT record. The details are in RFC 7208’s evaluation limits.

For DKIM, publish the selector and key or delegation supplied by your sending provider. A record for the employee mailbox’s selector does not automatically configure the ATS. Record which service owns each selector so that removing a provider later does not delete another service’s working signature.

For DMARC, inspect the existing policy before replacing it with a tutorial’s example. Someone may already be collecting reports or enforcing a stricter policy. Give the domain owner the full proposed change, including retained senders and the intended reporting destination, before applying it.

How do you test the actual candidate email path?

Send through the real workflow, inspect the receiver’s results, and reply. A test from an administrator’s mailbox does not exercise the ATS’s outbound configuration.

For each inventory row, create a recognizable test subject and use a mailbox you control at the recipient provider you want to examine. In the ATS, use a fictional application and the same reply action a recruiter would use. In the scheduler, trigger the actual invitation workflow rather than manually reproducing its text.

Open the received message’s full headers or original-message view. Record the visible From, the envelope domain shown after delivery, and the DKIM signing domain. Then find the authentication results added by the receiving service. Use that service’s trusted results; a line copied into the message by an earlier sender is not equivalent evidence.

Your acceptance sheet can stay small:

Include the date, sending configuration, recipient provider, and owner. Record whether the test appeared in the inbox or spam folder as a separate observation. Keep enough evidence to investigate a failure, without putting private headers or candidate content into a public issue.

Finally, press Reply and send a short response. Confirm that it reaches the intended mailbox or candidate thread and that the right teammate can see it. A scheduler may intentionally use a different reply route; document that behavior rather than assuming every invitation returns to the ATS.

A passing row proves something useful about that message, path, configuration, and receiver. Repeat for another important recipient provider if needed. Forwarded messages and mailing lists introduce other authentication behavior, so investigate those separately before treating an SPF failure as proof of an unauthorized sender.

What do Gmail and Yahoo require from your sending domain?

Both providers publish sender requirements, with additional duties for bulk senders. Scope the requirement to the recipient provider, sending volume, and message purpose before using it as your checklist.

Google’s sender guidelines apply to messages sent to personal Gmail accounts. All senders need SPF or DKIM, valid forward and reverse DNS, TLS, compliant formatting, and low reported spam. Bulk senders need SPF, DKIM, DMARC, and alignment, among the other listed requirements.

Google’s sender FAQ describes bulk classification at around 5,000 messages in a day to personal Gmail accounts. It aggregates subdomains under the primary domain and says the classification persists once assigned. Count the domain’s relevant sending activity, not just your recruiter’s daily messages. These rules are scoped to personal Gmail recipients, rather than Google Workspace recipient accounts.

Yahoo’s requirements similarly call for SPF or DKIM from all senders, and both mechanisms plus passing DMARC from bulk senders. Yahoo accepts at least a p=none policy and relaxed alignment. Its FAQ deliberately gives no numeric bulk threshold, so Google’s number is not a Yahoo rule.

Keep unsubscribe requirements attached to their message category. Google exempts transactional messages from its one-click requirement, but that does not make every message sent by a recruiter transactional. A response to an applicant and a promotional recruiting newsletter serve different purposes. Check the actual message and provider guidance.

For qualifying messages, Gmail requires the POST mechanism described by RFC 8058; a mailto link alone is insufficient. Yahoo currently accepts mailto while recommending POST, and requires easy unsubscribe for bulk marketing or subscribed messages. Do not infer identical implementation rules just because both providers use the phrase “one-click.”

Why can authenticated recruiting email still land in spam?

Authentication is one input to filtering. A receiver can accept an authenticated message and still place it in spam based on reputation, complaints, content, or recipient preferences.

The Gmail guidelines and Yahoo guidance cover these wider signals. Neither makes an authentication pass an inbox-placement certificate. If your test passes authentication but lands in spam, investigate that observed filtering result instead of repeatedly replacing correct DNS records.

Separate failures by where they occur:

An earlier boundary matters too. Successful SMTP submission means the accepting server takes responsibility at that hop, as described in RFC 5321. Your application hands mail to its sending server before the recipient can put it in an inbox.

Keep four events distinct in your team’s language: SMTP handoff, observed recipient placement, reading, and replying. A “sent” timestamp does not establish the later three. A lack of response likewise does not diagnose an authentication failure; it could reflect the candidate’s decision or your message.

What should you check after changing providers?

Repeat the affected acceptance rows after changing a sender, domain, signing configuration, or scheduling integration. Review the DMARC policy and reports with the person who owns the domain.

DMARC p=none expresses no preference for quarantine or rejection. Aggregate reporting is configured separately with a reporting destination. Publishing it alone does not block impersonation. To use reports, configure a working reporting destination, assign someone to review them, and check any authorization needed for an external destination. DMARC’s reporting rules cover that external authorization.

Before moving toward quarantine or reject, identify legitimate senders and investigate their failures. Confirm that employee mail, ATS replies, scheduling, and any other retained services work with the intended alignment. Agree on the enforcement change with the domain owner, then check what happens after it takes effect. RFC 9989 defines the policies, while receivers retain discretion over handling.

Make provider removal an explicit change too. Confirm which SPF authorization and DKIM selector belonged to the old service, preserve the others, and decide where old replies should go. A candidate can respond to an invitation sent before your migration; the new outbound test does not prove that older inbound route survives.

How Kit handles your recruiting domain and candidate replies

A hosted recruiting domain needs both a configured sending identity and a working candidate conversation. You should verify the received message even when the setup page reports success.

Kit’s Startupkit Email setup presents MX, DKIM, SPF, and DMARC records for your configured domain. Kit generates a domain-specific DKIM key pair and configures signing through its mail server. The suggested DMARC policy starts at p=none.

Eligible candidate mail can use your configured hiring inbox for the visible From and envelope sender. Send-as requires an active integration, signing keys, verified sending records, and explicit activation. DNS checks and provisioning status are separate: “Active” means the service is provisioned, not that every DNS record has propagated.

Those checks have a specific scope. Kit checks for the expected key content, its SPF authorization marker, and a DMARC version marker. It uses cached verification state, updated by asynchronous DNS checks. This is not a full SPF-policy evaluation, a DMARC report-analysis dashboard, or a fresh DNS lookup for every message.

Kit also records candidate replies in the hiring conversation. Its successful-send timestamp follows the application handing the message to the SMTP transport; it does not prove recipient inbox placement or reading. Your receiver test shows what happens after that handoff.

Start with one fictional candidate reply: send it through the configured Kit path, inspect the received authentication results, and answer it back into the application. Then complete the rows for your employee mailbox and scheduler. If you are evaluating Kit for hiring, this is a useful task to include in your trial, with a named owner keeping the results current.