Accredible SPF, DKIM and DMARC setup, step by step

Accredible authentication depends on how you send. Its default delivery uses SendGrid with a provider-controlled Return-Path. If you use your own address in Sender Details on that route, start Sender Authentication with Accredible Support and publish the records supplied for your domain. If you enable SMTP Overrides, your chosen mail server becomes responsible for SPF and DKIM instead. Adding include:sendgrid.net everywhere is not a substitute for choosing and authenticating the correct route. Accredible delivery guidance, SMTP Overrides

This guide covers credential email sent through Accredible’s default service, branded Sender Authentication on that service, and the separately documented SMTP Override route. It does not assume a custom credential website domain, an email template or a display-name change authenticates an email domain.

No Accredible account, customer DNS or delivered-message test was performed for this guide.

Start by identifying your sending route

Accredible’s troubleshooting guide identifies support@credential.net as its default sender and explains that the default SendGrid Return-Path uses its domain. It directs customers using their own Sender Details address to support@accredible.com to begin Sender Authentication. Check your actual message rather than assuming every notification uses a default identity. Official route and sender guidance

Before changing DNS, record the intended From domain, Accredible department or workflow, existing sender settings, and whether an SMTP override is enabled. Confirm who controls the authoritative DNS zone. Export existing records and identify all other services using the same domain. Retain a recovery copy and a change owner.

Route A: authenticate your domain on Accredible’s delivery service

Request the correct record set

Contact Accredible Support to start Sender Authentication for the exact domain used by your intended From address. Include enough account and workflow context for Support to associate the configuration with the right sending service. Ask Support to confirm:

• The approved visible From domain and whether your account can use the requested configuration.
• Every record’s type, full DNS owner and value or target.
• Which records configure DKIM and which configure the envelope/bounce domain.
• The expected DKIM signing domain and selectors.
• The actual envelope domain, its alignment behavior and any region-specific values.
• How verification and activation are confirmed after you publish DNS.

The public Accredible article establishes the support-led entry point and links to SendGrid’s domain-authentication documentation. It does not publish universal customer-specific selectors or a separate Accredible activation button. Do not create a new independent SendGrid account and assume that its authenticated domain automatically configures Accredible’s sender. Accredible Sender Authentication

Understand the generated records without copying examples

SendGrid’s current documented automated-security example contains an envelope-related CNAME, two DKIM CNAMEs and a DMARC TXT suggestion. Its non-automated configuration instead uses an envelope-domain MX record and TXT values for SPF, DKIM and DMARC. Those are underlying service patterns, not proof of the exact record set Accredible will issue to your account. SendGrid’s generated-record tables

Treat the instructions returned by Accredible as the source of your actual account values. For each DKIM record, use the complete generated selector owner and corresponding target or public key. Do not substitute s1, s2, an account number or a regional hostname from another tenant’s screenshot. If a selector is already occupied, ask Support to coordinate an alternative rather than overwriting another sender.

If the issued signing domain is a child such as news.example.com, an illustrative full DKIM owner is ISSUED-SELECTOR._domainkey.news.example.com. A relative-name editor in the parent example.com zone needs ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone it needs ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone it needs only ISSUED-SELECTOR. Use the real issued selector, type and value, not these placeholders. Publish at the authoritative zone and preserve existing NS delegation rather than adding an inactive parent-zone copy. DKIM owner construction, relative DNS names.

Publish public DNS material only. No private signing key, SMTP credential or API secret belongs in a DNS record.

Publish, then obtain activation confirmation

1. Add the issued records at the authoritative DNS provider, keeping the supplied type and target intact.
2. Check whether the provider expects a short owner such as selector._domainkey or a full hostname. Avoid a duplicated domain suffix.
3. Check for existing data at every proposed CNAME owner. Do not delete an active TXT or CNAME record simply to make the new record fit.
4. Query the completed public records and compare them character for character with the issued set.
5. Return the results to Accredible Support through your approved support process and ask them to confirm verification and active signing for your domain and workflow.
6. Test a newly generated message through that workflow after activation.

A CNAME generally cannot coexist with other ordinary data at the same owner. If your DNS provider offers proxying or CNAME flattening, preserve the publicly visible CNAME required by the issued verification workflow; do not substitute web-proxy addresses. DNS alias rules, Cloudflare’s CNAME verification guidance

Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls.

Keep your existing mailbox MX records. If an issued non-automated setup includes an MX record, it belongs at the specified envelope subdomain, not automatically at the domain’s apex. Keep other senders’ DKIM selectors and verification records as well.

What SPF means for Accredible

SPF checks the connecting server using the SMTP MAIL FROM domain, normally reflected in the delivered Return-Path. It does not check the display name, Reply-To or visible From address. A null reverse-path uses the HELO identity. SPF identities

Accredible’s troubleshooting page lists include:sendgrid.net, but it also explains that its default delivery uses a provider-controlled Return-Path. These facts must be interpreted together. Adding SendGrid to example.com does not make SPF evaluate example.com if the message actually uses a provider’s envelope domain.

For branded Sender Authentication, use the issued envelope configuration and verify the resulting smtp.mailfrom identity. A generated CNAME can delegate the envelope domain’s authentication to the provider; do not add a redundant root SPF record by habit. For an SMTP override, use the actual relay provider’s authorization rather than assuming SendGrid still sends the message. Accredible delivery routes, SendGrid record variants

If the confirmed configuration requires a TXT SPF change at an owner you control:

• Preserve the other authorized senders in the existing policy.
• Publish only one record beginning v=spf1 at that owner.
• Add the approved mechanism before the terminal all; preserve its intended qualifier.
• Review any redirect= design before merging changes.
• Evaluate the full chain against SPF’s ten lookup-causing-term limit, including nested includes. Ten includes is not a safe shorthand for ten lookups.

Do not create +all, change a deliberate -all to ~all, or copy historical sending IPs to suppress an error. SPF evaluation and DNS limits

Route B: use SMTP Overrides without carrying over the wrong DNS assumptions

Accredible documents Emails > SMTP Overrides as the setup path: enter the target server’s information, save it and use Send Test Email to check the connection. The feature is not available on Free Trial accounts. For Microsoft OAuth, the guide links to a dedicated setup flow rather than treating every mailbox as a basic username/password connection. Current SMTP Override instructions

Before enabling an override, work with the mail administrator to establish the supported authentication method, TLS/port configuration, authorized sender addresses and sending limits. Accredible advises avoiding port 25 when another option is available. Do not weaken the mailbox provider’s security controls to make an old example work.

For email that actually leaves through the override server, Accredible states that previously configured Accredible SPF/DKIM settings no longer affect delivery. Your chosen server must authorize its outgoing infrastructure and sign with the intended domain. Preserve old records until you have checked for remaining service routes, queued mail and a possible rollback; switching routes is not permission to remove records used elsewhere.

Plan for the operational differences too:

• Accredible says it cannot accurately report bounce analytics for overridden delivery. Use the outbound provider’s logs and bounce handling.
• The guide says credential delivery emails on this route do not contain Accredible’s unsubscribe link. Ask your email administrator to implement the appropriate unsubscribe handling for the messages you send.
• Changed mailbox credentials must be updated in the override configuration where applicable.
• Mailbox-provider daily or other sending limits can cause large credential batches to fail. Confirm current limits and batch accordingly.

These are documented route-specific limitations, not problems SPF changes can fix. SMTP Override limitations

A successful connection test does not prove branded DKIM or DMARC alignment. Validate both the test and a representative credential notification through the intended route. If the target server is SendGrid, the separate SendGrid domain-authentication guide explains that provider’s configuration. If it is Workspace, use the Google Workspace authentication guide for its domain controls. Neither guide substitutes for Accredible’s sender selection.

Keep your DMARC policy and reporting safe

DMARC checks the visible From domain against an authenticated identity. Either an aligned SPF pass or an aligned DKIM pass is sufficient. SPF passing for a provider’s domain does not align with your branded From domain merely because the message came from an authorized service.

For DKIM, compare the passing signature’s d= domain with the From domain. Relaxed alignment allows the same organizational domain; strict adkim=s requires exact equality. SPF has its own independent aspf mode. For example, a bounce domain bounce.example.com can align with From example.com in relaxed mode but not strict mode. DMARC alignment and authentication

Inspect the actual From domain’s existing DMARC policy and any applicable parent policy. Preserve the domain owner’s enforcement, alignment and reporting decisions. Do not replace an established policy with a SendGrid sample or publish a second DMARC record.

For a newly monitored domain with no existing applicable policy to preserve, the owner might approve an illustrative TXT record at _dmarc.example.com such as:

For this owner-approved first policy only, map type TXT to the actual From domain. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses _dmarc.news.example.com: enter _dmarc.news relative to the parent zone, or _dmarc in a separately delegated news.example.com zone. Keep existing NS delegation and direct or inherited policy unchanged; a missing local record does not authorize a child override. DMARC record publication, relative DNS names.

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Use an approved reporting destination instead of the example address. p=none requests monitoring, not protection through DMARC quarantine/rejection and not a spam-filter bypass. Plan stronger enforcement only after assessing all legitimate sending routes. Do not add third-party rua recipients or failure-reporting ruf addresses without approving the data sharing. DMARC policy, aggregate reporting safeguards

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.

Validate DNS and the message that recipients receive

Check the exact published owners

Replace these placeholders with the records actually issued by Accredible or the override provider. These are examples for a later check, not tests already completed:

dig +short NS example.com
dig @ns1.example.net CNAME issued-owner.example.com +noall +answer
dig +short CNAME issued-owner.example.com
dig +short TXT selector._domainkey.example.com
dig +short TXT envelope.example.com
dig +short TXT _dmarc.example.com

Query every issued CNAME and follow its target when checking the final TXT data. If the issued configuration uses a DKIM TXT record directly, query that owner instead. For the non-automated envelope configuration, also query its issued MX owner:

dig @ns1.example.net MX envelope.example.com +noall +answer
dig +short MX envelope.example.com

Compare the exact MX owner, priority and target with the values supplied for your account. Accept this branch only when the required MX and SPF TXT records resolve at that envelope owner; do not mistake the main mailbox domain’s MX answer for the envelope-subdomain result. Compare authoritative and recursive results after relevant TTLs expire. Validate the actual envelope domain’s SPF, not automatically the visible From domain’s apex.

DNS can prove a record is present; it cannot prove Accredible selected that domain or that the outbound server signed with its key.

Accept the intended branded signature, not any green result

After setup is approved and activated, generate a representative credential message to a controlled external recipient. Test each relevant department, sender configuration and sending route. A message sent manually from your employee inbox does not establish that Accredible uses the same path.

Open the full headers in the receiving mailbox. Use the Authentication-Results added by the receiving system you trust; copied upstream fields can be forged. Record the From domain, Return-Path, smtp.mailfrom, DKIM d= and s=, and the SPF, DKIM and DMARC outcomes. Authentication-Results trust model

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.

For branded sending, require:

1. The intended From domain on the message.
2. The intended branded DKIM signature reporting dkim=pass, with its signing domain aligned under the applicable adkim mode.
3. The expected SPF identity, with its authentication result and aspf alignment assessed separately.
4. A trusted dmarc=pass for the intended From domain.

An SPF-only DMARC pass is not sufficient evidence that the branded DKIM setup succeeded. A provider-domain DKIM pass is not proof of branded alignment. Conversely, an aligned DKIM pass does not excuse an SPF error: investigate fail, softfail, permerror and temperror independently.

Troubleshoot by route and authentication result

Keep the original DNS and configuration snapshots. Coordinate a rollback with Support and your mail administrator, changing only the affected route. Do not weaken DMARC for every sender to conceal one route’s failure.