Greenhouse SPF, DKIM and DMARC setup, step by step

Direct answer: For Greenhouse Recruiting's Mailgun route, register the sending domain in Configure > Dev Center > Email Settings, publish the SPF and DKIM TXT records generated for that registration, add the required subdomain MX records, and run Check DNS Records Now. Then verify a delivered Recruiting message. Custom SMTP and Sourcing Automation need their own mail-provider checks; adding a generic Greenhouse SPF include to your root domain is not a substitute. Greenhouse domain verification

This guide describes supported configuration and acceptance checks, not a completed account setup, DNS change or delivery test.

Contents

• Choose the Greenhouse route first
• Prerequisites and change plan
• Register the domain and collect its records
• Publish SPF, DKIM and supporting DNS safely
• Activate and validate, in two separate stages
• Troubleshooting Greenhouse-specific failures
• Custom SMTP is a separate deployment
• DMARC reporting and maintenance
• Frequently asked questions
• Review scope

Choose the Greenhouse route first

Greenhouse's FAQ describes Mailgun as the default route for candidate messages, invitations, notifications and mentions. The current service configuration page offers Mailgun or custom SMTP for the organization. Sourcing Automation's separate security page directs users to their email provider, including Google and Outlook guidance. Recruiting FAQ, service configuration, Sourcing Automation security

Record the feature, intended visible From address, current service, sending domain and affected users before editing anything. A message from a vendor-owned notification address does not demonstrate that a candidate email from your own domain is authenticated.

Prerequisites and change plan

Greenhouse lists Core, Plus and Pro for its current email-settings documentation. Use a Site Admin with Can configure email settings permission and involve the administrator of the authoritative DNS zone. Sourcing Automation separately requires Job Admin or above, CRM access and a Sourcing Automation seat/add-on. Do not assume those entitlements are interchangeable. Service permissions, sourcing permissions

Before the change:

• Export existing DNS records and record their TTLs, owners and purpose.
• Inventory current SPF, DKIM selectors, root and subdomain DMARC policies, and receiving MX records.
• Decide whether the normal gh-mail route meets your alignment requirements.
• Choose a quiet change window and a rollback owner. Removing an existing registration can interrupt the working route; do not do it merely to experiment.
• Keep candidate data, credentials and private keys out of public DNS and support screenshots.

Register the domain and collect its records

1. Open Configure > Dev Center > Email Settings.
2. Confirm Mailgun is the route you intend to configure.
3. Enter the domain portion of the intended sending address, without @, and select Register.
4. Copy the generated hostnames, record types and required values. Greenhouse can also send the instructions through Email Your I.T. Dept to an authorized DNS administrator.
5. Publish the actual records returned by this registration. Do not reuse a public key, selector, MX target or tracking CNAME from a screenshot or another organization.

By default, Greenhouse registers a gh-mail subdomain. It helps avoid conflicts with a root domain already registered in Mailgun or a crowded root SPF policy. The visible sender address need not change simply because the envelope uses a subdomain. Registration and gh-mail behavior

Does strict DMARC require removing gh-mail?

Not simply because your policy is p=reject. Enforcement and alignment are different settings. aspf=s requires the authenticated SPF domain to equal the visible From domain; adkim=s requires an exact DKIM signing-domain match. Relaxed alignment permits an organizational-domain match. DMARC needs one aligned authentication pass, not both. DMARC, RFC 9989

For configurations that cannot use gh-mail, Greenhouse documents registering the domain with a leading exclamation mark, such as !example.com, to suppress that automatic subdomain. This is Greenhouse registration syntax, not a DNS hostname. The documented migration removes the old registration and generates a new one. Plan this with IT and, where needed, Greenhouse Support; review root SPF capacity and existing Mailgun use first. Preserve the existing DMARC policy rather than weakening alignment or enforcement to make a test pass. Greenhouse no-gh-mail procedure

Publish SPF, DKIM and supporting DNS safely

SPF authenticates the SMTP MAIL FROM domain, not the displayed From address. A root SPF edit will not fix an incorrectly configured gh-mail.example.com policy. At each owner, maintain only one TXT record beginning v=spf1. Preserve legitimate existing authorizations and the established terminal policy; do not paste a second full policy or automatically replace -all with ~all. SPF permits at most ten evaluated DNS-querying terms across the evaluation, including nested includes and redirects. This is not ten vendors or ten visible includes. SPF, RFC 7208

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Greenhouse's current DNS troubleshooting documentation specifies TXT for both SPF and DKIM. If the DNS editor appends the zone name, enter only the relative owner portion it needs; inspect the final name to avoid a doubled suffix. For the optional tracking CNAME, use DNS-only and disable CNAME flattening that would hide the alias. Cloudflare CNAME verification guidance

Only for the approved optional tracking CNAME, preserve the literal issued alias: turn relevant per-record Flatten off where the authoritative DNS host offers it, and ensure applicable zone-wide settings do not suppress that answer. On Cloudflare, flatten-all prevents per-record overrides, apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of the setting. If mandatory behavior or a shared control prevents the required literal alias, stop and coordinate a supported configuration with the DNS owner and provider without disrupting dependent records or removing NS delegation. These Cloudflare controls are not assumed to exist at every DNS host. This is not a CNAME requirement for Greenhouse’s TXT DKIM key. Cloudflare CNAME verification, flattening controls and limits.

For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

Do not place a CNAME at an owner that already has other data. Request a conflict-free owner rather than deleting unrelated records. Greenhouse DNS troubleshooting

Greenhouse defaults to a 2048-bit DKIM key. Its documentation offers a shorter-key option when a DNS editor reports a length problem. First check whether your DNS host supports splitting a long TXT value into multiple character strings within one record; a 255-character string limit is not necessarily a whole-key limit. Do not truncate the key or downgrade it solely because of an editor warning. Follow your DNS host’s format and your security team's key-strength requirement. DKIM signs messages; it does not encrypt their contents. Greenhouse key options, DKIM, RFC 6376

Activate and validate, in two separate stages

First check the public DNS and Greenhouse verification state. Replace these illustrative names with the generated owners; these commands do not change DNS:

dig +short TXT gh-mail.example.com
dig +short TXT SELECTOR._domainkey.gh-mail.example.com
dig +short MX gh-mail.example.com
dig +short TXT _dmarc.example.com

The DKIM owner must match the registration, even if it differs from this illustrative shape. Query authoritative nameservers as well as a recursive resolver when diagnosing propagation. Expect exact required values, one SPF policy, and an intact DKIM key. Return to Show domain details > Check DNS Records Now. Greenhouse says DNS visibility can take up to 48 hours; that is not a reason to ignore an incorrect owner or truncated value. Verification steps

Before publishing or activating the issued MX design, obtain the mail-routing owner’s separate approval of the complete full-owner, numeric-priority and target set for the actual registration. Receiving generated records is not approval of their routing consequences. Compare the entire approved set at authoritative and public recursive DNS, preserve corporate receiving MX, and stop on any unapproved or conflicting tuple. Do not treat one matching target as validation of the full route.

Second, send an authorized test through the real Recruiting workflow to a mailbox whose original headers you can inspect. Use the receiving service's trusted Authentication-Results, not arbitrary upstream headers or only a dashboard check mark. Save:

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

• Visible From domain and actual Return-Path/smtp.mailfrom domain.
• SPF result and the domain it authenticated.
• Each DKIM result, header.d signing domain and header.s selector.
• DMARC result for the visible From domain, with the aligned pass identified.
• Message ID, timestamp, workflow and Greenhouse registration used.

Accept the route only when the intended sender is present, the expected branded DKIM signature passes and aligns with that sender, SPF behaves as expected for the envelope, and DMARC passes through aligned SPF or DKIM. An SPF-only DMARC pass does not complete the DKIM setup. Investigate SPF fail, permerror and temperror separately even if aligned DKIM carries DMARC; do not ignore an authorization or DNS-resolution fault. Repeat for materially different candidate/notification routes rather than extrapolating from one message. Delivery and inbox placement remain separate from authentication success.

At the actual observed envelope domain, diagnose SPF authorization fail or softfail separately from transient evaluation temperror (often DNS) and invalid-policy, duplicate-policy or lookup-budget permerror. Investigate each even when aligned DKIM supplies DMARC; do not add authorization at an unrelated apex to conceal the error. SPF result definitions.

Troubleshooting Greenhouse-specific failures

The fallback domain and Mailgun route are documented in the service guide; bounce-list troubleshooting is covered in the FAQ.

Custom SMTP is a separate deployment

The March 2026 service guide documents selecting Custom SMTP, entering IT-provided connection details, testing receipt and saving. It also says the service applies across the organization and can be changed without contacting Support. The domain-verification page still describes paid, solutions-engineer-assisted SMTP options. Treat this as an entitlement/documentation ambiguity: use the current service workflow where offered, but confirm account access and commercial requirements rather than assuming either that SMTP is free or that every change requires Support. Current service workflow

A switch to SMTP requires the final mail system's authorization, DKIM signing and receiver-side alignment checks. A successful SMTP connection proves neither DKIM nor DMARC. Do not switch the entire organization as an improvised fix for a single DNS error.

For an approved Microsoft 365 transport, consult the separate Microsoft 365 authentication guide. Its signing controls do not activate the Recruiting Mailgun route.

DMARC reporting and maintenance

Retain any established policy. Where no policy exists, IT may approve a monitored p=none starting policy while inventorying all legitimate mail streams; it does not request rejection of spoofed mail. Do not enforce solely because Greenhouse passed one test. Current DMARC is RFC 9989; pct is obsolete and is not a reliable percentage rollout control. Aggregate reporting is specified separately in RFC 9990. Confirm external report-destination authorization and mailbox handling; failure reports can expose message information and need a privacy review under RFC 9991. DMARC, aggregate reporting, failure reporting

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4. First inspect the direct TXT policy at _dmarc.YOUR-FROM-DOMAIN and any applicable inherited policy. Only absent both, with owner-approved monitoring, an illustrative first TXT value is v=DMARC1; p=none. It requests no reports unless an authorized monitored rua destination is added. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.

Use EmailAuth's reporting workflow to distinguish the Greenhouse stream from corporate and sourcing mail, then investigate new failures before retiring old records. Keep old selectors until queued messages and other dependent routes no longer need them.

Review scope

No customer account configuration, DNS changes or real-message tests were performed. Validate the account-specific records and delivered-message evidence before treating your configuration as complete. Authentication does not guarantee delivery or inbox placement.