Recurly SPF, DKIM and DMARC setup, step by step

Recurly Subscriptions provides native Sender Authentication for sites that do not use their own paid SendGrid account. Open Email Templates → Sender Authentication, copy the DNS records issued for each sender domain, publish them at its authoritative DNS provider, and select Verify DNS. The current native example uses two DKIM CNAME records and a branded envelope-domain CNAME. It does not prescribe a universal SPF TXT record for your root domain.

Keep your intended From address unchanged. Completion means Recurly accepts the DNS configuration and a message sent through the intended Recurly path has a passing, aligned branded DKIM signature and a trusted dmarc=pass result. Inspect SPF separately, including its actual envelope domain and any errors.

This is a setup and validation guide, not a report of changes or test messages sent in your account.*

Contents

• Choose the correct Recurly sending route
• Before changing DNS
• Retrieve the records from Sender Authentication
• Publish the CNAME records at the correct owners
• Understand what the SPF record authenticates
• Preserve the applicable DMARC policy
• Verify DNS, then test the actual sending path
• Troubleshooting
• Frequently asked questions
• Sources and next steps

Choose the correct Recurly sending route

This walkthrough covers native Sender Authentication in Recurly Subscriptions, not Recurly Engage or Revenue Recognition.

Recurly says native authentication is required for all new sites without their own paid SendGrid account. Email Templates are available on all Recurly plans. Configuration privileges allow access to Email Templates and Site Settings; a Site Admin also has access. Obtain the necessary permissions rather than borrowing another person's account. Recurly: Email Templates, roles and permissions

The optional customer-owned SendGrid integration is a separate decision. It uses your own authenticated SendGrid account and an authorized API key configured in Recurly. Native Sender Authentication does not require you to create a paid SendGrid account, supply an API key, generate a private key, or upload a private key.

If a site already uses the optional integration, do not remove its credentials or switch delivery routes merely to make these instructions match its screen. Recurly documents that, after the own-account integration is saved, newly queued messages use that account while previously queued messages finish through the default route. A sample from an older queue may therefore represent a different path. Recurly: SendGrid integration

Before changing DNS

Inventory the From addresses that customers should see

Start with the site's default sender, then inspect individual Email Templates. Recurly permits template-level From-address and display-name overrides. Its Sender Authentication panel identifies an associated template by name or identifies the default sender as Default Sender.

The Billing Contact Email in Site Settings supplies the default From address and appears on receipts. Account-level or business-entity configuration may also affect the billing-contact information used in a particular workflow. Inventory the relevant variants in your account instead of assuming one domain covers every site, account and template. Recurly: Site Settings

Use a small test matrix:

Do not change a billing address customers recognize simply to obtain an easier authentication result. If the intended address cannot be authenticated through the chosen route, resolve that limitation with the domain owner and Recurly before sending.

Record the current DNS and ownership

Before editing, save the existing records at each proposed owner, the authoritative nameservers, current SPF policies, applicable DMARC policy, and active DKIM selectors. Identify other services sharing the domain.

Use the provider that hosts the authoritative DNS zone, which may differ from the registrar or website host. If the sender domain is a separately delegated child zone, work in that child zone. Adding records below a delegation in the parent's zone does not make them authoritative.

Do not replace parent nameservers, move a website, change MX records or remove an existing sender's records for this native CNAME setup. If an issued owner is already occupied, stop and establish which service depends on it.

For test delivery, use a valid, real mailbox under your control. Recurly treats recipient addresses at @test.com and @example.com as invalid. The reserved domains used below explain DNS names only; they are not test recipients. Check recipient and fallback billing-contact behavior before triggering a notification so it does not reach an unintended person.

Retrieve the records from Sender Authentication

1. Open Email Templates, then the Sender Authentication panel.
2. Locate the domain associated with the intended default sender or the relevant template's From address.
3. Copy every issued row's Type, Host and Value. Preserve the complete values and note each record's status.
4. Repeat for each distinct sender domain your test matrix requires.

The official panel example has two DKIM CNAMEs, one branded envelope CNAME, and a check of an applicable DMARC TXT record. The two DKIM owners end in ._domainkey beneath the sender domain; the envelope owner has an issued em-style label.

Those patterns explain the record roles. They are not account credentials or reusable records. The panel's selectors, envelope label and SendGrid tenant targets belong to that account. Copy your actual rows, not a screenshot's s1, s2, em2734, tenant identifier or target hostname.

The verified native instructions do not establish a separate Add Domain button. If the expected domain or panel is missing, check the actual default or template From configuration and your permissions, then obtain account-specific guidance from Recurly. Do not substitute a direct SendGrid setup screen.

Reusing authenticated senders across Recurly sites requires Recurly Support or your Customer Success Manager. A verified domain on one site is not proof that another site is ready to use it. Recurly: Sender Authentication

Publish the CNAME records at the correct owners

Translate a full Host into your DNS editor's format

Assume only for illustration that the sender domain is billing.example.com. These are name-mapping examples, not records to publish:

Replace each illustrative label with the exact Host from Recurly. If your DNS editor accepts fully qualified owner names, enter the full name instead. Do not supply the full name to a relative-only field and accidentally create ...example.com.example.com.

For every issued CNAME:

• Set Type to CNAME.
• Enter the correctly translated owner.
• Enter the exact issued target as a DNS hostname, not a URL. Do not add https://, a path, spaces or quotation marks. Follow the DNS editor's rules for a terminal dot.
• Use the provider's normal TTL or an approved change-window TTL.
• Keep the record DNS-only, not behind an HTTP proxy.
• Publish both DKIM records and the envelope record, not merely whichever row appears to pass first.

A CNAME owner cannot simultaneously hold an ordinary TXT, A, AAAA, MX or another conflicting record. Do not add SPF or DMARC TXT data at an issued CNAME owner. A conflict is a reason to investigate or obtain a different supported owner, not permission to delete an active service. DNS CNAME rules, RFC 1034

Check flattening as well as proxy status

Disabling an HTTP proxy is not always sufficient. If your DNS host flattens CNAMEs, inspect both per-record settings and any zone-wide “flatten all CNAMEs” setting. Provider verification may need the CNAME itself to remain publicly visible.

Some DNS services automatically flatten apex or same-zone aliases. A record-level switch may not override the zone-wide behavior. Do not relocate an issued authentication record to the apex or alter a shared zone's global setting without assessing effects on other records. If the required CNAME cannot remain visible, ask your DNS provider and Recurly for a supported solution. Cloudflare: CNAME flattening behavior

Understand what the SPF record authenticates

SPF evaluates the sending server against the domain used in the SMTP envelope, usually reported as smtp.mailfrom and reflected in the delivered Return-Path. That domain is not necessarily the visible From domain.

The native Recurly example supplies a branded envelope-domain CNAME. SendGrid's automated-security model uses DNS aliases so it can maintain the underlying authentication records. Follow the issued alias rather than inventing a root-domain TXT record such as include:recurly.com or copying an unrelated SendGrid SPF recipe. SendGrid: Domain Authentication

There are three practical consequences:

1. Adding an include to example.com will not repair SPF evaluated at an issued envelope domain beneath billing.example.com.
2. Adding a TXT record at the envelope CNAME owner creates a DNS conflict, not a second way to authorize delivery.
3. Passing SPF does not establish DMARC alignment unless its authenticated domain also aligns with the visible From domain under the applicable policy.

An envelope such as issued-envelope-label.billing.example.com and a From domain of billing.example.com can align in relaxed mode because they share an organizational domain. They are not equal, so that pair does not satisfy strict SPF alignment, aspf=s.

Recurly's native documentation does not establish a customer-editable custom Return-Path control. Do not assume the advanced controls in a customer-owned SendGrid account also exist in Recurly's native panel. If strict SPF alignment is a requirement, ask Recurly about a supported design. Do not casually weaken the DMARC policy or change the intended From address.

Preserve other SPF policies and diagnose SPF independently

Keep valid SPF policies for other senders at their existing owners. If a separately documented route requires an SPF change, edit the one policy at the domain that route actually evaluates. Do not create multiple v=spf1 records or replace a policy without retaining authorized senders and its intended terminal behavior.

SPF permits at most 10 DNS-lookup-causing terms across an evaluation, including nested include and redirect processing. The relevant terms include include, a, mx, ptr, exists and redirect; ip4, ip6 and all do not themselves consume that budget. This is not simply a count of TXT records or visible includes. SPF, RFC 7208

For native Recurly, inspect the evaluated envelope policy through the issued alias and escalate managed-target faults to Recurly. Do not edit a vendor-owned target or flatten its current IP addresses into your own permanent list. Investigate SPF fail, softfail, neutral, none, temperror or permerror even when aligned DKIM allows DMARC to pass.

Preserve the applicable DMARC policy

DMARC uses the domain in the visible From address. It passes when at least one valid SPF or DKIM result aligns under the applicable policy. For this branded-sender setup, require the intended Recurly DKIM signature to pass and align as well; a DMARC pass caused by a different mechanism is not proof that the intended signing configuration works.

Inspect the direct policy and any applicable inherited policy before publishing anything. For a From domain of billing.example.com, inspect _dmarc.billing.example.com and the applicable parent or organizational-domain policy, such as _dmarc.example.com. Account for the actual domain hierarchy and existing subdomain policy behavior, rather than assuming the last two labels always identify the organizational domain. DMARC, RFC 9989

Recurly's official screenshot checks a parent-domain DMARC record for a sender subdomain. Its example p=none is not an instruction to replace your organization's policy. Preserve existing p, subdomain policy, adkim, aspf, reporting destinations and other applicable settings.

A direct child policy can override inherited protection. Do not create one merely because there is no TXT record at the child owner.

Only when no applicable policy exists

If there is no existing direct or inherited applicable DMARC policy, the domain owner may choose a monitoring-only first policy. The minimum TXT value is:

v=DMARC1; p=none

Publish it only at the deliberately selected DMARC owner:

An editor that expects full owner names takes the full left-hand value instead. Use the DNS zone that is actually authoritative; do not add child records in the parent below an existing delegation. Publish only one DMARC policy at the selected owner.

This minimal value requests no reports and does not enforce quarantine or rejection. If aggregate reports are wanted, add an approved rua destination that is monitored. If the report destination has a different Organizational Domain from the policy domain, the report receiver must publish the required external-report authorization in its DNS. A destination within the same Organizational Domain does not need that external authorization. Verify any required authorization with the reporting service. External reporting authorization, RFC 9990 section 4

Reports can expose sending infrastructure, volumes and domain relationships. Restrict access, agree retention and avoid adding forensic-report destinations without a separate privacy assessment. Do not copy another organization's reporting address. DMARC aggregate reporting, RFC 9990

Verify DNS, then test the actual sending path

Gate 1: Public DNS matches the issued records

Check the authoritative answers and a public recursive resolver. The commands below use illustrative names; replace them with your real issued owners:

dig +noall +answer CNAME issued-selector-1._domainkey.billing.example.com
dig +noall +answer CNAME issued-selector-2._domainkey.billing.example.com
dig +noall +answer CNAME issued-envelope-label.billing.example.com
dig +noall +answer TXT _dmarc.billing.example.com
dig +noall +answer TXT _dmarc.example.com

Resolve each issued DKIM target to its public key and inspect the envelope alias's effective SPF response. Check for duplicate suffixes, missing target labels, conflicting records, wrong authority or DNS errors. Cached responses can lag a correct change, but waiting will not fix an incorrect owner.

Never expose or request a private signing key. The CNAMEs point toward public authentication data maintained for the sending service.

Gate 2: Recurly accepts the DNS

Return to the matching domain in Sender Authentication and select Verify DNS. Inspect every row and the domain's overall result.

Do not treat one verified DMARC row as acceptance of the DKIM and envelope rows. Conversely, a verified panel means the provider's DNS checks passed; it does not prove that every template uses the intended sender on a delivered message.

If the public records are correct but verification remains pending, give Recurly Support the site, sender domain, issued public records, verification time and relevant DNS answers. Do not share API keys, credentials, private keys or customer invoice content.

Gate 3: A real message proves the intended identity

Use an authorized test in a safe site or workflow with a real recipient you control. Preview checks rendering; Send Test Email, next to Preview, sends a message. Confirm whether that test exercises the same sender and transport as the notification being deployed. Where it does not, validate the actual notification path in a safe test configuration without charging a customer or starting a live collection action.

Repeat for materially different default and custom-From templates, relevant billing or dunning paths, and separate sites. Check that the template is enabled where required at the site and plan levels. The existence of a preview is not proof that an automated notification is enabled.

In the receiving mailbox's original message or trusted trace, record:

• The visible From address, exactly as customers should see it.
• The intended DKIM signature's d= signing domain and s= selector.
• A passing DKIM result for that signature, with alignment to the From domain under the actual adkim mode.
• The actual SMTP envelope domain and its SPF result, with alignment assessed under the actual aspf mode.
• A trusted dmarc=pass result for the unchanged From domain.

There may be more than one DKIM signature. A passing vendor-domain signature is not a substitute for the intended branded signature. Publishing two DKIM CNAMEs also does not mean every message must carry two DKIM signatures. Use the selector on the actual message to identify which published record was used.

Under strict DKIM alignment, the signing domain must equal the From domain. Under relaxed alignment, their organizational domains must match. Verify the actual signature instead of assuming the native configuration guarantees either result.

Trust the receiver, not any header with the right name

Use Authentication-Results added by the receiving system within its trusted boundary. An upstream sender can forge a header with that name, including a plausible authserv-id. Matching a server-name string alone does not make the result trustworthy.

The receiving infrastructure must remove or distinguish untrusted upstream results. If you cannot establish that boundary from the raw headers, use the mailbox provider's authenticated message details or an administrator's trusted trace. Authentication-Results, RFC 8601

A passing authentication result does not guarantee inbox placement. Receiver policy, filtering, reputation and message content remain separate. If Microsoft 365 handles a message differently from its authentication result, use EmailAuth's guide to inspecting Microsoft 365 inbound DMARC policy overrides and receiver decisions to investigate that receiving layer.

Troubleshooting

Keep a before-and-after DNS record and retain active selectors needed by other senders. Avoid using Remove in the authentication panel as a speculative reset. Any rollback should restore a known working configuration and consider queued messages and active notification paths.

Sources and next steps

The implementation authority is Recurly's current Sender Authentication documentation, supported by its Site Settings, permissions and separate SendGrid integration documentation. SendGrid's domain-authentication guide explains the managed CNAME model, not additional controls guaranteed in Recurly's native panel.

Keep the issued DNS rows, provider verification result and trusted received-message evidence together. Recheck the affected paths when you change a From address, template override, sending route, DNS host or site configuration. These checks establish the sender's authentication state; they do not promise a search ranking, inbox placement or a receiver's final disposition.